Come gestite i progetti lasciati da altri dipendenti? [chiuso]

Succede che qualcuno lasci la compagnia all'improvviso. Ora il suo lavoro deve essere completato e ti viene assegnato. Non avendo idea di cosa stesse facendo (è stato fatto il 90% o il 9%), come gestisci gli avanzi?

1. Devo iniziare da zero? E se fosse stato fatto al 90%?
2. Devo provare a capire qualunque cosa abbia fatto? E se fosse solo una sciocchezza?

Per capire cosa fare, devi sapere cosa hai e in che forma è.

Quindi, inizia dando una rapida occhiata a tutte le fonti e vedi cosa hai. Se è vividamente chiaro, è più semplice finire ciò che manca. Fai dei test unitari per scoprire cosa funziona e cosa no.

Se non è vividamente chiaro, inizia a capire cosa funziona con i nuovi test unitari. Se ciò è impossibile, fai capire al tuo caposquadra che hai un problema e che potresti non essere in grado di risolverlo. Può quindi decidere se il lavoro di sinistra debba essere salvato comunque o se è semplicemente un peccato e devi rifarlo.

Oltre a quello che hanno scritto gli altri, ti suggerirei di parlare con chiunque abbia avuto un contatto diretto con il ragazzo. Capisco dalla tua descrizione che stava lavorando da solo, doveva comunque riferire a qualcuno? E potrebbe esserci del personale addetto al controllo qualità che ha testato ciò che aveva prodotto ... Queste persone dovrebbero (normalmente) avere almeno un'idea approssimativa di quanto il ragazzo si è avvicinato al suo progetto prima di partire. A meno che, naturalmente, le informazioni / il prodotto da lui forniti non siano completamente affidabili, contribuendo al suo licenziamento.

Discutilo con il tuo manager e alloca un lasso di tempo per l'esplorazione / test iniziale del codice rimanente e comprendi le specifiche e i requisiti. Questo potrebbe essere all'incirca un giorno per un progetto nella scala temporale di alcuni mesi di persona, al massimo una settimana per un progetto di lavoro di una o più persone per anno, ecc.

Dopo questa esplorazione iniziale, dovresti avere una stima approssimativa di

• cosa dovrebbe fare il prodotto,
• cosa può fare attualmente e quanto bene,
• quanto tempo e rischio ci vorrebbe per riscrivere da zero,
• quanto tempo e rischio ci vorrebbe per finire ciò che è già stato fatto.

Quindi puoi sederti di nuovo con il tuo manager per prendere una decisione.

Nella mia esperienza non è una situazione insolita. Sfortunatamente, hai davvero due problemi qui :

1) I resti di questo progetto 2) I motivi per cui sei entrato in questo casino in primo luogo

Per (1) è necessario considerare le dimensioni / complessità del progetto. Se è una settimana di lavoro, probabilmente dovrai ricominciare tutto da capo. Se è un anno di lavoro, potresti dover vedere cosa puoi recuperare dal codice esistente.

In entrambi i casi, è necessario eseguire immediatamente questi passaggi:

a) Spiega ai tuoi manager che hai un grosso problema

b) Ottieni le specifiche del progetto e ottieni una conoscenza approfondita di ciò che devi raggiungere, oppure parla con gli sponsor del progetto se non ci sono specifiche.

c) Parla con dirigenti / clienti ecc e scoprire se qualcuno ha / pensa di avere alcuna idea di ciò che lo stato del progetto è.

Una volta fatto, sarai in grado di iniziare a esaminare il codice / elaborare una strategia.

(Non credo 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 essere lì.)

Quello che non vedrei dopo è avere una visione d'insieme dell'architettura del codice esistente e di come questo si associa al problema definito nelle specifiche. Quindi lavora su quali sono i sottocomponenti di ciascuno di questi componenti principali e guarda come si adattano al quadro generale. In questo modo 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.

Una volta fatto tutto ciò, sarai in grado di stimare quanto lavoro resta da fare.

Per quanto riguarda la parte (2), la tua azienda potrebbe dover esaminare le politiche di assunzione / le politiche di fidelizzazione del personale, trovare modi per rendere i programmatori responsabili dei progressi.

Infine, dovresti anche considerare come potresti evitare che ciò accada alla compagnia se dovessi andartene di fretta.

Devi assolutamente provare ad eseguire il software per vedere cosa funziona e cosa no.

