Il codice di outsourcing è più costoso a lungo termine? Danneggia la qualità del codice? [chiuso]

Sono a conoscenza di una società che possiede la proprietà intellettuale di un prodotto software decente e guadagna un ottimo reddito dalle licenze all'anno. Tuttavia, il direttore (non tecnico) si lamenta del costo di mantenimento del team di sviluppo, in quanto consuma in modo significativo i margini di profitto e sta prendendo in considerazione lo sviluppo in outsourcing di moduli specifici in altri paesi che applicano tariffe più basse.

Personalmente, non credo che questa sarà una soluzione più economica a lungo termine. Ciò può comportare interruzioni della comunicazione in caso di problemi, inoltre le specifiche dovranno essere impermeabili, il che può richiedere comunque più tempo. Secondo me, quando si lavora in gruppo la comunicazione è la chiave - o esiste un modo efficace per farlo funzionare?

Sono sicuro che qualcuno abbia un esempio di questo funzionamento, ma non l'ho visto.

Ho lavorato in un'azienda Fortune 500 per molti anni in cui hanno esternalizzato molti sviluppi. Non ho un solo esempio in quegli anni di un progetto in outsourcing che costa meno che se lo avessimo fatto da soli (internamente).

Mentre i loro tassi di programmazione erano inferiori ai nostri, abbiamo trascorso 3 volte il tempo a gestire il team in outsourcing rispetto a quanto facciamo per i team interni. Questo è in aggiunta al tempo aggiuntivo necessario per avere i requisiti più dettagliati di quelli necessari al nostro team interno e al tempo aggiuntivo necessario nel QA perché il codice non è mai stato vicino alla correttezza.

Puoi averlo rapidamente, puoi averlo a buon mercato o puoi farlo bene. Non puoi averli tutti e tre, e direi che anche due su tre possono essere un allungamento.

Per un'azienda di software, questo è semplicemente stupido. Il più vicino possibile a una decisione ragionevolmente intelligente sarebbe quello di spostare l'azienda in un'altra sede con un talento più economico.

Una società di software che esternalizza il proprio sviluppo software non è più una società di software. Direi che qualsiasi guadagno guadagnato avrà vita breve, perché stai creando la tua competizione. Una volta che si rendono conto di conoscere il prodotto meglio di te, si rendono anche conto che non hanno più bisogno di te.

La mia unica esperienza di outsourcing presso un'azienda in un altro paese sarà la mia ultima. La società che è stata assunta, non è riuscita a completare il lavoro in tempo o addirittura a rispettare le specifiche a distanza, e ci ha portato a dover rifare l'intero lotto internamente.

Tuttavia, se riesci a trovare un'azienda affidabile di cui ti puoi fidare (cioè hai visto / sentito cose positive su di loro da altre persone), allora forse vale la pena.

Il regista vuole sostituire alcuni dei suoi esperti sviluppatori locali con persone di un paese lontano la cui competenza non è competente a giudicare, che non hanno alcuna esperienza con il codice e che non possono essere supervisionati o guidati direttamente da nessuno che lo sappia il codice.

L'ho passato due volte. In entrambi i casi, le società straniere poco costose non sono riuscite a consegnare in tempo con una qualità adeguata. Quando gli sviluppatori locali hanno saputo che il lavoro stava andando all'estero, hanno trovato altri lavori piuttosto che aspettare di essere licenziati. Con il proseguimento dell'esperienza emorragia, i programmi sono scivolati, i bug critici non sono stati corretti, i clienti si sono arrabbiati e sono passati alla concorrenza, e alla fine entrambe le società hanno chiuso.

Ci sono stati anche strani problemi con la comunicazione, le aspettative e la cultura. Ad esempio, un team straniero non stava controllando molto codice o non rispondendo prontamente alle e-mail. Si è scoperto che il responsabile IT locale ha ottenuto un bonus per contenere i costi, quindi ha avuto l'intero ufficio su una connessione Internet a bassa velocità. Un'altra volta, i tester QA del terzo mondo hanno sistematicamente inserito diversi bug selvaggiamente diversi nella stessa segnalazione; il loro manager aveva paura di rimanere senza numeri di bug.

Alcune squadre in posti economici vanno bene. Da quello che sento, Red Hat sembra avere una squadra molto competente a Pechino. Ma hanno già avuto anni di esperienza con persone che lavorano da tutto il mondo tramite telelavoro prima di iniziare a farlo, e la gente di Pechino sono dipendenti Red Hat, non una società di outsourcing.

Sì, ottieni ciò per cui paghi.

Nella mia esperienza, a meno che le tue esigenze di mercato e di sviluppo non siano così semplici da poter essere spiegate facilmente via e-mail a qualsiasi sviluppatore con una possibile barriera linguistica, e così semplici che persino uno sviluppatore che non è realmente investito nell'azienda può ancora avere successo nel creare un prodotto di qualità, allora sì, il tuo prodotto ne risentirà .

