
<<åter
Dålig kunskap kvaddar
stora projekt
(Lars Danielsson,
ComputerSweden 2002)
Flera konsulter som
Computer Sweden talat med ser bristen på kunskap om den dominerande
utvecklingsmetoden Rup som ett problem. De stämmer också in i ett fördömande
av stora projekt.
Rapporterna om stora
misslyckade projekt har varit vanliga under senare år. Många av projekten
har drivits av myndigheter och i ett flertal fall har Rationals
utvecklingsmetod Rup använts, till exempel i RFVs projekt som dragit över
budget med hundratals miljoner kronor.
- Det är inte fel på Rup, tvärtom, jag uppskattar verkligen Rup. Problemet
är att det ibland drivs stora projekt där endast ett fåtal av de inblandade
kan använda Rup, säger Oscar Nyströmer, projektledare på Arete.
Han säger vidare att det är viktigt är att alla kan den metod som används,
samt att projekten drivs av erfarna projektledare. Dessutom anser han att
stora projekt ofta blir svåra att överblicka.
Stort är farligt
Søren Ravnskov, vd på Astrakan strategisk utbildning, har lång erfarenhet
både som utvecklare och projektledare. Han håller med Oscar Nyströmer.
- Ju större projekt, desto större risk att det misslyckas. Om projekt når en
viss gräns vad gäller storlek misslyckas de alltid, säger Søren Ravnskov.
Inte heller han vill peka ut Rup som skurken i dramat. Han anser också att
det är dålig kunskap om Rup som orsakar problem i projekt.
- Det finns inte så många duktiga Rup-konsulter. Det räcker inte med en
certifiering.
Han säger vidare att det finns en övertro på metoder, vilket orsakar problem
i projekt. Anders Torelm, vd på Rational i Sverige, håller med om att
bristen på kompetens om Rup är ett problem.
- Vi försöker förändra situationen med böcker, utbildning och certifiering.
Certifiering är inget kvitto i sig, men ett steg på vägen. Det krävs
praktisk erfarenhet för att få certifiering, till exempel fem år för nå
certifieringsnivån Principal Consultant
Han påpekar att ett av problemen är att det ibland brister i
kunskapsöverföring från konsulter till företags egen personal. När ett
projekt är klart försvinner konsulterna utan att ha överfört kunskap om Rup.
För stor kostym
Dan Johnsson som ansvarar för forskning och utveckling på Frobozz påpekar
att Rup är extremt konfigurerbart, till exempel vad gäller mängden dokument
som ska skapas under ett projekts gång. Det är svårt att hitta en balans
mellan formalia och viktig information.
- Rup inbjuder till en för stor kostym. Många dokument kan ge en falsk
känsla av trygghet. Dokument är bra, att prata är bättre, säger Dan
Johnsson.
Han anser inte att en metod som Rup behövs i små projekt, med mellan 10 och
20 utvecklare. Däremot behövs en sådan kanske i ett projekt med mellan 100
och 200 utvecklare.
David Byers är vd för XP Tools som arbetar med utvecklingsmetoden extreme
programming, xp. Denna metod brukar ibland beskrivas som rena motsatsen till
Rup, men David Byers håller inte med.
- Rup är ett ramverk och det går antagligen att formulera xp som en instans
av det ramverket. Det går att göra bort sig med både xp och Rup, säger han.
Standard-Rup eller inte?
Enligt David Byers är ett av problemen med Rup att det finns en övertro på
metoden i dess standardutförande. Han anser att alla metoder, även
lättviktsmetoder som xp, måste anpassas till de projekt och organisationer
som de ska användas i.
Anders Torelm på Rational tycker inte att det är lika viktigt med anpassning
av Rup.
- Det är däremot viktigt att välja vilka delar av Rup man ska använda och
koncentrera sig på dem.
Ett vanligt problem med stora projekt är, enligt David Byers, att de
inblandade inte vet vad de vill ha från början, att de har oklara mål som är
orealistiska. Han påpekar att anledningen till att misslyckade projekt ofta
drivs med tunga metoder helt enkelt är att lättviktsmetoderna inte har
börjat användas i dessa sammanhang ännu.
- När lättviktsmetoderna blir accepterade tror jag att vi kommer att se
misslyckanden med dem också. Det är först då som vi verkligen kan bedöma hur
bra de fungerar.
* Kommentar - Det är konsulternas fel, (Conny
Leinstedt, ComputerSweden 2002)
<<åter