Dovrai quindi considerare quale documentazione è stata lasciata. Ci sono requisiti scritti? Esistono attività specifiche: le attività vengono monitorate in qualche modo? Qualcuno lo ha testato? In tal caso, sapranno cosa è stato fatto e cosa no.

Penso che un piano d'azione sarebbe:

1. Contrassegnare quali requisiti sono stati completati (eseguendo rapidamente il sistema come farebbe un tester)

2. Guarda il codice: puoi dargli un senso? È ben scritto?

Chiaramente se è fatto al 90% e il codice è ben scritto, lo finiresti.

Non ancora menzionato.

Prova a contattare il ragazzo che ha lasciato. Non è possibile in ogni caso. Ma se è sano e almeno gli è piaciuto un po 'il suo lavoro, ti aiuterà e ti darà una risposta onesta a progressi e parti mancanti. E potrebbe spiegarti il ​​quadro generale.

Congratulazioni, questa è la tua occasione per brillare e fare un'impressione davvero positiva sui tuoi capi. Quello che hai qui è un'opportunità inestimabile. Quindi cosa devi fare e come?

Innanzitutto, ottieni il codice. Potrebbe non aver registrato tutto (il ragazzo che ci ha fatto questo non lo ha fatto) e quindi qualcuno con i diritti di amministratore lo estrae dal suo computer e lo fa per te.

Successivamente triage il problema. Prendi i requisiti e osserva quali parti sembrano avere il codice scritto e quali no. Questa è la lista approssimativa di ciò che non è finito. Crescerà mentre fai il prossimo passo. Quindi scorrere il codice, valutarlo, eseguirlo e vedere cosa funziona attualmente e cosa sembra non funzionare anche se è stato scritto del codice. Aggiungi le parti non funzionanti all'elenco. Cerca i test unitari (sarei sorpreso se li trovassi, le persone che salvano poco prima di una scadenza perché sanno che stanno fallendo tendono a non scriverli). Ora almeno hai una buona idea di quanto sia brutto. Guarda anche i requisiti e vedi a quali domande devi rispondere. Molto tempo, i fallimenti del progetto derivano da scarsi requisiti e da 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 quindi elenca le cose che devi fare per completare il lavoro. Fai una stima di quanto tempo impiegherà ciascuno. Determina se ciò che esiste attualmente è salvabile (e in caso contrario, preparati a giustificare il perché).

Ora incontrate il project manager (e il vostro capo se sono due persone diverse) e ditegli le cattive notizie. (È quasi sempre una brutta notizia quando qualcuno esce all'improvviso e devi riprendere da dove avevano interrotto, i buoni sviluppatori non lasciano le persone in difficoltà - almeno se ne vanno con un elenco di ciò che hanno fatto e di ciò che resta da fare L'eccezione potrebbe essere se qualcuno se ne andasse a causa di problemi di salute.) Nella tua discussione, potresti ottenere alcune delle risposte di cui hai bisogno e tu e il PM potete rielaborare un po 'il piano del progetto.

Seguire la riunione inviando il Primo Ministro e altre parti interessate (il Primo Ministro identificherà chi), una copia delle domande a cui è necessario rispondere e il piano di progetto elaborato.

Ora hai quello che ti serve per iniziare con la codifica attuale, quindi mettiti al lavoro.

Nel frattempo, probabilmente sei stato tirato fuori qualcos'altro per salvare questo progetto. Assicurati che il tuo lavoro sia in forma per essere raccolto da qualcun altro o per te dopo aver terminato il progetto. Ciò significa gli stessi tipi di cose, un documento in cui dici cosa viene fatto e che cosa non lo è e un check-in di tutto il codice sorgente (non necessario al trunk se non viene fatto, ma da qualche parte in cui qualcun altro può accedervi .

Se non sei stato rimosso dal tuo lavoro esistente, allora devi allenarti con il tuo capo quanto tempo nella giornata lavorativa trascorrerai su ciascuno di essi. Questa è una di quelle volte in cui possono essere necessari straordinari e saranno apprezzati. Più è vicino alla scadenza effettiva, più la gestione è disperata, potresti essere in grado di calcolare la retribuzione degli straordinari o un grande bonus se la scadenza è vicina. Se questo lavoro ritarderà in modo significativo l'altro lavoro, allora devi assicurarti che le parti interessate in quel progetto ne siano consapevoli.

Una volta riuscito a salvare il progetto, assicurati di vantartene nella prossima revisione delle prestazioni.