Store produkter sker ikke ved uheld

Brug af playbooks til design og bygning af produkter

Dette er slides og speaker notes fra en præsentation, jeg holdt den 21. juli 2016 på Design & Content Conference i Vancouver, B.C ..

Jeg vil gerne begynde at stille dig et simpelt spørgsmål. Hvordan gør du, hvad du gør? Dårlig grammatik og alliterering til side. Det vil sige, hvilke handlinger udfører du gentageligt og konsekvent for at gøre det, du er bedst til?

Mens du tænker over det, vil jeg fortælle dig om min erfaring med at besvare dette spørgsmål.

PMI Process - sådan byggede vi websteder i 1998

Jeg begyndte at lave ting på Internettet i 1994. Jeg overlevede den første bølge af Internettet, hvor jeg havde arbejdet med for mange forfærdelige PM-drevne projekter, der var så belastet med processen, at de ikke havde nogen evne til at reagere på fluiditeten ved at fremstille software.

Kravspapirer oprettet på dag 1 var irrelevante på dag 2, men processen dikterede en kompleks protokol for at fortryde noget, der var aftalt på dag 1.

Forandringsstyring var så smertefuld, at det undgik for enhver pris. Så du arbejdede på et projekt, der havde forkert antagelser oven på dårlige beslutninger. Dette førte til massivt design og tekniske fordærvende produkter og projekter inden de endda blev lanceret.

MS-projekt

Det herskende dokument om projekter på det tidspunkt var Gantt-diagrammet, der syntes at være den eneste output fra Microsoft Project. Hvis du levede gennem denne æra, kan du sandsynligvis huske, at hele vægge var dækket af projektets Gantt-diagram.

Gantt-diagrammer viser strømmen af ​​arbejde og deres indbyrdes afhængighed. Når du hører folk tale om vandfaldsprocesser, kommer de fra denne metode til at arbejde. Diagrammet skaber visuelt et "vandfald", da afhængigheden af ​​arbejdsstrømmen er visualliseret ... også navnet på TLCs største sang.

Henry Gantt og hans kort

Diagrammet er navngivet til Henry Gantt en århundredeskift produktionschef vendte management konsulent, der troede på metoder til videnskabelig ledelse. Scientific Management, også kendt som Taylorism, er en teori om ledelse, der analyserer og syntetiserer arbejdsgange. Dets hovedmål er at forbedre den økonomiske effektivitet, især arbejdsproduktiviteten. Den forsøgte at maksimere den økonomiske effektivitet i fabrikker og butikgulve ved at minimere affald forårsaget af ineffektive arbejdstagere.

Arbejdet med Taylor og Gantt blev vidt diskrediteret og i vid udstrækning opgivet af 1930'erne. Teorierne var så dehumaniserende og moralsknusende for arbejderne, implementeringen var fiaskoer.

Videnskabelig ledelse var afhængig af at omfatte forestillingen om, at der var ”en bedste måde” til at udføre en opgave. Man troede, at man gennem videnskabelig måling kunne bestemme den mest effektive bevægelse af arbejdstagere (f.eks. Den bedste måde at skovle kul på) og derefter ordinere denne bevægelse til alle arbejdere.

Den iboende fejl ved Scientific Management var, at den ikke havde klare metoder til at håndtere teknisk innovation eller løbende forbedringer.

På trods af sin fiasko overlevede nogle dele af videnskabelig ledelse ind i moderne tid, to bemærkninger er brugen af ​​timefakturering og Gantt-diagrammet.

Da jeg kom ansigt til ansigt med Gantts håndværk i midten af ​​90'erne, var det allerede 80 år gammel, et relikvie, der var tænkt til effektiv produktion af svinejern og pistolpulver, der blev anvendt til oprettelsen af ​​software og design.

Venkatesh Rao er en bawse

Men i de tidlige 2000'ere begyndte revner at vise sig i de puristiske metoder til bygningssoftware. Stigningen af ​​open source-software og lavprismæssigt hardware krydset med boblepop af dot coms.

Selvom det ikke er direkte skylden, er det nu klart, at mange af den første generation af webvirksomheder mislykkedes på grund af, hvordan de byggede deres produkter. Vedtagelse af puristiske tilgange til softwareudvikling på toppen af ​​monolitiske hardwaresoftwarestakke, der spændte under deres egen vægt. Venkatesh Rao sidestiller dette med et forudsigeligt svigtningsmønster, der eroderer alle industrielle aldersmodeller for produktion, distribution og salg.

I midten af ​​2000'erne steg en ny race af virksomheder ved hjælp af nye, mere smidige metoder til at opbygge deres produkter.

Agile's fødsel

