Offshoring di un progetto software - Risoluzione dei conflitti [chiuso]

Mi era stato affidato il compito di gestire un progetto che era stato esternalizzato ad alcuni sviluppatori ucraini.

La compagnia li assunse attraverso Elance a un prezzo fisso . A quel punto il mio capo mi ha lasciato solo per gestirli e portare a termine il lavoro. Ho creato una specifica dettagliata di tutto ciò che doveva essere fatto.

Il progetto prevedeva di occuparsi di cose come XMPP, RabbitMQ e Database. Nel mio primo incontro con loro (sempre IM) ho spiegato a fondo cosa dovevano fare. Sembravano capirlo - ed erano molto fiduciosi che sarebbe stato facile farlo.

Fin qui tutto bene. Ma dopo una settimana, quando ci siamo incontrati di nuovo, erano pieni di incomprensioni su ciò che doveva essere fatto. Quando ho chiesto a uno degli sviluppatori se conosceva XMPP, mi ha detto che ci stava lavorando per la prima volta. Al nostro primo incontro avevo menzionato in modo molto specifico la complessità del progetto e le tecnologie coinvolte. Inoltre, avevo ripetutamente chiesto loro di scrivere una specifica funzionale di esattamente come lo avrebbero fatto. Ma hanno detto NO e hanno insistito sul fatto che avrebbero preferito scrivere il codice. Ho detto ok.

Il progetto è stato completato dopo 3 settimane e hanno consegnato ciò che era necessario. A quel punto ho iniziato a rivedere il codice. È andato tutto bene per la maggior parte, ma ci sono alcuni problemi importanti:

• hanno codificato alcune delle cose che dovevano essere separate in un file di configurazione
• c'erano più file di configurazione che dovevo consolidare in uno
• hanno scritto assolutamente NESSUNA documentazione
• alcune altre piccole modifiche

Ho chiesto loro di apportare queste modifiche (tranne la documentazione) - E abbiamo avuto una discussione.

Dissero che, dato che il prezzo era stato fissato, non ero giusto nel chiedere loro di apportare modifiche una volta completato il codice di lavoro. Che avevano lavorato per un periodo irragionevole sul progetto e ora era completamente sbagliato chiedere qualcosa.

Finalmente ora hanno apportato le modifiche e il progetto è finito. Ma mi vengono in mente alcune domande ...

• Hanno fatto ciò che era necessario, ma io ne avevo bisogno nel modo giusto , e quindi i cambiamenti. ero davvero ingiusto?

• Perché ho accettato di lasciarli codificare senza avere una specifica funzionale?

• Perché non mi sono assicurato che capissero tutto la prima volta?

Qualcuno si ritrova nella stessa posizione? Pensi che ci sia un modo migliore per gestire i progetti in outsourcing?

-- AGGIORNARE --

Grazie per tutte le opinioni - dopo aver riflettuto sull'intera esperienza, posso concludere ...

• Anche se non ero vago nelle specifiche dalla mia parte, certamente non li ho resi coraggiosi come suggerito. Quindi il take away è: sii sempre il più specifico possibile - leggi anche le tue specifiche dalla loro prospettiva e vedi se ti sei perso qualcosa. Ripeti almeno tre volte.

• Basta specificare cosa dovrebbe fare il codice non abbastanza. È necessario specificare l'aspetto del codice. Quale sarà la struttura delle directory; anche i nomi dei file, se possibile. Questo ti salverà da molti fastidi in seguito. Specificare rigorosamente le linee guida di codifica, le convenzioni di denominazione variabili, il formato della documentazione interna, ecc. Accertarsi che rispettino tali linee guida e, in caso contrario, urlare.

• Richiedi una specifica funzionale dalla loro parte - insisti che sia scritta prima di qualsiasi codice. Ciò eliminerà molte confusioni e incomprensioni.

• Rivedi il codice mentre viene sviluppato in modo da identificare le anomalie in precedenza e farle correggere. Parla con loro almeno una volta ogni due giorni.

• Infine, cerca di stabilire un buon rapporto con loro. Fagli sentire che apprezzi il loro lavoro. Non spingerli in modo esagerato per adattarli alle tue linee guida, ma richiedi loro di farlo e di dire loro che renderebbe il mantenimento del codice molto più facile per te una volta completato il progetto.

Prima di tutto questo non è un problema di off shoring, è un problema di gestione del fornitore

Sì, hai commesso MOLTI errori ...

