Forside » Klean weblog - om bedre websites » Når hele systemet er halvt færdigt

Når hele systemet er halvt færdigt

Hvad gør man, når et projektet er kommet i problemer, og der er flere opgaver end tiden tillader?

Vi arbejder i øjeblikket med et par projekter, der af forskellige årsager er kommet lidt i stormvejr.

Det sker ofte i it-projekter. Ofte er det bare sådan, at man synes, de andre ikke skal vide noget om det. De andre = kunderne.

Det gode ved scrum er, at man ikke kan holde det hemmeligt. Det er virkelig en fordel. Hvorfor det?

  • Sammen kan man reagere på situationen. Et team af udviklere vil nogle gange tro, at de "kan indhente det til sidst", men de fleste projektplaner er optimistiske fra starten. Det er derfor, man altid har travlt inden deadline.
  • Måske kan man aflevere hurtigere. Man kan indføre en tidligere fase med en mindre aflevering først. Så er der mere tid og ro til at aflevere resten bagefter. I scrum arbejder man jo hele tiden med små, afgrænsede afleveringer, så derfor er produktet altid tættere på 100% god kvalitet.

Det er selvfølgelig ikke let, men man kan starte med at vælge fra.

En god metode er at se hele projektet igennem. Der mangler måske 150 opgaver før "det er færdigt". Okay, så vælg 100 fra. "Hvilke 50 opgaver vil du helst have løst?"

Arbejdet har det med at udvide sig, så 50 opgaver tager sikkert den tid, der var estimatet for 75.

Man kan halvere arbejdstiden til første aflevering ved at skære 2/3 i projektet. Ikke noget man består en matematik-eksamen med, men det virker i praksis.

Hvis man ikke gør det, har man også valgt:
Man har valgt at få et helt system, der er halvt færdigt.

I vores projekter har vi skåret hårdt, og det er svært. Vi har, synes jeg, fundet gode løsninger, og vi afleverer i fornuftig tid inden deadline. Der er skåret nogle features, men kernen er sund.

Resten kan vi levere bagefter, og for brugerne er det nogle gange en fordel at få systemet i mindre afleveringer. Det gør det lettere at lære, at det hele ikke kommer på samme tid.

 
 
 

Kommentarer: 5

Det er god logik og godt beskrevet af jer. Jeg tror, at vi kommer til at se flere mindre og “agile” digitale markedsføringstiltag i stedet for den store færdige digitale klods der forventes at holde de næste 4 år. Start med kernen af det forhold virksomheden ønsker til kunden og byg så videre på at forstærke den over tid. Der skal også være plads til at verden forandre sig og at virksomheden kan lære.

Skrevet af Kasper Kristensen 10. februar, 2010 kl. 23:33

Hvordan har I skruet det sammen, så kunderne ikke står og siger, “jamen, vi skal have 100%, det aftale vi jo”?

Er det et spørgsmål om kontrakten, forventnings-styring, kritisk valg af kunder, eller noget helt andet?

Skrevet af Jakob S 11. februar, 2010 kl. 14:43

Ja, det er det faktisk. Hvis du nu spørger din vvs-mand om, hvad det koster at få skiftet dine vandrør, så har han to forslag:

- Du kan betale for den tid, det koster – Han kan give dig en fast pris.

Han er god til at fortælle dig, at hvis det er til fast pris, så bliver det dyrest for dig, for han er nødt til at dække sin risiko af.

Det var i hvert fald, hvad min egen vvs-mand sagde til mig. ;-)

Argumentet er jo til at forstå, så hvis vi oversætter til scrum:

1. Vi laver projekter til fast pris og deadline.

2. Kunden indtræder som produktejer og har ret til helt uden problemer at skifte mening undervejs. Man må gerne blive klogere, og der er også mulighed for at reagere på at omverdenen forandrer sig.

3. I budgettet er der indregnet typisk 20 til 40% margin til retningsskifte, nye krav og den slags.

Ligesom vvs-manden har vi stor rutine i at bedømme en opgave, så det er vores professionelle skøn i starten af projektet, der skal lægge en korrekt ramme.

Alligevel kan man blive ramt af sygdom, uventede problemer og alt andet. Murphy har ikke levet forgæves.

Når det sker, kan man sammen med kunden finde den bedst mulige løsning.

Hvis aftalen er at lave to afleveringer, så bliver projektet jo alligevel 100% færdigt, men der er to deadlines.

Det er ikke sikkert at alle er glade ved den løsning, men alternativet er værre. Jeg tror også at alle er realistiske omkring komplekse projekter og ved, at der er en vis risiko. Vores opgave er at minimere risikoen hvor man kan, men det er naturligvis ikke altid det lykkes.

Undskyld det lange svar – håber du var med til sidste linie.

Skrevet af Martin Frederiksen 11. februar, 2010 kl. 15:54

Det er super med langt svar, tak for det :) Sat lidt på spidsen lyder det til, at det, der kræves for at have success med fast-pris projekter er:

  • Evnen til at estimere nøjagtigt
  • Kunder, der er fleksible, når estimatet er forkert.

Estimeringen er helt sikkert noget jeg – og sikkert mange andre – kan arbejde på og blive bedre til.

Det med kunderne er nok sværere, men er vel langt hen af vejen et spørgsmål om at uddanne dem før projektet rigtigt kommer igang.

Man kunne fx – jeg ved ikke – blogge og skrive en bog om måden man arbejder på? :P

Skrevet af Jakob S 12. februar, 2010 kl. 14:41

Både ja og nej. En almindelig fejl i agile projekter er at estimere alle opgaver og tro summen er korrekt.

Man er nødt til at lægge en faktor oveni. For webprojekter er det min erfaring at der er tale om 20 til 40%.

Det beløb dækker opgaver, der er glemt. Det dækker også at kunden kan være agil. Hvad skal man bruge en agil model til, hvis budgettet alligevel er låst.

Åbenhed om alt – også ting der fejler totalt – er nødvendigt for at kunderne ved, at vi ikke er troldmænd. Efaring med gode og dårlige estimater kan kunderne bruge til deres egen risikovurdering.

Alle vores kunder har været involveret i andre it-projekter, der gik galt. Når processen ikke er transparent ved man det bare først den dag, man tror det nye site skal åbne.

Skal der endelig være panik, så lad det ske i god tid. “Fail Early”.

Det med bogen lyder i øvrigt som en god idé. Den tror jeg, vi planker!

Skrevet af Martin Frederiksen 12. februar, 2010 kl. 22:45

Skriv din kommentar...

Kommentar:

Navn:

E-mail:

Hjemmeside:

1. Tryk Preview for at gennemse din kommentar.
2. Tryk herefter Gem for at publicere den.