Succede che qualcuno lasci improvvisamente la compagnia. Ora il suo lavoro deve essere completato e ti viene assegnato. Non avendo idea di cosa stesse facendo (era fatto al 90% o al 9%), come gestisci gli avanzi?
Per capire cosa fare, devi sapere cosa hai e quanto è buono in esso.
Quindi, inizia con una rapida occhiata a tutta la fonte e vedi cosa hai. Se è vividamente chiaro, è più facile finire ciò che manca. Fai test unitari per scoprire cosa funziona e cosa no.
Se non è vividamente chiaro, inizia a capire cosa funziona con i nuovi test di unità. Se questo è impossibile, fai notare al tuo capo squadra che hai un problema e che potresti non essere in grado di farlo. Può quindi decidere se il lavoro lasciato dovrebbe essere comunque salvato o se è semplicemente troppo brutto e devi rifarlo.
Oltre a ciò che altri hanno scritto, ti suggerirei di parlare con chiunque avesse un contatto diretto con il ragazzo. Capisco dalla tua descrizione che stava lavorando da solo, ma deve aver segnalato qualcuno? E potrebbe esserci personale del QA che ha testato ciò che ha prodotto ... Queste persone dovrebbero (normalmente) avere almeno una vaga idea di quanto il ragazzo abbia ottenuto con il suo progetto prima di partire. A meno che, ovviamente, le informazioni / prodotti da lui forniti non siano completamente affidabili, contribuendo al suo licenziamento.
Discutere di questo con il proprio manager e allocare un intervallo di tempo per l'esplorazione / test iniziale del codice rimanente e comprendere le specifiche ei requisiti. Questo potrebbe essere circa un giorno per un progetto sulla scala temporale di pochi mesi di persona, al massimo una settimana per un progetto di uno o più anni di lavoro, ecc.
Dopo questa esplorazione iniziale, dovresti avere una stima approssimativa di
Quindi puoi sederti nuovamente con il tuo manager per prendere una decisione.
Nella mia esperienza questa non è una situazione insolita. Sfortunatamente hai veramente due problemi qui :
1) Gli ultimi di questo progetto 2) I motivi per cui sei entrato in questo casino in primo luogo
Per (1) è necessario considerare la dimensione / complessità del progetto. Se è una settimana di lavoro, probabilmente devi ricominciare tutto da capo. Se è un lavoro di un anno, potrebbe essere necessario vedere cosa è possibile recuperare dal codice esistente.
In entrambi i casi, è necessario eseguire immediatamente queste operazioni:
a) Dì ai tuoi dirigenti che hai un grosso problema
b) Ottieni le specifiche del progetto e ottieni una conoscenza approfondita di ciò che devi realizzare - o parla con gli sponsor del progetto se non ci sono specifiche.
c) Parla con i gestori / clienti ecc. e scopri se qualcuno ha / pensa di avere qualsiasi idea di quale sia lo stato del progetto.
Dopo averlo fatto, sarai in grado di iniziare a esaminare il codice / elaborare una strategia.
(Non penso che i test unitari ti aiuteranno molto - potrebbero dirti se le funzioni che sono state scritte funzionano davvero, ma non ti dicono quali funzioni dovrebbero esserci.)
Quello che non troverei dopo è una panoramica dell'architettura del codice che esiste e di come si mappa sul problema definito nelle specifiche. Quindi, lavoriamo su quali sono i componenti secondari di ciascuno di questi componenti principali e vediamo come si adattano al quadro generale. Fare questo ti dirà (approssimativamente) quali componenti mancano.
Una volta che sai cosa esiste, devi iniziare a esaminare il codice esistente per vedere se fa quello che dovrebbe fare.
Dopo aver fatto tutto questo, sarai in grado di stimare quanto lavoro è ancora da fare.
Per quanto riguarda la parte (2), la tua azienda potrebbe aver bisogno di esaminare le politiche di assunzione / politiche di fidelizzazione del personale, trovare modi per tenere i programmatori responsabili dei progressi.
Infine, dovresti anche considerare in che modo puoi impedire che ciò accada all'azienda se tu parti di fretta.
Devi assolutamente provare a eseguire il software per vedere cosa funziona e cosa no.
Dovrai quindi considerare quale documentazione è stata lasciata. Ci sono dei requisiti scritti? Ci sono compiti specifici: le attività vengono tracciate in qualche modo? Qualcuno lo ha testato, in tal caso sapranno cosa è stato fatto e cosa no.
Penso che un piano d'azione sarebbe:
Segna quali requisiti sono stati completati (con una rapida esecuzione del sistema come farebbe un tester)
Guarda il codice: puoi capirci qualcosa? È scritto bene?
Chiaramente se è fatto al 90% e il codice è ben scritto, lo finiresti.
Non menzionato ancora.
Prova a contattare il ragazzo che è uscito. Non è possibile in ogni caso. Ma se è sano e almeno ha gradito un po 'il suo lavoro, ti aiuterà e ti darà una risposta onesta sui progressi e sulle parti mancanti. E lui potrebbe spiegarti il quadro generale.
Congratulazioni, questa è la tua occasione per brillare e fare davvero una buona impressione sui tuoi capi. Quello che hai qui è un'opportunità inestimabile. Allora, cosa devi fare e come?
Per prima cosa, prendi il codice. Potrebbe non aver controllato tutto (il tizio che ci ha fatto questo no) e quindi avere qualcuno con diritti di amministratore, estrarlo dal suo computer e controllarlo per te.
Avanti, triage il problema. Prendi i requisiti e nota quali parti sembrano avere il codice scritto e quali no. Questa è la lista approssimativa di ciò che non è finito. Crescerà man mano che farai il prossimo passo. Quindi passare attraverso il codice e valutarlo ed eseguirlo e vedere ciò che è attualmente funzionante e ciò che sembra non funzionare anche se c'è il codice scritto. Aggiungi le parti non funzionanti all'elenco. Cerca i test unitari (sarei sorpreso se li trovassi, le persone che salvano prima di una scadenza perché sanno che stanno fallendo tendono a non scriverle). Ora almeno hai una buona idea di quanto sia male. Guarda anche i requisiti e vedi quali domande hai bisogno di una risposta. Un sacco di tempo, i fallimenti del progetto derivano da requisiti poveri e uno sviluppatore che non vuole (per una miriade di ragioni) porre ulteriori domande.
Ora fai il tuo piano di progetto. Inizia con un elenco delle domande che hai dai requisiti (scrivilo formalmente in un documento) e poi elenca le cose che devi fare per completare il lavoro. Fai una stima di quanto tempo ci vorrà. Determina se ciò che esiste attualmente è recuperabile (e in caso contrario, preparati a giustificare perché no).
Ora incontrati con il project manager (e il tuo capo se sono due persone diverse) e informali delle cattive notizie. (È quasi sempre una cattiva notizia quando qualcuno si allontana improvvisamente e devi riprendere da dove avevano lasciato, i bravi sviluppatori non lasciano la gente in asso: almeno lasciano un elenco di ciò che hanno fatto e di ciò che resta da fare L'eccezione potrebbe essere se qualcuno se ne fosse andato a causa di problemi di salute.) Nella tua discussione, potresti ottenere alcune delle risposte di cui hai bisogno e tu e il PM potresti rielaborare un po 'il piano del progetto.
Segui l'incontro inviando il PM e altri stakeholder critici (il PM identificherà chi), una copia delle tue domande a cui è necessario rispondere e il piano del progetto che hai elaborato.
Ora hai ciò di cui hai bisogno per iniziare la codifica attuale, quindi mettiti al lavoro.
Nel frattempo, probabilmente sei stato portato fuori qualcos'altro per salvare questo progetto. Assicurati che il tuo lavoro sia in forma perché qualcuno possa riprenderlo o che tu possa riprenderlo dopo aver completato il progetto. Ciò significa lo stesso tipo di cose, un documento in cui dici cosa è stato fatto e cosa no e un check-in di tutto il codice sorgente (non necessariamente per il trunk se non è fatto, ma da qualche parte che qualcun altro può accedervi .
Se non ti è stato tolto il lavoro esistente, allora devi lavorare con il tuo capo per quanto tempo dedichi a ciascuno il giorno lavorativo. Questo è uno di quei momenti in cui gli straordinari possono essere necessari e saranno apprezzati. Più si avvicina alla scadenza effettiva, più la gestione è disperata, si può essere in grado di calcolare le ore di lavoro straordinario o un grande bonus se la scadenza è vicina. Se questo lavoro sta ritardando significativamente l'altro lavoro, è necessario assicurarsi che gli stakeholder di quel progetto ne siano consapevoli.
Una volta riuscito a salvare il progetto, assicurati di esserne orgoglioso nella prossima revisione del rendimento.
Leggi altre domande sui tag project-management efficiency