Come posso avere successo come sviluppatore principale? [chiuso]

Sono diventato lo sviluppatore principale in un particolare progetto, ma ho difficoltà a concentrarmi sul quadro generale e ad accertarmi che tutti i pezzi del progetto siano coperti.

Cosa devo tenere a mente quando gestisco questo progetto? Come posso assicurarmi che tutto venga gestito come dovrebbe?

Ho visto questo viaggio su altri sviluppatori mentre effettuano il passaggio a senior o lead. Ecco alcuni suggerimenti che ho fatto ad altri.

• Comprendi qual è l'obiettivo del progetto.

Spesso non si tratta di tutte le funzionalità che sono state inserite nel progetto. Si tratta di un set di funzionalità di base che risponde a un'esigenza aziendale. Tienilo sempre presente perché quello è il tuo obiettivo principale.

• Analizza ciò che deve essere fatto in compiti. Comprendi le dipendenze tra di loro.

Abbattere un progetto dovrebbe essere piuttosto semplice. Ripartilo il prima possibile nel progetto. Se devi sorvolare le parti, comprendi che rappresentano un rischio fino a quando non capisci cosa deve essere fatto.

• Comprendi quali sono le domande aperte o le ambiguità del progetto.

Non sarai in grado di risolvere inizialmente tutte le ambiguità (anche se dovresti provare). Assicurati che il tuo manager e le parti interessate del progetto comprendano cosa sono e quali rischi comportano per il progetto.

• Il business odia la sorpresa.

Assicurati che tutti sappiano (idealmente su base giornaliera, ma lavori settimanali) quale sia lo stato del progetto. E per status intendo cosa è stato fatto, cosa è rimasto da fare, domande aperte, problemi, ecc. Tutto ciò che può influire sul completamento del progetto dovrebbe essere segnalato.

• Ogni giorno, ripassa il quadro generale.

Dovresti esaminare il quadro generale ogni giorno per un'ora. Ponetevi le domande. Cosa è stato completato? Cosa resta da fare? Quali sono le domande aperte? Qual è l'obiettivo? Dovresti essere in grado di dare a qualcuno uno stato dettagliato del progetto ogni volta che lo chiedono.

Il primo consiglio che ti darò è di accettare che la gestione del team è più critica che svolgere i tuoi compiti di programmazione. Ciò significa che quando hai 3 junior che hanno bisogno di aiuto, è il tuo compito aiutare a non lamentarti di come ti sta allontanando dallo sviluppo. Di conseguenza, spesso diventi il ​​blocco stradale per progredire se prima ti concentri troppo sulle tue attività di sviluppo.

Inoltre, devi imparare a delegare. È difficile assegnare compiti a qualcuno quando puoi farlo facilmente in un'ora e sai che rimbalzeranno per un giorno. Tuttavia, non progrediranno mai a meno che non ottengano i compiti e tu lavorerai fuori orario mentre la tua squadra sta giocando.

Inoltre, non basta mai correggere il codice di qualcun altro. Dì loro cosa non va (e perché) e falli riparare. Oppure entrerai in un ciclo in cui devi sistemare tutto perché non stanno migliorando. Se non riescono a risolverlo, considera se devono rimanere nella squadra. Non lasciare che i membri deboli del team rimangano perché stai risolvendo tutto ciò che fanno.

Come protagonista, devi essere il cattivo e dare loro le notizie spiacevoli (sia su che giù per la catena). Questo vale anche per il lavoro. Ciò significa che devi fare la scarsa valutazione delle prestazioni; devi dire loro che la scadenza è stata spostata in alto o i requisiti sono cambiati; devi spingere il ragazzo pigro che non sta facendo progressi; e devi dire ai tuoi superiori quando la scadenza non verrà rispettata e perché e cosa stai facendo al riguardo. Essere guidati non significa essere apprezzati, ma essere efficaci. Il tuo compito è far uscire il software dalla porta, non fare amicizia. La comunicazione è fondamentale ed evitare le cattive notizie finisce per peggiorare la situazione. È molto più probabile che un cliente gestisca la comunicazione che ci vorranno altre tre settimane al mese prima del lancio rispetto a quando passerà la data di lancio e poi gli dici che hai bisogno di altre tre settimane.

