Non è del tutto raro in IT che i programmatori vengano aggiunti a un progetto esistente da qualche parte nel mezzo o più vicino alla fine.
Sfortunatamente, ho visto che la gente si disillude rapidamente e lascia il lavoro.
Quindi, c'è un problema reale? Se c'è un problema, c'è qualche ricerca in o ci sono le migliori pratiche per evitare questa sindrome di metà progetto-join?
È comune nell'industria?
Penso che l'atteggiamento sia la prima cosa. Ci sono state molte decisioni prese nel progetto che non hai avuto la possibilità di dare input. Probabilmente non sarete d'accordo con alcuni o anche con la maggior parte di essi. L'ultima fase di un progetto non è solitamente il momento migliore per rivisitare le decisioni prese mesi fa e che dipende molto dal codice, quindi scegli attentamente le tue battaglie. Non vuoi fare nemici dal primo giorno. Questo è simile ad entrare in un progetto legacy, quando arrivi in ritardo nel gioco. Non capisci tutto sul perché hanno fatto le scelte che hanno fatto, quindi aspetta un po ', prendi un po' di credibilità dalla tua stessa competenza e poi inizia a suggerire cambiamenti in ordine di importanza. Non farlo anche giorni prima di una scadenza critica.
Problemi del documento che hai trovato con l'approccio in modo da poter dimostrare il problema nel prossimo progetto che sei dall'inizio. Spesso avere dettagli su ciò che si è rivelato un errore rende più facile vendere in un modo diverso in seguito.
Il prossimo grosso problema sta diventando veloce abbastanza da essere utile. Soprattutto verso la fine di un progetto, le persone non hanno il tempo di aiutarti ad andare avanti.
Quindi trascorri i primi due giorni a costruire un elenco di domande mentre guardi attraverso il codice e poi parla con uno sviluppatore senior (o responsabile di una squadra se la persona è tecnica) delle tue domande in un colpo solo, piuttosto che infastidirle continuamente diversi giorni. Dovrai chiedere alcune cose immediatamente, ovviamente, non puoi guardare attraverso il codice se non sai dove trovarlo. Ma cerca di essere un po 'indipendente nel capire le cose.
Probabilmente ti assegnano un'area specifica in cui lavorare, fai in modo che la tua azienda legga i requisiti (se hai un documento sui requisiti) e guarda prima il codice in quell'area. Una volta che pensi di capirlo o di sapere di essere bloccato nel comprenderlo, allora vai a parlare con qualcuno a riguardo. Conferma che la tua comprensione sia corretta e poni le tue domande. Ma soprattutto non porre le domande in modo tale da far sentire la persona come se considerasse il proprio codice come spazzatura, anche se lo si fa (forse anche solo in modo espeicale). Se qualcosa ti viene in mente, chiedi perché non hanno fatto qualcosa "come hai potuto farlo?" Cerca di capire i loro processi di pensiero e decisionali, non solo il loro codice.
Se entrare alla fine di un progetto è scoraggiante (e ammettiamolo, non sarebbero assunti alla fine se non avessero avuto problemi) tieni presente che sarai lì per l'inizio del prossimo progetto e avere la possibilità di avere più input. Il tuo lavoro, in termini di carriera, è quello di fare un lavoro abbastanza buono su ciò che ti assegnano per guadagnare credibilità per essere un attore significativo nel processo decisionale nel prossimo progetto. Quindi fai del tuo meglio per essere un giocatore di squadra, per rispettare le scadenze e fornire un codice di lavoro che funzioni bene con ciò che è già stato fatto. Ora è il momento di impressionarli con la tua abilità nel fare le cose. Puoi impressionarli con il tuo splendore più tardi.
Devi essere illuso prima di poterti disilludere.
Se ti unisci a un progetto in qualsiasi momento durante lo sviluppo, assicurati di avere una chiara comprensione del compito e del tuo ruolo in esso. Se hai aspettative realistiche sul progetto e il progetto ha aspettative realistiche su di te, è più probabile che tu rimanga felice l'uno con l'altro.
Uno dei problemi principali è conoscenza organizzativa . Le persone che sono state coinvolte in un progetto fin dall'inizio sono al corrente del ragionamento che sta dietro le decisioni di progettazione, la politica che potrebbe essere campi minati, fasci di documentazione privi di documenti e così via. Serve solo a calpestare una mina terrestre che non avresti modo di sapere per farti prendere in considerazione l'idea di alzare la posta in gioco e andare avanti, specialmente quando non c'è comprensione da parte della direzione che il problema della conoscenza organizzativa esista (risultando così il nuovo ragazzo che sente di essere essere accusati di qualcosa in cui non aveva alcun ruolo).
Procedure di documentazione rigorose e coerenti possono rendere questo un ostacolo minore. Ad esempio, se un nuovo incarico sta assumendo un ruolo di supporto, assicurati che disponga delle risorse necessarie per rispondere effettivamente alle domande in modo competente piuttosto che aspettarsi semplicemente che sarà in grado di dedurre la soluzione dai materiali di formazione. ("Joe Oldguy, il cliente X ha appena chiamato per chiedere il problema Y. Che diavolo sta succedendo?" "Oh, il client X ha un problema nel loro processo. Devono essere A, B e C prima di D. Questo è diverso da tutti gli altri. Un passo deve essere andato storto in {A, B, C}. ")
La mia esperienza di ingegneri che si uniscono a un progetto software durante lo sviluppo è che più tardi ci si trova in una iterazione (o ci si chiede se ci si avvicini alla fine della fase di implementazione di un progetto di modello a cascata) più è difficile per un ingegnere integrarsi con il team e il progetto stesso. Quando inizi un lavoro, di solito c'è un periodo di "ramp-up". Se hai familiarità con il lavoro perché lo hai già fatto, puoi disegnare paralleli o essere strumentale nella fase dei requisiti e della progettazione, ti "accelererai" più rapidamente. Altrimenti, ci vorrà del tempo.
Più tardi in un iterazione / progetto sei, generalmente più alta è la pressione. Il tuo progetto potrebbe essere eccessivo o in ritardo, o entrambi. Potresti essere sottoposto a forti pressioni per risolvere i difetti o implementare funzionalità e il piano del progetto non ha tenuto conto del "ramp-up". Questo è comune Mentre dovresti essere caricato all'80% su un piano in modo che si possano tenere in considerazione ferie, malattia, ecc. La mia esperienza è che nel migliore dei casi è ingenuo.
È comune nell'industria che i join di metà progetto siano difficili. Generalmente significa che devi solo sgusciare e mettere le ore per arrivare alla velocità. Sfruttate qualsiasi aiuto possibile dai membri esistenti del team e fate del vostro meglio. Lanciare ingegneri a un progetto senza pianificarlo (vale a dire farli unire a metà strada senza alcuna "accelerazione" allocata) è di solito un segnale che non tutto va bene per quel progetto.
L'accoppiamento può rendere molto più veloce la preparazione di un nuovo progetto di sviluppo. Personalmente, ritengo che possa farmi accelerare sul progetto 3 o 4 volte più veloce di fare il lavoro da solo. Questo è molto utile perché puoi ottenere un sacco di storia / decisioni del progetto nello stesso momento in cui acquisisci familiarità con il codice.
Leggi altre domande sui tag project-management