Il mitico e mitico mese dell'uomo

In qualità di leader di prodotto in un'azienda tecnologica, sono un pozzo senza fondo di bisogni. Il mio lavoro come Chief Product Officer di Mailchimp è portare sul mercato il prodotto che vincerà in uno spazio molto competitivo. Le aspirazioni di Mailchimp sono alte e per realizzarle abbiamo bisogno di fornire una notevole quantità di prodotto al mercato. Spesso per molti in azienda, sembra che stiamo facendo troppo. Siamo sempre al limite delle ruote che si staccano.

E quando stai facendo troppo e decidi di fare anche di più, inevitabilmente inizierai a sentire il riferimento a The Mythical Man-Month . È come una di quelle palle antistress in cui se ne stringi un'estremità, esce il Mitico Mese dell'Uomo all'altra estremità.

Pubblicato da Frederick Brooks nel 1975 (ricordate il 1975, vero? Quando lo sviluppo del software assomigliava al 100% allo sviluppo del software nel 2020?), questo libro è piuttosto famoso tra gli ingegneri del software. In particolare, c'è un punto nell'intero libro che è famoso (non sono convinto che le persone leggano altro che questo punto se hanno letto il libro):

"... l'aggiunta di più uomini allunga, non accorcia, il programma."

Soluzione facile. D'ora in poi inserirò solo le donne nei progetti (vedi Il Ritorno del Re e la lotta contro il Re Stregone di Angmar).

Ma supponiamo che il punto di Brooks sia valido indipendentemente dall'identificazione di genere degli ingegneri del software in questione. Ecco il punto: il software è difficile da costruire con molte interdipendenze complesse. E tutti devono lavorare insieme per farlo.

Quando aggiungo persone a un team, devono essere integrate e innestate nel progetto. Qualcuno deve ritagliarsi il lavoro giusto per loro. Il team deve comunicare per assicurarsi che tutte le loro cose funzionino insieme e ogni persona in più aumenta geometricamente la complessità della comunicazione. E a un certo punto, aggiungere persone diventa un peso per il progetto, non un vantaggio.

Ecco il grafico del libro che illustra quel punto:

Questo è assolutamente un punto giusto. Ecco perché lo sento così tanto al lavoro. I singoli contributori esauriti e i leader esausti allo stesso modo lo tireranno fuori: non possiamo andare più veloci, non possiamo fare di più, interrompere le assunzioni, leggere The Mythical Man-Month e disperare! Apparentemente l'unica soluzione è smettere di crescere e uccidere alcuni progetti.

Quando io come CPO dico "faremo questa cosa!" la risposta quindi è spesso: "OK, allora cosa uccideremo?" Il Mythical Man-Month trasforma lo sviluppo del prodotto in un gioco a somma zero. Se vogliamo una cosa, dobbiamo fermarne un'altra. Ora, questo è un vero mito, e io lo chiamo hogwash.

E portato alla sua conclusione patologicamente mal interpretata (arriveremo a questa), il libro a quanto pare dice che l'azienda tecnologica più veloce è quella che impiega tutte e quattro le persone - quattro uomini , a quanto pare. Qualsiasi cosa in più rallenta tutto. Qualcuno dovrebbe inviare copie del libro ad Amazon, Apple e Google, in modo che possano riparare le loro organizzazioni ovviamente gonfie.

L'unico problema con questo approccio è che in uno spazio in cui la concorrenza sta crescendo, iterando ed eseguendo — semplicemente schiacciando la crescita organizzativa — modificare e focalizzare il carico di lavoro in modo che corrisponda può essere una ricetta per l'estinzione. Sarai più sano di mente e meno stressato, fino a quando non sarai senza lavoro.

E come proprietario della gestione dei prodotti per la mia azienda, non sono antipatico a questa necessità di rallentare e concentrarsi. Dobbiamo dare priorità spietatamente! Nessun dubbio. Ma gestire un prodotto è un esercizio contraddittorio. Devo dare la priorità a ciò che ho mentre contemporaneamente complotto per fare di più. Ma cosa devo fare di fronte al mitico mese-uomo ?

