Kommer innovation og lommeuld samme sted fra?

Som oftest definere roller og titler hvilke ideer der har værdi. Uanset hvor god en ide er, vil den aldrig blive til noget, hvis igen tror på den eller den ikke kan føres ud i livet. De fleste gode ideer får dødstødet næsten inden de er opstået. Innovation opstår kun når rammerne er til stede i modsætning til lommeuld.

Papirudgaven af Ingienøren have sidst i august et tillæg om innovation. Forsiden var præget af en artikel som præcis beskrev hvordan en virksomhed ved en innovations-workshop havde skabt et sæt helt faste rammer for deres medarbejdere, hvor målet netop var at "få dem til at spille sammen uden at der er nogen, der snupper bolden og løber ud af en tangent", dog uden artiklen indeholdte præcis den formulering. Det lykkedes ved at 2 nye produkter så dagens lys.

Det vigtigste er ikke at slå ideerne ihjel per automatik. Tag imod dem med et åbent sind: Overvej dem seriøst i stedet for at afvise dem per refleks.

Når det så er sagt, er det vigtig siden hen at udfordre ideerne. De fleste af os har en kedelig tendens til at blive forelsket i vores egne ideer. Desværre er det alt for nemt at blive forelsket i en ide. Vi ser det dagligt; Både bland familie, venner, kollegaer og bland ledere i det private såvel som i det offentlige.

Mit mantra kører på: Grib de mest overraskende ideer og overvej dem seriøst. Hvis du stadig tror på ideen efter seriøse overvejelser, så udfordre den på alle tænkelig måder få at forstå den i dybten. Men måske vigtigst: Smid de dårlige ideer væk så hurtigt som muligt og tag de gode og byg videre på.

Det korte svar er: Hav en [b]åben[/b] men kritisk tilgang og så lær at [b]give slip[/b] mens tid er.

Artiklen bærer præg af mangel på viden om hvad innovation er - mennesker genrerer langt flere ideer end de er i stand til at omsætte til handling - problemer er ikke at generere ideer, men at generere iddeer der løser problemer og vide hvordan man ser forskel på gode/dårlige titlag samt hvordan disse omsættes til handling og dermed skaber FORANDRING.

Generelt skal man ikke spilde for megen tid på at genere "ideer" - det er idebehandlingen og navnlig effektueringen som er overbelastet og typisk har for dårlig kvalitet.

Mit bud på Danmarks "problem" kan siges at være at vi er gode til de mange små anti-autoritære tiltag, hvor nogen insisterer på at tage små skridt. Vi er til gengæld hamrende dårlige til at foretage store målrettede tiltag - alene fordi vi ikke fokusere på problemanalyse før vi springer til konklusioner.

I forståelse af Joharis vindue (2- dimensionel matrix hvor man krydser kompetence/inkomptance med bevidst/ubevidst) ligger der uhyggeligt mange fejl som forårsages af at man tror man kender de kausale forhold og derfor griber til tiltag alene ud fra forældede antagelser.

Her er f.eks. et indlæg som illustrerer mange forsøg på at løse problemer med fødselstallet ved at importere storke finansieret ved at fjerne barselsorloven, dvs. tiltag som man tror virker positivt, men reelt skyder os i foden grundet inkompetance og manglende rettidig omhu. http://www.danmark3nul.dk/lars-frelle-petersen-digitalisering-skal-kunne...

Generelt kan man øge innovationsevnen (dv.s den effektuerede forandring) på mange niveauer. Man kan 1) Tydeliggøre problemer 2) Udvælge de rigtige målparamtre (pas på såkaldte kvasi-paramere der risikerer at afspejle noget helt andet ned man tror) 3) Synliggøre kausale sammenhænge, dvs. klargøre hvordan tiltag påvirker målparametre 4) Styrke ide-evalueringen så man sætter de rigtige tiltag i gang. 5) Styrke ide-modningen, dvs. i stedet for at få mange ideer, så blive bedre til at kvalificere og nuancere mulige tiltag. 6) Styrke gennemførseln og herunder navnlig fjerne stopklodser, hvor specielt Mnopoler/karteller og planøkonomiske belsutningskonstruktioner er de kritiske at fjerne for at innovation kan finde sted. 7) Endelig bør man tænke i sammenhængen mellem incentive og indflydelse. Nepotisme og suboptimering er farligt.

Artiklen bærer præg af mangel på viden om hvad innovation er - mennesker genrerer langt flere ideer end de er i stand til at omsætte til handling - problemer er ikke at generere ideer, men at generere iddeer der løser problemer og vide hvordan man ser forskel på gode/dårlige titlag samt hvordan disse omsættes til handling og dermed skaber FORANDRING.

Dit svar bærer præg af at du til daglig ikke arbejder i et travlt udvikler-team.

Det har en stor værdi for et team at få lov til at træde ind i et rum hvor det er muligt at sprøjte ideer ud uden at tænke på om de alle er fantastisk gode, nyttige eller realistiske.

Du har ret i, at for alle ikke-trivielle ideer skal der et disciplineret idébehandlingsarbejde til før det kan omsættes til fremdrift.

Mit bud på Danmarks "problem" kan siges at være at vi er gode til de mange små anti-autoritære tiltag, hvor nogen insisterer på at tage små skridt. Vi er til gengæld hamrende dårlige til at foretage store målrettede tiltag - alene fordi vi ikke fokusere på problemanalyse før vi springer til konklusioner.

En knivskarp analyse! En vis portion iskold rationalitet kunne være et godt alternativ til en god dansk forestilling om at vi nok har fat i den lange ende med vores første, intuitive indskydelse.

Hvor kommer innovation egentlig fra? Opstår det af sig selv ligesom lommeuld, er det noget, man kan planlægge sig til, eller kan man regne med, at de gode idéer til videreudvikling af ens software vil dukke op under juletræet i år, hvis man husker at skrive det på ønskesedlen?

