Slik får du gode resultater fra ditt utviklingsarbeid

Skrevet av: hussam

Hussam er senior Coach og instruktør med 3 årtier bak seg i den globale IT industrien. Han har bidratt til banebrytende teknologiske nyvinninger både hos store og mindre selskaper i verden. Hussam hjelper bedrifter med å skape forretningsverdi ved å orkestrere team, få folk til å jobbe sammen mot felles mål og redusere sløsing og forsinkelser.

08.10.2014

Mange organiserer seg i funksjonelle team eller komponentbaserte team. Utgangspunktet er jo bra. Man vil gjerne spisse kompetansen slik at folk yter enda bedre og kvaliteten høynes. Dette er begrunnet i at man blir bedre hvis man har fokuset sitt på færre områder. Resultatet i utviklingsavdelingene ble til at noen utviklere spesialiserte seg på back end, noen på Front End og noen hadde database som sin aller helligste osv. Videre introduserte man testing som eget fag i IT bransjen med samme argument; Kvaliteten skal opp. Testerne satt og ventet på at utviklerne var ferdig så tok de over. Utvikleren forlangte god spesifikasjon før man starter utviklingen. Alle har jo rett i sine argumenter. Men alle overså at det de drev med var egentlig suboptimalisering og at totalen ble ikke optimal likevel.

 

Man har glemt at kunnskap forsvinner underveis ved overlevering fra person til person og fra faggruppe til neste faggruppe. Vi vet jo alle at det er umulig å dokumentere alt. Dvs at en del informasjon vil bli igjen hos den enkelte ved en overlevering. Et forsiktig estimat på dette er 50% (søk etter «tacit knowledge» for å lese mer om dette).

I et typisk norsk utviklingsselskap vil prosessen foregå som følger:

  • Kunden snakker med en prosjektleder eller business analyst (første overlevering)
  • Business analysten setter opp kravspesifikasjonen og leverer videre til utviklere (andre overlevering)
  • Utviklerne skriver kode og eventuelt deler opp denne mellom to team: back end og Front end (tredje og eventuelt fjerde overlevering)
  • Deretter sendes ferdig implementert kode til testing (femte overlevering)

Hvis vi mister 50% kunnskap under hver overlevering så betyr dette følgende

  • Business analysten får med seg 50% av kunnskapen inn i prosjektet
  • Backend utviklerne får 25%, front end utviklerne får 12,5 %
  • Testerne får 6% av den nødvendige kunnskapen for å sikre at systemene fungere slik de skal.

Er det rart da at vi har så mye feil og mangler i IT systemene?

 

Løsningen på dette er:

  • Reduser antall overleveringer for å beholde mest mulig av kunnskapen
  • Gå vekk fra å overlevere dokumenter til å holde workshops, gjerne face to face der man diskutere funksjonalitet over en protype, mockups eller lignende
  • Sette opp kryssfunksjonelle team der alle roller er til stede og får den samme infoen.
  • Sørg fro at kravstilleren/kunden får mulighet til å komme med tilbakemelding så tidlig som mulig og så ofte som mulig. Dvs hyppige releaser og nært samarbeid med kunden.

Prøv dette selv i ditt eget team. Trenger du hjelp til å implementere eller diskutere dette videre, er du velkommen til å ta kontakt med oss!

Anbefalt viderelesing…

0 kommentarer

Send inn en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

− 3 = 2