blog.iterate.no

Noen ganger er det vanskelig å være uenig.

For eksempel når man ser ord, som brukes så mye, overalt, at den egentlige meningen fortrenges til fordel for selvfølgeligheter ingen registrerer. Kvalitet er et slikt ord. Kompetanse er et annet. Kunnskap et tredje. Hva forteller det deg når en virksomhet sier de satser på kunnskap, kvalitet og kompetanse?

Meg forteller det ingen verdens ting. Ganske enkelt fordi nettopp alle i bransjen vår satser på kunnskap, kvalitet og kompetanse. Iallefall tilsynelatende.

Det skulle være moro å se et selskap overføre “rent a wreck”-konseptet til IT-bransjen. “Hos oss får du leie middelmåtelige ingeniører til en rimelig penge! De er rufsete i kantene og velbrukte, men du vet – slike traktorteknologer er kanskje gammeldagse, men desto mer slitesterke!”

Du verden, jeg kunne vært fristet til å kjøpe.

Så hvorfor er kommunikasjonen i vår bransje preget av floskler? Jeg kjørte nettsidene til noen typiske IT-selskaper, inkludert mitt eget, gjennom tagcrowd, og endte opp med følgende liste av ikke-meningsbærende ord:

Brukervennlig, faglig, kundetilfredshet, kunnskap, langsiktig, ledende, medarbeider, muligheter, samarbeid, smart, spennende, troverdig.

Ærlig talt: Er det mulig å ta noe annet standpunkt enn det disse ordene gir uttrykk for? Er det noen som er imot brukervennlighet og kundetilfredshet? Eller hva med medarbeidere? Noen som er imot medarbeidere?

Det neste naturlige steget i tankeprosessen blir å finne et uttrykk for våre faglige ambisjoner, der vi faktisk skiller oss ut. Det er en nyttig øvelse, som jeg kan anbefale alle å gjøre der de jobber. Forsøk å si noe som stemmer om din bedrift, men som du antar noen vil være uenig i. Og si for guds skyld fra til ledelsen om du ikke finner noe.

Kaizen er japansk og refererer til en filosofi om kontinuerlig forbedring. Umiddelbart liker jeg ordet fordi det gir meg en slik mystisk, asiatisk, Uma Thurman-ish følelse av noe sofistikert og tøft. (Jeg liker det også av faglige grunner.)

Om Uma Thurman bruker Kaizen vites ikke. Men ingen tvil om at hun er tøff.

Ordet Kaizen er imidlertid lost in translation. Kontinuerlig forbedring er jo nok et eksempel på en floskel, iallefall hvis man følger min ad hoc-definisjon: Hvem er vel imot å forbedre seg fra tid til annen?

Spør du meg, er en bedrift som faktisk gjør Kaizen et sted der du merker det allerede i resepsjonen. Det er en bedrift der alt du gjør, fra time til time, utledes fra et ønske om å forbedre seg. Forbedringer blir navet i det daglige arbeidet.

Hvordan arter dette seg i programvareutvikling? Det første mange tenker på er kanskje iterativt arbeid med jevnlige evalueringer. Min erfaring med vanlig praksis innen iterative metoder, er å inkludere et relativt kort evalueringsmøte etter hver iterasjon, lage seg en liten handlingsplan med noen tiltak som lever side om side med de andre, planlagte oppgavene. Jeg lar det være opp til deg som leser å vurdere om slik praksis er Kaizen eller jevnlige forbedringsforsøk.

Det nærmeste jeg har kommet Kaizen-liknende tilstander i mitt fag er lean startup-metoden (som du kan bruke selv om du ikke jobber i en startup). Om du har en time å avse, anbefaler jeg denne introduksjonen fra Eric Ries. Han mener programvare bør utvikles gjennom systematisk validering av antagelsene du har i ditt business case. Det betyr at du må ha et business case – og ikke en kravspesifikasjon – som utgangspunkt for arbeidet. Du jobber i svært korte iterasjoner og bruker all din tid på å skaffe tilbakemeldinger på dine antagelser om kundene og markedet. Ingen tilbakemeldinger er bedre enn det du får høre fra betalende kunder, som bruker programvaren din.

