Omul mitic-luna

În calitate de lider de produs la o companie de tehnologie, sunt o groapă fără fund de nevoi. Sarcina mea de Director de Produse la Mailchimp este să aduc pe piață produsul care va câștiga într-un spațiu foarte competitiv. Aspirațiile Mailchimp sunt mari și pentru a le realiza trebuie să livrăm o cantitate substanțială de produs pe piață. Deseori, pentru mulți din companie, se simte că facem prea multe. Suntem mereu la marginea roților care se desprind.

Și când faci prea multe și te hotărăști să faci mai mult decât atât, vei începe inevitabil să auzi referire la The Mythical Man-Month . Este ca una dintre acele mingi de ameliorare a stresului în care, dacă strângi un capăt, apoi iese Miticul-Luna omului la celălalt capăt.

Publicată de Frederick Brooks în 1975 (vă mai amintiți de 1975, nu? Când dezvoltarea de software semăna 100% cu dezvoltarea de software în 2020?), această carte este destul de renumită printre inginerii de software. Mai exact, există un punct din întreaga carte care este faimos (nu sunt convins că oamenii citesc altceva decât acest punct dacă au citit cartea deloc):

„... adăugarea mai multor bărbați prelungește, nu scurtează, programul.”

Remediere ușoară. Voi personal doar femei pentru proiecte de acum înainte (vezi Întoarcerea Regelui și lupta împotriva Regelui Vrăjitor din Angmar).

Dar să presupunem că punctul lui Brooks este valabil, indiferent de identificarea de gen a inginerilor de software în cauză. Iată ideea: software-ul este dificil de construit cu multe interdependențe complexe. Și toată lumea trebuie să lucreze împreună pentru a o duce la bun sfârșit.

Pe măsură ce adaug oameni într-o echipă, aceștia trebuie să fie incorporați și grefați în proiect. Cineva trebuie să-și facă treaba potrivită. Echipa trebuie să comunice pentru a se asigura că toate lucrurile lor funcționează împreună, iar fiecare persoană suplimentară crește geometric complexitatea comunicării. Și la un moment dat, adăugarea de oameni devine o povară pentru proiect, nu un beneficiu.

Iată graficul din carte care ilustrează acest punct:

Acesta este un punct absolut corect. De aceea aud atât de mult la serviciu. Colaboratorii individuali epuizați și liderii epuizați deopotrivă o vor arunca - nu putem merge mai repede, nu putem face mai mult, opriți angajarea, citiți The Mythical Man-Month și disperați! Se pare că singura soluție este să nu mai creștem și să omorâm unele proiecte.

Când eu, ca CPO spun, „vom face acest lucru!” atunci răspunsul este adesea: „OK, atunci ce vom ucide?” The Mythical Man-Month transformă dezvoltarea de produse într-un joc cu sumă zero. Dacă vrem un lucru, trebuie să oprim altul. Acum, acesta este un mit real și eu îl numesc hogwash.

Și dusă la concluzia sa interpretată greșit patologic (vom ajunge la aceasta), cartea aparent spune că cea mai rapidă companie de tehnologie este cea care angajează toți cei patru oameni - patru bărbați , se pare. Orice altceva doar încetinește totul. Cineva ar trebui să trimită Amazon, Apple și Google copii ale cărții, astfel încât să își poată repara organizațiile evident umflate.

Singura problemă cu această abordare este că, într-un spațiu în care concurența crește și se repetă și se execută - doar împingând creșterea organizațională - editarea și concentrarea volumului de lucru pentru a se potrivi poate fi o rețetă pentru dispariție. Vei fi mai sănătos și mai puțin stresat - chiar până când nu vei avea un loc de muncă.

Și, în calitate de proprietar al managementului de produs pentru compania mea, nu sunt neînțelegător cu această nevoie de a încetini și de a se concentra. Trebuie să acordăm prioritate fără milă! Fără îndoială. Dar rularea unui produs este un exercițiu de contradicție. Trebuie să prioritizez ceea ce am și, în același timp, plang să fac mai multe. Dar ce să fac eu în fața lunii-omul mitic ?