Sorprendentemente, la risposta a questa domanda viene dallo stesso libro di Brooks. Ecco un altro grafico nello stesso capitolo:

C'è una battaglia nel ridimensionamento dello sviluppo del prodotto. Se il lavoro che stai cercando di realizzare è puramente partizionabile, allora vai avanti e aggiungi persone! Se il tuo lavoro è tutto connesso, a un certo punto aggiungere persone è semplicemente sbagliato.

Se qualcuno dice che devo assolutamente terminare un progetto per iniziarne un altro, non è proprio così. Se i due progetti richiedono pochissima comunicazione e coordinamento, allora possiamo ridimensionare.

Questo è il motivo per cui l'aggiunta di core a una CPU può aumentare la velocità del tuo computer o telefono fino a un certo punto, qualcosa di cui gli ingegneri dovrebbero sapere tutto. Certo, l'aggiunta di core non mi aiuterà a completare un complesso calcolo a thread singolo. Ma potrebbe aiutarmi a eseguire un sacco di attività indipendenti .

Il conflitto per un dirigente di prodotto tra il ridimensionamento e l'assegnazione spietata delle priorità può essere gestito.

1. Assegni spietatamente la priorità in luoghi a thread singolo (il backlog per un team di prodotti, diciamo).
2. Puoi scalare aggiungendo più core per gestire il lavoro indipendente.

Molto raramente, tuttavia, qualcosa è completamente indipendente da tutto il resto in un'azienda. Come minimo, la tua azienda centralizzerà le funzioni di supporto (IT globale, legale, HR, ecc.) portando a colli di bottiglia.

È tutta una questione di gestione delle dipendenze

Il lavoro di un dirigente di prodotto diventa quindi non solo la creazione di una strategia, ma l'esecuzione in modo da massimizzare il valore per il cliente e per l'azienda, garantendo il throughput e riducendo il più possibile il rischio di interdipendenza. "Per quanto possibile" è la chiave qui. In questo modo puoi rendere l'azienda simile al secondo grafico piuttosto che al primo. L'interdipendenza è una malattia senza cura , ma i suoi sintomi possono essere gestiti con molti trattamenti.

Una soluzione consiste nell'assemblare una direzione strategica per l'azienda che minimizzi o limiti la dipendenza attraverso un portafoglio di iniziative accuratamente selezionato. La cosa divertente qui è che molte persone respingeranno su questo. Diciamo che ho due opzioni, una in cui posso eseguire progetti A, B e C che hanno pochissimo coordinamento (diciamo che hanno un impatto su prodotti diversi ) e un'altra opzione con progetti D1, D2 e ​​D3 che hanno tonnellate di interdipendenze ( diciamo che incidono tutti sullo stesso prodotto). Capita spesso che il Mitico Uomo-Mese venga invocato contro il primo piano piuttosto che contro il secondo. Perché sulla carta sembra di più .

In effetti, è meno "focalizzato". Ma in realtà è meno difficile dal punto di vista della dipendenza e quindi è più giusto con l'aggiunta di personale.

Tieni presente che non sto dicendo di scegliere un sacco di lavoro per l'azienda che non è correlato. Mailchimp non costruirà presto un forno a microonde. Tutto il lavoro dovrebbe guidare nella stessa direzione a lungo termine. Questo approccio può aumentare il rischio dell'esperienza del cliente (di cui parleremo più avanti) nonché l'onere per funzioni globali come la ricerca sui clienti. Tieni d'occhio questo.

Un altro trattamento consiste nel creare un processo di gestione del prodotto e del programma che faciliti il ​​coordinamento e la comunicazione delle dipendenze ove necessario senza sovraccaricare i team con il coordinamento se non richiesto . A volte, nel tentativo di gestire il coordinamento in modo da poter fare di più, finiamo per creare processi così onerosi che finiamo per fare di meno. È un equilibrio tra fare troppo poca coordinazione che fa sì che i pezzi non interagiscano e fare troppa coordinazione che fa sì che i pezzi non vengano mai costruiti perché siamo tutti in piedi in piedi per l'eternità.