Betyr dette at du lar brukerne diktere produktet ditt? Nei. Det er fortsatt ditt ansvar å tolke svarene du får, og omsette de til et helhetlig, sammenhengende produkt. Poenget er at du skaffer deg svar, hele tiden. At du tolker dem, hele tiden. At denne økende innsikten styrer arbeidsinnsatsen din, hele tiden.

Det er Kaizen.

Ida tar sin idé umiddelbart ut i markedet, og hun kommer til å vinne over det store prosjektet, som jobber grundig frem mot en stor lansering. Mot alle odds vil noen si. Ren flaks sier andre. Stikk motsatt, sier vi.

Det er en utbredt oppfatning at en god idé bør utvikles ordentlig før den lanseres. Sluttproduktet må ha en skikkelig finish når den møter et marked med lite rom for tilgivelse. Førsteinntrykk er alt, ikke sant?

I spillindustrien erfarer man at en dårlig førsteutgave av et spill kan medføre at senere, forbedrede versjoner flopper. Ikke bare nekter kundene deg et andre forsøk, de sprer også negative meninger om skuffelsen de opplevde med den første versjonen. Spillselskaper sørger derfor for å gjøre seg flid før de slipper et produkt, og da er det vel nærliggende for andre bransjer å anta at det samme gjelder dem?

Samtidig er det bekymringsverdig normalt å høre om nedlagte IT-satsinger. Noen prosjekter flopper i møtet med markedet, mens andre legges ned før de ser dagens lys. Verst av alt er det at som regel står talentfulle, kompetente og dyktige personene bak prosjekter som feiler.

Det er finnes ingen garantier for å lykkes, selv om vi er dyktige i vårt fag eller har en god idé. Ei heller gir kombinasjonen av faglig dyktighet, en god idé og et stort budsjett noen garanti. Tvertimot er dette den største risikosonen av dem alle.

På vei til markedet

La oss dikte opp et eksempel, ved å se for oss en fiktiv forretningsidé. Den kommer fra den nordnorske reiselivsnæringen, som ønsker seg en tjeneste som samler og presenterer reisetips, tilbud og produkter i salg fra regionen. Her vil brukerne kunne bestille pakkereiser, få tips om tur-, jakt- og fiskemuligheter, kjøpe raffinerte matprodukter som tørrfisk, fenalår, multesyltetøy osv. Alt på et sted!

Vår forretningsutvikler heter Ida, og hun er faktaorientert. Hun har gjort en markedsanalyse, brukt fokusgrupper og andre virkemidler for å skape seg et inntrykk, men innser dette fortsatt er antagelser. I tillegg har hun erfart at det kan være stor forskjell på hva du hører i en fokusgruppe, og hva du hører fra betalende kunder.

Hun vil derfor ut i markedet så fort som mulig, og bestemmer seg for å begynne med en tur-blogg. (For å gjøre vår lille anekdote ytterligere spennende, ser vi for oss at en større reiselivsaktør samtidig starter opp et utviklingsprosjekt for det som kan bli en konkurrerende tjeneste. Utviklingsdelen av prosjektet er estimert til å ta ca ett år.)

Hva med å selge lokalmat fra Lofoten? (Bilde: Visitnorway.com)

Turbloggen til Ida har et enkelt konsept: Den omtaler skjulte “perler” – turtipsene bare noen få kjenner til. Den begynner med å beskrive turen opp til Håtinden i Lofoten, og har i tillegg et par annonser til noen utvalgte, spesielle kvalitetshoteller, for eksempel Edvardas Hus på Hamarøy. Bak sceneteppet har hun sørget for å integrere et standard analyseverktøy slik at hun har kontroll på trafikken til bloggen, og for eksempel kan se hvilke annonser som blir trykket på, hvem som lenker til bloggen, og så videre. I tillegg har hun gjort det svært raskt å gjøre endringer på bloggen i produksjon. Noen enkle, automatiserte tester passer på at alt fungerer som det skal.

Ida sørger også for at annonsene vises i to forskjellige versjoner. De har samme innhold, men forskjellig utforming, og hun ønsker å finne ut hvilken av dem som får flest klikk.