Innovation er indsigt i, hvordan en aktuel kunde måler værdien i en given proces, og herefter evnen til, at forbedre (dvs. tilføre mere værdi ) processen. Som jeg læser indlægget er kunden ikke med i din innovationsproces og det undrer mig derfor bla. hvordan man kan samle mere end 60 ideer på 1.5 time hvor af de fleste endda var brugbare. Hvad er jeres kriterier for en brugbar ide ? At ideerne, som du skriver "nemt og hurtigt kan indarbejdes i produktet" betyder nødvendigvis ikke, at de også er brugbare. Denne fremgangsmåde resulterer gerne i - set fra kunden - unødige komplicerede produkter med en masse overflødig funktionalitet, som ikke tilfører den aktuelle proces værdi.

Succesfuld innovation opnås ikke ved at sidde hjemme og lege med hatte og navneord men derimod ved at forstå hvilke resultater fra en given proces, som giver kunden den ønskede værdi.

Sofie

Rigtig dejlig elitær taylorisme du giver udtryk for. Vi alene vide - troede egentlig den tilgang døde i 60erne med brugerinddragelse, men den har vel aldrig været stærkere fordi "eksperterne" tror stadig at de "forstår" brugerne.

Hatte-tænkning er en udemærket måde at katalysere den ikke-udtalte viden som deltagerne sidder inde med via forskellige fokus.

Selvfølgelig er "udviklingsafdelingen" i bred forstand på godt og ondt den process som katalysere alle input i nyudvikling. Og resultatet bliver ikke bedre end udviklingsafdelingen formår og tager ansvar for at frembringe.

Men

a) Innovation får du først i det øjeblik at tiltag møder realitetstesten - at kunderne runtime tager produktet/servicen til sig og herunder i hvilken grad produktet/servicen rent faktisk møder den enkelte kundes behov (=Kvalitet).

b) Hatte-tænkning har IKKE et eksplicit kunde-perspektiv indbygget udover den forståelse som deltagerne evner at bibringe.

Jeg ville docere en væsentligt højere grad af ydmyghed og erkendelse af at den enkeltes kundes behov er en langt mere kompliceret størrelse end "eksperter" nogensinde vil kunne overskue - og dermed at det gælder om at lytte og tilpasse sig kundernes valg meget mere end at fokusere på udbyder-push processen.

Udbyder-push KAN være heldige, men begår oftest fejl.

Historien er fyldt med eksempler på hvor dårlig ex ante "markedstest" og "bruger-drevet innovation" fungerer. Ingen forudså f.eks. hvor stort SMS ville blive ligesom historien om succesen for kapsel-ekspresso er instruktiv i hvordan en direktørs erkendelse af hans egen adfærd i praksis var meget mere sigende og rigtig end de samlede teoretikkeres modsigelser og anbefaling af at droppe produktet.

I stedet for at bruge tid på den næste gadget-feature, så brug tid på at gøre produktet mere customiserbart i de parameter som virkelig rummer forskelle i kundebehov hos de målgrupper, der addresseres. Pas på I ikke falder i Borger.dk's naive "persona"-fælde - brug NemId som den helt store skræmmecase i arrogant fejldesign.

Rigtig dejlig elitær taylorisme du giver udtryk for.

Taylorisme i den variant hvor arbejderne sidder i rundkreds og bliver opfordret til at komme med deres ideer.

Hvis du kan få flettet en Hitler-sammenligning ind i din argumentation, tror jeg det vil give den en ekstra klangbund.

Jeg ville docere (...)

Det har du vist allerede gjort, Stephan.

Anne-sofie og Rune

Hold nu op med det pjat og hentydninger til "Hitler-jugend" som er nonsens Ad Hominem.

Det kontroversielle er når man utestet antager at de gode ideer afspejler faktiske kundebehov.

Taylorisme i den forstand at udviklerne bilder sig ind at være eksperter på kundernes behov og problem i stedet for en smule ydmyghed. Præcis som når Ingeniører tidligere bildte sig ind at forstå processerne på fabriksgulvet.

Konsekvensen er præcis som jeg skrev ovenfor at man springer til konklusioner som ender i fiaskoer.

Men jeg skriver eksplicit at selvfølgelig er udviklingsafdelingen og dermed selvfølgelig medarbejderne den kritiske katalysator for produktudviklingen.

MEN a) Langt hovedparten af alle produktudviklingsforløb er en fiasko.

Min påstand er at hovedårsagen er udviklernes (i bred forstand inkl. produktmanagers/systemejere) manglende fokus på behov som de faktisk kommer til udtryk og fejlagtige antagelser om egen indsigt og overlegenhed.

b) Innovation skal ses i et dynamisk med- og modspil med både kunder og konkurrenter.

Dem som overlever er dem som er bedst til at tilpasse sig - ikke de absolut stærkeste. En bil er ikke kvalitet fordi den er støbt i jern, men fordi den passer til kundens behov.

Lad mig sige det anderledes.

Vi ved at backtracking hvor man sent i et projektforløb finder væsentlige designfejl vokser eksponentielt i omkostninger fra fase til fase.

Samtidig ved vi med f.eks. agil computering at vi også er nødt til at flytte fleksibelt i kortere og mere isolerede timeboxes.

2 tilsynelande modsætninger

Men ikke hvis du erkende at Design processen drejer sig om at få de langsigtede principper på plads og bruge RIGTIGT MEGEN tid herpå med henblik på at levne rum til en masse fleksibilitet i den konkrete implementering.

McKinsey har en "hestesko"-model hvor de præciserer at det gælder om at bruge megen tid på lang sigt (relativt til problemet), dvs. præcis strategiske afklring af hvor man vil hen samt på helt kort sigt, dvs. flytte handlingsorienteret - men ikke spild en masse tid på det mellemlange sigt.

Min påstand er at Danmark og specielt det offentlige (de store private nicheeksportvirksomheder er noget andet) gør det helt forkert.

Den offentlige sektor er blinde på 2 års sigt og her ikke den fjerneste ide om hvor man skal hen. Samtidig har man ingen frihed på kort sigt, men lider under komplekse bureaukratiske styringsmekanismer som fokusere på 1-2 års sigt. Fokus er på at lave urealistiek projektplaner og sikre at disse overholdes fremfor at fokusere på den præcise abstrakte måldefinition og give plads til den kortsigtede implementering og test af ideer.