La contesa nel Mitico mese dell'uomo è che quando si aggiungono persone a un progetto software, la comunicazione deve aumentare geometricamente. Ad esempio, se hai 3 persone nel progetto, sono 3 linee di comunicazione. Ma se ne hai 4, sono 6 linee di comunicazione. Una persona in più, in questo caso, porta a raddoppiare la comunicazione! Divertimento. (Si tratta, ovviamente, di una semplificazione eccessiva della comunicazione sui progetti di sviluppo software.)

Persone diverse hanno ruoli diversi e quindi ricevono diverse quantità di autonomia. Forse il project manager ha bisogno di comunicare con tutti i membri del team. Ma un ingegnere che lavora sull'API deve comunicare con il marketer del prodotto? O il marketer può semplicemente passare attraverso il product manager? Un buon processo e la cadenza delle riunioni possono quindi eliminare comunicazioni e riunioni non necessarie. Il punto è che la formula di intercomunicazione di Brooks è un limite superiore al coordinamento , non una condanna a morte.

Infine, utilizzare strumenti, principi e strutture combinate con un lavoro indipendente sull'effettiva collaborazione per combattere i sintomi di interdipendenza. Ad esempio, se riesco a coordinare gli indicatori chiave di prestazione (KPI, ovvero le misurazioni del successo) di due team per incentivare il movimento più o meno nella stessa direzione, è più probabile che il loro lavoro indipendente finisca per "essere più vicini" che se i loro KPI incentivano il movimento ortogonale. Questo non assicurerà che le cose si incastrino perfettamente, solo che il lavoro che devo fare per farle combaciare in futuro è minore di quanto potrebbe essere altrimenti. Altri esempi potrebbero includere l'utilizzo di dichiarazioni "even-over", sistemi di progettazione e test automatizzati.

Quindi c'è un inizio. Ma le interdipendenze assumono molte forme oltre il codice. Lasciami fare un esempio da Mailchimp.

Rischio dell'esperienza del cliente: il costo nascosto (ma accettabile?) del lavoro di firewalling

Poiché il cliente di Mailchimp è spesso un piccolo imprenditore che è un principiante del marketing (e ci sono milioni di proprietari di piccole imprese che si sono trasformati in esperti di marketing in tutto il mondo), dobbiamo offrire un'esperienza end-to-end perfetta e immediatamente comprensibile. Non ci è concesso il lusso di assemblare il mostro di nuvole di Frankenstein tramite l'acquisizione come fanno i giocatori aziendali. Non possiamo nascondere software mal integrato con consulenti e account manager.

Come prodotto di consumo (pensa a Instagram o a Nintendo Switch o a Roomba), dobbiamo essere usabili immediatamente. Per una piattaforma di marketing all-in-one pensata per potenziare la tua attività, è difficile! E ciò significa che ogni cosa che Mailchimp costruisce deve essere perfettamente connessa dal punto di vista dell'esperienza.

Ma il partizionamento perfetto dei progetti introduce quindi il rischio dell'esperienza . Non è che il codice non possa essere scritto in modo indipendente. Ciò può essere ottenuto, ma c'è ancora il rischio che i prodotti appaiano come se fossero stati costruiti da team diversi e quell'esperienza può essere davvero dannatamente confusa per l'utente. Ci scontriamo con la legge di Conway: i nostri clienti possono dire dove finisce il lavoro di una squadra e inizia il lavoro dell'altra squadra.