Brukerne på sin side opplever en helt vanlig blogg med annonser. Eneste forskjell fra andre blogger er at annonsene lenker til virkelig gode tilbud, og at blogginnlegget gir verdifull informasjon – iallefall for de som hadde tenkt seg på fottur i Nord-Norge.

Fremfor å utvikle noe mer, tar hun seg nå tid til å promotere bloggen. Hun er aktiv på andre reiselivsfora, legger inn kommentarer som lenker til bloggen sin og twittrer. Kanskje skaffer hun seg tilogmed omtale av en etablert blogger, eller Turistforeningen. Hun skriver noen flere innlegg med flere turtips.

Tørrtrening med tørrfisk

Neste steg er å bytte ut én av annonsene til overnatting, og istedenfor promotere et tørrfiskprodukt hun ønsker å selge. Brukeren går da til en annen side på “bloggen”, der et enkelt formular innhenter de nødvendige opplysninger. Formularet lages på samme måte som annonsene, med to utforminger som vises om hverandre (men hun sørger for at samme bruker alltid får se samme versjon av formularet). Det tar henne to dager å utvikle en enkel integrasjon med PayPal, slik at hun kan ta betalt. Siden hun foreløpig bare selger ett produkt, vil innsending av formularet sende henne en epost med informasjonen som ble fylt inn.

Etter nok en uke, analyserer hun dataene – faktaene – hun har samlet. Det viser seg at siden for salg av tørrfisk får flest besøkende med klar margin. Det som overrasker henne mer er at mesteparten av trafikken inn til denne siden ikke kommer fra bloggen. Analyseverktøyet røper at den kommer fra Google-søket “tørrfisk salg”.

Hun bestemmer seg for å legge ut et produkt til, men denne gangen uten annonse fra bloggen. Istedenfor optimaliserer hun nettstedet sitt, slik at søkemotorene indekserer og presenterer den på best mulig måte. I mellomtiden merker hun at salget begynner å øke, og at det snart vil være vanskelig å betjene den nokså manuelle prosessen med epost. Hun implementerer derfor en enkel database-tabell, der bestillingen legges inn. På den måten kan hun nå benytte et standardverktøy for databaser til å hente ut bestillingsinfo.

Etter samtaler med noen lokale kjøpmenn, som tenner på idéen hennes, bestemmer de seg for å legge ut et tilbud som er virkelig godt. En kjempe-deal, som også anbefaler et annet produkt til vanlig pris. Begge deler selger bra, og hun blir overrasket over at mesteparten av trafikken kommer rett fra Google. Hun bruker noen av pengene hun har tjent på salget til å legge ut Google-annonser for å drive inn enda mer trafikk.

På dette tidspunktet har konkurrenten skaffet seg en leverandør, og de jobber iherdig med å spekke opp tjenesten som skal lages. Wireframes, grafisk design og konseptbeskrivelser produseres, mens utviklerene jobber med å sette opp et standardløsning for nettbutikk, og en annen standardløsning for bestilling av reiser (de skal integreres på et senere tidspunkt). Først skal de sørge for at forsiden til tjenesten får den riktige finish, der flotte bilder av storslått nordnorsk natur ruller i en imponerende Flash-animasjon.

Intetanende om konkurrentens ambisjoner jobber vår forretningsutvikler iherdig videre. Hun har kommet i dialog med noen av brukerne, gjennom kommentarfunksjonaliteten hun har lagt til bloggen, og flere av dem har begynt å etterlyse noen forskjellige, enkle funksjoner. De blir svært entusiastiske når hun få dager etter en etterlysning har implementert en enkel førsteutgave av det de ba om. De synes selvfølgelig det er gøy å hjelpe henne forme den videre. Hun får også mye skryt for den enkle brukeropplevelsen, der man kan finne produktet man ønsker seg, og bestille det ved hjelp av få klikk. Flere av de som har gått turen opp til Håtinden har begynt å anbefale bloggen blant sine venner. De begynner igjen å anbefale tjenesten videre, og tilbakemeldinger, ønsker og ros strømmer inn. Hun begynner å se behov for å bygge opp et lite utviklingsteam – én utvikler om gangen.