E.g. NemId er et trist eksempel på netop dette problem. De har INGEN ide om hvor de vil hen (single signon er absolut ikke en ønskelig måldefinition) og implementeringen er desideret klodset og totalt ufleksibel.

Det samme gælder Borger.dk, Dokumentboks, Medcom.

Danmark er præget af blind "mudling-through" styret af snævre kortsigtede egeninteresser i stive bureaukratiske processer fremfor af abstrakte visioner og klare principper som efterlader handlerum til at eksperimentere med forskellige løsninger på forskellige behov.

De fakto mål-idealet i Danmark er det totale bureaukrati selvom alle erfaringer viser at det går totalt galt og for længst også er gået galt i Danmark med en offentlig sektor hvor produktiviteten falder år for år.

Der er intet galt med hatte-tænkning - tværtimod. Men at sende en udvikler på kursus i "hattetænkning" om et problem, som han basalt set ikke forstår er som at sætte en journalist til at skrive om en teknologi, han ikke har indsigt i. Det er langt mere værd at bruge tid på at forstå materien end på at få lidt processværktøj til at begå fejl med bravour.

Laver du sundheds-it, så tag et 7 dages praktikophold på en hospitalsafdeling fremfor at tage en sygeplejerske som gidsel uden at forstå hvad hun siger.

Lad mig sige det anderledes.

Vi ved at backtracking hvor man sent i et projektforløb finder væsentlige designfejl vokser eksponentielt i omkostninger fra fase til fase.

Samtidig ved vi med f.eks. agil computing at vi også er nødt til at flytte fleksibelt i kortere og mere isolerede timeboxes.

2 tilsyneladende modsætninger

Men ikke hvis du erkender at der er tale om forskellige abstrakte niveauer - at Design processen drejer sig om at få de langsigtede principper på plads og bruge RIGTIGT MEGEN tid herpå med henblik på at levne rum til en masse fleksibilitet i den konkrete implementering.

McKinsey har en "hestesko"-model hvor de præciserer at det gælder om at bruge megen tid på lang sigt (relativt til problemet), dvs. præcis strategiske afklring af hvor man vil hen samt på helt kort sigt, dvs. flytte handlingsorienteret - men ikke spild en masse tid på det mellemlange sigt.

Min påstand er at Danmark og specielt det offentlige (de store private nicheeksportvirksomheder er noget andet) gør det helt forkert.

Den offentlige sektor er blinde på 2 års sigt og her ikke den fjerneste ide om hvor man skal hen. Samtidig har man ingen frihed på kort sigt, men lider under komplekse bureaukratiske styringsmekanismer som fokusere på 1-2 års sigt. Fokus er på at lave urealistiek projektplaner og sikre at disse overholdes fremfor at fokusere på den præcise abstrakte måldefinition og give plads til den kortsigtede implementering og test af ideer.

E.g. NemId er et trist eksempel på netop dette problem. De har INGEN ide om hvor de vil hen (single signon er absolut ikke en ønskelig måldefinition) og implementeringen er desideret klodset og totalt ufleksibel.

Det samme gælder Borger.dk, Dokumentboks, Medcom.

Danmark er præget af blind "mudling-through" styret af snævre kortsigtede egeninteresser i stive bureaukratiske processer fremfor af abstrakte visioner og klare principper som efterlader handlerum til at eksperimentere med forskellige løsninger på forskellige behov.

De fakto mål-idealet i Danmark er det totale bureaukrati selvom alle erfaringer viser at det går totalt galt og for længst også er gået galt i Danmark med en offentlig sektor hvor produktiviteten falder år for år.

Der er intet galt med hatte-tænkning - tværtimod. Men at sende en udvikler på kursus i "hattetænkning" om et problem, som han basalt set ikke forstår er som at sætte en journalist til at skrive om en teknologi, han ikke har indsigt i. Det er langt mere værd at bruge tid på at forstå materien end på at få lidt processværktøj til at begå fejl med bravour.

Laver du sundheds-it, så tag et 7 dages praktikophold på en hospitalsafdeling fremfor at tage en sygeplejerske som gidsel uden at forstå hvad hun siger.

Anne-sofie

Udviklere kommer af alle typer, så jeg siger intet om udviklere - jeg siger at man skal forholde sig mere kritisk og navnlig selvkritisk til den måde, man træffer beslutninger

Jeg siger også at megen udvikling IKKE drejer sig om at gøre en indsats for at finde en løsning på de problemer som KUNDERNE oplever, men på at springe til konklusioner og bruge en masse tid på det fejlbehæftede billede af kunderne, som udviklingsprocesser ofte lider af.

Jeg siger helt generelt at vi skal flytte os fra bruger-dreven gidseltagning til behovdrevent "frie valg" runtime. Med internettet skal vi bruge megen mere tid på KUNDERNE fremfor på MEDARBEJDERNE og EJERNE.

Anne-Sofie

Bemærk dit eget sprogbrug "at udviklere pr. definition ikke forstår de produkter, de udvikler"

Udviklere forstår nok det tekniske produkt de laver, men det relevante er om de forstår det problem, de forsøger at løse.

Problemet skal ses fra KUNDENs synspunkt.

Kundens behov er mange-dimensionelt og under konstant forandring og derfor svært at udtrykke ex ante og generelt. Fejlene opstår fordi udviklere antager at det er kundens problem at oversætte problemet til udviklerens tekniske produktforståelse og derved laver grove fejl og simplificeringer.

Sagt på en anden måde - udviklere har en tendens til at forsøge at tilpasse kunden til produktet i stedet for at løse kundens behov. Det er ikke udtryk for ringeagt, men for en fælde vi alle skal være opmærksomme på og som ofte begås i større eller mindre grad.

Men Stephan:

Præcis som når Ingeniører tidligere bildte sig ind at forstå processerne på fabriksgulvet

Det gør de altså mig bekendt stadigvæk.

Det der er problemet, er at udviklingsafdelinger er befolket med mennesker der bedrager sig selv til at tro at de ved alt om de problemer de prøver at løse. (Jeg ved det for jeg har brugt 12 af mit professionelle liv i en udviklingsafdeling). Problemet med det, er bare at man som udvikler har et meget snævert syn på hvad virkeligheden er og hvad problemer der er. Nemlig et syn der kun omhandler nøjagtigt det produkt man arbejder på. Det vil være godt for udviklere i udviklingsfdelinger, hvis de udviklede i 6 mdr. på et år, og derefter var ude og arbejde med rigtige kunder i den rigtige virkelighed de sidste 6 mdr. Det ville også give meget mere inspiration.

