Veikls sprints salīdzinājumā ar dizaina sprints

Kā un kad savienot šos jaudīgos ietvarus, lai izveidotu jaunus produktus vai pārdomātu esošos.

Fons

2000. gadu laikā biznesa pasaule bija pieradusi pie tādiem produktu attīstības terminiem kā veikls, ērts, viegls un MVP.

Notika maiņa, kas daudzus no mums attālināja no industriāla vecuma iedvesmotiem ūdenskritumu procesiem, kur viss tika dokumentēts sākotnēji, un pēc tam virzījās pa skatuves vārtiem, līdz produkti beidzot bija gatavi izvietošanai. Ūdenskrituma vietā nāca iteratīvas attīstības pieejas, ieskaitot Scrum, Kanban, XP (ekstrēma programmēšana) un citas variācijas.

Šīs disciplīnas atdalījās no tvertnes un ūdenskrituma pieejas, aizstājot to ar liesiem, izmērāmiem būvēšanas, pārbaudes, kuģošanas cikliem. Šie ātrie cikli, parasti 1–2 nedēļas, tika precīzi nosaukti par “sprintiem”.

Produktu un projektu vadītāji spriegošanas plānu vietā ievietoja Ganta diagrammas, lai organizētu produktu attīstības plānus - prioritārās funkcijas tika noņemtas no produkta aizmugurē esošās daļas, sprinta atlikumiem, nodotas cauri sprintam un pēc tam nodotas ražošanai.

Ar Agilebuddha.com atļauju

Un, tiklīdz C-suite un pārdošanas un mārketinga vadība pierada pie sprintiem un iemācījās runāt savu tehnoloģiju grupu jaunākajā valodā, 2015. gadā sāka burbuļot jauns “sprints” - “Design Sprint”.

Dizaina sprintus, kas veidoti pēc IDEO dizaina domāšanas ietvara, sākotnēji Google inkubēja Džeiks Knaps, kur viņi palīdzēja organizēt tādu produktu kā Gmail un Hangouts (tagad Iepazīstieties) veiksmīgu palaišanu.

Gadu gaitā un simtiem gadu spriešanas laikā Džeiks galu galā uzlaboja procesu līdz vietai, kurā daudznozaru komandas varēja pavadīt 5 dienas, lai saprastu, idejētu, izstrādātu prototipus un pārbaudītu lielās biznesa problēmas, pirms sākt pilnvērtīgu produktu izstrādi.

Pēc neskaitāmiem veiksmes stāstiem GV satvēra Džeiku un dizaina sprintus, lai viņi varētu sākt tos piedāvāt (gan Džeiku, gan sprintus) saviem portfeļa uzņēmumiem. Izmantojot sprintus, lai palīdzētu tādiem uzņēmumiem kā Uber, Slack un Blue Bottle Coffee (starp daudziem citiem), Džeiks un vairāki citi GV dizaina partneri sadarbojās, lai 2016. gada 8. martā izdotu grāmatu Sprint. Tā ātri kļuva par NY Times un WSJ Bestselleru. .

Produktu grupas visā pasaulē kopš tā laika ir patērējušas, pārbaudījušas un ieviesušas dizaina sprintus savā instrumentu komplektā. Bez šaubām, dizaina sprints ir mainījis veidu, kā jebkuras formas un izmēra uzņēmumi vēršas pret jaunu produktu un pakalpojumu attīstību.

Bet tur ir viena lieta

Kopš dizaina sprinta pirmoreiz sāka veidoties viļņi, vairākkārt tika uzdots ļoti specifisks jautājums. Mēs to dzirdam gandrīz katrā no darbnīcām, kuras mēs piedāvājam iemācīt dizaina sprintiem produktu vadītājiem, dizaineriem, inženieriem, pētniekiem un vadītājiem: “Kā dizaina sprints ir saistīts ar veiklām attīstības sprintiem?”

Un tāpēc šodien es ceru ieskaidrot, kā dizaina sprints ir saistīts ar veikliem attīstības sprintiem gan jaunizveidotiem izstrādājumiem, gan esošo produktu atjaunošanai vai atjaunošanai.

Bet vispirms ļaujiet man uzgleznot visu ar digitālo produktu izstrādes procesu saistīto attēlu ...

Programmatūras inovācija

Jaunajā matu griezumā mēs domājam par digitālu risinājumu radīšanas procesu lielu problēmu risināšanai 8 cieši savstarpēji saistītās darbībās.