Hanno fatto ciò che era necessario, ma io ne avevo bisogno nel modo giusto, e quindi i cambiamenti. ero davvero ingiusto?

Sì, è giusto, se lo volevi fare in un certo modo avresti dovuto dirlo prima che il prezzo fosse concordato, in modo che possano fare offerte di conseguenza.

Perché ho accettato di lasciarli codificare senza avere una specifica funzionale? Perché non volevi pagare per le specifiche! La documentazione richiede tempo e denaro, dovrebbero semplicemente farlo gratuitamente?

Perché non mi sono assicurato che capissero tutto la prima volta?

Hanno capito. Ma al tuo pugno che si incontra DOPO che il contratto è stato firmato (e il prezzo fisso concordato) è quando l'hai SCADUTO! Quindi la necessità di ridurre i costi (ore) dove tutti potevano. Fondamentalmente tenendo solo un incontro a settimana, senza dare alcuna opzione di confutazione.

Ecco come farlo la prossima volta ... In due fasi ...

Fase 1: faglieli raccogliere i requisiti, eseguire l'analisi dei sistemi e scrivere il disegno tecnico e \ o le specifiche funzionali (o scriverlo tu stesso). Concordare un prezzo per questa fase. Assicurati di spiegare che non c'è alcun impegno da parte tua a dare loro la fase di sviluppo. Assicurati di includere il tempo per l'incontro nel prezzo.

Fase 2: fagli fare offerte sugli sviluppati in base alle specifiche ora che loro (e te) hanno, e sanno davvero che lo sforzo è coinvolto. Assicurati di nuovo di includere il tempo per le riunioni nel prezzo. Perché includere un piccolo budget opzionale per le modifiche.

Modifica: voglio aggiungere un ulteriore punto .. Anche qui il venditore è in errore, parte del lavoro è troppo utile per guidare l'utente nella gestione del progetto e farti sapere dove ci sono problemi nel processo.

Ne avevo bisogno fatto correttamente

Quindi non esternalizzarlo o, se lo fai, assicurati che funzionino nel tuo team di progetto e che tu partecipi alle revisioni del codice in quel momento.

Il progetto è stato completato dopo 3 settimane e hanno consegnato ciò che era necessario. A quel punto ho iniziato a rivedere il codice.

Ancora una volta, avresti dovuto rivedere il codice durante il progetto, non dopo.

Dissero che, dato che il prezzo era stato fissato, non ero giusto nel chiedere loro di apportare modifiche una volta completato il codice di lavoro.

Hai pagato loro un prezzo fisso per il codice funzionante. Ops. Non è colpa loro, è tua. Paga il loro tempo per partecipare agli sprint che controlli e non incontrerai questo problema. Dovresti pagarli per il tempo e accettare le storie degli utenti, non per il codice.

Nel mio primo incontro con loro (sempre IM) ho spiegato a fondo cosa dovevano fare. Sembravano capirlo - ed erano molto fiduciosi che sarebbe stato facile farlo.

Quando si ha a che fare con un progetto completamente esternalizzato, è necessario assicurarsi che le specifiche siano coronate. Se devi spiegare qualcosa che richiede più di qualche frase, le tue specifiche non sono complete. Questo è il motivo per cui sono passati dalle specifiche.

Quando ho chiesto a uno degli sviluppatori se conosceva XMPP, mi ha detto che ci stava lavorando per la prima volta.

È comune quando si esternalizzano in popolari paesi offshoring a basso costo per gli sviluppatori di gonfiare troppo i propri curriculum e le proprie competenze solo per sbarcare il lavoro. Spesso non si preoccupano delle loro capacità fino a quando non lo atterrano, perché molti di loro riprendono a costruire per sbarcare il concerto che in realtà paga un salario confortevole.

Perché ho accettato di lasciarli codificare senza avere una specifica funzionale?

Solo tu puoi rispondere da solo, ma prenderlo come esperienza di apprendimento per la prossima volta.

La compagnia li assunse attraverso Elance a un prezzo fisso. A quel punto il mio capo mi ha lasciato solo per gestirli e portare a termine il lavoro. Ho creato una specifica dettagliata di tutto ciò che doveva essere fatto.

Quindi voi due prima avete fatto un contratto e poi vi hanno lasciato scrivere una specifica, e hanno accettato quella specifica per diventare parte del vostro contratto? Se è andata così, non è colpa tua, è colpa del tuo appaltatore. Avresti potuto facilmente scrivere una specifica dando loro 3 mesi di lavoro anziché 3 settimane, tutto allo stesso prezzo.

