En programmerers evolusjon – Produktutvikleren.
“Hvordan kan du levere et godt produkt om du ikke bryr deg om å forstå kundens opplevelse? Kunden selv har aldri bygget kjøkken før. Det har du.”
Siden EDB kom til verden hvor vi måtte lære oss å programmere “bits & bytes” og frem til i dag, har både kravet og egenskapene til den moderne programmereren endret seg. Fra barneårene med prøving og feiling, gjennom tenårene i kjelleren, til en voksen person som er likestilt med andre voksne jobber. Dessverre har ikke alle den samme forståelsen av hva en programmerer kan og bør gjøre. Noen programmerere er fortsatt mentalt i kjelleren og bør komme seg opp og få litt lys og oversikt. Noen ledere ser fortsatt på programmereren som “hodet” som trenger å bli fortalt hva som skal gjøres.
Programmereren har aldri vært opptatt av penger og makt (det er alltid noen unntak selvfølgelig…). Indre drivkraft har vært å løse analytiske utfordringer og få datamaskinen til å gjøre ting – gjerne nyttige ting. Man har vært opptatt av å lage, leke og lære.
Med Internett ble det raskt et behov å forstå forretning og kommunikasjon også, i tillegg til selve teknologien. Flere fagområder ble tatt inn på teamet i utviklingen av IT-systemer. Programmereren ble etterhvert degradert og plassert stillesittende i et hjørne. Flere og flere lærte seg å programmere og gjorde kompetansen tilgjengelig blant mange – ihvertfall på papiret. Håndverket er programmering. Noen kaller dem hoder, kodere eller utviklere. Og da kommer raskt assosiasjonen til nerdene som sitter nede i en mørk kjeller. Code monkeys. Gi dem dem nok bananer og la dem være i fred.
Jeg mener at alle programmerere, og prosjektdeltagere forsåvidt, kan bidra i mye større grad om vi klarer aktivisere hele mennesket i oss og fremprovosere den kollektive kunnskapen. Da vil vi ta de klokeste beslutningene. Da kan vi etterhvert også få ned størrelsen på teamene og en mye mer effektiv kommunikasjon og beslutningeprosess i utviklingen av produktet. Det krever at vi forstår programmeringens moderne rolle.
Må forstå brukereffekten
Nå som “alle” kan lage sine egne programmer og app´er, og gjøre de tilgjengelige for alle, så er utfordringen en helt annen. I mange tilfeller så vet man ikke hvem brukeren er og hva de egentlig ønsker seg. I større grad enn før er det ekstrem usikkerhet knyttet til hva som er den beste løsningen. Brukbarhetseksperten blir inhabil og brukeren selv vet sjelden hvilke muligheter som finnes. Svaret finnes et sted i mellom (mer om dette i artikkelen “The User Feedback Problem” av Anders Haugeto). Og for å finne svaret trenger vi i dag det vi hos oss kaller Produktutvikleren som både evner og ønsker å forstå helheten.
En forblåst høstdag i oktober 2006…
Scrum Master: – Vi har nå fire måneder på å implementere den nye selvbetjeningsløsningen. Den skal produksjonsettes 15. februar 2007.
Produkteier: – Vi har nå skrevet om kravspesifikasjonen til brukerhistorier, som jeg har prioritert i en såkalt backlogg.
Scrum Master: – Vi har fått laget alle skjermbilder og knyttet dem til brukerhistoriene. Så da er det bare å gyve løs på oppgavene!
Programmererne: OK, vi kan klare 3-4 brukerhistorier til demonstrasjonen om to uker.
Programmereren er navet
I dag er produktutvikleren på full fart tilbake som sentral midtbanespiller på laget. Det nytter ikke lenger å ha masse eksperter og teoretikere som bare synser. Synsingen må testes ut i produksjon raskt. Det er produktutvikleren som må programmere og sørge for å kunne legge ut ny kode raskt for å verifisere hypotesene om hva som er riktig løsning. Produktutvikleren må kunne logge, analysere og ha et forhold til hvilken effekt endringer har på brukeren. Og som i gamle dager på samlebåndet hos Toyota, er det produktutvikleren som må stoppe båndet, når noe er feil og utbedre dette. Gjerne i samarbeid med andre fagfelt. Produktutvikleren må være en innovatør (mer om dette i bloggartikkelen; Developer´s DNA). Men, ingen andre fagfelt vil noen gang kunne være en like effektiv erstatning.
…en kald og klar vinterdag i 2012…
Produkteier: – Ledelsen ønsker at vi fokuserer mer på å skape lojale brukere
Programmerer 1: – Hvordan kan vi vite om brukerne våre er mer lojale?
Produkteier: – Det er vår første oppgave å finne ut av. Vi skal definere en måleparameter som skal gi oss en indikasjon på lojalitet
Programmerer 2: – Jeg kan finne ut hvor mange som har besøkt oss mer enn en gang. Hvis brukeren kommer tilbake så er vel det tegn på lojalitet? Eller hva UX?
UX: – Jo, men erfaringsvis så er den sterkeste tegn på lojalitet brukere som er villige til å komme tilbake å bruke penger igjen.
Programmerer 3: – Det kan vi også logge.
Produkteier: – Bra! Da rapporterer jeg tilbake til ledelsen at vi vil starte med å logge hvor mange brukere som kjøper noe mer enn én gang. Når kan vi ha de første resultatene klare?
UX: – Vi bør nok logge det over en periode på to uker, og gjerne få med datostempel for å kunne lese ut når på døgnet de kjøper.
Programmerer 1: – Vi bør kunne starte loggingen i løpet av morgendagen, så kan vi implementere en enkel rapport/visning i løpet av perioden, som vi kan vise til ledelsen.
Produktutvikleren forstår helheten
Vi gjør oss selv en bjørnetjeneste om vi tror at en programmerer ikke trenger å forstå helheten. Den moderne programmereren – produktutvikleren – må forstå. Hvordan kan du vite om snekkeren lager et møbel du vil være fornøyd med om han ikke forstår behovet? Skal du stå å passe på snekkeren mens han jobber? Liker du når andre kikker over din skulder? Har du ikke viktigere ting å gjøre?
Tre måneder senere…på morgenmøtet…mens våren trenger inn gjennom vinduet…
Programmerer 1: – Siste periode viser at gjenkjøpsgraden har økt med 1,3%
Programmerer 2: – Det er litt lavere enn vi håpet, men jeg kan også se at 22% har falt av på steg tre i betalingsprosessen hvor vi la inn tre nye valgalternativer for to dager siden.
UX: Av de som har fullført, har under 5% valgt alternativ b og c.
Produkteier: Da prøver vi å fjerne de alternativene igjen.
Programmerer 3: Ehh… jeg gjorde det i går ettermiddag da jeg hadde samme mistanke…
Produkteier: Jasså?!
Programmerer 3: Ja, altså…
Produkteier: – Ja, men fortell da! Hvilken effekt hadde det?
Programmerer 3: Kun 3% har falt av på steg tre, siden jeg produksjonsatte endringen.
Produkteier: Bra! Jeg har fått ett innspill fra ledelsen om at de ser behovet for å possisjonere oss sterkere gjennom mobilkanalen, og de vil gjerne ha forslag til hvordan vi kan måle dette og hva vårt første eksperiment skal være…
Det jeg forsøker å formidle her. Er det samme som bl.a. Eric Ries har erfart og forsøker å formidle, fra en investor´s ståsted, i boken sin “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”. Jeg har valgt å kalle en moderne programmerer for en Produktutvikler, fordi det er veldig betegnende for hvordan rollen bør utøves i moderne tid. Forstå målet. Eksperimentere. Analysere. Lære. Forbedre. Og iterere i takt med omgivelsene. Løp og kjøp!
Developer’s DNA
“The candidates must have at least three years of Java development and experience with four of the following five technologies…”. This is how a typical request for consultants goes, both for public and private sector customers. It clearly favors candidates with long, stable assignments behind them. It seems to be commonly accepted in our industry that the most important quality a developer can bring to a new project is experience. That may not be such a good idea.
The underlying premise here is that training makes you a more effective developer. That may be true, but only to a very small degree.
The problem is that deep tool knowledge is not where the biggest gains are. Software development is just not that trivial.
I have seen teams that have success based on criteria that are different from this kind of experience. A developer with 4 different projects in a 2 year time span take along more good thoughts than one with 5 years of experience with the technology being used. A fresh graduate with nothing to defend often asks those stupid questions that makes the rest stop and think. One who is attending meetups and reading relevant blogs takes along experiences others have gained without having been there himself.
Efficiency is not first and foremost dependant on the speed with which you can code because you have long experience with a specific tool. Efficiency comes with the one who asks if we really need to use the framework we have taken for granted. It comes with the one that had heard of the tool that ends up saving the team for weeks of work. It comes with the one who takes the time to think clearly and simplifies our process and makes everyone more productive. The efficient developer thinks like an innovator.
Development is innovation, and the best developers are innovators. The good news is that you do not have to be among the very creative to think new thoughts. You do not have to be fresh from school to ask the stupid questions, and you do not need experience from many different projects to be able to draw on other people’s knowledge.
You too can be innovative by paying more attention to how innovation happens.
Jeff Dyer, Hal Gregersen and Clayton M. Christensen have coined the term Innovator’s DNA. They have, based on extensive research, uncovered what practices and techniques the most renowned innovators use to come up with new ideas. The conclusion is that innovation only to a small degree owes to genetics, while it to a much bigger degree is an effect of how you behave.
So, to become a better developer you can use some of the five techniques they have described:
1) Associating. Connect seemingly unrelated ideas, questions or problems.
2) Questioning. Don’t be afraid to look stupid. “What would we do different if we only had half the time we do now?”
3) Observing. Meet up with the guys at customer service. What are people complaining about?
4) Networking. Talk to people with different backgrounds. Can you use their insight?
5) Experimenting. Create a prototype, set up an experiment, do an A/B-test.
When we hire at Iterate, we don’t just look at people’s experience. We try to find their intrinsic motivation, their desire to create something, their eagerness to play and experiment and their drive to continue learning. We value and grow the factors that make you an innovative and excellent developer.
Er nye bygninger trygge?
Vi er vant til at programvare har feil. Bare husk de grufulle minnene fra Windows sin blåskjerm “blue screen of death”, som selv for Bill Gates kom på det mest ubeleilige tidspunkt (da Windows 95 krasjet under en demonstrasjon for pressen). Som brukere har vi forsonet oss med at programvare ikke er perfekt.
Enkelte av oss har nylig erfart ubehageligheter med selvangivelsen. Problemer mer alvorlige enn de vanlige ytelsesproblemene som kommer når halve kongeriket sjekker restskatten samtidig: Enkelte har til sin store overraskelse fått anledning til å se en annen person sin selvangivelse. Det er kanskje å ta offentlige skattelister en smule langt?
Vi stoler ikke på nye IT-systemer. Vi har lært oss å ikke oppgradere noe som helst rett før vi tar med oss laptoppen på hytta, eller før vi går i et viktig møte. Jo eldre programvare, desto tryggere føler vi oss, fordi tiden har luket ut de styggeste feilene.
Det er anderledes med bygninger. Selv føler jeg meg mindre trygg desto eldre bygning. En kompis bodde en gang i en loftsleilighet fra 1800-tallet, og etasjeskillerne besto av knusktørr halm. Én flamme på feil sted i første etasje, og hele bygningen hadde blitt en stor skorstein. Nye bygninger derimot, de står støtt. Bygget etter moderne metoder, og gjennomgått grundig ettersyn. Iallefall de fleste av dem.
Hva skiller disiplinene bygg og programvare? I byggeindustrien må man sikre kvalitet i hvert ledd. Du kan ikke bygge andre etasje før du vet at første etasje holder. Det er man (dessverre) ikke nødt til i programvareindustrien. Istedenfor å bygge integritet inn i løsningen, tester vi kvaliteten etterpå. Da finner vi selvfølgelig masse feil, som vi ikke har tid til å rette opp. Det er et paradoks: Vi tester for å finne feilene vi har laget, når det åpenbare alternativet er å unngå feilene i utgangspunktet.
Empire State Building ble bygget på ett år, men kanskje ikke utelukkende i små sikre steg ..
Hvorfor er det slik?
La meg først presisere: Jeg er Altinn-fan. Tross ytelsesproblemer og dagens defekt. Det er ikke mange andre land i verden hvor det er så enkelt å betale skatt som i Norge. Altinn sparer det offentlige for store summer, og gjør en lite forlystelig oppgave for oss arbeidstagere mye enklere. Altinn er en kjempesuksess, la oss ikke glemme det.
Når store virksomheter kaster seg ut i utviklingen av kritiske IT-systemer, da kan vi ikke lenger tenke som vi gjør når vi kjøper pølse fra kiosken på hjørnet. Se heller på det som å stå over en porøs fjellformasjon i minusgrader og helle ut varmt vann. Hvor kommer vannet til å renne? Hvor fryser det først? Hvordan kommer formasjonen til å slå sprekker?
Vi vet ikke.
Derfor må vi bygge inn integritet gjennom små, sikre steg. Kunne man lansert selvangivelsen i segmenter? For eksempel alle med forenklet i selvangivelse i Hedmark: Dere er først ut. Det kunne gått på rundgang, en “etasje” om gangen. Utviklere og saksbehandlere lanserer én og én funksjon, og forholder seg dermed til en håndgripelig oppgave. Med slike små steg får vi heller ikke store folkehav som hamrer løs på systemet samtidig, og vi slipper noe av den kompleksiteten (og dermed også faren for feil) høy ytelse krever.
Dette var kun et eksempel. Skatteetaten vet selv hva som er best, men de må få rammene for å jobbe smart. All erfaring fra internasjonal IT-industri tilsier at tradisjonelle hierarkier, budsjetter og byråkrati står i veien. Så lenge det dreier seg om å unngå i gjøre feil, kommer vi til å gjøre feil. Skatteetaten / Altinn må kunne organisere seg som det de er: Produktutviklere. Det er da de kan utvikle arbeidsprosessene sine i takt med produktet. Det er da de stygge feilene forsvinner.
Kent Beck: Best Practices for Software Design with Low Feature Latency and High Throughput
I was fortunate to attend a lecture by Kent Beck, Iterate’s Chief Scientist, for one of our customers, summarizing his experiences and thoughts regarding efficient software design. Traditionally there have been two schools of thought about design: Predictive design, trying to design everything upfront (and making lot of wrong decisions) and reactive design, where any design is only done if it is absolutely necessary for implementing a feature (thus developing often on top of an insufficient design). Kent tried hard to discover such a design method that really delivers on the promises of both while avoiding their failures. This method is based on evolving design frequently in small, safe steps and focusing on learning while following some key best practices. It doesn’t really matter what scope of design we are are speaking about, the method and principles are the same whether you’re redesigning a class or a complex system.
Et forfriskende fossilt pust
Torsdag denne uken arrangerte Computerworld konferansen Energyworld, som handlet om IKT i olje- og gassindustrien.
Noen profilerte foredragsholdere som Sonja Chirico Indrebø, CIO Statoil og Frederic Hauge i Bellona holdt innlegg på konferansen som betimelig fant sted i oljebyen Stavanger. En nokså intetsigende keynote ble balansert av et dertil mer givende innlegg fra Statoil, og i kombinasjon med parallellsesjonene kunne man, utover Computerworld sitt vante (enkelte vil kanskje driste seg til å antyde kjedsommelige) fokus på nettskyen, ane en rød tråd om innovasjon. Både knyttet til kjernedisiplinene i olje-gass-industrien, og IT sine fremtidige bidrag til dette forblåste, avleirede og uthulede landskapet.
So far so good. Tross en god intensjon og et godt initiativ om å etablere en møteplass for IT-profesjonelle innen olje/gass (all ære til Computerworld), satt jeg igjen med et inntrykk av at denne bransjen IT-messig henger bak. Det skulle man kanskje ikke tro, at eksempelvis byråkratiske innretninger som SPK og NAV skulle ligge langt foran en progressiv bransje som “åljå”, men på Energyworld virket det slik. Riktignok bruker bransjen mange spesialiserte IT-verktøy, men disse brukes fortsatt på avgrensede områder; i bransjens såkalte integrerte operasjoner kan det virke som om alt annet en en helhetlig IT-tankegang er integrert.
Aldri har tiden for gode idéer vært bedre enn nå sier Statoil (bildet fra statoil.com)
Jeg mener ikke å henge ut noen her, men trekker frem noen eksempler slik at leserne kan bedømme selv. Et foredrag handlet om en påstått agile tilnærming til en IT-satsing, som til alt overmål skulle være basert på standardkomponenter (hørte jeg en selvmotsetning?). Det nyvinnende prosjektet hørtes for meg ut som et klassisk skreddersømprosjekt, med krav- og testfaser, endringsforbud og målsetninger uttrykk utelukkende i tid og budsjett. Man er ikke agile bare fordi man har involvert brukerne i kravspesifiseringen – selv ikke i oljebransjen.
Verdibudskapet til sponsorene var nesten uten unntak uttrykt i form av kostnadsbesparelser. “Få kontroll på driftsbudsjettet”. “Hold serverkostnadene nede”. Osv. I tillegg var det knapt mulig å forstå hva som var den egentlige brukerverdien av de promoterte produktene. Kanskje er jeg utenfor mentaliteten i denne bransjen, men ord som “Energy Components”, “integrert dokumenthåndtering” og “executive scorecard” resonnerer ikke hos meg.
I motsetning til shippingindustrien, der preskriptive krav som stålplatenes tykkelse på et skip ligger som hindringer for nytenkning (hvorfor kan man ikke heller si at et skip skal tåle en kollisjon under en hvis hastighet?), har petroleumstilsynet for lengst laget funksjonelt orienterte krav som sier noe om egenskaper til et system, istedenfor implementasjonen.
Dette er tankegangen oljebransjen også må bruke på sine IT-satsinger. Så lenge de styrer utelukkende på tid og budsjett, så lenge de ser på IT som som en kostnad og organiserer seg slik at IT-sjefen kun har utgifter, så lenge de så langt det er mulig skal kjøpe standardkomponenter, og dermed som vane spesifiserer opp alt de trenger av IT-funksjonalitet på forhånd, så får de det som kalles continuous innovation – marginale forbedringer av eksisterende regimer.
I en utsatt bransje med tidvis vanvittige resultater og dertil hørende sviende nederlag og katastrofer som en del av hverdagen hadde jeg forventet meg en større anerkjennelse av den tvetydighet vi alle vet IT-utvikling fører med seg. Jeg hadde forventet meg en bransje som gikk inn for disruptive innovation, nye regimer og tankesett, der man anerkjenner at du ikke på forhånd vet hvordan løsningen skal se ut. Jeg hadde forventet meg en bransje som så større verdi i forretningsmessige gevinster enn budsjettmessige gevinster, og som håndterer risiko så bra at de ikke trenger å være redd for å trå feil.
Det er forfriskende at en konferanse som Energyworld blir etablert, men til neste gang ønsker jeg meg mer utfordrende foredrag, mer utfordrende leverandørstander og mer utfordrende produkter. Maten må de imidlertid gjerne beholde. Lunsjen var preget av den lokale tidsånden, som tydelig viste at oljebyen Stavanger også er matbyen Stavanger, som har utnyttet lokale ressurser og lykkes med å tenke nytt uten at en smørkrise måtte tvinge det frem.
Få betalt for feil du ikke finner!
På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen. Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.
Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.
Mange med test som fagfelt er ikke-tekniske personer som klikker seg gjennom brukerscenarioer og manuelt sjekker om systemet oppfører seg som forventet. Denne type verifisering er nødvendig, og teknologien i dag tillater større grad av automatisering av slike tester. Men ikke vær redd for å gjøre deg selv arbeidsledig ved å ha større grad av automatiserte funksjonelle regresjonstester. Sørg heller for å bruke tiden der det er vanskelig å automatisere. Vær med tidlig i utviklingsløpet og test så tidlig som mulig. Vær gjerne med å spesifisere funksjonaliteten. På denne måten kan du som tester bidra til å bygge kvaliteten inn fra starten av og ikke bare avdekke dårlig kvalitet i etterkant. Du kommer til å få en mer givende hverdag enn å melde feil på feil på feil inn i et eller annet ticket-system, for så og måtte re-teste dem igjen etter flere uker (kanskje måneder og år). Du kommer til å gjøre deg selv uvurderlig i markedet som den testeren som tilfører mest kvalitet til systemene du er med på å lage.
For at vi skal komme dit at de tradisjonelle test-diktatorene der ute kan omfavne tanken om å forhindre feil fremfor å finne feil, og på den måten jobbe mer sammen med utviklere har jeg et forslag:
Vi lønner testere etter hvor mange feil de ikke finner!
Iterate støtter Digitalt personvern
En stor andel av de oppdragene vi i Iterate utfører for våre kunder gjelder utnyttelse av de mulighetene et fritt og åpent internett gir oss – alt fra friheten til å eksperimentere med nye forretningsmodeller til selvbetjent saksbehandling og salg av varer og tjenester på nett.
I løpet av 2012 blir datalagringsdirektivet del av norsk lovgivning. Direktivet pålegger lagring av trafikk- og lokaliseringsdata fra bruk av telefon, mobiltelefon, e-post og internett. Med andre ord hvem som kommuniserer med hvem, når det kommuniseres, og hvordan det kommuniseres. Kort oppsummert vil det digitale personvernet bli mye dårligere enn ellers i samfunnet.
Som selskap har Iterate sjelden lagt seg opp i politiske diskusjoner. Et klart unntak er der lovgivning eller reguleringer truer våre verdier og grunnlaget for vår eksistens. Datalagringsdirektivet er et slikt unntak.
Det svake personvernet på internett vil utgjøre et hinder for kunder som ønsker å benytte seg av nettbaserte tjenester. Direktivet er et skritt i retning av et mer lukket og kontrollert internett og en trussel mot den innovasjon og nyskapning Iterate er til for å støtte og fremme.
I forrige uke la vi derfor ut en avstemning ut for de ansatte. Spørsmålet alle skulle ta stilling til var om Iterate skulle gi NOK 10 000,- til foreningen Digitalt personvern, som samler støtte til en prøving av Datalagringsdirektiv i norsk rett.
Alle de som avla sin stemme var positive til dette forslaget. Vi har derfor i dag overført penger til Digitalt personvern.
Innovasjon i større organisasjoner
Mange større bedrifter har innovasjon høyt på agendaen og streber etter å øke sin innovasjonsstyrke. Det viser seg imidlertid vanskelig, hvor utfordringen hos mange ligger i selve bedriftskulturen. Innovasjon handler om evnen til å fornye og tilpasse produkter, tjenester, prosesser etc for å være konkurransedyktige i sitt marked. De fleste er enige om at det finnes bedre og mer helhetlige måter å drive innovasjon og verdiskapning, men har vanskeligheter for å finne de rette virkemidlene for å få det til å skje i praksis. Så hva skyldes dette?
Det viser seg at problemet delvis ligger fundert i frykten for å miste kontrollen (eller følelsen av å ha kontroll). De selskapene som har lykkes med innovasjon har bygget hele sin bedriftskultur hvor det å lære, samt validere læringen, er den viktigste styringsparameteren. De har bygget en lærende organisasjon. Hva skal til for å bygge en lærende organisasjon?
Den nakne sannheten om IT-prosjekter (Del II)
Som jeg lovet i DEL I, så skulle jeg dele mine erfaringer om hvorfor det er viktig å gjøre kunden god i egen organisasjon. Jeg skal også røpe noen ukonvensjonelle triks som viser hvordan du gjør dette mest effektivt.
Det vil hjelpe om vi ser dette i kontekst av tradisjonelle IT-prosjekter. Eksempelvis betyr dette at kundens prosjektleder eller produkteier, som har fått et leveranseansvar internt, vet at det egentlig kun er TO ting som betyr noe; at det leveres “noe” til avtalt tid og budsjett. Resten er i praksis underordnet.
Jeg kunne godt skrevet et helt blogginnlegg om hvor UENIG jeg er i den tradisjonelle prosjektmodellen, hvor leverandør setter nytt system i produksjon og overleverer til linjen i mottagende organisasjon. Faktum er at en denne modellen virker mot sin hensikt som er å oppnå en definert forretningsmessig verdiøkning. Men, det får vi diskutere en annen gang. Tilbake til dagens tema…
DEL II
Som konsulent har du et ansvar for å gjøre kunden god i egen organisasjon
Husker du historien om da jeg skulle kjøpe meg nye ski fra del 1 av denne bloggserien? (hvis ikke kan det være greit å friske opp minnet før du leser videre). Hva nå om jeg skulle kjøpe ski til kona. Med bestilling fra kona.
Hva ville en dårlig selger gjort? For det første så ville han ikke brydd seg om å finne ut hva dine reelle behov er (og i de fleste tilfeller så vet vi jo knappt det selv). Deretter ville han spurt deg hvilke type ski og merke du har tenkt deg. Hvis du i beste fall er så ærlig at du innrømmer å ikke helt vite det selv, så har man fortsatt en liten sjanse for at vedkommende innser at han må tilkalle forsterkninger. I realiteten ender man som regel med at selgeren finner frem 2-3 vilkårlige alternativer som du presenteres. Dette hjelper ikke særlig.
Hva gjør en god selger? Han får tankene dine bort fra pris og fokuserer på at utstyret skal passe med ditt behov og ønskede kjøreopplevelse. Det er tross alt det du vil huske resten av sesongen (prisen husker du i verste fall frem til neste lønning eller skitur).
Denne historien handler ikke om hvorvidt selgeren er sleip og har et underliggende ønske om å prakke på deg mest mulig. Den handler om konsekvensene av å føye seg etter kunden for å fremstå “hyggelig” i stedet for å gjøre kunden en ordentlig tjeneste og lære han mer om sine egne behov og presentere noen relevante løsningsalternativer. Hvis noen kommer og spør om råd, så er det som oftest fordi man trenger rådgivning. Anta da ikke at vedkommende kjenner alle sine behov. POENGET her er om man klarer å finne en løsning som vil fungere – for kona – på sikt. Det er stor fallhøyde for meg som “kundens prosjektleder” om man ikke lykkes.
Dersom kjøreopplevelsen for kona ikke er god i det lange løp pga skivalget, så hjelper det ikke lenger om skiene hadde riktig farge eller var billige nok i utgangspunktet. Opplevelsen går fra god til dårlig. Vi klarer ikke å gjøre kunden god i egen organisasjon hvis de alltid må gå fra gode til dårlige nyheter.
Bygg så store buffere du kan, men ikke si noe til kunden
De færreste produkteiere eller andre kunderepresentanter har noen formening om hvor lang tid det tar å implementere funksjon x og funksjon y. Hva det koster. En målsetning er da at man unngår å gå fra et estimat til et høyere tall i faktisk forbrukt tid. Det beste du kan gjøre – for begge parter – er å legge til grunn et best mulig rasjonale for ditt høyeste estimat.
Selv om kunden er aldri så misfornøyd med tallet du presenterer (fordi de hadde håpet at det skulle være lavere) så vil man med større trygghet kunne forklare i sin egen rapport til intern ledelse hvorfor dette er slik (intern ledelse har heller ingen forutsetning for å vite hva funksjonen koster, men forholder seg naturlig nok til budsjettet eller tidligere estimater).
Skulle du være så “snill” å gi kunden det laveste estimatet, så er risikoen langt større for at det kommer ubehagelige overraskselser senere. Ingen liker å gå fra gode nyheter til dårligere nyheter. Alle liker å gå fra dårlige nyheter (høyt estimat) til bedre nyheter (levert under estimat). Skulle det vise seg at de dårlige nyhetene (høyt estimat) forblir dårlige nyheter (leveres på tid), så har man med tiden vent seg til tanken. Det gjør ikke så vondt lenger.
Bare tenk dere forskjellen på om man i første scenario kommuniserer et “snilt” estimat på 50 timer, hvorpå sluttresultatet blir 75 timer. I scenario to argumenterer du først for et estimat nærmere 100 timer, hvorpå endelig forbrukt tid ender på 75 timer. Hva er å foretrekke?
Det er konsulentens ansvar å lære opp kunden
Man kan ikke forvente at kunden som til vanlig jobber med et helt annet domene, skal vite hvordan et komplekst system som IT-utvikling må håndteres. Som proffesjonelle utøvere innenfor utvikling av IT-løsninger, må vi bistå en kunde og deres organisasjon konsekvensene av sine valg (både fordeler og ulemper).
Hvorfor skal vi alltid starte med å sende ut minst fem endringsmeldinger i løpet av de to første ukene i et fastprisprosjekt? Det er for å lære kundene effekten og resultatet av å “sikre seg” gjennom fastpris-avtaler. Gjør man ikke dette, så vil man for det første ende opp med at kunden ikke forstår at det koster å omprioritere ofte (det er krevende å endre kontekst ofte).I tillegg er det viktig at alle parter forstår hvordan den underliggende konsekvensen av å kjøre fastpris-prosjekter er at a) kunden ikke blir så opptatt av hva som er innenfor eller utenfor omfanget og b) leverandøren blir veldig opptatt av å ikke inkludere mer enn nødvendig i kravene. Og tilslutt endre man opp med å bruke altfor mye tid på å diskutere hva som er utenfor og innenfor oppdraget…
I smidige prosjekter sier man at man omfavner endringer. Det betyr ikke at det er uten kostnad å omprioritere og bytte kontekst ofte. Grunntanken her er at man ikke skal låse seg til en detaljert krav-/løsningsspesifikasjon gjennom et prosjekt.
Vi har alle behov for å føle oss trygge
Uansett hvilken stilling og rolle vi har fått i samfunnet, så har vi alle de samme grunnleggende behovene. Det må vi aldri glemme.Helt avslutningsvis har jeg valgt å sitere et utdrag fra en av mine tidligere bloggartikler (og starten på noe som kan bli en bok en dag), “People. Culture. Fire. A gut feeling.“:
“As a human being I am filled with emotions. Sometimes I laugh. Sometimes I cry. Sometimes I get upset, even though I´m not sure why. Sometimes I can´t control my emotions. Sometimes my pride gets in my way – in everyone’s way. Please don´t fight me. Try to see my perspective. Help me, and I will want to help you. I´m only human.”
I DEL III vil jeg dele mine erfaringer fra hvordan vår streben etter å føle kontroll og måten vi organiserer oss i realiteten undergraver vår evne til å optimalisere helheten og nå våre mål.
Bang
Den nakne sannhet om IT-prosjekter (del 1)
Om PROSJEKTSTYRING som du ikke lærer på kurs eller leser om i bøker
Hvorfor skriver jeg denne serien med blogginnlegg om prosjektstyring?
Fordi jeg ønsker å dele egne erfaringer og høre andres synspunkter om den underliggende psykologien i IT-prosjekter, og årsakssammenhenger som man ikke lærer om på kurs eller i bøker, men som er realiteten. IT-prosjekter er som egne økosystemer hvor vi må evne å gjøre bærekraftig for å lykkes. Vi må forstå hvordan enkeltelementene i dette systemet gjensidig påvirker hverandre og hva som optimaliserer helheten (understøtter primærmålet).
Skjønner vi dette så vil vi også i større grad evne å skape bærekraftige endringer i organisasjoner, men vi må gjøre det i små steg – hver dag (Kaizen).
Det er noe av det samme som Jurgen Appelo tar opp i sin nye bok Management 3.0, når han snakker om “Complexity theory” som bl.a handler om å forstå kompleksiteten i å lede endring i en organisasjon eller blant en gruppe mennesker.
Husk å dele dine erfaringer og synspunkter som kommentar til denne artikkelen når du er ferdig!
Skikjørere på vei opp mot en av toppene i Lyngsalpene
DEL I
“Vi styrer våre egne valg” – en sannhet med modifikasjoner
Jeg går inn i en sportsbutikk og skal kjøpe nye ski til skisesongen. På vei inn minner jeg meg selv på mitt “budsjett”.
Selgeren sier: – Hei, hva kan jeg hjelpe deg med?
Jeg sier: – Jeg skal ha nytt alpinutstyr. Sånne carvingski. De gamle fungerer ikke så bra lenger (Jeg tenker: “De er ikke ødelagt eller noe, men jeg føler ikke akkurat at jeg følger med i utviklingen”)
Selgeren sier: – Det finnes ulike alternativer, som varierer litt i pris ift behov og ønsket kjøreopplevelse. Fra kr 4000 til kr 10 000. Hvor mye kjører du? Mest off piste eller i preparert løype?
Jeg sier: – Ja, skjønner. (Jeg tenker: “Det eneste jeg skjønner er at jeg må revurdere budsjettet mitt.”). Jeg kjører mest i bakke, men også en del off piste (Jeg tenker: “I realiteten har jeg hatt 3-4 turer i sesongen de siste 5-6 årene, hvor jeg kun ved to tilfeller har kjørt i løssnø, som skyldtes at preppemaskinen ikke hadde kjørt bakken ennå. “)
Selgeren sier: – Hvis skal kjøre mest i preparert løype, så vil jeg anbefalle disse skiene. Bestselger, som også fungerer fint om det er litt løsnø i bakken. Ikke fullt så bra om du skal gå mye toppturer med pudderkjøring. Skiene koster kr 4999, men vi har de også i et pakketilbud med støvler, bindinger og staver til kr 8 900. Vi har solgt masse av disse. Jeg kjører selv på fjorårsmodellen og hadde en sinnsyk god opplevelse i de franske alpene. Da har du utstyr i mange år fremover. Aksel Lund Svindal kjører med samme merket.
Jeg sier: (Jeg tenker: “Aksel Lund Svindal – kult!. Det må jeg bare fortelle gutta! Han sa jo også at det var en bestselger. Nå må jeg bare ikke virke for ivrig. Prute litt”). Det var litt stiv pris, synes jeg.
Selgeren sier: – Vi har også andre ski som er på tilbud. Bl.a et par fra en modell som utgikk i fjor.
Jeg sier: – Men, som du sier så vil jeg ha utstyret i mange år fremover. (Din rasjonelle hjernehalvdel rettferdiggjør valget og valget ditt bør fremstå veloverveid.). Det er greit. Jeg tar dem. Ha´kke tid til å stå her. Må komme meg ut i pudderet, vet du! (Jeg tenker: “Pudder? Takket jeg ikke nettopp ja til ski som var best egnet i preparert løype?…”). Takk for hjelpen!
Denne historien illustrerer i hvor stor grad den emosjonelle delen av hjernen vår påvirker våre valg. Det meste handler om det vi opplever som “magefølelsen” (som egentlig er Det Limbiske System i hjernen som driver følelser og oppførsel hos mennesker) og gir oss en sterk indikasjon på hva vi virkelig ønsker, mens vårt rasjonelle “jeg” febrilsk jobber med å rettferdiggjøre valget. Dette betyr i praksis at vi er mer opptatt av hva andre mener om oss, enn resultatene vi skaper. Det er et helt grunnleggende og naturlig instinkt for de fleste av oss.
Hva gjør en god konsulent her?
Det er ikke selgeren som tar valget, han bare legger frem alternativene så jeg skal kunne gjøre det beste valget utifra mine behov. Problemet oppstår så snart jeg ikke helt vet hva mine behov er. Kanskje burde jeg lånt med meg to par ski og kjørt dem en uke, for så å kjøpe paret som fungerte best i “produksjon”?
En virkelig god selger ville foreslått nettopp utlån av ski, for å sikre at jeg gjorde et godt valg.
Denne problemstillingen er velkjent når man jobber med produktutvikling og er nærmere utredet i artikkelen om “The User Feedback Problem“
Hovedpoenget mitt her er at vi må bedre forstå det underliggende behovet hos våre kunder. Vi må både forstå hva bedriften trenger, samtidig som vi forstår hva kundens produkteier eller prosjektleder trenger for å gjøre gode valg. Forstå hvilket enormt press det innbærer å stå mellom leverandøren og sin egen ledelse. Det holder ikke å bare avfeie folk med “Å, de skjønner jo ingenting!”.
Hvis kunden forstår hvorfor og selv kan ta nødvendige valg fordi vi er flinke til å presentere valgalternativene med fordeler og ulemper, så blir det enklere å forsvare det mot egen styringsgruppe eller ledelse. Da er også sannsynligheten større for at man vil se på arbeidet som vellykket fordi man tok det beste valget i rådende situasjon (man hadde tross alt ikke noen bedre alternativer).
Som konsulent så forplikter du å gjøre mer enn “jobben din”, om det være seg programmere, designe eller å teste. Du forplikter å gjøre kundens jobb så enkel som mulig. Husk at det er ikke engang sikkert vedkommende har bedt om å bli prosjektleder eller produkteier for et IT-prosjekt (i tillegg til jobben i linja). Ta ansvar og bry dere om hverandre. Vi er ikke roboter, men mennesker med kjøtt, blod og følelser – masse følelser.
Hvilke tanker vekker dette hos deg?
Neste gang skal jeg ta utdype dette som er din viktigste oppgave som konsulent, rådgiver eller leverandør; nemlig å gjøre kunden god i egen organisasjon.
Bang
