In una startup che consiglio, le attività archiviate da PMs per gli ingegneri da implementare avevano una priorità bassa/media/alta.
Poiché si tratta di una startup in fase iniziale, c’è sempre più lavoro da fare rispetto al tempo o alle persone, quindi gli ingegneri non sono mai riusciti a svolgere attività basse o medie.
Quindi PMs ha smesso di archiviare attività a priorità bassa e media.
Ora tutte le attività sono ad alta priorità. Quindi le priorità vengono comunicate in modo informale:”Sì, entrambi sono ad alta priorità, ma X viene prima di Y”. Il che porta naturalmente a disaccordi: “Perché non hai finito Un?””Perché stavo lavorando su B. “” Ma A è la priorità più alta.”No, hanno la stessa priorità di alta.”
La cosa interessante è che questo non è accaduto perché un lato ha sovvertito il sistema. Al contrario, entrambe le parti stavano facendo quello che avrebbero dovuto fare sotto il sistema. Gli ingegneri che abbandonano le attività basse e medie avevano senso perché l’intero punto di priorità è dire cosa può essere eliminato quando non possono essere tutti fatti. La decisione del PMS di archiviare di nuovo solo attività ad alta priorità aveva senso perché qual è il punto di archiviare attività che non saranno fatte, comunque? In questo modo si perde solo tempo per tutti i soggetti coinvolti. O lo archivia come alto o no.
Quindi il sistema si è rotto.
Quali sono alcune alternative?
Un metodo di priorità che funziona è quello di avere priorità che sono definite oggettivamente. A Google, per esempio, P0 significava un’emergenza di produzione: fermare quello che stai facendo e lavorare su questo. Non è irragionevole che le persone vengano chiamate per riparare un P0, svegliate nel cuore della notte. P1 significava un’attività insolitamente alta priorità: non è necessario interrompere ciò che si sta facendo per lavorare sul P1 (non è un P0), ma quando hai finito con quello che stai facendo, devi lavorare sul P1. P2 è stato utilizzato per la maggior parte delle attività. E P3 e P4 non sarebbero finiti, mai.
Questo sistema ha funzionato perché le priorità erano oggettivamente definite e ampiamente comprese, quindi le persone potevano respingere e impostare la giusta priorità: “No, non è un P0-non è un’emergenza produttiva” o ” No, non è un P1 — sì, è importante, ma non ha la precedenza su tutto il lavoro che abbiamo.”Considerando che con basso / medio / alto, un compito particolare è un medio o un alto? E ‘ una questione di opinione. Può significare qualsiasi cosa, causando il guasto del sistema.
Un secondo metodo di prioritizzazione che funziona è per il PM definire un ciclo o uno sprint costituito da un elenco definito di attività da eseguire in un tempo concordato. Se un’attività è inclusa nel ciclo corrente, significa che dovrebbe essere eseguita in questo ciclo, quindi la priorità è meno rilevante .
Un terzo metodo di priorità che funziona è per il PM definire un elenco di priorità di attività. Una lista numerata in cui il 1 ° è più importante del 2°, che è più importante del terzo, e così via. Questo ha ancora un senso. In definitiva, ciò che conta è se un ingegnere dovrebbe eseguire l’attività X o Y, quando non c’è tempo per fare entrambe le cose. Non se X è medio in senso assoluto, il che non ha senso comunque.
In ogni caso, non utilizzare una priorità bassa/media/alta. Usa qualcosa come Trello in cui trascini le attività verso l’alto o verso il basso per impostare una priorità implicita .
Funziona particolarmente bene se l’elenco comprende un obiettivo di alto livello, come la funzione di avvio X. Che dà alle persone la proprietà e li motiva.
Naturalmente, tutto ciò presuppone che tu abbia una PMS competente e ben intenzionata. Ho lavorato con alcuni PMS di seconda categoria che cercano di stipare il maggior numero possibile di attività in un ciclo, e sono quindi arrabbiati quando le cose sono più lunghe del previsto. Non possono dare la priorità. Vogliono tutto. Oppure non capiscono il compromesso fondamentale nella gestione del progetto, vale a dire il compromesso tra tempo, portata e qualità.
O capiscono tutto quanto sopra, ma usano questo per manipolare gli ingegneri per ottenere più lavoro da loro. Questo non funziona a lungo – ho smesso di dare informazioni rilevanti al PM, perché di solito lo abusava come un’opportunità per criticarmi. Sconterei tutto quello che dice. Quando ha avuto un disaccordo con chiunque altro nella squadra, inizierei supponendo che l’altra persona abbia ragione.
Se si dispone di PMS di seconda categoria o cattive intenzioni, nessun metodo di priorità funzionerà bene.
È interessante notare che gli strumenti di tracciamento dei bug progettati per gli ingegneri non funzionano così come gli strumenti di tracciamento delle attività progettati per qualsiasi tipo di attività. Ciò è probabilmente dovuto al pregiudizio degli ingegneri di mettere un’interfaccia utente in cima a un database. Ma gli umani non pensano come un database. Una metafora del mondo reale come un mazzo di carte disposte e ordinate su una scrivania potrebbe essere un modello migliore.