O código de terceirização é mais caro a longo prazo? Isso prejudica a qualidade do código? [fechadas]

Estou ciente de uma empresa que possui a propriedade intelectual de um produto de software decente e obtém uma excelente renda com o licenciamento por ano. No entanto, o diretor (não técnico) reclama do custo de manutenção da equipe de desenvolvimento, pois consome significativamente as margens de lucro, e está considerando terceirizar o desenvolvimento de módulos específicos para outros países que pagam menos.

Pessoalmente, não acho que essa seja uma solução mais econômica a longo prazo. Isso pode levar a falhas de comunicação quando houver problemas; além disso, as especificações precisarão ser à prova d'água, o que pode levar mais tempo. Na minha opinião, ao trabalhar em equipe, a comunicação é fundamental - ou existe uma maneira eficaz de fazer isso funcionar?

Tenho certeza de que alguém tem um exemplo disso funcionando, mas eu não o vi.

Eu trabalhei em uma empresa da Fortune 500 por muitos anos, onde eles terceirizaram muito desenvolvimento. Não tenho um único exemplo naqueles anos de um projeto terceirizado que custa menos do que se o tivéssemos feito por nós mesmos (internamente).

Embora suas taxas de programação sejam menores que as nossas, passamos três vezes o tempo gerenciando a equipe terceirizada do que nas equipes internas. Isso inclui o tempo adicional necessário para ter os requisitos mais detalhados do que nossa equipe interna precisa e o tempo adicional necessário no controle de qualidade, porque o código nunca esteve perto de estar correto.

Você pode ter rapidamente, pode ter barato ou pode fazer bem. Você não pode ter todos os três, e eu diria que até dois em cada três podem ser um exagero.

Para uma empresa de software, isso é simplesmente estúpido. O mais próximo que eles pudessem chegar de uma decisão razoavelmente inteligente seria mudar a empresa para outro local com talento mais barato.

Uma empresa de software que terceiriza seu desenvolvimento de software não é mais uma empresa de software. Eu argumentaria que qualquer ganho obtido terá vida curta, porque você está criando sua própria competição. Quando eles percebem que conhecem o produto melhor que você, também percebem que não precisam mais de você.

Minha única experiência de terceirização para uma empresa em outro país será minha última. A empresa contratada falhou em concluir o trabalho a tempo ou até mesmo remotamente atendeu às especificações e resultou em que refizemos todo o lote novamente internamente.

No entanto, se você pode encontrar uma empresa confiável em que pode confiar (ou seja, você já viu / ouviu coisas boas sobre elas de outras pessoas), então talvez valha a pena.

O diretor deseja substituir alguns de seus experientes desenvolvedores locais por pessoas em um país distante, cuja experiência ele não é competente para julgar, que não têm nenhuma experiência com o código e que não podem ser diretamente supervisionados ou orientados por alguém que conheça o código.

Eu já passei por isso duas vezes. Em ambos os casos, as empresas estrangeiras baratas não conseguiram entregar pontualmente a qualidade adequada. Quando os desenvolvedores locais souberam que o trabalho estava indo para o exterior, encontraram outros empregos em vez de esperar para serem redundantes. À medida que a hemorragia pericial continuava, os cronogramas caíam, os bugs críticos não eram corrigidos, os clientes ficavam bravos e passavam para os concorrentes e, eventualmente, as duas empresas desistiam.

Havia também problemas estranhos com comunicação, expectativas e cultura. Por exemplo, uma equipe estrangeira não estava verificando muito código ou respondendo ao e-mail imediatamente. Aconteceu que o gerente de TI local recebeu um bônus por manter os custos baixos, então ele tinha todo o escritório em uma conexão de Internet de baixa velocidade. Outra vez, os testadores de controle de qualidade do terceiro mundo rotineiramente colocam vários erros totalmente diferentes no mesmo relatório de erros; o gerente deles tinha medo de ficar sem números de bugs.

Algumas equipes em lugares baratos estão bem. Pelo que ouvi, a Red Hat parece ter uma equipe muito competente em Pequim. Mas eles já tinham anos de experiência com pessoas que trabalham em todo o mundo via telecomutação antes de começarem a fazer isso, e o pessoal de Pequim é funcionário da Red Hat, não uma empresa de terceirização.

Sim - você obtém o que paga.

Na minha experiência, a menos que suas necessidades de mercado e desenvolvimento sejam tão simples, elas podem ser facilmente explicadas por e-mail a qualquer desenvolvedor com uma possível barreira de idioma e tão simples que mesmo um desenvolvedor que não está realmente investido na empresa ainda pode ter sucesso. na criação de um produto de qualidade, sim, seu produto sofrerá .