Ho lavorato in un'azienda in cui avevamo un grande team di sviluppo locale e il nostro prodotto ha sofferto semplicemente perché il team di gestione ha investito più denaro e sforzi nelle vendite. Dato che così tanto sforzo è stato investito nelle vendite, sembrava che stessimo facendo "bene", ma significava guadagnare entrate che dovevamo continuare a versare denaro e risorse nel processo di vendita.

Avevamo un team remoto ma li abbiamo integrati completamente nell'azienda e hanno partecipato allo stesso livello dei nostri team locali. Questo è l'unico modo in cui può funzionare . Ero il team leader locale per loro e siamo volati fuori a lavorare sul posto con loro regolarmente. Abbiamo dato loro camicie e giacche aziendali proprio come le squadre locali. Dopo tutto, forse ci ha risparmiato il 20-30%. Se metti insieme un sistema che tenta di ridurre i costi di più, il tuo prodotto ne risentirà di conseguenza.

Se stai lavorando con un team di outsourcing di qualità e la direzione è disposta a comunicare e applicare criteri di accettazione.

Quindi il costo sarà approssimativamente uguale a quello di un prodotto sviluppato internamente.

Puoi anche ottenere la stessa qualità, se sei fortunato.

Potrei essere un po 'di parte perché la mia azienda mantiene uno staff di sviluppo interno e non ha esternalizzato alcuno sviluppo di prodotto. Sospetto che le esperienze che abbiamo avuto con partner di integrazione che hanno esternalizzato lo sviluppo abbiano avuto qualcosa a che fare con quella decisione.

Nella mia esperienza, esternalizzare un progetto non è la soluzione migliore quando si cerca di ottenere margini migliori.

Al lavoro avevamo qualcosa del genere in corso e bene, come dicevano anche altri, abbiamo finito per rifare la buca e mantenere ciò che era su un server di produzione. Conclusione sulla questione, è costato il doppio.

La mia opinione in merito è che se stai pensando di provare a fare la differenza sugli sviluppi dell'outsourcing dei margini, potresti buttare via il tuo investimento. Se ci pensate, il successo del prodotto è una questione di cose che funzionano secondo le aspettative, quindi se cambiate dev-team, le cose potrebbero diventare brutte.

La tua risposta potrebbe essere un software open source ben pianificato / fatto, perché può essere altamente redditizio e la manutenzione viene in qualche modo delegata a una comunità, ma non esiste una ricetta per il successo. Il miglior consiglio che posso dare è di raccomandare diversi discorsi su ciò che è veramente open source e i suoi shenanigans:

• "Come avviare un progetto open source" di Jeremy Ruston (BT) http://vimeo.com/856110
• "Open Source is Magic" di Chris DiBona (Google) http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "I motori della comunità" di Jono Bacon (canonico) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Progetti open source e persone velenose" Ben Collins-Sussman e Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "Cosa c'è dentro per me? Vantaggi del codice di sourcing aperto" Ben Collins-Sussman e Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

E forse anche:

• "Come scegliere un modello di business" di Roan Lavery (FreeAgent) http://vimeo.com/5588154

La cosa sull'open source, secondo me, è costruire qualcosa di valore e interesse non solo per te ma per tutti, il potere dell'open source sta nelle comunità.

Inoltre, se il tuo capo / azienda è riluttante ad aprire il software, basta isolare le specifiche della propria logica aziendale e del proprio know-how. Quindi, cosa faresti:

1. Incubare un progetto open source con le tue risorse
2. Fai crescere una comunità
3. ???
4. Profitto =)

Sì, sono serio e "???" implica qualsiasi strategia tu voglia perseguire dopo aver raccolto abbastanza interesse. Con gli strumenti di oggi come Github e Twitter puoi spargere la voce più facilmente, ma tieni presente che la tua prima impressione dovrebbe essere abbastanza interessante.

Se in realtà non vuoi open source ( che devi capire come modello di business prima di implementarlo, se vuoi avere successo ), puoi sempre avviarlo come servizio, per quello controlla il video di Carsonified, ma ciò implica un intero molte altre cose per la tua azienda.

Alla fine, essere open source o lanciarlo come servizio sono modi per rendere sostenibile il progetto a lungo termine.

Non ricordo l'autore di questa citazione, ma colpisce l'unghia.

"I team debolmente accoppiati che lavorano insieme su componenti strettamente accoppiati falliscono. Inevitabilmente "

Esternalizzazione = squadre debolmente accoppiate.

Cercare di ridurre i costi dividendo geograficamente il lavoro sui componenti interdipendenti fallisce sempre.

D'altra parte, in base alla mia esperienza, spostare un'intera parte del portafoglio software potrebbe funzionare, il che significa che può essere sviluppato in buona qualità con costi ridotti.