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

Prima di tutto questo non è un problema di off-shore, è un problema di gestione dei fornitori

Sì, hai ALOT di errori ...

They did what was needed but I needed it properly done, and hence the changes. was I really unfair?

Sì, è giusto, se avessi voluto farlo in un certo modo avresti dovuto dirlo prima che il prezzo venisse accettato, in modo che possano fare offerte di conseguenza.

Perché sono stato d'accordo nel lasciarli codice senza avere una specifica funzionale? Perché non volevi PAGARE per le specifiche! La documentazione è dispendiosa in termini di tempo e denaro, se dovessero farlo gratuitamente?

Why did I not make sure that they understood everything the first time?

Hanno capito. Ma alla prima riunione DOPO che il contratto è stato firmato (e il prezzo stabilito è stato concordato) è quando l'HA STIPULATO! Quindi il necessario per tagliare i costi (ore) dove potevano. In pratica tenendo solo una riunione alla settimana, senza dare alcuna possibilità di confutazione.

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

Fase 1: Chiedi loro di raccogliere i requisiti, eseguire l'analisi dei sistemi e scrivere il disegno tecnico e \ o le specifiche funzionali (o scriverlo tu stesso). Accetta 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 l'orario di riunione nel prezzo.

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

Modifica: voglio aggiungere un altro punto. Anche il venditore è in errore, parte del lavoro è troppo utile per guidarti nella gestione del progetto e ti fa sapere dove ci sono dei problemi nel processo.

I needed it properly done

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

The project completed after 3 weeks and they delivered what was needed. At that point I started to review the code.

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

They said, since the price was fixed, I was being unfair in asking them to make any changes once they completed the working code.

Hai pagato loro il prezzo fisso per il codice funzionante. Ops. Non è colpa loro, è tua. Paga il loro tempo per partecipare agli sprint che controlli e non ti imbatterai in questo problema. Dovresti pagarli per il tempo e accettare user story, non per codice.

In my first meeting with them (always IM) I explained thoroughly what they needed to do. They seemed to understand it -- and they were very confident that it would be done easily.

Quando si ha a che fare con un progetto completamente esternalizzato, è necessario assicurarsi che le specifiche siano corazzate. Se devi spiegare qualcosa che richiede più tempo di alcune frasi, le tue specifiche non sono complete. Questo è il motivo per cui hanno virato dalle specifiche.

When I asked one of the developers if he knew XMPP, he said he was working with it for the first time.

È comune quando si esternalizzano a paesi di offshoring a basso costo per gli sviluppatori per sovrainfiltrare i loro curriculum e competenze solo per ottenere il lavoro. Spesso non si preoccupano delle loro abilità fino a quando non lo atterrano, perché molti di loro sono appena tornati a costruire per sbarcare il concerto che effettivamente paga un salario di sussistenza comodo.

Why did I agree on letting them code without having a functional specification?

Solo tu puoi rispondere a te stesso, ma prendilo come esperienza di apprendimento per la prossima volta.

The company hired them through Elance at a fixed price. At that point my boss left me alone to handle them and get the work done. I created a detailed specification of the complete thing that needed to be done.

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

It was okay for the most part, but there ware some important problems:

• they hard-coded some of the things that needed to be separated out into a config file
• there were multiple config files that I needed to be consolidated in one
• they wrote absolutely NO documentation
• some other minor changes

Queste cose erano parte delle tue specifiche? Se lo fossero, è colpa loro. Se no, è tuo. Se non è 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.

Ho fatto una presentazione qualche tempo fa per offshoring. Si chiamava "Global Outsourcing, 10 consigli per potenziare la tua attività". Ecco un riassunto dei 10 suggerimenti (che provengono da un massimo di 400 progetti in outsourcing):

A. Scelta

1. Evita gli offerenti più bassi e più alti . Questo è ovvio, non vuoi rischiare con offerenti più bassi e i migliori offerenti tendono ad essere meno preziosi (valore / prezzo) rispetto alla mediana.

2. Controlla le classifiche (o i riferimenti) . Controllo sempre i riferimenti & rating.

3. Dare priorità alla motivazione . A parità di prezzo, scelgo l'offerta che è stata motivata. Ad esempio avere l'offerente parlare del tuo progetto è un buon segno.

B. Supervisione

1. Proteggi la tua proprietà intellettuale . Questo è uno dei più grandi errori. Solitamente gestito dalla piattaforma che usi (come vworker o elance).

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

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

4. consulta in anticipo, esamina frequentemente . La maggior parte dei problemi possono essere "aggiustati" se rivedi il codice sorgente dopo la prima settimana o lavori.

C. Strategia

1. Provider di test 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 i rischi . Per il progetto critico, seleziono due o tre offerenti, quindi prendo la migliore implementazione. Funziona al meglio con piccoli progetti (meno di $ 5000).

