Agile rikub teie toodet

Väikeste, kiirete ja autonoomsete meeskondade otsimine loob killustatud, segaseid ja hajutatud kogemusi.

Joan LeMay illustratsioon

Hädad paradiisis

Minu tootetreeneri ja konsultandina töötades küsitakse tavaliselt esimest küsimust: “Kuidas saaksime olla sarnasemad [kuulsa tehnoloogiaettevõtte X]?” Sellele küsimusele on loendatud lugematu arv kordi hästi reklaamitud juhtumiuuringutes, näiteks Amazoni “kahe pizza meeskonnad”, Spotify “meeskonna, hõimude, peatükkide ja gildide” mudel ning Facebooki pensionile läinud inimesed “liiguvad kiiresti ja lõhuvad asju” mantra. Tervikuna kokku võttes loovad need lood köitva pildi sellest, milline näeb välja tootearendus oma klassi parimatel digiettevõtetel: väikesed, autonoomsed meeskonnad, kes tegutsevad välkkiirel kiirusel.

Väikeste autonoomsete meeskondade idee - paljude kaasaegsete tehnoloogiaettevõtete kasutatava Agile metoodika tuum - pakub ahvatlevat alternatiivi bürokraatlikele juhtimis- ja juhtimisstruktuuridele, mis endiselt domineerivad ärimaailmas. Ja sellegipoolest kaasneb selle lähenemisviisiga ka oluline oht: väikeste autonoomsete meeskondade loodud tooted tunnevad end eraldatud väikeste autonoomsete funktsioonide komplektina.

Facebooki peamise navigeerimise jaotis „Avasta” (vasakul) ja üks paljudest arusaamatutest funktsioonide loenditest, mis on Google'i G-Suite'i (endine Google Apps) toote administraatoritele kättesaadavad (paremal).

Selle anti-mustri reaalmaailma näidete jaoks ei pea vaatama kaugemal kui lipulaevatooted, mille on valmistanud mõned neist “oma klassi parimatest” digiettevõtetest. (Vaadake eriti hõlpsa näite saamiseks Facebooki avalehe jaotist „Avastage” või proovige sujuvalt navigeerida toodete vahel, mida kunagi nimetati „Google Appsiks”.) Kuna digitaalsed tooted kasvavad suuremaks ja keerukamaks, on tähtsam kui kunagi varem, et vaatame kaugemale üksikutest funktsioonidest ja mõtleme, kuidas need omadused ühendavad, et luua sujuvaid ja sidusaid elamusi. Ja see nõuab teadvustamist, et väga sõltuvused, mis aeglustavad väikeste autonoomsete meeskondade tööd, võivad mõnikord olla kasulikud klientidele, keda need meeskonnad lõpuks teenindavad.

Töökiirus vs kliendi vajadus

Agile liikumise põhimõtted ja tavad on osutunud eriti köitvaks organisatsioonidele, kes soovivad sammu pidada kiiresti muutuva maailmaga. Ja kahtlemata suurendab suurte ja üksteisest sõltuvate meeskondade jagamine väikesteks autonoomseteks meeskondadeks tõenäoliselt kiirust, millega iga meeskond saab teha parandusi selle toote osas, mille eest ta vastutab.

Probleemiks selgub, et väikeste autonoomsete meeskondade eemaldatud sisemine hõõrdumine on väliste klientide poolt endiselt sageli tunda. 2013. aasta Harvardi ettevõtte ülevaateartikkel nimega „Tõde kliendikogemuse kohta“ toob välja kriitilise punkti, mis sageli kaob väikeste autonoomsete meeskondade vestluses: kliendi seisukohast pole toote kõige olulisem osa sageli selle individuaalsed omadused, vaid pigem kuidas need omadused kokku panna, et luua sujuv ja ühtne kogemus.

Sellise töö ulatuse määramine, tähtsuse järjekorda seadmine ja täitmine eeldab tingimata meeskondadevahelist ja omavahelist tihedat kooskõlastamist - see koordineerimine võtab aega ja vaeva. Organisatsioonide jaoks, mis mõõdavad iga meeskonna edukust oma töö kiiruse järgi, võib see luua silmatorkava ühenduse kliendi jaoks kõige olulisema töö ja töö vahel, mida iga väike autonoomne meeskond tõenäoliselt tähtsustab. Lõpuks tekitab see küsimuse: kas autonoomia on tõesti eesmärk, mille nimel tahame töötada?

Pannes selle kokku

Suurte toodete jaotamine väikesteks, hallatavateks tükkideks pole lihtne ülesanne - kuid nende tükkide kokku panemine on aga palju keerulisem. Paljud skaleeritud Agile-raamistikud on loodud osaliselt tasakaalustama väikesemahulist autonoomiat suure pildi koordineerimisega. Kuid kõige olulisem samm väikeste meeskondade ühendamise ja koordineerimise suunas, nagu ma avastasin oma viimast raamatut Agile for Everybody uurides, on vähem org-diagrammide ja -raamistike küsimus kui koostöö ja kultuuri küsimus. Nagu Spotify majanduskasvu ja turunduse asepresident Mayur Gupta ütles mulle:

