Veikls sagrauj jūsu produktu

Mazu, ātru un autonomu komandu meklējumi rada sadrumstalotu, mulsinošu un nesakarīgu pieredzi.

Joan LeMay ilustrācija

Nepatikšanas paradīzē

Man, strādājot par produktu treneri un konsultantu, pirmais jautājums, ko man parasti uzdod, ir: “Kā mēs varam būt līdzīgāki [slavenajam tehnoloģiju uzņēmumam X]?” Uz šo jautājumu neskaitāmas reizes ir atbildēts labi publiskotos gadījumu pētījumos, piemēram, Amazon “divu picu komandas”, Spotify “komandas, cilšu, nodaļu un ģilžu” modelis un Facebook kopš pensionēšanās “ātri pārvietojas un sagrauj lietas” mantru. Kopumā šie stāsti rada pārliecinošu priekšstatu par to, kā produktu izstrāde izskatās klasē labākajos digitālajos uzņēmumos: mazās, autonomās komandās, kas darbojas zibens ātrumā.

Mazu, autonomu komandu ideja - daudzu Agile metodoloģiju pamatā, ko izmanto mūsdienu tehnoloģiju uzņēmumi - piedāvā pievilcīgu alternatīvu birokrātiskajām, vadības un kontroles struktūrām, kas joprojām dominē korporatīvajā pasaulē. Un tomēr šī pieeja rada arī būtisku risku: ka produkti, ko izveidojušas mazas, autonomas komandas, jutīsies kā atvienots mazu, autonomu funkciju kopums.

Facebook galvenās navigācijas sadaļa “Pārlūkot” (pa kreisi) un viens no daudzajiem nesaprotamo funkciju sarakstiem, kas pieejami Google G-Suite (iepriekš Google Apps) produkta administratoriem (labajā pusē).

Šī anti-modeļa reālās pasaules piemēriem nav jāskatās tālāk par galvenajiem produktiem, kurus izgatavojuši daži no šiem “klases labākajiem” digitālajiem uzņēmumiem. (Skatiet Facebook sākumlapas sadaļu “Pārlūkot”, lai iegūtu īpaši krāšņu piemēru, vai mēģiniet nemanāmi pārvietoties starp produktiem, kas kādreiz tika dēvēti par “Google Apps”.) Tā kā digitālie produkti kļūst lielāki un sarežģītāki, tas ir svarīgāk nekā jebkad agrāk. mēs skatāmies tālāk par atsevišķām funkcijām un domājam par to, kā šīs funkcijas apvieno, lai izveidotu nemanāmu, saliedētu pieredzi. Un, lai to izdarītu, būs jāatzīst, ka pašas atkarības, kas palēnina mazu, autonomu komandu darbu, dažreiz var nākt par labu klientiem, kurus šīs komandas galu galā apkalpo.

Darbības ātrums salīdzinājumā ar klienta vajadzībām

Agile kustības principi un prakse ir izrādījusies īpaši saistoša organizācijām, kas vēlas iet kopsolī ar strauji mainīgo pasauli. Un, bez šaubām, lielu un savstarpēji atkarīgu komandu sadalīšana mazās autonomās komandās, iespējams, palielinās ātrumu, ar kādu katra komanda var atbrīvot uzlabojumus konkrētajā izstrādājuma gabalā, par kuru tā ir atbildīga.

Problēma, izrādās, ir tā, ka iekšējo berzi, ko mazas autonomas komandas noņem, joprojām bieži izjūt ārējie klienti. 2013. gada Hārvarda Biznesa pārskata rakstā ar nosaukumu “Patiesība par klientu pieredzi” ir norādīts kritisks punkts, kas bieži vien tiek zaudēts sarunā par mazām, autonomām komandām: no klienta viedokļa produkta vissvarīgākā sastāvdaļa bieži nav tā individuālās īpašības, bet drīzāk tas, kā šīs funkcijas apvieno, lai izveidotu viengabalainu un saliedētu pieredzi.

Šāda darba noteikšana, prioritāšu noteikšana un veikšana obligāti ietver augstu koordinācijas pakāpi starp komandām un starp tām, un šī koordinācija prasa laiku un pūles. Organizācijām, kas novērtē katras komandas panākumus pēc viņu darba ātruma, tas var radīt acīmredzamu saikni starp darbu, kas klientiem ir vissvarīgākais, un darbu, kuru katra mazā autonomā komanda, visticamāk, uzskatīs par prioritāti. Visbeidzot rodas jautājums: vai autonomija tiešām ir mērķis, uz kuru vēlamies strādāt?

Saliekot to kopā

Lielu produktu sadalīšana mazos, pārvaldāmos gabalos nav viegls uzdevums - bet, izrādās, šos gabalus salikt kopā ir daudz grūtāk. Daudzi pielāgojamie Agile ietvari ir daļēji izstrādāti, lai līdzsvarotu maza mēroga autonomiju un lielu attēlu koordināciju. Bet vissvarīgākais solis ceļā uz mazu komandu savienošanu un koordināciju, kā es atklāju, pētot savu jaunāko grāmatu Agile visiem, ir nevis orģisko diagrammu un ietvaru jautājums, bet gan sadarbības un kultūras jautājums. Kā Man sacīja Spotify izaugsmes un mārketinga viceprezidents, Mayur Gupta:

