mandag 15. november 2010

Effektive utviklingsavdelinger!


Hva gjør en utviklingsavdeling eller IT prosjekt effektiv? Tradisjonelt defineres produktivitet til “The amount of output per unit of input (labor, equipment and capital)”. På norsk kan vi si at effektiviteten defineres som produserte produkter delt på antall dagsverk. For et IT-prosjekt vil mange definere produktiviteten som:
  • antall funksjoner/antall utviklerdagsverk
Jeg har lyst til å utfordre denne definisjonen for kunnskapsbedrifter, da funksjoner som ikke blir benyttet neppe kan regnes som en verdi. Undersøkelser viser at 40% av løsningen utviklet på tradisjonelt vis aldri blir benyttet av kundene, og 20% blir benyttet i meget liten grad. Vi kan derfor definere 50% av funksjonene som unødvendige! Det bør være unødvendig å si at unødvendige funksjoner er... unødvendig!

I henhold til Gartner så vil den totale utviklingskostnaden kun være 9% av et produkts totale livssykluskostnad. Å benytte utviklede funksjoner / utviklingskostnaden er derfor en meningsløs effektivitetsparameter da man regner på kun noen få prosenter av de reelle kostnadene. Faktisk vil dette bety at dataprosjekter ikke ser sin effektivitetsgrad først etter flere års drift (når vi ser hvor mange som bruker de ulike funksjonene, og hvor stabile de utviklede løsningene er). Effektiviteten til et utviklingsprosjekt blir derfor:
  • Kundebenyttede funksjoner / (Utvikling + driftskostnad)
Dette krever at vi kjenner driftskostnaden til de ulike funksjonene, noe som veldig få gjør. Dessverre vil en slik definisjon være lite nyttig siden vi ikke får svaret før etter flere års drift. Kan det være årsaken til at de fleste offentlige og private bedrifter ignorerer de største effektivitetsparameterne: Driftskostnaden og om en funksjon blir benyttet? Målbart eller ei, noe av det mest effektive tiltaket vi kan gjøre er å utvikle løsninger som er rimelig å drifte (da driftskostnaden er 91% av den totale funksjonskostnaden).

 Det vil si at de mest effektive kunnskapsorganisasjoner har følgende egenskaper:
  • De lager funksjoner som folk har nytte av. For å lykkes med dette lever selskapene tett med sine kunder, og er veldig utadrettet i sin væremåte. De bryr seg i mindre grad om interne prosesser. De mest ekstreme selskapene lar kundene utvikle funksjonene selv (crowdsourcing)
  • De som utvikler kjenner godt til produksjonsprosessen, og lager høykvalitetsløsninger som er lett å drifte. Store deler av verdikjeden er automatisert, og testrutiner gjensomsyrer kulturen. Oppdragsgiver er veldig opptatt av kvalitet fremfor kvantitet.

Effektivitet handler altså ikke om hvor effektiv man er til å utvikle, hvor mye overtid man jobber eller hvor lange kravspesifikasjoner man har skrevet. Faktisk er det så at redusert arbeidstid kan bedre effektiviteten, da en opplagt utviklerhjerne lager færre feil enn en sliten. Lager man noe som en kunde ikke vil benytte drar man helt unødvendig med seg kostnaden på det nyutviklede systemet i hele produktets levetid.

Min erfaring er at handovers mellom avdelinger og manglende kommunikasjon og samarbeid fører til redusert effektivitet da kvaliteten forringes og kunnskapen om kundene ikke flyter rundt omkring i organisasjonen. Faktisk er de fleste selskaper organisert slik at kunnskapsflyt og samarbeid blir vanskelig, godt hjulpet av oppdragsgivere som har liten kunnskap og interesse om utvikling og driftsverdikjeder. Resultatet er overfokusering på utviklereffektivitet som igjen fører til dårlig kvalitet på det som er utviklet, og utvikling av funksjoner som ikke blir benyttet av kundene.

Ingen kommentarer:

Legg inn en kommentar