Kaut arī vizuālais izskats ir secīgs, ir svarīgi ņemt vērā, ka produkta attīstība nekad nav lineāra.
  • Uzņēmējdarbības sakārtošana: nolemj strādāt pie problēmām, kas atbilst uzņēmuma stratēģijai, vīzijai un resursiem
  • Lietotāju izpēte: Iepazīstiet vairāk par tirgu, lietotājiem un konkurenci, kas apņem šīs problēmas
  • Dizaina domāšana (izmantojot dizaina sprints): izpratnes veidošana par problēmu un prototipu risinājumu apstiprināšana potenciālajiem klientiem
  • MVP plānošana: izveidojiet pilnīgu sava risinājuma attēlu un izlemiet par minimālo vērtīgo produktu (MVP), kuru tirgū laidīsit, izmantojot produkta ceļvedi
  • UX dizains: informācijas arhitektūras, mijiedarbības un uz cilvēku vērstās pieredzes plūsmas veidošana, ko jūs piedāvājat savā risinājumā.
  • Vizuālais noformējums: piešķiriet risinājumam stilu, toni un saskarni (attiecīgā gadījumā)
  • Loģistika: Izstrādājiet risinājuma sistēmas infrastruktūru un lietojumprogrammu arhitektūru
  • Veikla attīstība: sava programmatūras risinājuma būtības veidošana un laišana tirgū.

Piezīme: daudzas komandas apvieno UX un / vai vizuālo dizainu veiklā attīstībā - mums šķiet, ka tas parasti vislabāk darbojas vienkāršāku lietojumprogrammu un nelielu funkciju uzlabojumu gadījumos. Veidojot uzņēmumu digitālos produktus, mēs esam uzskatījuši par efektīvāku un lietderīgāku tos viegli atdalīt, lai arī komandas bieži strādā vienā brīdī.

Jaunu produktu sprints

Pirmoreiz izmantojot šādu pieeju - kad jūs sākotnēji veidojat jaunu produktu - dizaina sprints notiek pirms veiklās attīstības sprinta.

Tam ir jēga - pirms sākat projektēšanu un kodēšanu, jums ir jāizveido dažas problēmas un lietotāja perspektīvas un pēc tam jāpārbauda risinājumi ar vienreiz lietojamiem prototipiem. Prototipi ir ne tikai lētāki un ātrāki, bet arī komanda emocionāli iegulda mazāk prototipa nekā skaisti noformēti ekrāni un darba kods.

Kā?

Iznākot no dizaina sprinta, jums ir prototips, kas pārbaudīts ar ~ 5 mērķa lietotājiem. Kā tad mēs varam pāriet no prototipa uz funkcionālu, strādājošu produktu?

Produktu ceļvedis izvērsīs īpašu uzmanību jūsu dizaina sprinta prototipā, lai precizētu atlikušās, prioritārās funkcijas / ekrānus / lietotāju plūsmas. Šīs prioritātes kļūst par ierakstiem jūsu produktu krājumā, ko pēc tam var ievadīt jūsu veiklajā dev sprintā.

Koda sprints

Mēs vienmēr pārliecināmies, ka mūsu projektēšanas sprintos ir inženierijas eksperts. Tomēr mēs pamanījām, kad šis vienīgais inženieris atgriezās projektēšanas sprintā atpakaļ viņu arhitektu, kodētāju un testētāju komandai - joprojām bija daudz jautājumu, pirms viņi varēja iedziļināties.

  • Kāda ir labākā tehnoloģija?
  • Vai ir kādi risinājumi, kurus varam iekļaut?
  • Kur mums vispirms vajadzētu koncentrēties?

Tāpēc mēs izstrādājām Code Sprint (jā, mēs pievienojām vēl vienu “sprinta” vārdu maisījumam… atvainojiet?).

Jauns matu griešanas kods Sprint

Code Sprint tehnoloģiju komandas pavada 4–5 dienas, lai:

  • Izprotiet visu iepriekš apkopoto informāciju
  • Balsojiet par 2–3 lielākajiem tehnoloģiju izaicinājumiem, kas viņiem būs jāpārvar
  • Atšķirīga izpēte un konkurējošu prototipu veidošana katram izaicinājumam
  • Pārbaudi prototipus, kas palīdz izlemt par uzvarošo (-ām) ieviešanu (-ām)

Mēs modelējām Code Sprints, lai izmantotu tās pašas intensīvās fokusēšanas, ilguma un atšķirīgās-konverģējošās tehnikas, kā Design Sprint. Pēc tam mūsu tehnoloģiju komandas spēja atbildēt ne tikai uz jautājumiem: “Ko mēs būvējam?” Un “Kā mēs to veidojam?”, Bet arī izveido pamata infrastruktūras, arhitektūras un koda slāni, uz kura balstīties savā veiklajā attīstības sprints.

Gaidāmie uzlabojumi

