Hai bisogno di un eroe: il Project Manager

Questo articolo è per te, il coraggioso imprenditore con un'idea di app nel cuore e un po' di contanti in banca. I diagrammi che hai scarabocchiato sui tovaglioli da cocktail sconvolgeranno il mondo intero e camion con cassone ribaltabile pieni di soldi sono già stati spediti a casa tua. Per assicurarti che arrivino in tempo, ecco alcuni semplici consigli per fare in modo che il tuo ciclo di produzione si svolga senza intoppi.

Perché hai bisogno di un Project Manager in primo luogo

"I programmi per computer sono le cose più complesse che fanno gli esseri umani", afferma Douglas Crockford. Potresti non aver sentito quel nome prima, ma è piuttosto famoso per essere un programmatore. Attualmente è un architetto software senior presso PayPal e ha aperto la strada a tutti i tipi di tecnologie interessanti che esulano dall'ambito di questo articolo. È qualcuno che sa molto di lavorare su grandi progetti.

Quanto a me, ho programmato per 13 anni, e anche adesso, a un certo punto, ogni progetto mi porta in un territorio inesplorato. Ci sono così tante diverse tecnologie là fuori e nuove tecniche vengono ideate a un ritmo così allarmante che non mi sento mai completamente al passo con quello che sta succedendo. Mentre ogni progetto ha le sue sfide uniche, ci sono alcune costanti:

• Il progetto ha poco tempo.
• Il budget è inferiore a quello che vorrei.
• Sono più costoso di quanto vorrebbe il cliente.
• Non ascolto perfettamente come vorrebbe il cliente.
• Il cliente non spiega le cose perfettamente come vorrei.

Chiaramente, abbiamo bisogno di una baby sitter. Qualcuno deve intervenire per stabilire le regole di base, mantenere tutti onesti e assicurarsi che non dimentichiamo nulla di importante. Qualcuno deve facilitare la comunicazione tra tutte le parti.

Questo qualcuno, questo eroe, è il project manager.

Toptal non offriva contratti con i project manager quando ho iniziato a scrivere questo articolo, ma ora lo fanno. sinergia! Posso solo immaginare che i poteri che hanno letto i seguenti consigli e si siano resi conto che stavano perdendo una grande opportunità.

Perché un programmatore non è un buon project manager

Certificazione del Project Management Institute a parte, la cosa più importante che un project manager può portare in tavola è l'esperienza. Di conseguenza, molti programmatori diventerebbero project manager abbastanza decenti; abbiamo più esperienza con i progetti tecnici di chiunque altro e le nostre menti analitiche sono abili nella catalogazione delle informazioni e nella definizione di obiettivi concreti.

Dio sa, ci stai pagando abbastanza, quindi sembra ragionevole aspettarsi che potremmo gestire noi stessi piuttosto che costringerti a pagare anche per il tempo di qualcun altro, giusto?

Bene, per cominciare, ci stai pagando per programmare.

Quando usciamo dal nostro stordimento di programmazione per prendere decisioni su cosa dare la priorità, o per discutere su quanto verrà effettivamente fatto questa settimana, il codice non viene scritto. Ci vogliono quindi almeno 10 minuti per tornare "nella zona", soprattutto se siamo stressati dalla conversazione che abbiamo appena avuto, il che è probabile se stiamo discutendo della priorità delle funzionalità. Boo hoo, lo so, ma si tratta di fare l'uso più efficiente di risorse costose.

Soprattutto, non possiamo davvero vedere la foresta per gli alberi. Se non prendi nient'altro da questo articolo, per favore capisci questo: quando passo tutto il giorno a fissare alcuni bug specifici, il mio cervello perde la traccia del quadro più ampio.

Il mio cervello mi premia quando correggo quei bug e presumo di aver fatto grandi cose e di poter giocare ai videogiochi ora. Quando qualcuno mi ricorda che la home page è ancora rotta, è una sorpresa completa perché ho passato la giornata a riempirmi il cervello di una conoscenza molto dettagliata di una piccola parte del progetto generale e mi sono quasi dimenticato del resto. È così che funziona il mio cervello e molti altri programmatori hanno una struttura psicologica simile.

