Ho appena avuto una discussione molto interessante in un seminario la scorsa settimana su questo stesso problema. Di conseguenza, ho aggiunto alcune cose alla mia lista di controllo per accettare lavori a contratto:

• Passaggio 1: chiedi di parlare con lo sviluppatore precedente. Se non è disponibile, chiedi perché. È molto più probabile che l'appaltatore abbia licenziato il cliente rispetto al contrario. Questo è qualcosa che vorresti sapere.

• Passaggio 2: se lo sviluppatore precedente non è disponibile a causa di qualcosa di diverso dalla morte o dal rapimento alieno, ripensa seriamente ad accettare il progetto. Non dico che sia sempre così, ma la mia esperienza nell'acquisizione di progetti abbandonati è stata mista. Solo uno era a causa di uno sviluppatore seriamente fuori dalla sua profondità. La maggior parte è stata a causa di problemi politici, precedente cattiva gestione e percezioni divergenti dell '"obiettivo" del progetto.

• Passaggio 3: Richiedi la comunicazione dei 3 mesi precedenti con il proprietario del progetto e lo sviluppatore per entrare nel contesto. Se sei fortunato, è in JIRA o qualcosa di simile. Se non è stato gestito correttamente, riceverai un mucchio di email.
• Passaggio 4: quindi fai una rapida revisione dei requisiti aziendali, quindi esamina il progetto e documenta l'architettura. Leggi le comunicazioni, quindi torna indietro e guarda di nuovo il progetto per vedere se puoi iniziare ad abbinare tutti questi elementi.
• Passaggio 5: a questo punto, dovresti avere circa 20 domande per lo sviluppatore, quindi vedi se riesci a ottenere mezz'ora del loro tempo per una teleconferenza. L'altro sviluppatore può fatturare questo tempo, quindi mantienilo conciso.
• Passaggio 6: prepara un rapporto sui requisiti, cosa è stato fatto su ciascuno (suddividilo in sviluppo, test e accettazione da parte degli utenti, almeno) e cosa resta da fare. Se hai tempo, è utile anche aggiungere valutazioni di scalabilità e "fragilità" di ciò che è stato completato.

A questo punto, dovresti avere un incontro con il tuo capo e analizzarlo. Allora dovresti chiedere delle priorità. Ti spingerà sui requisiti di risorse / tempo in questa riunione, ma non sei ancora abbastanza approfondito da dirlo con certezza. Assicurati che il tuo capo lo capisca.

Il meglio che posso fare per una procedura "Generica - Inizia".

Vale la pena leggere - un po 'di umorismo, un po' di verità: http: / /wikibon.org/wiki/v/Prepare_three_envelopes

Raccogli tutta la documentazione esistente e leggila

Fai una rapida revisione del codice (tipo 1-2 giorni)

Non dire che il programma è spazzatura e devi iniziare finita anche se lo fai. Non vogliono sentirlo. C'è qualcosa che puoi salvare. Questi moduli sembrano solidi, richiedono molto lavoro e devono ricominciare da capo.

Scrivi i requisiti e progetta se non ce n'è uno

Se si lamentano molto dell'ultimo ragazzo e non sanno davvero cosa vogliono, preparati a essere l'ultimo ragazzo si lamentano.

La mia opinione su questo è leggermente diversa, in quanto darei più peso alla determinazione dei requisiti rispetto alla maggior parte degli altri partecipanti. Ci possono essere diversi motivi per cui un appaltatore ha lasciato improvvisamente, ma troppo spesso il motivo per cui un "programmatore non aveva idea di cosa stesse facendo" è perché gli stakeholder non avevano idea di cosa volessero. È molto importante esaminare i requisiti in dettaglio e porre tutte le domande che potresti avere su di essi. Se ottieni resistenza a questo, è una grande bandiera rossa, perché non avrai nemmeno idea di cosa stai facendo e sarai un comodo capro espiatorio per tutti.