Sējot veiklās dev sprints ar dizaina un koda sprintiem, mēs esam pieredzējuši dažus būtiskus uzlabojumus gan produktos, kurus mēs palīdzam mūsu klientu uzņēmumiem ieviest, gan arī praksēs, kuras mēs izmantojam to palaišanā:

  • Atgūstiet vairākus mēnešus un gadus veltītos centienus, kas saistīti ar problēmām, kuras cilvēkiem nerūp
  • Ļaujiet uz inženierijas virzītām organizācijām efektīvi sadarboties ar citiem produktu izstrādes procesā
  • (no augšas uz augšu) Ļaujiet lomām ārpus izstrādājuma un tehnikas, lai būtu nepieciešama un atzinīgi vērtēta sēdvieta pie risinājumu dizaina galda
  • Nodrošiniet inženieru komandas ar empātisku skatījumu un lietotāja balsi, kuras viņiem parasti trūkst

Esošo produktu sprints

Bet kā būtu, ja strādājat pie esoša produkta?

Viena kļūda, ko daudzas komandas pieļauj, pirmo reizi pieņemot dizaina sprintus, ir to pārmērīga izmantošana. Viņi sāk darboties dizaina sprintos par gandrīz katru funkciju, kuru viņi vēlas ieviest. Vai lapai pievienojat veidlapu? “Izpildīsim sprintus.” Vai veidojat mūsu Android lietotnes iOS versiju? “Sprints!” Tas ir pārspīlēti.

Dizaina sprints vislabāk ir paredzēts problēmai, kas atspoguļo kritisku biznesa iespēju vai izaicinājumu. Piemēram, ja jūsu uzņēmums nolemj sākt piedāvāt jūsu produktu pilnīgi jaunam klientu segmentam, tas ir galvenais lēmums, kas būtu jāpieņem, izmantojot dizaina sprintu.

Kā?

Esoša risinājuma radīšana rada ierobežojumus vairākos iespējamos veidos:

  1. Tas liek mums izvēlēties risinājumu, pirms mēs pilnībā saprotam problēmu
  2. Tas ietekmē risinājumus, kurus mēs piedāvājam
  3. (ja mums jāveido esošais risinājums) Tas ierobežo mūsu risinājumus šī risinājuma ietvaros - tas ir īpaši grūti, ja šie risinājumi nav mūsu kontrolē; piem. trešo personu platformas / dati / piekļuve

No otras puses, esoša risinājuma nodrošināšana mums sniedz arī etalonus, kuriem jauniem produktiem nav piekļuves.

Ja ritināsit atpakaļ uz augšpusē esošo jauno matu griešanas pieejas diagrammu, redzēsit, ka problēmas apstiprināšana ir kritiska dizaina sprintam (risinājuma validācija). Parasti tas notiek etnogrāfisku pētījumu, aptauju, papīra (pazīstams arī kā īpaši viegls) prototipu veidā. Tomēr, kad var izmantot jau esošos risinājumus, jūs saņemat papildu datu avotu.

Triks, izmantojot esošos risinājumu datus, ir ieskats, sans ieviešanas aizspriedumi. Citiem vārdiem sakot, meklētie dati vairāk attiecas uz modeļiem (labiem vai sliktiem), pamatojoties uz problēmu, kuru pašreizējais risinājums mēģina atrisināt.

Noteikti var atzīmēt, kā šis risinājums pašlaik ir ieviests, taču tam nevajadzētu stipri ietekmēt gaidāmo dizaina sprintu, kura mērķis ir atklāt jaunas iespējas. Atcerieties, ka dizaina sprinta priekšrocība ir tā, ka jums ir nodrošināta vieta lieliem sapņiem, izmantojot pilnīgi jaunus, interesantus un dzīvotspējīgus risinājumus.

Šīs mantotās novirzes dēļ tas bieži nozīmē, ka ļoti rūpīgi jāpārdomā komandas locekļu no iepriekšējiem iemiesojumiem izmantošana nākamās paaudzes risinājumos. Tas, kas parasti darbojas, ir sprinta nedēļas pirmdien piesaistīt iepriekšējos komandas locekļus kā ārējos ekspertus.

Ieguvumi

  • Izmantojiet kritisko ieskatu, kam jauniem produktiem nav piekļuves
  • Jauni risinājumi var aizņemties no esošajiem risinājumiem vai nu atkārtot, vai arī radīt pilnīgi jaunu pieredzi

Un kā izskatās esošam produktam, lai iesāktu dizaina sprintu, pirms pāriet uz veiklu attīstību?

Iesaiņošana uz veikliem sprintiem un dizaina sprintiem

Produktu izstrādes komandas pastāvīgi atrodas zem ieroča, lai iegūtu labākus produktus tirgū mazāk laika un budžeta ietvaros. Kadences apvienošana, kurā tiek izmantotas dizaina sprintu, kodu sprintu un veiklās attīstības sprints priekšrocības, ļāva mums to izdarīt arī mūsu klientiem - es ceru, ka tas piedāvā tādas pašas iespējas jūsu organizācijai.