Ho esternalizzato più di 300 progetti IT di tutte le dimensioni negli ultimi 10 anni. Sono stato io stesso lo sviluppatore esterno.

Ecco i problemi più problematici che ho riscontrato più volte e i suggerimenti per evitarli (imparo nel modo più duro). Questi errori mi sono costati centinaia di migliaia di dollari, quindi spero che risparmierai tanto grazie ai suggerimenti quindi sono pari e posso riposare in pezzi:)

• richiede l'accesso al repository . Se non è possibile, richiedere di essere inviato alla fonte completa ogni settimana per la revisione.

Non vuoi scoprire alla fine del progetto che il codice non ha rispettato i tuoi standard di qualità come i commenti mancanti, la documentazione, le cattive pratiche di codifica, ecc. Rivedendo il lavoro frequentemente ti consentirai di dare un feedback all'inizio del fase di sviluppo.

• assicurati di aver firmato i documenti di assegnazione NDA e IP appropriati .

Questo è uno degli errori più comuni. Le cose sono andate male per la compagnia che hai esternalizzato il progetto per rivendicare la piena proprietà del loro lavoro. O peggio, decidono di usare quello che hai pagato per i loro affari. Assicurati che sia firmata una corretta assegnazione di diritti di proprietà intellettuale e NDA.

• spesso usano framework di librerie personalizzate senza codice sorgente . Verifica che sia accettabile per te.

A volte gli sviluppatori o la società che hai assunto decidono di utilizzare framework o librerie personalizzate che hanno scritto. Questo potrebbe essere un problema se sei così dipendente da cambiare il tuo sviluppatore è quasi impossibile. A volte il negozio di sviluppo ti darà pieno diritto sul codice che hanno scritto appositamente per te ma non sulle loro librerie. È così problematico. Assicurarti di avere la possibilità di continuare il tuo progetto senza di loro è una possibilità davvero importante che vuoi mantenere.

• assicurati che utilizzino gli standard nella tecnologia di scelta .

Anche se non usano librerie personalizzate specifiche, potresti dover affrontare un altro problema: un modo specifico di codifica che non soddisfa gli standard del settore. Nel peggiore dei casi, devi riscrivere tutto per rendere possibile qualsiasi manutenzione senza di loro.

• se la scadenza è importante, richiedi le sanzioni nel caso in cui lo perdano .

Questo è uno a volte non specificato in modo esplicito. Cosa succede se perdono la scadenza? Diciamo che affrontano un strong problema interno che impedisce loro di consegnare in tempo? Avrai il budget da sviluppare in un altro dev shop in modo urgente?

As a general rule, I would add that the specification is very important in that kind of work. So you have lot of responsibilities there. With time, I learnt that it's preferable to propose a first small project to a company to test it first, and reserve bigger projects to trusted providers you work with before.

Insieme alle risposte precedenti.

• Se è possibile, cerca di intervistare i ragazzi con cui stai lavorando. Dovresti essere consapevole delle capacità e degli stili di comunicazione e sviluppo delle persone con le quali lavorerai. Questo imposta anche i canali di comunicazione.

• Richiedi prova dei concetti.

• Dare il req & fase di progettazione più attenzione. La stabilità dei requisiti è molto importante se il progetto ha un programma serrato. In caso contrario, la fase di risoluzione dei bug verrà trascinata inutilmente.

Ora che sono sopravvissuto al progetto che mi ha spinto a chiedere questo, riassumerò il mio apprendimento come:

Fidati, ma verifica

Non puoi fare affidamento su ciò che il rappresentante dell'azienda esterna ti dice sullo stato dell'app o sul sistema. Possono fraintendere i requisiti o non riescono a trasmettere rapporti / domande / problemi dai loro sviluppatori, potresti fraintendere le loro relazioni sullo stato dei test, o, meno caramente, potrebbero pensare di poter "consegnare" una caratteristica che non hanno testato a tutti.

Insistere su alcune funzionalità che vengono consegnate ai (vostri!) tester in determinate date, se possibile. Altrimenti potresti finire con un mucchio di funzionalità "consegnate" proprio alla fine del progetto, che porteranno a una serie di bug che dovrai (a) pagare più soldi per sistemare, o (b) aggiustare te stesso.

Oltre a ciò Pierre 303 ha affermato, dal momento che stai sviluppando API, ci sono un paio di cose aggiuntive che dovresti richiedere all'azienda:

• Assicurati che l'azienda scriva anche i documenti API appropriati. doxygen sembra apparentemente andare bene con Obiettivo- Programmatori C (che accetta il ben noto formato JavaDoc). Le API sono librerie pubbliche (anche se vengono utilizzate in un'impostazione privata come all'interno di un'azienda) ed è importante che sono ben documentate.
• Suggerisci test con TDD e BDD. BDD ti coinvolge nella scrittura di specifiche per l'API, che chiude il ciclo di sviluppo tra te e l'azienda. Le API di solito sono la forma più semplice di software per fare TDD / BDD con. Dico suggerire, dal momento che alcune aziende probabilmente non sanno come fare questo.