Jeg kender EDB's tænkehatte og vi prøvede dem også for længe siden (fordi nogen havde prøvet det på et eller andet kursus), men problemet er, at man stadigt er låst fast i rammerne af det produkt man laver (og den teknologi man har valgt at bruge til formålet).

Men Stephan:

Præcis som når Ingeniører tidligere bildte sig ind at forstå processerne på fabriksgulvet

Det gør de altså mig bekendt stadigvæk.

Det der er problemet, er at udviklingsafdelinger er befolket med mennesker der bedrager sig selv til at tro at de ved alt om de problemer de prøver at løse. (Jeg ved det for jeg har brugt 12 af mit professionelle liv i en udviklingsafdeling). Problemet med det, er bare at man som udvikler har et meget snævert syn på hvad virkeligheden er og hvad problemer der er. Nemlig et syn der kun omhandler nøjagtigt det produkt man arbejder på. Det vil være godt for udviklere i udviklingsfdelinger, hvis de udviklede i 6 mdr. på et år, og derefter var ude og arbejde med rigtige kunder i den rigtige virkelighed de sidste 6 mdr. Det ville også give meget mere inspiration.

Jeg kender EDB's tænkehatte og vi prøvede dem også for længe siden (fordi nogen havde prøvet det på et eller andet kursus), men problemet er, at man stadigt er låst fast i rammerne af det produkt man laver (og den teknologi man har valgt at bruge til formålet).

Jeg synes, det er vigtigt at hente inspiration mange steder fra. Selvfølgelig får vi også feedback fra kunderne, og vi er ved at lave usability studies. Men jeg kan ikke se, hvorfor udviklingsafdelingen i sig selv ikke skulle kunne spille en aktiv rolle i at bruge sin viden om produktet, de use cases, der knytter sig til det, samt det input vi har fået fra bl.a. kunder til at se på, hvor vi kan forbedre usability.

Udviklingsafdelingens opgave er, at omsætte de indsamlede krav til et produkt - deres opgave er ikke selv at finde på nye krav. Det bør heller ikke være udviklingsafdelings opgave, at tage stilling til om kravene er gode eller ej. Når kravene er nået dertil er det fordi de skal implementeres og ikke debatteres.

Når man arbejde med usability er det langt hen ad vejen et spørgsmål om man kan reducere mængden af kompleksitet for brugen uden at gå (for meget) på kompromis med funktionaliteten. Det kan også være tilfældet, at man finder steder, hvor ens eget produkt gør tingene på en ikke-standardiseret måde i forhold til kendte produkter.

Hvem afgør om kompleksitets mængden bliver reduceret og at der ikke opstår eventuelle sideeffekter som øger kompleksiteten andre steder ?

I en del af tilfældene er det ganske enkelt at tage stilling til, om brugeroplevelsen forbedres eller ej.

Hvem afgør dette og hvordan ?

Og så kan du jo sagtens komme med lystige bemærkninger om at vi "leger med smarte hatte", men jeg ville nu hellere høre om, hvad du gør for at forbedre jeres produkter, udover at modtage input fra kunderne - det kan vel ikke stå alene?

Det var ikke meningen, at det skulle være en "lystig" bemærkning, men jeg indrømmer, at ordvalget blev en anelse for dumsmart. Hvad jeg mener er, at sidde hjemme med diverse kreative metoder bør man benytte en mere pragmatisk tilgang og finde ud af hvad der virkelig skaber værdi for kunden. Jeg siger ikke det er nemt og det løses ikke bare ved at spørge kunden hvad han ønsker. Man bliver nødt til at sætte sig ind processen og se den med kundens øjne før man kan tilføre den rigtige værdi.

Et eksempel: For printer fabrikanterne er innovation bla. hvor mange sider en printer kan skrive ud pr. minut - jo flere sider pr. minut des bedre produkt, mener de. Men er man som bruger ikke - for det meste - ligeglad om printeren skriver 50 eller 100 sider pr. minut ? Til gengæld er det et irritationsmoment, at printeren ofte er løbet tør for papir, når man skal hente sin udskrift. Så det at udviklingsafdelingen bruger tid på hastigheds optimering tilfører ingen værdi til brugerens arbejds process, denne bliver tværtimod forringet.

Anne-Sofie

Hvis du et øjeblik kunne slippe den fornærmede lillepige mine og lytte med åbent sind, så ville du konstatere at det netop er erfaringen og læringen, du lytter til.

Et af udviklernes største problemer er at man tror sig bedre end kunderne til at forstå kundernes behov.

Forudsætningen for at lave bedre produkter/services er mere selvkritik, mere respekt for kundernes/brugernes komplekse behov og mere valgfrihed i løsningsdesignet. Specielti den offentlige sektor, hvor man begår enorme grove fejl på stribe.

Udviklere bør bruge MEGET mere tid på at forstå de reelle problemer førend man kaster sig over "løsningen" (på et fejl- eller for snævert opfattet problem).

Jeg tror man skal forstå Anne-Sofie ud fra hvor hun kommer. Hun kommer fra produktudvikling - hvor software er produktet. Ikke hardware udvikling, hvor software bare er en nødvendighed. Ikke projektbranchen, som udvikler systemer til det offentlige eller private, baseret på hårde kontrakter og kravspecifikationer.

Jeg har selv arbejdet som Sofie, og det er svært, og en det er et område hvor kvalitet ofte er langt højere (og skal være det), end i den projektbaserede branche. Det er desværre også der hvor man er længst fra kunderne (ikke for at fornærme, men det er man), og man skal tage hensyn til rigtigt mange kunder (som er lidt en tåge, for der er så mange), samtidigt skal man tænke på fremtidige kunder, dvs. man skal planlægge og implementere features som kan sørge for at man ikke kommer bagud i forhold til konkurrencen (altså man bibeholder de kunder manhar), og finde på nye fordele til sit produkt som sætter det foran konkurrencen. Der er innovation blandt alle der arbejder med produktet (også udviklere) en gave. Der er rigtig mange udviklere der har noget at byde på, ligesom marketing og salg (dem som er tættere på kunderne).