Ecco la mia lista di controllo informale. È molto informale ... Non faccio tutto ogni giorno, ma se non ho colpito tutte queste cose settimanalmente mi preoccupo un po ', e se non le colpisco mensilmente, dovrei andare nel panico. E il chilometraggio varia interamente in base alla cultura dell'azienda / del team, allo stile personale e al tipo di progetto.

• Parla con il team individualmente - tutti i membri del tuo team - hanno un lavoro utile da fare? sai qual è l'obiettivo generale del prodotto e la versione attuale? sanno come si guadagna e qual è la principale spinta della tua attività? sanno come il loro lavoro attuale si adatta a tutto ciò?

• Parla con il team collettivamente : mettili tutti insieme con le notizie più importanti, riunisci i gruppi per assicurarti che la comunicazione avvenga con e senza di te. In quanto piccola squadra, si tratta probabilmente di sessioni di strategia di gruppo. Man mano che la squadra diventa più grande, diventerà il caso in cui dovrai guidarli attraverso i punti principali, e diventerà inevitabilmente un tuo interlocutore nel loro scenario. Non è sbagliato - ci sono momenti in cui è molto importante che tutti ti sentano dire le informazioni pubbliche a tutti . Quindi tutti sanno che stai dando le informazioni universalmente. Ma l'incontro "tu - a tutti" è molto diverso dall'incontro di strategia di gruppo in cui sei più una guida.

• Prova il lavoro del team : prova a fare un sondaggio sul lavoro di tutti. Leggi il loro codice, esegui le loro funzioni, prova i loro casi di test. Non mirare al 100% del lavoro di tutti, prova a provare un po 'da tutti. Fornisci loro feedback, ma archivia anche aree di punti di forza e di debolezza in tutto il team.

• Controlla con la tua direzione presto e spesso - questo non è un naso marrone, questo è sempre aggiornato. Se non sai di cosa ha bisogno il tuo management e cosa pensa il tuo management, come può il tuo team soddisfare le aspettative? Devi avere un ottimo rimprovero con il tuo capo e devi essere nella sua squadra, come la tua gente è nella tua squadra. Essere in grado di comunicare efficacemente con il capo su cose insignificanti aumenta la fiducia che sarai in grado di ottenere aiuto e capire chiaramente quando la crisi colpisce. È anche un buon controllo di realtà per sapere dove si trovano i tuoi grandi paraocchi.

• Rivedi periodicamente le risorse del team : le persone strilleranno quando una risorsa precedentemente disponibile non sarà disponibile, ma esamineranno i punti di dolore sconosciuti. Dove sono i tuoi chokepoints? Ci sono nuovi strumenti che sarebbe utile avere? La maggior parte delle squadre ha un ragazzo che penso sia Tool Hunter, che è sempre aggiornato sugli ultimi e più grandi gadget. Bilancia le conversazioni tra Tool Hunter e GuyWhoHatesEverythingNew per trovare il prossimo punto di evoluzione. Gli strumenti includono tutto: SW, HW, spazio fisico, risorse per l'apprendimento.

• Conoscere e rimanere in contatto con i team di supporto. Ogni azienda è diversa, ma conosce i responsabili del controllo qualità, della scrittura di documenti, legali, strutture, finanza e di qualsiasi altro gruppo di supporto unico per la tua attività. Sono i migliori fattori scatenanti che mi vengono in mente, perché vedono il mondo completamente diverso da te.

• Conosci la tua concorrenza - passa almeno un po 'di tempo ogni settimana a capire come qualcuno risolverebbe i problemi che il tuo prodotto risolve se non lo usasse. Potrebbe non essere una singola azienda, ma cosa offre quell'altra soluzione che non si offre?

