Paralleller mellan byggprojekt och IT-projekt
I boken Användarcentrerad systemdesign (sidan 59) finns ett bra exempel som ställer byggprojekt i kontrast med IT-projekt med avseende på beställarkompetens och genomförande. Detta är ett bra exempel som med ett praktiskt exempel illustrerar problematiken i olika IT-projekt.
Byggprojekt
En bostadsföreningen vill göra en renovering och tillbyggnad. I det här fallet är det mycket ovanligt att de boende är experter på hur man bedriver ett byggprojekt, de har helt enkelt inte den sortens kompetens som krävs. Detta medför att en konsult, t.ex. en arkitekt eller en byggnadsingenjör, tas in och hjälper till att etablera det fortsatta arbetet. Under renoveringsprojektets gång följer ofta konsulten med och agerar kontrollant gentemot leverantören. Beställaren håller inne med slutbetalningen i väntan på att båda sidorna är eniga att hela beställningen slutförts.
IT-Projekt
Det är inte ovanligt att beställaren inte inser sin bristande kompetens och behovet av att ta in en expert för att hjälpa till med kravarbetet. Istället försöker man själv skapa en kravspecifikation. När sedan systemet levererats är det snarare en regel än undantag att det inte motsvarar kundens förväntningar.
Kontentan av det hela är att det i fler IT-projekt borde finnas ett sammarbete med experter/konsulter som hjälper till med t.ex. etableringen av en kravspecifikation och vidare även kontroll. Detta skulle med stor sannolikhet förbättra resultaten och skapa den förväntade nyttan för både beställaren och användarna.
Håller definitivt med. Frågan är hur väl detta fortfarande gäller i många utvecklingsföretag nu mer då Agila metoder har börjat ploppa upp som “det nya”.
Dessa har ju just som mål att just brygga problemet med att kunden inte får precis det som den hade tänkt sig.
Vet nu inte hur marknaden ser ut om stora delar har gått över till Agila metoder eller om många fortfarande kör med UCD stuket.
Skrevs 24 April, 2008
ett alternativ är ju att leverera inkrement av systemet, så att kunden får kika på grejerna och komma med åsikter allt eftersom utvecklingen fortskrider. att jobba agilt med andra ord.
Skrevs 25 April, 2008
I Australien är det i alla fall tydligen vanligare att jobba mer agilt och leverera i delar. Vi läser en kurs som heter Software Engineering där vår professor är en stor fan av den metoden. Han brukar alltid jämföra ett IT-projekt med att bygga ett hus och påpekar minst en gång per föreläsning att utveckling av mjukvara bara är en del av software engineering.
Jag brukar själv försöka uppdatera mina kunder flera gånger under den tiden då jag jobbar, så att de kan tycka till och säga till i god tid vad de vill ändra. Å andra sidan så driver jag troligtvis ganska små projekt jämförelsevis.
Skrevs 28 May, 2008
De i Australien verkar vettiga måste jag säga ;)
Skrevs 28 May, 2008
Hej
Jag tror det finns behov av att identifiera mognaden hos användarna och planera införandet beroende på det. Tänk i flera steg, istället för att tro att man kan sikt på målet direkt. Under resans gång kommer många bra idéer att komma upp och vinsten blir större eftersom det är svårt att föreställa sig hur användningen kommer att bli och vad som accepteras av användarna.
När det gäller byggande finns en byggstandard som man började utveckla på 1920-talet och som vi fortfarande förbättrar. Det är ett regelverk som heter AMA och som innehåller beskrivningar och regler för hur man normalt gör. Det billigaste och säkraste är då att använda standard.
Kan vi tänka oss motsvarande för IT-system?
Fördelen är att beställaren får jämförbara anbud och det är priset som är avgörande.
Nu har ju byggbranschen dåligt rykte vad gäller ansvar och kvalitet. Kanske är det en variant av det vi ser för IT-branschen när man generaliserar att It-projekt “inte går att styra”.
Skrevs 16 February, 2009