Kad cilvēki atsaucas uz Spotify modeli, viņi parasti runā par ģildēm, ciltīm un nodaļām. Bet tie ir tikai rituāli. Es neticu, ka jūs nojaucat šķēršļus, mainot ziņošanas līnijas. Kad jums ir patiesi daudzfunkcionāla komanda, ziņošanas līnijas kļūst nebūtiskas…. Turpinot dzīvi un karjeru, jūs saprotat, ka šīs pārmaiņas patiesi virza tieši uz kultūru.

Citiem vārdiem sakot, vienkārši pārveidojot savu organizācijas diagrammu, lai sekotu “Spotify modelim” (vai jebkuram modelim šajā jautājumā), faktiski netiks atjaunota kultūra, kuras rezultātā Spotify - vai kāds no tiem “labākajiem savā klasē” uzņēmumiem - ir sasniedzis tās lielākās uzvaras. Tā vietā, lai sekotu vienam gatavam pieņemt darbības modelim, gandrīz katrs veiksmes stāsts, ko es dzirdēju, pētot Agile visiem, ievēroja trīs augsta līmeņa pamatprincipus:

  • Sākot ar klientiem un viņu vajadzībām, nevis ar uz uzņēmumu orientētu mērķi
  • Sadarboties agri un bieži vien vairākās komandās (neatkarīgi no tā, kā šīs komandas tiek formāli organizētas), lai apzinātu lielās iespējas, kā arī taktiskās atkarības
  • Plānošana nenoteiktībai, lai projekta gaitā faktiski iekļautu jaunu informāciju

Komandas un organizācijas, kas patiesi bija pārņēmušas šos principus, spēja ne tikai sadalīt lielus izaicinājumus mazākos gabalos, bet arī dinamiski pārdomāt, kā šie skaņdarbi atkal sader kopā. Viņu mērķis nebija panākt darbības ātrumu vai tīru autonomiju, bet drīzāk strādāt kopā, lai atrisinātu lielākās un vissvarīgākās problēmas, ar kurām saskaras viņu klienti.

Ceļš uz priekšu: no sudraba lodes līdz elastīgajām organizācijām

Šī raksta nosaukums ir paredzēts provokatīvs, taču tas runā arī ar svarīgu patiesību: darbojas jebkura organizācija, kas ir pārāk koncentrējusies uz darbības, uz uzņēmumu orientētiem mērķiem, piemēram, ātrumu, autonomiju vai “ievērojot veiklīgas sistēmas noteikumus”. risks attālināties no klientiem. Lai arī centieni novērst iekšējo berzi ir cienīgi, mums jāsāk ar izpratni par mūsu klientu piedzīvoto ārējo berzi un nenogurstoši (un sadarbībā) strādājot, lai mazinātu šo berzi.

Šeit ir norādīti daži soļi, kurus jūsu organizācija var veikt, lai izvairītos no ātruma un autonomijas sasniegšanas uz klientu pieredzes rēķina:

  • Pretoties mudinājumam stingri izmērīt progresu pēc darbības ātruma (t.i., atbrīvošanas biežuma vai koda rindām). Tā vietā padomājiet par ātrumu no klienta viedokļa - vai jūs palīdzat viņam ātri un viegli sasniegt savus mērķus? Vai arī jūs palēnināt viņu darbību ar sarežģītu, sadrumstalotu pieredzi?
  • Pārliecinieties, ka individuālie un komandas stimuli nav tik lokalizēti, lai tie netieši kavētu veltīt laiku un pūles darbam komandās.
  • Skaidri atdaliet “labas atkarības” (t.i., iespējas apvienot centienus vai funkcijas klientiem nemanāmā pieredzē) no “sliktajām atkarībām” (t.i., atkarības, kas nevajadzīgi palēnina organizācijas spēju apmierināt klientu vajadzības). Esiet īpaši modrs, meklējot situācijas, kad vairākas komandas veic dublējošu vai lieku darbu - tā ir izplatīta problēma organizācijās, kuras cenšas novērst atkarības un sekmēt autonomiju.
  • Esiet piesardzīgs attiecībā uz visām izvēlnēm un sarakstiem (piemēram, Facebook vietnē “Pārlūkot”), kas var kļūt par atslēgto funkciju avotu. Atcerieties, ka katra jaunā prece, ko jūs nododat savu klientu priekšā, maksā par viņu laiku un uzmanību.
  • Ārpus “veiklības” veiksmīgākās organizācijas ir patiesi elastīgas; tas ir, viņi var ātri izveidot jaunus organizatoriskos modeļus un struktūras bez apjomīgas, formālas pārkārtošanās. Viens tūlītējs veids, kā veidot šo elastību, ir izveidot pagaidu “SWAT komandas” ar pārstāvjiem no dažādiem līmeņiem, funkcijām un funkcijām balstītām komandām, kuru tiešais uzdevums ir izpētīt, kā šo atsevišķo komandu darbs var apvienot, lai izveidotu labāku klientu pieredzi. Kā papildu bonusu mēģiniet uzticēt šādai komandai uzdevumu pilnībā izgudrot visu produktu no nulles, neatkarīgi no tā esošā funkciju komplekta. (Turpmākajā rakstā es rakstīšu vairāk par elastīgajām organizācijām un “SWAT komandas” pieeju.)

Lai iegūtu papildinformāciju par šo tēmu, es ceru, ka jūs apskatīsit manu jauno grāmatu Agile visiem. Kā vienmēr, nekautrējieties sazināties ar mani tieši uz e-pastu matt@mattlemay.com, ja jums ir kādas domas, padomi vai ieteikumi!