În mod surprinzător, răspunsul la această întrebare vine din aceeași carte a lui Brooks. Iată un alt grafic din același capitol:

Există o luptă în dezvoltarea de produse la scară. Dacă munca pe care încercați să o realizați este pur partiționabilă, atunci mergeți mai departe și adăugați oameni! Dacă munca ta este conectată, atunci la un moment dat să adaugi oameni este pur și simplu greșit.

Dacă cineva spune că trebuie să omor un proiect pentru a începe altul, pur și simplu nu este cazul. Dacă cele două proiecte necesită foarte puțină comunicare și coordonare, atunci putem extinde.

Acesta este motivul pentru care adăugarea de nuclee la un procesor poate crește viteza experimentată a computerului sau a telefonului până la un punct - ceva despre care inginerii ar trebui să știe totul. Sigur, adăugarea de nuclee nu mă va ajuta să finalizez un calcul complex cu un singur fir. Dar m-ar putea ajuta să duc o grămadă de sarcini independente .

Conflictul pentru un director de produs între scalare și prioritizarea nemilos poate fi gestionat.

1. Prioritizează fără milă în locurile care au un singur thread (întârziere pentru o echipă de produs să spunem).
2. Scalați adăugând mai multe nuclee pentru a gestiona munca independentă.

Foarte rar, totuși, este ceva complet independent de orice altceva la o companie. La minimum, compania dumneavoastră va centraliza funcțiile de asistență (IT global, juridic, HR etc.), ceea ce duce la blocaje.

Totul este despre managementul dependenței

Meseria unui director de produs devine apoi nu numai crearea unei strategii, ci și executarea într-un mod care maximizează valoarea pentru client și afacere prin asigurarea debitului și reducerea riscului de interdependență cât mai mult posibil. „Cât mai mult posibil” este cheia aici. În acest fel, puteți face compania să semene mai mult cu cel din urmă grafic decât cu primul. Interdependența este o boală fără tratament , dar simptomele ei pot fi gestionate cu multe tratamente.

O soluție este asamblarea unei direcții strategice pentru companie care să minimizeze sau să limiteze dependența printr-un portofoliu de inițiative atent selectat. Lucrul amuzant aici este că mulți oameni vor refuza acest lucru. Să presupunem că am două opțiuni, una în care pot executa proiectele A, B și C care au foarte puțină coordonare (să zicem că au impact asupra produselor diferite ) și o altă opțiune cu proiectele D1, D2 și D3 care au o mulțime de interdependențe ( să presupunem că toate afectează același produs). Este adesea cazul ca Omul-Lună Mitică să fie invocată împotriva primului plan, mai degrabă decât a celui din urmă. Pentru că pe hârtie pare mai mult .

Într-adevăr, este mai puțin „concentrat”. Dar, de fapt, este mai puțin dificil din perspectiva dependenței și, prin urmare, este mai bine cu personal suplimentar.

Ține minte, nu spun să alegi o grămadă de muncă pentru companie care nu are legătură. Mailchimp nu va construi un cuptor cu microunde în curând. Toate lucrările ar trebui să conducă în aceeași direcție pe termen lung. Această abordare poate crește riscul experienței clienților (despre care vom discuta mai târziu), precum și sarcina asupra funcțiilor globale, cum ar fi cercetarea clienților. Fii cu ochii pe asta.

Un alt tratament este crearea unui proces de management al produselor și programelor care facilitează coordonarea dependenței și comunicarea acolo unde este necesar , fără a supraîncărca echipele cu coordonarea, dacă nu este necesar . Uneori, încercând să gestionăm coordonarea astfel încât să putem face mai mult , ajungem să creăm procese atât de oneroase încât ajungem să facem mai puțin. Este un echilibru între a face prea puțină coordonare, ceea ce face ca piesele să nu interacționeze și a face prea multă coordonare, ceea ce face ca piesele să nu fie niciodată construite pentru că suntem cu toții în stand-up-uri pentru eternitate.