De fleste af de features der er i produkter (ikke projekter) er enten nogen konkurrenterne har eller nogen der er skabt af innovative medarbejdere. Det er IKKE kunderne der har forlangt dem. De ved nemlig ikke hvad det er de helt har behov for.

Det er ikke kunder der har skabt CD, DVD, Blu Ray, LP, TV, LCD, Harddisk, RAM, Multi core processorer, iPhone, iPad, iTunes, GMail, Google Apps, Facebook osv. det er udviklere (software som hardware) der har innoveret noget, som der så er blevet et marked for.

Softwareudivikling kommer generelt i 3 former: Skræddersyet løsninger til en enkelt kunde, rammesystemer der delvis kan tilpasses en specifik kundes behov og se decideret produktudvikling. Permisserne er væsentlig forskellige fra de 3 typer udviklinger.

Som jeg høre Stephan snakker han primært om skræddersyet løsninger hvor den enkelte kundes behov er i centrum. Produktudvikling med hyldevarer som resultat er en helt anden type udvikling. Rammesystemer befinder sig et sted midt imellem.

Grundlæggende er jeg enig i Stephans betragtninger. Behov bliver alt for ofte misforstået eller forsøgt presset ind i kasser hvor der er alt for trang. Ligeledes bruges der ofte forholdsvis lidt tid på den indledende analyse og forståelse af domænet samt de dybereliggende behov.

Desværre er ansvaret svært at flytte over på udviklingsafdelingen. Mange kunder, herunder også de offentlige, er ikke særlig modne. På leverandørsiden forholder det sig nogenlunde på samme måde, dvs. modspil er nærmest ikke eksisterende.

Kunder ønsker ofte leverancer ret tidligt i forløbet. Det er svært at forklare en kunde at 30% af den samlede udviklingstid skal bruges før der bliver lavet en linie kode. Kunden kan ikke forstå hvad han betaler for. Han betaler jo for software, så skal der da også produceres noget software. I modsatte fald kan det være meget svært at se hvad det er hans penge går til.

Omkring produktudvikling er forholdene helt anderledes. Her ligger alle risici på leverandøren. Her er situationen dog alligevel lidt den sammen. Jo hurtigere de nye produkter kan komme på gaden, jo hurtigere er der afkast af investeringen.

Modenhen spiller en helt central rolle i den måde udviklingsprojekter køre på. Så nok har Stephan ret i sine betragtninger. Desværre er rammerne for behovsdrevet udvikling med fokus på langsigtet strategiske løsninger bare ikke til stedet.

Her er mit forsøg på at skubbe debatten i en lidt anden retning...

Innovation betyder reelt bare fornyelse men den gængse betydning er vel nærmere (kreativ?) fornyelse som skaber værdi...

Som Carsten sagde: "Det vigtigste er ikke at slå ideerne ihjel per automatik."

Og i forlængelse af det vil jeg sige: Slå dem især ikke ihjel inden de overhovedet er født...

Hvis man spørger Ken Robinson (som bl.a. mener at vi "uddanner" kreativiteten ud af børn), så siger han at en vigtig katalysator for kreativitet er at være villig til at tage fejl... Du finder aldrig en hurtigere vej på arbejde hvis ikke du er villig til at prøve en ny rute - som måske er langsommere...

Hvis du har kloge og kreative hoveder i din organisation så vil jeg mene at fornyelsen bobler frem af sig selv hvis bare der er plads til fejltagelser. Dine folk skal nok komme frem med deres nye ideer af sig selv hvis de synes du giver dem tid og rum til det...

Jeg synes egentlig din workshop er et udmærket initiativ men jeg er ikke overbevist at de bedste ideer kan piskes frem på kommando. Jeg tror at (noget af) den tid du giver dem til at brainstorme sammen i nogle tilfælde vi være bedre givet ud hvis de selv individuelt fik lov at disponere over den...

Lad mig sige det anderledes.

Bla, bla, bla... Du har sikkert helt ret Stephan...

Men...

Hvorfor skal du absolut binde et 5-tons offentligt-IT-katastrofe-anker fast til et lille og lækkert optimist-jolle-oplæg som egentlig var meget sjovt at sejle rundt i?

Den omtalte artkikkel fra Ingienøren i August omhandlede en producent at maskiner, jeg kan ikke huske præcis hvilke. Work-shoppen var bygget op omkring et rum hvor medarbejderne kuunne udtrykke de ideer de allerede havde uden de blev skudt ned 'per automatik'. Samtidig var virksomhedens direktør ikke direkte en del af seancen. Som han selv udtrykte det: 'Folk ved godt at jeg bestemmer'. Hans blotte tilstedeværelse ville hæmme den åbne kreative kommunikation.

Som Anne-Sofie udtrykker det, dukker de mest kreative ideer ofte op på uventede tidpunkter i uventede situationer: Når vi reflektere over oplevelser og problemstillinger.

Processen nok ikke direkte forceres. Den kan dog gødes: Giv plads til reflektion og fordybelse. Og så sørg for at have rigeligt af materiale og reflektere over, jo mere input jo bedre, og jo større diversitet i input jo bedre. Samle gerne input fra utraditionelle kilder, f.eks. de mest krævende og de mest irriterende kunder. En del af disse udtrykker faktisk nogle af de grundlæggende mangler i den nuværende understøttelse af behov.

Anne-Sofie

Dua gerede nærtagende uden grundlag og det påpegede jeg bare.

Du fortsætter med den arrogante/selv-centrerede forståelse af at innovation er noget som opstår i hovedet på udviklere.

Måske kan man forbedre den proces, hvor man "seed'er" hjernen?

Den seedning kommer udefra i form af behovstilkendegivelser fra kunder/markedet som man kobler med viden om muligheder.

Med fare for at gentage mig selv, så skal man bruge MEGET mere tid på at analysere problemer og meget MINDRE tid på at forfinde forhastede "løsninger".