Meget af dette skift og kan være en kredit til en gruppe af 17 softwareingeniører, som i 2001 mødtes i Snowbird Utah for at diskutere letvægtsudviklingsmetoder.

De blev enige om og skrev ned et sæt værdier, der skulle definere det, vi nu kalder Agile.

Disse værdier sætter en tung præmie på forandring og tilpasningsevne.

Jeg tror, ​​at agile eller pragmatisk design foregik i 2006, men dette er vigtige eksempler

Omkring denne samme tid på en parallel sti kom nogle af os i designfællesskabet til lignende erkendelser som softwareingeniører. Meget langsomt stoppede vi med at generere rækker af dokumentation som 200 sider wireframe-dæk og statiske mock, i stedet for at se enorm værdi i oprettelsen af ​​0-arbejdssoftware og iteration.

I 2000'erne oplevede teknologiforringelse af konjunkturcykler og stigende forstyrrelse af traditionelle forretningsmodeller. Da teknologien flyttede distributionsomkostninger tæt på nul, var vigtigheden af ​​hastighed og smidighed ikke længere en konkurrencedygtig differentierer for virksomhederne, men essentiel for virksomhedernes eksistens.

I slutningen af ​​2000'erne hævdede virksomheder i Silicon Valley, at selv fiasko blev hilst velkommen, så længe den kom hurtigt. Agile metoder afslørede fejl hurtigere og derfor overlegne.

Den offentlige fiasko af sundhedsvæsenet.gov syntes uundgåelig for alle, der arbejdede inden for tech. Webstedet, der var blevet udviklet med bagvæggen af ​​industrielle aldersmetoder og virksomheder (offentlige entreprenører), måtte reddes af den nye vagt af bygherrer, der bragte metoder, der var populære i Silicon Valley og startups til Washington.

Denne fiasko tjener som den symbolske afslutning på en kamp mellem to modstridende verdensanskuelser. I denne kamp syntes forhandlingen at være afgjort med pragmatisk, smidighedsejr over stive metoder.

Det er inde i dette miljø, vi har ofret ”proces” til agilitygudene.

Processen er blevet en fuldmagt for de gamle metoder og fjenden for fremskridt.

Værktøjer overalt

Da vi værdsætter smidighed, er vores teknologi og værktøjsmæssighed steget for at gøre det muligt for os at forfølge den. Disse samme produkter og aktiverende teknologier har fremskyndet tilbagegangen i strukturerede metoder til bygningssoftware. Og disse værktøjer er fantastiske. De låser vores kreativitet op og hjælper os med at opbygge løsninger, der forhåbentlig forbedrer liv.

Men vi er blevet en branche, der bruger en masse tid på at diskutere de relative fordele ved den ene Javascript-ramme eller prototypesoftware i forhold til den anden. Vi diskuterer uendeligt, om designere skal kode, og i bekræftende fald hvilket sprog de skal lære.

Vi er blevet besat af hurtighed, smidighed og hvordan vi får det.

Mens jeg tror på hurtig iteration og validering ...

når hastighed bliver det eneste, vi taler om, er det dårligt ... virkelig dårligt.

Når vi stopper op og spørger ”hvordan skal vi gøre, hvad vi gør?”. Vi har ikke rigtig gode svar. Vi har en tendens til at svare med hvilket værktøj vi bruger. Spørg en designer, hvordan de designer, og de vil normalt svare “In Sketch”.

Dette er som at spørge en snedker, hvordan de byggede det møbel, og de reagerede med ”en hammer”.

Så lad mig gå tilbage til det spørgsmål, jeg stillede i begyndelsen ... “hvordan gør du det, du gør”?

Jeg er blevet lidt besat af dette spørgsmål i de sidste par år, jeg er interesseret i svaret, så jeg stiller mange mennesker dette spørgsmål, og det mest almindelige svar, jeg får, er ...

”Det afhænger” er et forfærdeligt svar. Men det føles godt at sige, fordi vi findes i en branche, der værdsætter hurtig iteration og skifter mening. Det afhænger af, at indstillingsværdien bevares.

Tænk på at høre "Det afhænger" som svar på spørgsmål, hvad du ville fjerne?

Q: Kaptajn, hvordan flyver du dit fly? A: Det afhænger

Q: Dr. hvordan vil du udføre dagens operation? A: Det afhænger

Q: Elsker du mig? A: Det afhænger

Der er to problemer med at besvare et spørgsmål med “Det afhænger”.

For det første indebærer det, at du ikke har nogen overbevisning om, at du ved, hvordan man gør, hvad du er god til. Det betyder, at du ikke har fundet noget tydeligt mønster, der gentagne gange giver et vellykket resultat.