Kui inimesed viitavad Spotify mudelile, räägivad nad tavaliselt gildidest, hõimudest ja peatükkidest. Kuid need on lihtsalt rituaalid. Ma ei usu, et te aruandlusliinide muutmise abil tõkkeid ületate. Kui teil on tõeliselt funktsionaalne meeskond, muutuvad aruandlusliinid ebaoluliseks…. Oma elu ja karjääri jätkates mõistate, et neid muutusi tõepoolest juhib kultuur.

Teisisõnu, lihtsalt oma organisatsiooni diagrammi ümberjoonistamine, et järgida „Spotify mudelit” (või mis tahes mudelit selles küsimuses), ei taasta tegelikult seda kultuuri, mis on Spotify - või mõne neist „oma klassi parimatest” ettevõtetest - saavutanud selle suurimad võidud. Ühtse kasutuselevõtuvaliku järgimise asemel järgisid peaaegu kõik edulood, mida kuulsin Agile for Everybody'i uurimisel, kolme kõrgetasemelist juhtpõhimõtet:

  • Alustades klientidest ja nende vajadustest, mitte ettevõttekesksest eesmärgist
  • Tehakse koostööd varakult ja sageli mitme meeskonna vahel (sõltumata nende meeskondade ametlikust korraldusest), et teha kindlaks suured võimalused ja ka taktikalised sõltuvused
  • Ebakindluse kavandamine uue teabe reaalseks kaasamiseks projekti edenedes

Need põhimõtted tõeliselt omaks võtnud meeskonnad ja organisatsioonid suutsid mitte ainult jagada suured väljakutsed väiksemateks tükkideks, vaid ka dünaamiliselt mõelda, kuidas need tükid uuesti kokku sobivad. Nende eesmärk polnud saavutada töökiirust ega puhast autonoomiat, vaid pigem teha koostööd klientide ees seisvate suurimate ja olulisimate probleemide lahendamisel.

Tee edasi: hõbekuulidest elastsete organisatsioonideni

Selle artikli pealkiri on ette nähtud provokatiivseks, kuid räägib ka olulist tõde: iga organisatsioon, mis on liiga keskendunud operatiivsetele, ettevõttekesksetele eesmärkidele nagu kiirus, autonoomia või “järgides agiilse raamistiku reegleid”, jookseb klientidest kaugemale tõmbamise oht. Ehkki sisemise hõõrdumise eemaldamise püüdlus on vääriline, peame kõigepealt mõistma klientide poolt kogetud välist hõõrdumist ja töötama väsimatult (ja ühiselt) selle hõõrdumise minimeerimiseks.

Siin on mõned sammud, mida teie organisatsioon saab teha, et vältida kiiruse ja autonoomia saavutamist kliendikogemuse arvelt:

  • Pidage vastu soovile mõõta edusamme rangelt töökiiruse (st vabastamise sageduse või koodiridade) järgi. Mõelge selle asemel kliendi seisukohast kiirusele - kas aitate neil eesmärke kiiresti ja hõlpsalt saavutada? Või aeglustate neid keerukate, killustatud kogemustega?
  • Veenduge, et individuaalsed ja meeskondlikud stiimulid poleks nii lokaliseeritud, et need kaudselt ei soovitaks võtta aega ja vaeva meeskondade vaheliseks koostööks.
  • Eristage selgelt „head sõltuvused“ (s.t võimalused ühendada jõupingutused või funktsioonid klientide jaoks sujuvaks kogemuseks) „halbadest sõltuvustest“ (st sõltuvustest, mis aeglustavad tarbetult organisatsiooni võimet täita klientide vajadusi). Olge eriti tähelepanelik, kui otsite välja olukordi, kus mitu meeskonda teevad dubleerivat või üleliigset tööd - see on tavaline probleem organisatsioonide seas, kes on püüdnud sõltuvusi kõrvaldada ja iseseisvust edendada.
  • Olge ettevaatlik kõikehõlmavate menüüde ja loendite suhtes (nagu Facebooki leht „Avasta”), millest võib saada lahtiühendatud funktsioonide prügila. Pidage meeles, et iga uus ese, mille klientidele ette annate, maksab nende aja ja tähelepanu hinnaga.
  • Lisaks agilityle on edukaimad organisatsioonid tõeliselt elastsed; see tähendab, et nad saavad kiiresti luua uusi organisatsioonilisi mustreid ja struktuure ilma massilise, formaalse ümberkorralduseta. Üks otsene viis selle elastsuse loomiseks on moodustada ajutised SWAT-meeskonnad, millel on esindajad mitmest tasemest, funktsioonidest ja funktsioonipõhistest meeskondadest, kelle ülesandeks on selgesõnaliselt uurida, kuidas nende üksikute meeskondade tööd saab parema kliendikogemuse loomiseks ühendada. Lisaboonusena proovige sellisele meeskonnale määrata kogu toote täielik nullist leiutamine, sõltumata selle olemasolevatest funktsioonidest. (Kirjutan tulevases artiklis lähemalt elastsetest organisatsioonidest ja SWAT-i meeskonna lähenemisviisist.)

Selle teema kohta lisateabe saamiseks loodan, et leiate minu uue raamatu Agile kõigile. Nagu alati, võtke minuga julgesti ühendust aadressil matt@mattlemay.com, kui teil on mingeid mõtteid, näpunäiteid või ettepanekuid!