È andato tutto bene per la maggior parte, ma ci sono alcuni problemi importanti:

• hanno codificato alcune delle cose che dovevano essere separate in un file di configurazione
• c'erano più file di configurazione che dovevo consolidare in uno
• hanno scritto assolutamente NESSUNA documentazione
• alcune altre piccole modifiche

Queste cose facevano parte delle tue specifiche? Se lo fossero, è colpa loro. In caso contrario, è tuo. Se non è stato davvero chiaro se queste cose sono contenute nelle specifiche, allora è anche colpa tua, dal momento che hai scritto il documento. Prova a scrivere una specifica migliore la prossima volta.

Qualche tempo fa ho fatto una presentazione sull'offshoring. Si chiamava "Global Outsourcing, 10 consigli per potenziare la tua attività". Ecco un riepilogo dei 10 suggerimenti (questo proviene da un massimo di 400 progetti in outsourcing):

Una scelta

1. Evita gli offerenti più bassi e più alti . Questo è ovvio, non si vuole correre rischi con offerenti più bassi e gli offerenti più alti tendono ad essere meno preziosi (valore / prezzo) rispetto alla mediana.

2. Verifica valutazioni (o riferimenti) . Controllo sempre riferimenti e valutazioni.

3. Dai la priorità alla motivazione . A parità di prezzo, scelgo l'offerta motivata. Ad esempio, fare in modo che l'offerente parli correttamente del proprio progetto è un ottimo segno.

B. Supervisione

1. Proteggi la tua proprietà intellettuale . Questo è uno dei maggiori errori. Solitamente gestito dalla piattaforma utilizzata (come vworker o elance).

2. Rifiuta framework personalizzati . Oppure rischi di essere legato ad esso, o più specificamente allo sviluppatore che lo ha scritto;)

3. Imporre standard . Relativo al suggerimento precedente. L'uso di standard aumenta il valore del codice sorgente in quanto è comprensibile da un numero maggiore di sviluppatori.

4. Rivedi presto, rivedi frequentemente . La maggior parte dei problemi può essere "corretta" se si esamina il codice sorgente dopo la prima settimana o il lavoro.

C. Strategia

1. Provider di servizi con piccoli progetti . Prima di dare un grande progetto a un fornitore, lo collaudo con uno o due progetti più piccoli.

2. Accetta più offerenti per ridurre il rischio . Per il progetto critico, seleziono due o tre offerenti, quindi prendo la migliore implementazione. Funziona meglio con piccoli progetti (meno di $ 5000).

3. Montare i componenti . Un'altra strategia è quella di esternalizzare i componenti che vengono assemblati in seguito. Uno dei vantaggi è che puoi facilmente passare da un provider all'altro e nessuno può davvero accedere a tutto (ridurre i rischi di proprietà intellettuale).

Concordo pienamente con la risposta di maple_shaft.

Hai accettato il codice e presumo abbia scritto l'assegno, quindi hai rivisto il codice, in un certo senso hai fatto tutto al contrario.

Perché ho accettato di lasciarli codificare senza avere una specifica funzionale?

Perché non l'hai scritto nel contratto. Dal momento che volevi che il lavoro fosse fatto, hai accettato le loro ragioni, anche se è proprio quello che ti ha messo nei guai.

Perché non mi sono assicurato che capissero tutto la prima volta?

Avresti dovuto fornire loro un design che pensavi avrebbe funzionato. Quindi non importerebbe davvero se non capissero completamente. Voglio dire, non li hai pagati per farlo, quindi chi lo farà? Come verrà gestito questo codice senza alcuna documentazione e specificazione di progettazione. La risposta probabilmente non sarà .

Dissero che, dato che il prezzo era stato fissato, non ero giusto nel chiedere loro di apportare modifiche una volta completato il codice di lavoro.

Sei fortunato che abbiano apportato le modifiche che volevi. Avrebbero potuto dire: sfortuna

Qualcuno si ritrova nella stessa posizione? Pensi che ci sia un modo migliore per gestire i progetti in outsourcing?

Naturalmente altre persone sono nella tua posizione altrimenti, l'intero settore "in outsourcing" non sarebbe male, molte aziende stanno iniziando a rendersi conto che dover pagare (o aspettare) per farlo 3 e 4 volte è più costoso di farlo nel modo giusto una volta .

Almeno facendolo da soli puoi controllare quotidianamente lo stato del progetto. Se sei dietro ci sono cose che puoi fare per controllare il danno, almeno in teoria.