For det andet er det ikke sandt. Der er et helt sæt af ting, du gør instinktivt; at løse problemer, skrive, designe, forskningsadfærd, indsamle og analysere data. Du har bare ikke kodificeret det ved at identificere de konsistente mønstre, der findes.

Inden nogen debat eller diskussion om processen skal du acceptere, at det arbejde, vi udfører, ikke er fatalistisk. Du skal tro, at skabelse af produkter eller hvad du end gør, ikke kun er en usynlig hånd, men i stedet noget, der kan opnås gennem forsætlige gentagne handlinger og rammer.

Dette er ikke at sige, at held eller timing ikke er variabler, men at de ikke er de eneste variabler. Dette er ikke at sige, at en proces garanterer succes, men at den biaser dig mod den.

Hvis du mener, at den eneste måde at finde produktmarkedstilpasning er at kaste en masse ting mod væggen og håbe, at noget klæber, er det vanskeligt at diskutere eller diskutere forsætlige metoder.

Hvis du tror, ​​det er tilfældet. Så kan du lige så godt starte ethvert projekt med et drømmebræt. Du siger, at The Secret er en værdifuld driftsfilosofi. Hvis du tror på dette, er enhver diskussion af processen spild af tid.

Jeg tror ikke på det. Jeg tror ikke, det er tilfældigt. Jeg tror ikke, at det hele er en ulykke. Jeg tror, ​​at gode produkter ikke sker ved et tilfælde.

Hvor mange af jer kender dette? Det er en del af præsentationen, som Spotify bruger til at forklare, hvordan de implementerer Agile. Hver gang jeg begynder at tale om at være mere bevidst om, hvordan vi bygger, er det det mest citerede eksempel på, hvorfor man ikke skal være stiv.

Der er to problemer med dette diagram.

  1. Mens diagrammet er en stor forenkling af iterativt design, tror jeg ikke, at hvis du vil bygge en bil, skal du først bygge et skateboard. Det antages, at der er nogle klare beviser eller data, der fortæller teamet, at motorcyklen kan eller bør blive en bil.
  2. Det andet problem er, at vi aldrig ser ud til at tale om det næste lysbillede i præsentationen ...

Den anden dias, som folk snakker om mindre, er denne, den, der siger, at der skal være en slags plan for, hvordan du gør, hvad du gør. Grove, adaptive arkitekturer er det, der tager os ud af rammen af ​​visionboards.

Men hvad er grove adaptive arkitekturer?

Grove arkitekturer er et sæt af grænser, vi bruger til at vejlede os i dynamiske miljøer.

I improvisationsmusik er den uslebne arkitektur tempo og nøgle. Så længe musikerne ikke krænker denne arkitektur og lytter til hinanden, kan de skabe utallige musik.

I improviserende teater er den uslebne arkitektur et sæt regler som ... siger "ja og", "tilføj oplysninger efter og", "Undgå spørgsmål".

Hvis du spørger en komiker, hvordan de improviserer, er deres svar ikke "være morsom", de vil fortælle dig et sæt regler, der skal følges ... som giver dem mulighed for at være sjove.

Den bedste uslebne arkitektur, jeg har fundet til byggeprodukter, kommer fra ...

Fodbold.

Fodbold er et dynamisk miljø med skiftende variabler, som spillere og træner har brug for at reagere på. Hold forsøger at bevæge bolden ned ad banen ved at løbe eller passere i et bestemt antal stykker.

Til vores formål er det alt hvad du virkelig har brug for at vide om fodbold, at dens ru arkitektur udover reglerne er skuespil.

Både overtrædelsen og forsvarskørsel spiller for at prøve at vinde spillet.

Det giver ingen mening for en træner at forud bestemme, hvert eneste spil, så de kører i et spil, før de træder på banen, da de ikke ved, hvor godt hvert stykke fungerer.

Det ville også give meget lidt mening for spillerne at bare gøre, hvad de følte var lige på banen. Der kræves et vist niveau af koordination og kollektiv aftale for at vinde spillet.

I løbet af en coachkarriere vil de skabe og arve hundreder, hvis ikke tusinder af teaterstykker. Disse samles i playbooks. Hvis du aldrig har set et fodboldspil, ser de sådan ud ...

Det betyder ikke rigtig noget, hvis du forstår, at i dette spil blokerer tacklingen den defensive ende, eller at det er tre modtagere på vingen. Det er mere vigtigt at forstå arkitekturen i et teaterstykke.

Et spil er et aftalte sæt handlinger, holdet foretager i en given situation. Når træneren siger ”lad os køre Statue of Liberty Buck Sweep” ved alle, hvad det betyder, og ved hvad de skal gøre for at udføre det spil.

I vores verden, når du siger ”lad os bygge en MVP”, ved alle, hvad det betyder? Forstår vi hver vores rolle i udførelsen af ​​dette skuespil?