Perché un cliente non è un buon project manager

Ebbene, se noi programmatori non vogliamo assumerci la responsabilità di portare a termine le cose gestionali del progetto, allora tocca a te, il cliente. Sono i tuoi soldi. È la tua visione. In definitiva, sei comunque responsabile dell'intera faccenda.

Tuttavia, hai anche molto nel tuo piatto.

Molti clienti sono semplici mortali con lavori giornalieri come il resto di noi, e alcuni sono anche noti per soffrire di procrastinazione o dimenticanza. Sebbene questo non ti descriva necessariamente, in particolare, per favore prendi in considerazione l'idea di avere un Ricordatore professionista in giro in modo da poter tornare all'importante lavoro di mantenere vivo l'intero progetto.

Se hai lavorato o supervisionato un progetto tecnico di portata simile, potresti davvero essere un buon manager per il tuo progetto. In caso contrario, non sottovalutare il valore di qualcuno in grado di prevedere i problemi che potrebbero sorgere. Le stime del tempo sono sempre solo stime e i bug tendono a comparire nei momenti meno opportuni. Vale il costo di un altro dipendente (anche se solo part-time) per avere qualcuno intorno che sa quali parti del processo richiedono, o probabilmente richiederanno, più attenzione.

Prendi il controllo qualità (QA), per esempio. Un corretto QA è essenziale per ottenere ciò che desideri da qualsiasi progetto e non ottiene mai l'attenzione che merita. Un buon project manager trarrà il massimo dalle limitate risorse di QA e assicurerà anche la qualità dei tuoi programmatori per te. A volte usciamo dalla nostra profondità e a volte commettiamo errori. Hai bisogno di una persona tecnicamente competente con un ruolo di supervisione per determinare se il tuo programmatore sta solo avendo una giornata di riposo o se, in effetti, non è adatto al progetto. Eliminare presto i problemi del personale potrebbe fare la differenza tra la vita e la morte per il tuo progetto.

Infine, anche tu, cliente, a volte hai bisogno di un piccolo controllo e/o equilibrio. È difficile per me scrivere poiché noi programmatori di computer non siamo famosi per la nostra natura schietta. Basti dire che ho lavorato a molti progetti in cui il cliente era fermamente convinto che tutto fosse la massima priorità e assolutamente tutto il necessario per essere realizzato. Anche se non ho dubbi che questo fosse assolutamente vero, questi clienti, purtroppo, non avevano il controllo sul numero di ore in un giorno. Non hanno ottenuto il risultato positivo che desideravano e/o meritavano e ritengo che questo risultato avrebbe potuto essere evitato se il cliente avesse affidato a un project manager l'autorità di valutare il carico di lavoro e di tenere le cose sotto controllo con tatto, ma con fermezza . È difficile fare il giudizio spassionato che richiede la maggior parte dei progetti tecnici quando è una tua idea e i tuoi soldi in linea e al computer non importa se tu o io piangi e urliamo per questo. (So ​​che questo è vero perché l'ho provato molte volte.)

Un elenco incompleto di tecniche per la gestione di un progetto tecnico

Se hai deciso di ignorare le precedenti 1.000 parole e gestire il tuo progetto da solo, o se hai intenzione di assumere qualcuno ma vuoi essere più informato sul processo, questo elenco ti aiuterà. Non sono mai stato (ufficialmente) un project manager, quindi non posso dire quali strumenti utilizzerebbe un determinato project manager, ma ho avuto un buon successo con tutte queste tecniche:

Pietre miliari