• Verifica costi e pianificazione- Quanto è probabile che la tua squadra significherà la scadenza attuale? Che ne dici della prossima scadenza? Qual è il tasso di combustione dei tuoi costi? Per quali grandi acquisti imminenti non hai ancora pagato? Cosa resta del tuo budget? I dettagli variano in base al modo in cui esegui il monitoraggio finanziario, ma anche in una società molto informale, dovresti avere un'idea sia di quanti giorni / settimane / mesi di budget ti sono rimasti sia di quale sia la scadenza per il prodotto corrente. Da qualche parte, in qualche modo è meglio che qualcuno stia pianificando "di quante persone abbiamo bisogno per fare questo lavoro?" e "possiamo permetterci di pagarli il prossimo mese / trimestre / anno?". Devi conoscere quei numeri e inserire i passaggi successivi. Hai bisogno di un piano chiaro per la prossima settimana che potresti spiegare in questo momento se qualcuno è entrato e ha chiesto. Hai bisogno di un piano abbastanza buono per il prossimo mese, che cambierà solo in 2-3 posti quando la realtà colpisce. Hai bisogno di un piano abbozzato per il trimestre e di un generale in cima alla tua idea per l'anno. Oltre questo, anche in un progetto enorme, i numeri sono solo numeri. Ascoltali, ma renditi conto che nessuno ha firmato con il sangue.

Questo è il mio fuori dalla mia lista di testa. In genere lo aggiungo mentre vengo schiacciato a testa in giù da una "sorpresa" (immaginatemi sensibile all'area che mi mancava e poi riesco a piegarlo nella lista di controllo. "Sorpresa" con un sorriso forzato e denti stretti ).

Inoltre, preparati per il Dread Context Switch. Se hai appena iniziato la gestione, è probabile che tu abbia una piccola squadra e qualcuno nella direzione ha pensato che sarebbe bene per te passare un po 'di tempo a gestire una squadra e un po' di tempo facendo cose individuali per i collaboratori. Questo può essere fatto, ma il cambio di contesto tra i due è approssimativo. Pianificalo. Blocca il tempo per passare (come prima e dopo il pranzo) e conosci il tuo set di abilità meno praticato e renditi conto che dovrai trascinarti lì le prime volte - quindi prenota il tempo libero per fare qualcosa di "quadro generale" e immagina che avrai bisogno di almeno due ore per arrivare davvero ovunque.

Il cambio di contesto funziona in entrambe le direzioni: dalla gestione al lavoro pratico e viceversa. Ma quando passi dal tuo punto di forza e pratica al tuo luogo di disagio e meno pratica, senti più il dolore e l'impeto di ritirarti è forte. Sappi che è lì e combatti e renditi conto che il thrash nel quadro generale ti rende migliore nel prendere tutto. Dedicati del tempo al thrash.

Leggi questo libro: Herding Cats: un primer per programmatori che guidano programmatori

Qualche tempo fa ho regalato questo libro al mio capo e gli è piaciuto. Quando lo stavo leggendo, sembrava che sapesse di cosa stava parlando. E così è. L'autore racconta la propria esperienza. Non è una raccolta di "semplici verità" del manager: queste sono le parole dell'ex programmatore. E si dovrebbe capire che è stata la SUA esperienza, ma la tua potrebbe essere diversa. Quindi, su alcune cose dovresti guardare in modo critico. "Il manager non può più essere un programmatore, è importante".

Quando di recente ho assunto la direzione tecnica di una piccola azienda su un prodotto che non ho sviluppato, quello che ho trovato molto utile nella gestione delle cose è stato quello di documentare in inglese il funzionamento del prodotto - caratteristiche che ho documentato in cetriolo e per uso interno Ho scritto spiegazioni sul modello a oggetti e scorre attraverso vari controller. Ciò che ho scoperto è stato che A) il prodotto era un po 'un casino :) E B) ho imparato molto più rapidamente come funzionava l'app, così da poter avere una conversazione intelligente su quali problemi c'erano e cosa necessitava di refactoring, o cosa sarebbe necessario per implementare una determinata funzionalità.

Le immagini aiutano anche: non pasticcio con prodotti come Visio, uso solo pastelli e carta bianca (davvero, lo faccio — lavoro da casa e spesso insieme al mio bambino di 2 anni) ma qualunque cosa funzioni per te è ciò che dovresti usare.