Conflictul din Luna-omul mitic este că, pe măsură ce adăugați oameni la un proiect software, comunicarea trebuie să crească geometric. De exemplu, dacă aveți 3 persoane în proiect, înseamnă 3 linii de comunicare. Dar dacă ai 4, înseamnă 6 linii de comunicare. O persoană în plus, în acest caz, duce la dublarea comunicării! Distracţie. (Aceasta este, desigur, o simplificare excesivă a comunicării privind proiectele de dezvoltare software.)

Oameni diferiți au roluri diferite și, prin urmare, primesc cantități diferite de autonomie. Poate că managerul de proiect trebuie să comunice cu toată lumea din echipă. Dar un inginer care lucrează la API trebuie să comunice cu comerciantul de produse? Sau poate marketerul să treacă doar prin managerul de produs? Un proces bun și o cadență de întâlnire pot elimina apoi comunicarea și întâlnirile inutile. Ideea este că formula de intercomunicare a lui Brooks este o limită superioară a coordonării , nu o condamnare la moarte.

În cele din urmă, utilizați instrumente, principii și cadre combinate cu munca independentă asupra colaborării efective pentru a combate simptomele de interdependență. De exemplu, dacă pot coordona indicatorii cheie de performanță ai două echipe (KPI, adică măsurători ale succesului) pentru a stimula mișcarea mai mult sau mai puțin în aceeași direcție, atunci munca lor independentă este mai probabil să ajungă „mai aproape împreună” decât dacă KPI-urile lor stimulează mișcarea ortogonală. Acest lucru nu va asigura că lucrurile se potrivesc perfect, doar că munca pe care trebuie să o fac pentru a le face să se potrivească în viitor este mai mică decât ar fi altfel. Alte exemple ar putea include utilizarea declarațiilor „even-over”, sisteme de proiectare și testare automată.

Deci există un început. Dar interdependențele iau o mulțime de forme dincolo de cod. Permiteți-mi să dau un exemplu de la Mailchimp.

Riscul experienței clienților: costul ascuns (dar acceptabil?) al muncii de firewall

Deoarece clientul Mailchimp este adesea un proprietar de afaceri mici, care este un începător în marketing (și există milioane de proprietari de mici afaceri care s-au transformat în profesioniști în marketing din întreaga lume), trebuie să oferim o experiență perfectă și de înțeles imediat de la capăt la capăt . Nu ni se permite luxul de a asambla un monstru de nori al lui Frankenstein prin achiziție, așa cum pot jucătorii de la întreprindere. Nu putem documenta software-ul prost integrat cu consultanții și managerii de cont.

Ca produs de consum (gândiți-vă la Instagram sau la un Nintendo Switch sau un Roomba), trebuie să fim utilizabili imediat. Pentru o platformă de marketing all-in-one menită să-ți alimenteze afacerea, asta este greu! Și asta înseamnă că fiecare lucru pe care Mailchimp îl construiește trebuie să fie conectat perfect din perspectiva experienței.

Dar, împărțirea perfectă a proiectelor introduce apoi riscul de experiență . Nu este că codul nu poate fi scris independent. Acest lucru poate fi realizat, dar există încă riscul ca produsele să arate ca și cum ar fi fost construite de diferite echipe, iar această experiență poate fi cu adevărat confuză pentru utilizator. Ne confruntăm cu legea lui Conway – clienții noștri pot spune unde se termină munca unei echipe și unde începe munca celeilalte echipe.

Așa că încercați să conectați munca tuturor – nu doar pe back-end, ci și pe front-end. În epoca ecosistemului, dominată de excelența CX de la jucători precum Apple, aceasta a devenit aproape mize de masă în spațiul consumatorilor. Dar acesta este un coșmar mitic al omului-lună , deși nu din perspectivă inginerească de data aceasta. Este din perspectiva designului de servicii. Pe măsură ce adăugăm mai mulți oameni la toate aceste lucrări conectate „de la capăt la capăt”, totul încetinește la un acces cu crawlere în colaborare.