Antagelser er roten

Denne historien kunne fortsatt, men jeg lar det være opp til leserne å tenke seg hvordan situasjonen ville vært for vår forretningsutvikler når konkurrenten hennes lanserer sin tjeneste året etter (hvis de kommer i mål på estimert tid). Om du ikke tror hennes fremgangsmåte er overførbar til dine omgivelser – kanskje har du rett – så må du iallefall være enig i at hun ikke baserer seg på flaks.

Det gjør derimot alt for mange. De lar seg forføre av en god idé og føler seg deretter forpliktet til å ha alle svarene på forhånd. Dette gir mange utfordringer på veien frem mot lansering. Alle involverte danner seg etterhvert egne oppfatninger av hva som er viktig. Det blir utfordrende å holde fokus, og det oppstår mange misforståelser mellom teknologer og forretningsutviklere. Ingen av dem har harde fakta, som kan stoppe de evinnelige diskusjonene. I dette spekulative klimaet har de færreste tid til å holde i “myke” aspekter, som brukeropplevelse og kundedialog.

Vi tror det er mulig for alle bransjer å rasjonalisere bort gevinsten av tidlige tilbakemeldinger. Problemet er at de som vinner idag gjør det stikk motsatte. Programvare kan – og bør – forandres kontinuerlig. Du må anerkjenne at selv med lang erfaring og høy kompetanse har du intet mer enn antagelser helt frem til den dagen du får betalende kunder. Du må innse at kundene ønsker å være delaktige i utformingen av ditt produkt. Ikke bare detaljene – men hele idéen i seg selv. Du må forstå at vil du investere med IT, så må du bruke IT til å investere.

Ikke alle som satser på flaks feiler. Det ligger i begrepets natur. Noen vinner alltid i lotto. Selv har jeg aldri opplevd det. Verken å vinne i lotto, eller vinne med et prosjekt som ikke oppsøker virkeligheten.

Har du?

Visste du at programvareutvikling kan betale for seg selv?

De fleste private vekstbedrifter i Norge er små og mellomstore. De bruker som oftest en kombinasjon av standard programvare. Noen har også skreddersømløsninger for spesielle behov.

Allikevel lurer mange på hvordan IT-bruken deres egentlig fungerer. Kunne vi jobbet smartere? Hvor lønnsom ble forrige IT-anskaffelse? Er vi tilstrekkelig forberedt på tidene som kommer?

Som IT-konsulentselskap retter Iterate seg mot kunder som trenger ikke-standard programvare, eller som trenger å få forskjellige standardprogrammer til å snakke bedre sammen. IT-utviklingsprosjekter er kostbare, og de innebærer høy risiko, fordi kunden som regel må investere en betydelig sum lenge før prosjektet blir verdiskapende.  Slik skreddersøm er derfor vanligst i store organisasjoner.

Hva gjør da små og mellomstore bedrifter med behov for slike prosjekter?

I samarbeid med nasjonalt og internasjonalt fagmiljø, har vi laget en metode for å utvikle programvare iterativt. Vi kaller metoden Selvfinansierende IT, og målet er å redusere investeringen, uten å redusere muligheten for verdiskapning.

Eksperimenter viser at barnehagebarn som får 20 stenger spaghetti, litt hyssing, teip og en marshmallow, klarer å bygge et tårn høyere enn det toppledere, som får sammen oppgaven, klarer. Årsaken er at barn umiddelbart starter byggingen av tårnet, og jobber stegvis frem til tiden er ute.

Slik jobber vi også, og det er derfor vi heter Iterate. En iterasjon varer noen uker, og leverer programvare som gir din bedrift verdiskapning. Pengene du tjener på programvaren kan du bruke til å finansiere neste iterasjon.

Vi levererer slike iterasjoner til kunden er fornøyd. Dette gir lavere risiko og raskere inntjening. Erfaring viser også at det gir dere bedre løsninger. Hvorfor? Fordi kunden får påvirkningskraft underveis. Fordi kunden lærer underveis. Fordi vi lærer underveis.

Dermed blir det også mulig for vanlige bedrifter å utnytte IT til å skape noe nytt.