Når man først forstår problemet, så giver løsningen ofte sig selv. Den primære kilde til fiasko er en for snæver / anstaget problemforståelse.

Selvfølgelig skal man være opdateret på værktøj-siden, men det er mange gange nememre at søge efter værktøjer på problemer, man forstå, end at finde problemer til de værktøjer man har fattet sympati for.

Verden er fyldt med "løsninger" og "ideer" som desparat søger at finde problemer som kan betale for løsningen.

Det vi har behov for at bedre problemforståelse med ydmyghed overfor modsætninger og kontinuerte forandringer, konkurrence, berøringsflader, værdier og fundamentale principper.

Test dig selv - prøv at definere "Frihed under Ansvar" i en teknisk forståelse som passer til et demokrati/markedsøkonomi.

Har du først fattet det så erkend at det er 1000 måder at gøre det på teknisk - hvordan vil du så sikre at de er interoperable?

Når man først har fattet at det kan man "sagtens", så er man i færd med at forstå pointen i problemanalyse som den primære drivkraft for innovation.

Og først da begynder man at forstå at hatte-tænkning ikke drejer sig om at tænke ens, men om at tænke rundt om problemerne og specielt finde ens empatiske egenskaber frem for at kunne sætte sig i andres sted i forskellige scenarier.

Øvrige

Jeg tænker så absolut på produkt-udvikling til mange forskellige, jf. f.eks. denne diskussion http://www.version2.dk/artikel/17142-er-digitalisering-svaret#headline86598

@Stephan

Øvrige

Jeg tænker så absolut på produkt-udvikling til mange forskellige, jf. f.eks. denne diskussion http://www.version2.dk/artikel/1714...

Det kan være du tænker på det, men du skriver ikke om det.

Et eksempel på innovation i virksomheder er Googles 80/20 model (som er lånt fra 3M), som giver masser af innovation der kan omsættes til værdi for virksomheden.

Iøvrigt er det en teknisk definition af frihed under ansvar.

Det er ok du ikke er enig med Anne-Sofie (og mig selv), og det har du ret til. Men lad dog være med at udtale dig kategorisk, som om du har patent på sandheden. Anne-Sofie og jeg har åbenbart nogle erfaringer der er anderledes end din opfattelse af virkeligheden (og den må jeg sige ser ret så firkantet ud herfra). Det må du acceptere.

Et eksempel på innovation i virksomheder er Googles 80/20 model (som er lånt fra 3M), som giver masser af innovation der kan omsættes til værdi for virksomheden.

Men hvor vil du hen med dette - diskussionen handler netop om at være i kontakt med kunderne ? I de 20% er Google kunden og de ansatte skal skabe innovation og levere værdi til Google. Men de bruger stadig 80% af deres tid på at udvikle ud af huset til eksterne kunder og her skal der også skabes værdi.

De 20% må de lave hvad de vil, bare de ikke arbejder på deres almindelige opgaver. Dvs. de må innovere helt vildt. Google er arbejdspladsen der betaler løn, og måske en kunde i sidste ende vis det de laver er noget der skaber en salgbar værdi (og så må de ikke bruge de 20% på det længere). På den måde er Google ikke kunden i de 20%, det er de i de 80% (og end customer er os).

Hvis du havde fulgt med i artiklen (diskussionen har en diskurs mod dette projekt marked, hvor Anne-Sofie ikke arbejder - så lad os tale om produkt udvikling!), så ville du også kunne læse at jeg aggitere for at udviklere sagtens kan innovere, og også er fulde af gode ideer.

At I ikke er, eller at I arbejder sammen med nogen som I ikke mener kan, det gør ikke at resten af os ikke kan, eller arbejder sammen med folk der kan.

Hvor vil du iøvrigt hen med dit indlæg, jeg forstår det kun som om du med vilje misforstår, for at prøve at komme med en pointe, som så bliver væk?

Nicolai

Hvis du nu tog et lille skridt tilbage, så ville du konstatere at Anne-Sofie kunne taler om et lille subset af det, jeg taler om.

For det første er vi ikke uenige om at udvikler selvfølgelig indgår med kreativ forståelse baseret på deres erfaringer og viden. Kvaliteten af deres arbejde er en central del af forandringsprocesser.

For det første er det ikke innovation førend det har forandret noget i markedet. En ide er ingenting førend den er omsat til noget som ændrer på noget. Du kan bruget 10.000 timer på et nyt stykke software - det er ikke innovation førend nogen bruger det.

For det tredje, så taler jeg om hvordan udviklere bliver bedre udviklere ved at fokusere på kunder fremfor at tro at innovation er noget som opstår som lommeuld fra dem selv - ikke om hvordan ANDRE gør udviklerens arbejde.

For det trejde, så taler jeg om at udvikler skal være mere ydmyge fremfor at tro at de kan overskue de problemer, de har med at gøre. At lave værktøjer er ikke at løse problemer - at løse problemer er noget som problemejer gør med værktøjer, men ofte bruges værktøjerne anderledes end udviklerne havde tænkt. Og endnu ofterere hæmmer udviklernes forsimplede problemforståelse problemløsningen.

Så - uden at tale ned til nogen - kravl ned fra den hvis hest.

De 20% må de lave hvad de vil, bare de ikke arbejder på deres almindelige opgaver. Dvs. de må innovere helt vildt.

Læs Googles "80-20 Rule" manifest igen. Der er visse retningslinier som bla. siger, at ingeniørerne må bruge 20% af deres tid på andre virksomheds relaterede opgaver, som har deres interesse. Der står intet om at de må lave "hvad de vil". Kig evt. og på hvilke ting som er blevet udviklet efter denne model.

Hvis du havde fulgt med i artiklen (diskussionen har en diskurs mod dette projekt marked, hvor Anne-Sofie ikke arbejder - så lad os tale om produkt udvikling!), så ville du også kunne læse at jeg aggitere for at udviklere sagtens kan innovere, og også er fulde af gode ideer.

Det er muligt, at du mener det, men sådan forholder det sig ikke i de fleste tilfælde - som du jo selv kan se længere oppe i debatten.

Så - uden at tale ned til nogen - kravl ned fra den hvis hest.

