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.