Quando si inizia un nuovo progetto, la maggior parte delle persone sa intuitivamente che è importante dividere il progetto in blocchi leggermente più gestibili, con ogni blocco che va da un paio di settimane a un paio di mesi di lavoro. All'inizio del progetto, è bello avere un incontro di avvio per stabilire queste pietre miliari. Va bene essere un po' vaghi su come raggiungerli, la cosa più importante è continuare a controllare dopo ogni traguardo in modo da beneficiare della migliore comprensione del progetto da parte di tutti e per assicurarsi che i traguardi del progetto siano ancora ( all'incirca) della stessa dimensione inizialmente creduto.

Stime di tempo

Noi programmatori detestiamo assolutamente le stime perché sappiamo che saranno sbagliate e sappiamo che verranno utilizzate contro di noi. Va bene che si sbaglino perché, per definizione, si basano su una manciata di incognite. Va anche bene che vengano usati contro di noi perché i nostri lavori sono piuttosto comodi e non fa male avere la frusta schioccata ogni tanto.

Quindi sentiti libero di chiedere preventivi ogni volta che iniziano i lavori su una nuova pietra miliare. Dovresti aspettarti una o due righe per ogni caratteristica principale insieme a una stima approssimativa di quanto tempo impiegherà quella funzione. Di solito faccio una stima ottimistica, poi la raddoppierò. Il più delle volte, questo tempo extra rappresenta insidie ​​invisibili.

Storie di utenti

Le storie degli utenti sono brevi descrizioni di una singola funzionalità all'interno dell'app. Sono utili come registrazione di caratteristiche importanti e dovrebbero essere piccoli, in grado di stare su una scheda e spesso accompagnati da un piccolo disegno. Ancora più importante, fungono da ponte tra ciò che il cliente vuole e ciò che il programmatore deve dire al computer. Sono abbastanza semplici per te, il cliente, da eliminare in un paio di minuti, ma abbastanza dettagliate per noi, i programmatori, in cui affondare i denti.

Per alcune informazioni rapide sulle storie degli utenti, ho trovato questi tutorial di Mountain Goat Software e Roman Pichler di alta qualità e concisi. Per ulteriori informazioni sull'intera filosofia della gestione agile dei progetti, prova questo post sul blog di Toptal The Ultimate Introduction to Agile Project Management di Paul Barnes.

Composizioni (prototipi)

Questo non è un articolo sul perché hai bisogno di un designer perché penso che la maggior parte dei clienti lo capisca già, ma vale la pena ripeterlo perché vedrai enormi guadagni di produttività se schiaffeggi un progetto concreto e ben ponderato davanti ai tuoi programmatori. Ogni volta che dobbiamo prendere una decisione di progettazione, dobbiamo lasciare "la zona" e ogni volta che dobbiamo tornare indietro e cambiare qualcosa perché non ci è stata fornita la bozza finale, beh, fai i conti... io' Non mi lamento, perché il design è divertente, ma secondo la mia esperienza, questa è la fonte n. 1 di ore extra fatturabili evitabili.

La maggior parte dei designer fornisce composizioni, note anche come composizioni, in Adobe Photoshop, Adobe Illustrator o Sketch. Se lo fai da solo, puoi utilizzare uno degli innumerevoli strumenti online come Balsamiq o InVision. La composizione non deve avere gli stessi colori e stili del prodotto finito (poiché possono essere facilmente modificati in seguito), ma ti preghiamo di dedicare più tempo per assicurarti che tutti gli elementi dell'interfaccia utente siano presenti e contabilizzati.

Riunioni in piedi

Le lunghe riunioni a volte sono inevitabili, ma non vuoi davvero sovraccaricare i tuoi programmatori o occupare più tempo del necessario. Ho avuto clienti che sembravano aspettarsi che ricordassi tutto ciò che è stato detto durante una riunione di due ore e mezza; erano molto delusi. Una riunione in piedi è generalmente limitata a 15 minuti ed è consuetudine rimanere in piedi per tutta la durata. L'aspetto in piedi dovrebbe garantire che tutti partecipino, oltre a mantenere breve la riunione.

Durante gli stand-up, tutti girano in cerchio per fornire un breve rapporto sullo stato, mantenendo tutti i membri del team aggiornati sui progressi reciproci. Puoi trovare ulteriori informazioni sugli stand-up su ExtremeProgramming.Org. Se lavorate tutti da remoto e non volete avere tutti su Skype tutti i giorni, potete provare uno strumento divertente come 15Five come alternativa agli stand-up. 15Five consente ai membri del team di fornire il proprio contributo ogni volta che è conveniente per loro e li chiederà con domande del sondaggio per ottenere risposte più approfondite.

Sistema di biglietteria

Mentre chiunque può mantenere un sistema di note adesive e Google Docs (con le attività di tutti evidenziate con colori diversi), non è davvero necessario; molte persone hanno cercato di risolvere questo problema per te. Basecamp e Trello sono famosi per la loro facilità d'uso, mentre Pivotal cerca di racchiudere l'intera filosofia "agile" in un pacchetto molto elegante. Qualunque sia la tua scelta, un buon sistema di biglietteria ti consentirà, come minimo, di:

• Crea compiti
• Assegna priorità e data di scadenza
• Collega attività e attività secondarie
• Assegna diverse risoluzioni come "test completato" o "test fallito"
• Mostra tutte le attività assegnate a un determinato utente

Quando un project manager ti mostra 40 biglietti rosso brillante con la massima priorità tutti in scadenza lo stesso giorno, capirai veramente il valore di questa vista a volo d'uccello del progetto.

Controllo della fonte

Potresti anche non guardare mai il codice nel sistema di controllo della versione del tuo progetto, ma il controllo del codice sorgente (o il controllo delle versioni) è uno degli strumenti più importanti a nostra disposizione, il più grande sistema di backup immaginabile.

La maggior parte dei progetti moderni usa Git, anche se a volte ti imbatterai in Subversion (SVN) quando lavori su progetti che esistono da un po' di tempo. Github ti consente di ospitare gratuitamente repository pubblici illimitati (inoltre, contiene la maggior parte dei progetti open source del mondo), mentre Bitbucket ti consente di ospitare repository privati ​​illimitati ed è quindi la scelta preferita per i progetti commerciali.

Qualunque sia il sistema di controllo della versione che scegli, memorizza il nostro codice da remoto nel caso succeda qualcosa, inoltre tiene traccia ogni volta che "impegniamo" il codice su di esso mentre ci costringe a scrivere un piccolo messaggio che descrive su cosa stavamo lavorando. Ciò impedisce a diversi sviluppatori di sovrascrivere il codice dell'altro, ci consente di vedere tutte le modifiche apportate in un determinato periodo di tempo e ci consente di creare nuovi rami di codice per archiviare funzionalità che non verranno attivate immediatamente. Ha anche un comando chiamato "colpa" che mostra chi era responsabile di una determinata riga di codice e quando è stata commessa.

Il controllo del codice sorgente è il massimo.

Sviluppo basato su test

Questa è una pratica relativamente costosa, il che significa che non viene spesso impiegata in progetti in cui il budget è limitato a un paio di liberi professionisti. Quindi tu, come imprenditore di una startup, non dovresti sentirti troppo in colpa per non averlo fatto, ma devo far pendere l'idea di fronte a te perché fornisce la difesa definitiva contro i bug. Fondamentalmente, i tuoi programmatori trascorrono ore preziose aggiuntive scrivendo test (piccoli blocchi di codice) che assicurano che alcune parti dell'app si comportino in modi specifici, prevedibili e ripetibili. Ad esempio, potrei scrivere un test affermando che quando si fa clic sul pulsante "accesso", si apre un popup con un campo nome utente.

Il bello dei test è che una volta che li ho scritti, posso eseguirli tutti con un solo comando. Se ho scritto 200 test, posso eseguirli dopo aver rilasciato una nuova versione dell'app per assicurarmi che nessun bug sia stato introdotto in nessuna di queste 200 funzionalità. Non è perfetto, ma è il più vicino possibile a garantire app prive di bug (almeno bug-lite).

Incartare

Questo è tutto quello che so sulla gestione dei progetti. Non sono sicuro di quanto di tutto questo passerebbe in rassegna al Project Management Institute, ma sono tutte cose che ho imparato lavorando su progetti web nel corso dell'ultimo decennio. Ovviamente, ti consiglio di assumere qualcuno per trarre vantaggio dalla sua esperienza, ma spero che trovi queste informazioni utili anche se non è qualcosa che sei in grado di fare. Sarai l'autorità suprema su questo progetto, quindi più capirai i suoi meccanismi interni, più è probabile che tu lo conduca alla vittoria.