Ja ja ja - det er iøvrigt sjovt hvordan folk begynder på det personlige plan lige pludseligt - måske er der nogen der følder sig klemt :-)

Nej... Stephan, du har ikke uret, men jeg synes du taler i øst og vest, på en eller anden måde bliver du ved til du får ret. Det her handler ikke om at få ret - det handler om at verden ses af mange. Det handler også om at Toyota selvfølgeligt lytter til deres kunder, men i enden ved de mere om biler end kunden.

Læs Googles "80-20 Rule" manifest igen. Der er visse retningslinier som bla. siger, at ingeniørerne må bruge 20% af deres tid på andre virksomheds relaterede opgaver, som har deres interesse. Der står intet om at de må lave "hvad de vil". Kig evt. og på hvilke ting som er blevet udviklet efter denne model.

Jeg har min viden fra en blog post skrevet af en Google ansat, samt en bekendt der arbejder for Google (i Californien) - at de har et manifest der siger een ting, er ikke det samme som, at det er praksis. Men fred være med det. Vi kan jo så tage 3M og hører lidt på Mary Poppendick om dette (eller læse nogen af bøgerne).

Pointen er at udviklere sagtens kan være innovative, det er vel svært at modsige (selvom en masse prøver).

Det er muligt, at du mener det, men sådan forholder det sig ikke i de fleste tilfælde - som du jo selv kan se længere oppe i debatten.

Jeg kan så sige det samme til dig. Hvad baserer du det udsagn på? Er det noget du ved?

Nicolai

Din Google-reference siger ingenting om det problem, der diskuteres. Fordi den ikke siger noget om hvor inspirationen kommer fra eller hvilken process som ligger bag.

Anne-Sofie lancerede den gammelkendte hatte-tænkning som om innovation er noget som opstår ud af det blå i hovedet på udviklere. (Det er iøvrigt en fejlopfattelse af hattetænkning, men so be it).

Jeg påpeger at det både er forkert og en farlig tankegang fordi det fører til den ligeså velkendte "ekspert-arrogance" eller taylorisme hvor udviklere sidder i en osteklokke med deres mere eller mindre besynderliger forestillinger om realiteterne uden at turde "røre" verden og blive berørt, dvs. uden at lade virkeligheden inficere deres problemforståelse.

Hvorefter udviklerne så prøver med mere eller oftest mindre held at pådutte deres vrangforestillinger på verden - des senere fejlene konstateres desto større backtracking.

Jeg siger så baseret på viden (mit teoretiske speciale er innovation som konkurrencekraft) og erfaring (jeg har også gjort masser af fejl specielt som nydannet know-it-all og navnlig set mange fejl) at man netop skal insistere på - selv eller som leder af en udviklingsafdeling - at få en højere grad af ydmyghed og realitetstest ind i processen.

Herunder at det drejer sig om at bruge meget mere tid på problemforståelse førend man laver technology-push, dvs. indoptage problemforståelse førend man er klar til at løse problemer.

Det som jeg ser er en småfornærmet opfattelse af at udviklere er "bedre" end andre.

Men vi ser fejlene vælter ind over os fra den "osteklokke"-tænkning. Tag bare fra i dag, hvor det næste katastrofeprojekt blev lanceret. http://www.version2.dk/artikel/17171-logica-vinder-udbud-af-el-datahub-t...

Men der er viden i landet som kunne have undgået den katastrofe som dette fejl-designede udbud uundgåeligt vil ende i, medmindre nogen slår hul på "osteklokken". Se f.eks. http://ing.dk/artikel/94539-intelligente-elmaalere-er-paa-vej-mod-standa...

Og ja - der er menge flere katastrofer i det offentlige hvor økonomistyringen gør at man ikke behøver bekymre sig om kundernes holdninger og dermed bare kan "Send more money", når fejlene og dårligdommene akkumulerer. I den private sektor dør den slags projekter oftere og hurtigere.

Anne-sofie

Du bliver ved med at se det som en konkret situel kritik fremfor som en generel problemstilling og antager - også her - at du skal "forsvare" dig konkret. Jeg har ikke kritiserer hvad I gør konkret, men påpeget fejl i den mentale model som er fremlagt. Den kan ikke rumme virkeligheden og slet ikke innovationsprocesserne.

Jeg har i mit blogindlæg beskrevet hvordan vi har prøvet at få udviklingsafdelingen til at komme med idéer til løsninger på nogle forholdsvis gammelkendte problemer i vores produkt.

Det som man "tror" er gammelkendte problemer.

Det er måske rigtigt, men det er også præcis det hvor man typisk rammer skævt - i problemopfattelsen og måden, man spørger på.

Jeg har givet dig en generel metode til at forbedre situationen - send udviklerne ud blandt kunderne og lad dem mærke kundernes FORETNINGSMÆSSIGE problemer i praksis. Usability er vigtigt men ikke løsningen hvis produktet er fejldesignet.

Og - uden at kritisere nogen - ALLE produkter og services kan forbedres, dvs. alle produkter og services er ud fra en innovationsmæssig forståelse fejldesignet fordi man altid kan gøre det bedre. Det er altid en "næste" version og - medmindre man strækker sig - en "bedre" konkurrent.

Det er essensen af konkurrencens værdiskabelse for samfundet. Udbydere vil gerne se sig selv i centrum - men det er kundens valg og navnlig fravalg som driver verden.

Jeg gider ikke diskutere det her længere - det er umuligt at opnå en accept af at udviklere kan være innovative, og at det er godt. Derimod skal det hamres fast med stratofæriske generaliseringer, at det er det ikke, og hvis nogen prøver, er det taylorisme og/eller andre rigtigt dårlige klistermærker sættes på.

Mit forsøg på at deltage, var at sige, at der foregår god innovation i nogle udviklingsafdelinger, men ikke alle. Hattetænkning har aldrig tiltalt mig, jeg synes personligt ikke om processen. Men at kategorisk afvise at udviklere skal være innovative, synes jeg er at gå alt for langt.

Det snakkes forbi hinanden, om det er bevidst - tja det ved jeg ikke? Men i hvert fald.

Over and out.