În afară de cea de-a treia soluție pe care am menționat-o mai sus, folosind instrumente și cadre, mai degrabă decât supraveghetori și porți de scenă, există o altă supapă de eliberare: faceți niște compromisuri deliberate ale experienței clienților . Mai exact, unde ne simțim confortabil să lansăm o experiență care este deconectată de restul (adică, este sub normal)? Acceptarea riscului și avansarea este treaba liderului de produs. Și, așadar, folosiți anumite criterii pentru a o rezolva (poate că nu ține zonele noi, cu trafic redus ale aplicației la aceleași standarde de experiență ca „vacile tale de bani”) și iei o decizie (de exemplu, iterație și învățare peste lustruire pe adiacente inovații). Acest lucru, desigur, se extinde dincolo de design.

Puteți oricând să scurtcircuitați legea lui Brooks alegând eforturile de firewall, inclusiv eforturile care, într-o lume perfectă, nu ar trebui să fie protejate cu firewall!

„

Voi avertiza spunând că software-ul pe care îl construiesc nu ucide pe nimeni. Nu aș susține această abordare dacă aș construi un dispozitiv medical. Dar la o companie de software de marketing, pot izola în mod deliberat echipele știind că am crescut șansele de incompatibilitate ca un compromis pentru creșterea personalului și mișcare mai rapidă.

Sunt trist să recunosc că Luna-Omul Mitic este o realitate la compania mea și bănuiesc și la a ta. Dar este ușor de gestionat - asta este concluzia. Paralelizarea și atenuarea dependenței ne oferă o cale de ieșire care limitează statutul aproape mitic al Omului-Luna Mitic . Așa că data viitoare când dihotomia puternică va fi ridicată la compania ta (scărcați mai încet sau renunțați la aspirațiile dvs.), amintiți-vă că, dacă sunteți deștept în ceea ce privește modul în care aliniați munca, puteți crește în continuare mare.

Nu uitați de partea mai moale a scalarii

Țineți minte că gestionarea Mythical Man-Month nu va împiedica inginerii să o invoce ca pe magie neagră. Ei invocă principiul nu numai pentru că există ceva adevăr în el, ci și pentru că scalarea pur și simplu este nasol (întotdeauna) din perspectivă emoțională și cognitivă. Dacă cred că sunt plătit să scriu cod și să rezolv problemele clienților, ultimul lucru pe care vreau să-l fac este să-mi schimb rutina și să îmi dau seama cum să lucrez cu oameni noi și cu o echipă mai mare.

Pe măsură ce vă extindeți compania, nu uitați să empatizați cu durerea creșterii și schimbării. O echipă care adaugă chiar și un singur membru devine o echipă complet nouă din perspectivă culturală și de încredere. Oamenii s-au săturat de această schimbare. Aceasta înseamnă că, în timp ce gestionați și atenuați Luna-omul mitic , va trebui să gestionați emoțiile din jurul creșterii. Aceasta este poate cea mai critică sarcină dintre toate.

Credința puternică în Omul-Luna Mitică de către o echipă în sine poate aduce concluziile acesteia în realitate. Este practic echivalentul credinței în zbor în Peter Pan. Dacă echipa crede că scalarea îi va încetini și nu acceptă schimbarea, într-adevăr va încetini.

Deci, pe măsură ce lucrați pentru a gestiona dependențele și introduceți instrumente pentru a ajuta la scalare, asigurați-vă că comunicați clar motivul din spatele practicilor. Implicați-i pe oameni în selectarea lucrărilor și a proceselor care atenuează problemele legate de luna umană, deoarece atunci când fac parte din schimbare și perspectiva lor se schimbă, scalarea devine brusc posibilă cel puțin din punct de vedere cultural.