mandag 16. mai 2011

Dekker du opp for andres inkompetanse?


Som sjef er det tidvis deilig å oppdage andres inkompetanse! Man er jo blitt sjef så man kan øse av sin erfaring for å få denne skeive skuta på rett kjøl! Men gleden er kun til stede når inkompetansen er plassert hos underleverandører eller eventuelle avdelinger som jobber for deg og din enhet. Som styrende myndighet har du da muligheten til å få strammet opp underleverandøren gjennom bruk av gulrot eller pisk. Frustrasjonen blir derimot stor dersom inkompetansen er plassert hos din oppdragsgiver!

På Smidig 2009 konferansen var jeg innom en gruppe som frustrert diskuterte produkteierrollen. Noe overraskende var det alle andre enn produkteieren som deltok i dette terapiforumet. Utviklere, testere og driftspersoner var enig i at styrking av produkteierrollen kunne revolusjonere effektiviteten til utviklingsteamene, men man hadde ingen forslag til hvordan dette kunne gjøres.

Produkteieren sitter på toppen av utviklingsverdikjeden, og bestemmer hva som skal lages til hvilken tid. Produkteieren har all makt over de tre viktigste rammene for et prosjekt, Ressurser, Omfang og Tidsplan. Den siste faktoren, kvalitet, er ofte utviklerstyrt.


Den vanligste problemstillingen er en salgsdrevet produkteier som styrer prosjektene etter hvor mange salgbare funksjoner som blir utviklet. Arkitektur, drift og endringsdyktighet er faktorer som sjelden kommer fram under salgssamtalen med kundene, og blir derfor aldri prioritert. Utvikleren som blir presset på tid, og som ser på seg selv som en servicefunksjon for produktsjefen, vil alltid forsøke å tilfredsstille produkteieren gjennom ivrig jobbing og kjappe leveranser. Kvalitetsaspektet blir glemt, og man vil levere en løsning med svak kvalitet. Dette er bra så lenge problemet med kvalitetsmangelen blir plassert der det hører hjemme, hos produkteieren. På 90 tallet var jeg selv vitne til en av de største lanseringene fra Telenor Nextel gikk dunken etter kun få uker: En webshopplattform som var mer nede enn oppe. Flere hundre kunder i Colosseum Kino observerte en livedemo som ikke fungerte, og deretter gikk det bare nedover. I etterkant av denne fiaskolanseringen endret produktavdelingen sin policy fra brekkjernstrategi (selge produktet basert på foilware, og presse utviklerne til å lansere før ferdigstillelse), til å få inn kunder etter man hadde satt opp en fungerende prototype. Produkt så konsekvensen av egne handlinger, og tok til seg læring.

Problemet dukker opp i enheter hvor IT i det skjulte forsøker å dekke opp for produkteierens manglende bevissthet rundt kvalitetsutvikling. IT vil forsøke å lage en skalerbar og stabil plattform som raskt kan tilpasse seg eventuelle krumspring fra oppdragsgiver, uten å ha ressurser til dette. Fra en produkteiers ståsted har en slik IT avdeling følgende karakteristika:

  • De reduserer innovasjonsgraden gjennom å jobbe med sine egne prosjekter som ikke gir nye inntekter 
  • De er treige til å utvikle nye løsninger, og vil alltid krangle på lanseringsdatoer 
  • I etterkant viser det seg at løsningene de har utviklet er ustabile 
  • Tidvis bruker de lang til på å utvikle nye løsninger, og tidvis bruker de kort tid: Umulig å bli kloke på 

Selv om IT oppfatter seg som selskapets redningsmann/kvinne, blir de av produkteier og ledelsen oppfattet som problemet.

Hos enkelte selskaper går dette så langt at IT får all makt, og produkteieren er redusert til en som kommer med gode tips på hvilken retning man bør gå i. Med teknologi og plattformkåte ingeniører i front, vil selskapet sitte igjen med en dobbeltarmert state-of-the-art løsning kundene ikke er interessert i.

Løsningen som jeg ofte foreslår er en Produkteier som ikke bare tar ansvar for funksjonaliteten, men også for brukerbehovet og driftsstabiliteten. Dette krever en produkteier som har mer enn salgserfaring, gjerne understøttet av et team. IT må slutte med utvikling i det skjulte, og kun jobbe på oppdrag av produkteier. Man bør stoppe med omfattende teknologiprosjekter som ikke leverer forretningsverdi, og lære seg hvordan man utvikler smidig arkitektur som tilpasser seg virkeligheten. IT må dermed lære seg å synliggjøre hvilke langsiktige forretningsmessige konsekvenser produkteierens valg har, så produkteieren lærer av egne handlinger. For kundene er tross alt det viktigste at løsningen fungerer!

PS: Salgsdrevet produkteier er i henhold til Clayton Christensen en meget dårlig ide, men dette kan bli viet mer oppmerksomhet i en senere artikkel.

torsdag 5. mai 2011