@Stephan Lad nu være med hele tiden at inddrage de her offentlige IT projekter, for ja de er rigtigt katastrofale, men der er rigtigt mange forskellige årsager til det: kontraktformen, processen for udbud (indberegnet kravsspec. udfærdigelsen) og mange flere. Vi kan kun være enige om, at det ville være rart at lave om på den måde alt dette i dag foregår på, da det er en tilsvining af os borgere, den måde hvorpå vores skattekrone benyttes til at lave IT. Men det er en anden snak, som jeg ser som dybt irrelevant for denne diskussion.

Du bliver ved med at se det som en konkret situel kritik fremfor som en generel problemstilling og antager - også her - at du skal "forsvare" dig konkret. Jeg har ikke kritiserer hvad I gør konkret, men påpeget fejl i den mentale model som er fremlagt. Den kan ikke rumme virkeligheden og slet ikke innovationsprocesserne.

Oversat til almen dansk betyder det: Kritikken er rent professionel og faglig, [b]ikke[/b] personlig.

Må jeg spørge hvordan du - i de situationer hvor vi taler udvikling af et produkt til mange kunder - kommer fra identifikation af problem til løsning? Er der nogen som i din verden er "bedre" en udviklerne til at foretage dette skridt?

Jeg kan svare for mig selv:

Første skridt er at forstå om problemet i det hele taget er som først antaget. Det kan f.eks. testes ved at snakke med udenforstående, dvs. aktører der ikke umiddelbart har nogen interesse i hverken problem eller løsning, potentielle kunder om du vil.

Andet skridt kan være at teste løsningen inden den bliver implementeret. Det kan gøres ved at fremlægge den for eksisterende kunder og så nøje betragte reaktioner og lytte til feedback.

Teknik er jo blot en del af det samlede kundeforhold til den enkelte kunde. Menneskelige og sociale aspekter betyder ofte mindst lige så meget som teknikken i udformningen af løsninger og de tilhørende konkrete implementeringer. Innovation har så meget desto bedre vilkår jo mindre de menneskelige relation former løsningen.

Nicolai

Vi snakker ikke "forbi" hinanden. Du og Anne-Sofie taler fra perspektivet på bunden af en ølflaske på et transportbånd, mens jeg taler om hele processen fra humle til nydelse.

Hvis udviklerne laver en "bedre" øl - men ingen kan lide den eller ingen køber den, så er det ikke "innovation", men ressourcespilde.

Det kan være en "opfindsom" eller "kreativ" øl, f.eks. en blå øl eller en som skifter smag i munden, men det er en Invention og ikke en Innovation førend værdikæderne ændrer sig.

Den samlede proces kan altså være innovativ, men det er begrebsforvirring at kalde en enkeltstående person for innovativ. Udviklere indgår i processen og kan bidrage, men er kun en del af processen.

Anne-sofie rejser så de klassiske spørgsmål

Må jeg spørge hvordan du - i de situationer hvor vi taler udvikling af et produkt til mange kunder - kommer fra identifikation af problem til løsning?

Den eneste årsag til at du laver "et produkt til mange kunder" er for at spare omkostninger.

Men det er rent logisk ikke anderledes end at lave et produkt til en kunde - dit problem er at dit produkt risikerer at blive fanget i ingenmandsland og prøver at være noget for alle og dermed intet for nogen.

Dit produkt er ikke bedre end hvor godt en konkret kunde opfatter dit tilbud om kvalitets/pris relativt til konkurrenter.

Betyder din produktudvikling at flere kunder rent faktisk vælger dit produkt (grundet bedre pris eller bedre kvalitet for den specifikke kunde) eller I tjener mere på det samme produkt, så er det innovation - ellers ikke.

Er der nogen som i din verden er "bedre" en udviklerne til at foretage dette skridt? Eller sætter du dig ned og venter på, at kunderne selv kommer til dig og severer løsningen på et sølvfad - og kan man forlange det af sine kunder?

Kunde fortæller dig det hver eneste dag i deres tilvalg og fravalg, samt hvis du er rigtig heldig i formaliseret kommunikation.

Om du er i stand til at forstå kunden er så en anden ting og din risiko.

De færreste mennesker er i stand til at formidle hvordan en abstrakt løsning på et hypotetisk problem skal indrettes - men de ved det når de skal vælge. Lyt til kundens problemkommunikation og studer hvad det gør og læg specielt mærker til når kunder ændrer adfærd - der er signalværdien enorm.

En god marketingafdeling og sælgere bør være tæt på kunden behovstilkendegivelser - men ligesom udviklere kan agere i en osteklokke, så er der mange marketingafdelinger som blot sælger på features uden at sætte sig nok ind i kundernes problemopfattelse.

Selvfølgelig

Technology-push & udbyderes forsøg på at lancere nye produkter er selvfølgelig en forudsætning for at kunder har nye muligheder at vælge imellem.

Men set dynamisk er det meste produktudvikling en reaktion på kunders tilvalg, dvs. de fleste "produktudviklingerger" er varianter på noget kudnerne allerede køber med henblik på at teste kundernes faktiske behov - feedback er først og fremmest tilkøb (handling) snarere end rundbodssamtaler.

Jeg siger intet om hvem du skal rette dit produkt imod - kun at du er i den klassiske afvejning mellem enkeltkundetilpasset Ordreproduktion (typisk dyrt) og standardproduktets lagerproduktion (typisk lavindkomst commodityprodukt), samt at den it-teknologiske løsning på dette trade-off er mass customisation og konfigurationsmuligheder.

Men det er stadig dit ansvar som udvikler at undgå at falde mellem 2 stole.

En mellemting mellem et barberblad og kosmetik har ingen kunde. Så enten laver du barberblade til både mænd og kvinder med de produktforskelle det medfører, kosmetik til både mænd og kvinder i det omfang det er muligt eller også må du vælge kundegruppe og dermed indsnævre målgruppen for at sikre at du leverer konkurrencedygtig nytteværdi til din målgruppe.

isoleret set skal du altså lave et produkt til hver kundegruppe - kan de smeltes sammen uden at miste kunder, så er der synergier, kan de ikke er det bedre at lade være.

NemId som en skambidt hybrid mellem en PKI digital signatur og en simpel site-specifik login-mekanisme er et skræmmeeksempel på hvad man IKKE skal gøre