3. Assembla componenti . Un'altra strategia è quella di esternalizzare i componenti che assemblerai in seguito. Un vantaggio è che puoi facilmente passare da un fornitore all'altro e nessuno può accedere a tutto il resto (riduci i rischi di proprietà intellettuale).

Sono completamente d'accordo con la risposta di maple_shaft.

Hai accettato il codice e presumo abbia scritto il controllo, quindi rivisto il codice, hai fatto tutto all'indietro.

Why did I agree on letting them code without having a functional specification?

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

Why did I not make sure that they understood everything the first time?

Avresti dovuto fornire loro un disegno che avresti ritenuto funzionasse. Quindi non sarebbe importante se non capissero pienamente. Voglio dire che non li hai pagati per farlo, quindi chi lo farà? Come si manterrà questo codice senza alcuna documentazione e specifiche di progettazione. La risposta è probabile che non sarà .

They said, since the price was fixed, I was being unfair in asking them to make any changes once they completed the working code.

Sei fortunato che hanno fatto i cambiamenti che volevi. Avrebbero potuto dire: sfortuna

Does anyone find themself in the same position? Do you think there is a better way to manage outsourced projects?

Ovviamente altre persone sono nella tua posizione altrimenti, l'intera industria "esternalizzata" non starebbe male, molte aziende stanno iniziando a rendersi conto di dover pagare (o aspettare) per farlo 3 e 4 volte è più costoso che fare giusto una volta.

Almeno facendolo tu stesso puoi controllare lo stato del progetto ogni giorno. Se sei dietro ci sono cose che puoi fare per controllare il danno, almeno in teoria.

I progetti a prezzo fisso a cascata falliscono sempre! Nessuna delle due parti sarà felice e una o entrambe le parti si sentiranno avvantaggiate o ingannate. Non otterrai mai la qualità in questo modo, avrai un lavoro incompleto affrettato come hai scoperto. Nessuna eccezione!

Non avrebbero mai dovuto accettare un prezzo cieco, non avresti mai dovuto accettare di pagare un risultato cieco.

Questo non ha nulla a che fare con "off shoring" , e tutto ciò che deve fare con cattiva gestione . Potevano essere dall'altra parte dell'edificio, e se le cose fossero gestite in questo modo sarebbero risultate esattamente uguali.

Questo è il posto che gli esperti di sviluppo del software chiamano Agile; brilla. Per il successo:

1. Preparati a pagare per risultati incrementali .

2. Collaborativamente pianifica una settimana o due settimane di lavoro, mai più, dici loro cosa è importante e cosa vuoi prima, ti dicono quanto possono ragionevolmente essere fatto nella settimana / due settimane. Devono impegnarsi nel deliverable, non è possibile dettare ciò che è. Questo è un mini-contratto.

3. Ottieni il deliverable alla fine della settimana (s), paga quando incontra ciò che ti è stato impegnato e lo dimostri, non prima. Siate pronti a non pagarli finché non incontrano il loro impegno .

4. Preparati a licenziarli al segno primo di incompetenza. Non dovresti pagare per addestrarli a imparare qualcosa che hanno detto di essere già esperti.

5. Preparati a eliminare i requisiti se non rientrano nel tuo budget.

6. Siate pronti a pagare più di quanto pensavate che sarebbe costato per una funzione, perché probabilmente vi sbagliate.

Questo a lungo termine sarà meno costoso di un accordo a prezzo fisso a cascata, otterrai ciò che desideri e ti aspetteresti, otterranno ciò che vogliono e si aspettano.

Avrai maggiori possibilità di chiamare il progetto con successo con questo approccio.

Questo è un approccio collaudato in ogni settore al di fuori dell'industria del software

Ecco come funziona ogni vero progetto di ingegneria.

Ad esempio: Pensi che le case personalizzate vengano create senza una costante revisione e feedback (iterazioni) da parte delle persone che contraggono i costruttori?

So quando ho costruito la mia casa personalizzata, sono andato a rivedere ciò che veniva fatto almeno due volte a settimana. Ci siamo incontrati con l'imprenditore edile ogni settimana e abbiamo parlato con la loro persona sul posto ogni due giorni.

Sì, avevamo piani e specifiche architettoniche dettagliate, ma c'erano ancora errori di intesa e errori e alcune semplici richieste di cambiamento a causa di cose che non avevamo pensato o dimenticato o cambiato idea.

Ci hanno detto che cosa si sarebbe fatto la prossima settimana o due in modo che potessimo pensarci e assicurarci di ottenere ciò che volevamo e sapremmo cosa cercare quando camminato sul sito di lavoro.

Li abbiamo beccati mentre accadevano e non dovevamo occuparci di loro dopo il fatto quando era costoso o semplicemente impossibile da risolvere.

Le metodologie di sviluppo del software chiamano questo "Agile", tutti gli altri lo chiamano buon senso . Non è un processo fan-boy, è ciò che le aziende di successo ragionevoli fanno in altri settori e hanno fatto per sempre.