Negli anni '90 sono stato eliminato come capro espiatorio numero due in una situazione come questa. Diversi mesi dopo, stavo insegnando a un corso nella stessa città e c'era un ragazzo della compagnia che mi aveva cacciato. Come si è scoperto, si erano appena sbarazzati del capro espiatorio numero tre, che aveva preso il posto di me (partendo da zero, potrei aggiungere), aveva messo al lavoro uno dei loro dipendenti e si erano assicurati che avesse una formazione sufficiente per diventare capro espiatorio numero quattro. In altre parole, il problema era con questi appaltatori, dacci tutti come inutili, formiamo uno dei nostri e portiamo a termine il lavoro. Il vero problema era che c'era un manager che andava alle riunioni del consiglio due volte a settimana e tornava con i requisiti modificati per il software che stavamo scrivendo. Per essere onesti, non era un manager IT, ma quando ho cercato di respingere e dire che dovevamo smettere di cambiare i requisiti a ogni riunione del consiglio, lei si limitava a scrollare le spalle e dire che dobbiamo fare ciò che vuole il consiglio. Quando ho detto che era abbastanza chiaro che non sapevano cosa volessero, dal momento che hanno continuato a cambiare idea e si sono offerti di incontrarli direttamente, mi sono messo fermamente sulla strada del capro espiatorio numero due. (Al giorno d'oggi proverei un po 'di più a istruire il manager sulle conseguenze sulla deliverability dei requisiti in evoluzione prima di adottare questo approccio.)

Se il tuo predecessore era ovviamente incompetente, potresti menzionare qualcosa non appena puoi efficacemente dimostrare la verità di tale affermazione. Se il codice è pieno di problemi architettonici, questo è un problema per il successo del progetto e la direzione dovrà conoscerlo. Ma sarà tuo compito convincerli, quindi assicurati di nuovo di poterlo fare.

Avendo avuto un cliente molto complicato in passato, rafforzerei la difficoltà di parlare con lo sviluppatore precedente. Il più delle volte, l'attore precedente potrebbe aver licenziato il cliente.

Sono stato così sfortunato da prendere un pessimo cliente, che ha gestito male gli appaltatori, ha perso tempo, ha cambiato i requisiti e dopo aver avuto il il lavoro svolto per lo più ha dispensato l'appaltatore e non voleva manutenzione ... e ha lasciato che la soluzione marcisse il più a lungo possibile, e ha ricominciato il ciclo da zero con un altro appaltatore - e prima di provare un nuovo appaltatore, ti hanno chiamato con un altro lavoro magnifico ... che rifiuteresti, ovviamente.

Documenta tutti i passaggi per iscritto / e-mail, inclusi requisiti, negoziazione e valori pagati.

In quanto appaltatore, è nel tuo interesse iniziare da zero, quindi prima ancora di guardare al lavoro svolto e contemplare di accettare un lavoro, spingo quell'angolo. E farò la mia prima citazione generale basata su questo assunto. E nella maggior parte dei casi sarebbe un prerequisito per me assumerlo.

Prenderò il controllo solo se non c'è scelta perché le scadenze si stanno avvicinando e posso vedere che almeno un lavoro parzialmente funzionante è stato fatto . Ma l'ho fatto solo una volta e quello era più un servizio per un cliente esistente, piuttosto che un nuovo lavoro. Quello che farò è prendere la struttura di un lavoro e rimuoverlo se è già stato completamente eliminato. Ciò consente effettivamente di risparmiare un sacco di fatica. Ma lavorare e risolvere i problemi con il codice di qualcun altro può essere un gran mal di testa, soprattutto se non è ben commentato.

I professionisti non si chiudono improvvisamente durante un progetto a meno che non abbiano seri problemi con il lavoro o con il cliente e il tipo di persona che lo farebbe non va oltre a incasinare il codice all'uscita (a meno che non si tratti di un problema di salute o di morte improvvisa).

Quindi, se prendi questo tipo di lavori, Dovrò controllare le cose molto accuratamente. E la prima cosa che dovresti scoprire è se il programmatore originale è contattabile, perché se non lo è, allora quella è una bandiera rossa. La maggior parte delle volte mi è stato chiesto che fosse molto vago e il tipo originale non era contattabile, e ho rifiutato il lavoro a meno che non lo facessi da zero.