Følg mig på Twitter

Speed innovation - sådan!

November 9, 2007 – 6:17 pm

For nogle uger siden konceptudviklede Jesper og jeg vores bank portal oven på kvartalsmøder med vore kunder. Vi havde fået en masse brugbare inputs, og målet med mødet var derfor at definere den videre udvikling af BankTorvet.dk. Efter 4 - 5 timers tegning på white boardet, havde vi ET stort og færdigt udkast klart. Efter en fortjent frokostpause (tænkepause) gik vi tilbage for at estimere udviklingsomfanget og konkluderede at det ville tage 3 - 4 måneder at udvikle.

Det var for lang tid - vi havde et problem…

Vi droppede det hele

I vores virksomhed har vi en regel om, at vi ikke laver produktudvikling, der tager 3 måneder eller derover. Det skal i hvert fald være essentielt, før vi gør det. Vi havde dermed et problem, og blev enige om, at vi sådan set nok var startet forkert og droppede derfor det hele igen.

14 dage fra ide til implementering

Vi besluttede os for at gribe det hele fuldstændig anderledes an ved at tage udgangspunkt i de centrale problemstillinger, fremfor de inputs vi havde fået. De inputs vi havde fået tog vi naturligvis med, men de blev ikke længere brugt som udgangspunkter for ideudviklingen. Vi endte med følgende liste:

  1. Vi vil have glade kunder
  2. Vi vil have glade brugere
  3. Vi vil have flere kunder
  4. Vi vil have flere brugere

Målet var nu ikke længere at finde EN stor løsning, men i stedet en række små løsninger, der hver især hæftede sig op imod en af disse punkter og som maksimalt måtte tage 14 dage fra idefase til gennemført udvikling og integration. Det at vi nu ikke længere skulle tænke i storebæltsbroer, men istedet kunne nøjes med at lægge et bræt over bækken, gjorde ideudviklingen meget mere overskuelig.

White boardet blev opdelt i fire kolonner og vi rystede bogstavelig talt ideer ud af ærmet, og føjede dem til den kollonne løsningen passede til. I løbet af en blot time havde vi noteret omkring 25 løsningsforslag, og kunne efterfølgende prioritere opgaverne.

Vi blev klogere

I fremtiden vil vi altid sigte imod at lave så små og så simple løsninger som overhovedet muligt. Vi er endt op med en masse rigtig gode forslag, som er lynhurtige at udvikle og implementere og som ikke låser systemet / produktudviklingen i måneder.

Det kan måske lyde som om vi er endt op med dårlige løsninger, fordi de er “lettere” end den store. Jeg mener faktisk at vi får meget bedre løsninger, fordi vi i højere grad kan tilgodese alle fire problemstillinger hurtigere end ellers.

Post a Comment