Eu trabalhei em uma empresa onde tínhamos uma grande equipe de desenvolvimento local, e nosso produto sofreu simplesmente porque a equipe de gerenciamento investiu mais dinheiro e esforço em vendas. Como tanto esforço foi investido em vendas, parecia que estávamos indo "bem" - mas isso significava obter receita que tínhamos a obrigação de continuar investindo dinheiro e recursos no processo de vendas.

Tínhamos uma equipe remota, mas os integramos totalmente à empresa e eles participaram do mesmo nível das nossas equipes locais. Essa é a única maneira que pode funcionar . Eu era o líder da equipe local e voávamos para trabalhar regularmente no local. Demos a eles camisas e jaquetas da empresa, assim como as equipes locais. Depois de tudo considerado, talvez nos tenha economizado 20 a 30%. Se você montar um sistema que tente reduzir os custos em mais do que isso, seu produto sofrerá de acordo.

Se você estiver trabalhando com uma equipe de terceirização de qualidade e a gerência estiver disposta a comunicar e aplicar critérios de aceitação.

Então o custo será aproximadamente a mesma taxa que um produto desenvolvido internamente.

Você também pode obter a mesma qualidade, se tiver sorte.

Eu posso ser um pouco tendencioso porque minha empresa mantém uma equipe interna de desenvolvimento e não terceirizou nenhum desenvolvimento de produto. Suspeito que as experiências que tivemos com parceiros de integração que terceirizaram o desenvolvimento tenham algo a ver com essa decisão.

Na minha experiência, terceirizar um projeto não é a melhor solução ao tentar obter melhores margens.

No trabalho, tínhamos algo assim acontecendo e bem, como outros também disseram, acabamos refazendo a coisa do buraco e mantendo o que estava em um servidor de produção. Conclusão sobre o assunto, custou o dobro.

Minha opinião sobre o assunto é que, se você está tentando fazer a diferença nos desenvolvimentos de terceirização de margens, pode estar jogando fora seu investimento. Se você pensar bem, o sucesso do produto é uma questão de trabalhar como esperado; portanto, se você mudar a equipe de desenvolvimento, as coisas podem ficar feias.

Software de código aberto bem planejado / executado pode ser sua resposta, porque pode ser altamente lucrativo e a manutenção é um pouco delegada a uma comunidade, mas não há receita para o sucesso. O melhor conselho que posso dar é recomendar várias palestras sobre o que realmente é código aberto e suas travessuras:

• "Como iniciar um projeto de código aberto", de Jeremy Ruston (BT) http://vimeo.com/856110
• "Código aberto é mágico", de Chris DiBona (Google) http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "Os motores da comunidade", de Jono Bacon (Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Projetos de código aberto e pessoas venenosas" Ben Collins-Sussman e Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "O que há para mim? Benefícios do código aberto de fornecimento" Ben Collins-Sussman e Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

E talvez também:

• "Como escolher um modelo de negócios", de Roan Lavery (FreeAgent) http://vimeo.com/5588154

A questão do código aberto, na minha opinião, é criar algo de valor e interesse não apenas para você, mas para todos, o poder do código aberto está dentro das comunidades.

Além disso, se o seu chefe / empresa estiver relutante em abrir o software, apenas isole as especificidades de sua própria lógica de negócios e know-how. Então, o que você faria:

1. Incubar um projeto de código aberto com seus recursos
2. Cresça uma comunidade
3. ???
4. Lucro =)

Sim, estou falando sério, e "???" envolve todas as estratégias que você deseja seguir depois de reunir interesse suficiente. Com as ferramentas atuais, como Github e twitter, você pode espalhar a palavra com mais facilidade, mas lembre-se de que sua primeira impressão deve ser interessante o suficiente.

Se você realmente não deseja código-fonte aberto ( que você deve entender como um modelo de negócios antes de implementá-lo, se quiser ter sucesso ), sempre poderá iniciá-lo como um serviço, para isso, verifique o vídeo Carsonified, mas isso implica um todo muitas outras coisas para sua empresa.

No final, ser de código aberto ou lançá-lo como um serviço são maneiras de tornar o projeto sustentável a longo prazo.

Não me lembro do autor desta citação, mas ela acertou em cheio.

" Equipes fracamente acopladas que trabalham juntas em componentes fortemente acoplados falham. Inevitavelmente "

Terceirização = equipes pouco acopladas.

A tentativa de reduzir custos dividindo geograficamente o trabalho em componentes interdependentes sempre falha.

Por outro lado, com base na minha experiência, mover uma parte inteira do portfólio de software pode funcionar, o que significa que ele pode ser desenvolvido em boa qualidade e com custos reduzidos.