Quindi cerchi di collegare il lavoro di tutti insieme, non solo sul back-end ma anche sul front-end. Nell'era dell'ecosistema, dominata dall'eccellenza CX di giocatori come Apple, questo è diventato quasi una posta in gioco nello spazio dei consumatori. Ma questo è un incubo mitico del mese-uomo , anche se questa volta non dal punto di vista ingegneristico. È dal punto di vista del design del servizio. Man mano che aggiungiamo più persone a tutto questo lavoro connesso "end-to-end", tutto rallenta fino a diventare una scansione collaborativa.

Oltre alla terza correzione che ho notato sopra, utilizzando strumenti e framework piuttosto che over-watcher e stage-gate, c'è un'altra valvola di rilascio: fare alcuni compromessi deliberati sull'esperienza del cliente . In particolare, dove ci sentiamo a nostro agio nel rilasciare un'esperienza che è disconnessa dal resto (cioè è scadente)? Accettare il rischio e andare avanti è il lavoro del leader di prodotto. E quindi usi alcuni criteri per risolverlo (forse non sta mantenendo le nuove aree dell'app a basso traffico con gli stessi standard di esperienza delle tue "vacche da mungere") e prendi una decisione (ad es. innovazioni). Questo, ovviamente, va oltre il design.

Puoi sempre mandare in cortocircuito la legge di Brooks scegliendo di bloccare gli sforzi, compresi gli sforzi che, in un mondo perfetto, non dovrebbero essere protetti dal firewall!

“

Lo avverto dicendo che il software che costruisco non uccide nessuno. Non sosterrei questo approccio se stessi costruendo un dispositivo medico. Ma in un'azienda di software di marketing, posso isolare deliberatamente i team sapendo che ho aumentato le probabilità di incompatibilità come compromesso per aumentare il personale e muovermi più velocemente.

Mi dispiace ammettere che il Mitico Mese dell'Uomo è una realtà nella mia azienda, e sospetto anche nella tua. Ma è gestibile : questa è la linea di fondo. La parallelizzazione e la mitigazione della dipendenza ci offrono una via d'uscita che limita lo stato quasi mitico del Mitico Mese-Uomo . Quindi la prossima volta che viene sollevata la netta dicotomia nella tua azienda (scala per andare più piano o rinunciare alle tue aspirazioni) ricorda che se sei intelligente su come allineare il lavoro, puoi comunque diventare grande.

Non dimenticare il lato più morbido del ridimensionamento

Tieni presente che la gestione del Mitico Mese dell'Uomo non impedirà agli ingegneri di invocarlo come magia oscura. Stanno invocando il principio non solo perché c'è del vero in esso, ma perché il ridimensionamento fa solo schifo (sempre) da una prospettiva emotiva e cognitiva. Se penso di essere pagato per scrivere codice e risolvere i problemi dei clienti, l'ultima cosa che voglio fare è cambiare la mia routine e capire come lavorare con nuove persone e un team più ampio.

Mentre ridimensioni la tua azienda, ricorda di entrare in empatia con il dolore del ridimensionamento e del cambiamento. Una squadra che aggiunge anche un solo membro diventa una squadra completamente nuova da una prospettiva di fiducia e culturale. Le persone sono stanche di questo cambiamento. Ciò significa che mentre gestisci e mitiga il mitico mese-uomo , dovrai gestire le emozioni che circondano la crescita. Questo è forse il compito più critico di tutti.

La forte convinzione nel mitico uomo-mese da parte di una squadra in sé e per sé può portare le sue conclusioni in realtà. Fondamentalmente è l'equivalente della convinzione di volare in Peter Pan. Se il team ritiene che il ridimensionamento lo rallenterà e non accetta il cambiamento, rallenterà davvero.

Quindi, mentre lavori per gestire le dipendenze e introdurre strumenti per aiutare a scalare, assicurati di comunicare chiaramente il perché dietro le pratiche. Coinvolgi le persone nella selezione del lavoro e dei processi che mitigano i problemi del mese-uomo, perché quando fanno parte del cambiamento e le loro prospettive cambiano, il ridimensionamento diventa improvvisamente almeno culturalmente possibile.