Hvis du nogensinde har set en fodboldkamp, ​​vil du se trænere med laminerede kort.

Disse kort er en undergruppe af teaterstykker fra coachens spillebog, som de mener kan virke for det spil, de spiller. Dette lader dem tage beslutninger i øjeblikket. En træner kan have 1000 stykker i spillebogen, men vil kun bruge en brøkdel i en spilsituation.

Spil kort

Spelskort skitserer tilgængelige muligheder for forskellige scenarier, de kan støde på i et spil. F.eks. 3. nede-afspilninger, 2 minutters bor, kick off-afspilninger. Disse teaterstykker er skabt gennem en karriere inden for coaching. En playbook er den indsamlede viden fra en coach eller hold om ”HVORDAN de gør, hvad de gør”.

Jeg tror, ​​vi er nødt til at oprette playbooks til byggeprodukter. Vi er nødt til at have et sæt skuespil, vi kan gå til, så vi kan bygge bedre produkter smartere og hurtigere.

Opbygning af en legebog med HVORDAN du bygger produkter er vigtig for enhver virksomhed, men mangler for de fleste.

At have et konsistent format til at dokumentere afspilninger er vigtigt for en fungerende spillebog. Afspilninger ligner opskrifter, hvor de har et standardformat (ingredienser, procedurer, værktøjer), der gør det nemt at læse et sæt opskrifter og forstå dem.

Din spillebog skal også have et konsistent format. Mens du kan oprette uanset skabelon, du ønsker, er her nogle ting, du kan lære af fodboldspil.

Navngiv din afspilning - Navne på skuespil skaber delt sprog. Sørg for at give en definition af navnet for at sikre, at alle forstår, hvad det betyder. Et skuespil kaldet MVP kunne have en masse betydninger.

Hvornår skal køres - definer situationer, hvornår dette styre skal køres. Mens de fleste teaterstykker kunne køres på ethvert tidspunkt i et produkts livscyklus, er de fleste teaterstykker mest effektive i en bestemt situation. Det er muligvis ikke bedst at køre en post mortem eller efter en gennemgang af produktet for tidligt i produktet, ligesom at sparke på andenpladsen ikke er en god ide.

Hvorfor skal man løbe - hvis holdet kører dette spil godt, hvad kan de forvente? Hvorfor er dette spil overlegent med andre handlinger, holdet kunne tage, eller hvilken fordel kan holdet håbe at opnå gennem dette spil?

Roller - kortlægge, hvilke roller der findes for stykket, og hvad man kan forvente af forskellige mennesker

Sådan løber du - skitsér trinnene i stykket. Hvilke gentagne handlinger gør du for at køre dette skuespil.

Pro tip - alt hvad teamet skal vide eller ressourcer, de skal læse.

Jeg ser en masse hold på Facebook, der kører dette stykke. Designsprinter.

Design Sprints er et skuespil, som du kan kalde på en bestemt del af det spil, du spiller for at få fremskridt. De har et sæt diskrete og definerede handlinger, du kan køre for at opnå et ønsket resultat. De har gentagne trin.

Designsprints er 5 dage, de har ordineret handlinger og roller. Mens hver Design Sprint er forskellig, har den en arkitektur, der skal følges. Design Sprints fungerer bedst i de tidlige faser af produkter, men kan køres når som helst i produktets livscyklus (de fungerer mindre godt, når du går mod lancering).

Indholdskort, prototyper, internationalisering, revisioner, lanceringsplaner ... de er alle skuespil. Alt, hvad du gør, der har nogle gentagne handlinger, er et spil.

Der er skuespil, du måske bruger meget ...

... og nogle bruger du sjældent.

At tænke i form af en legebog giver dig mulighed for at omfatte løbende forbedringer, da du altid kan fjerne gamle skuespil, der ikke længere fungerer og kontinuerligt tilføje nye, når de oprettes. Playbooks kræver kun, at hold bruger de teaterstykker, der fungerer for dem i deres situation.

Afsnit kan grupperes, uanset hvor du vil ... måske tror du, Stanford D-Schools designtænkningsmetode er bedst. Organiser dine skuespil for at kortlægge de forskellige faser.

organiser mere omkring en faseret implementeringsmodel

Afspilninger kan grupperes efter discipliner

eller situationelt. Dette er situationer, som hold, som vi kender hold, vil finde sig i, og her er skuespil, de kan køre, der har fungeret tidligere. Så hvis du prøver at validere en idé, her er skuespil, du kan køre, hvis du prøver at prioritere eller bestemme, hvad du skal bygge først, her er skuespil, du kan køre, hvis produktet ikke fungerer.

Så næste gang nogen spørger dig, hvordan gør du det, du gør ... kan du vise dem din playbook.