Offshoring de um projeto de software - Resolução de conflitos [fechado]

Fui encarregado de gerenciar um projeto que foi terceirizado para alguns desenvolvedores ucranianos.

A empresa os contratou através da Elance a um preço fixo . Nesse ponto, meu chefe me deixou sozinha para lidar com eles e fazer o trabalho. Eu criei uma especificação detalhada da coisa completa que precisava ser feita.

O projeto envolveu lidar com coisas como XMPP, RabbitMQ e Database. Na minha primeira reunião com eles (sempre como primário), expliquei minuciosamente o que eles precisavam fazer. Eles pareciam entender - e estavam muito confiantes de que isso seria feito facilmente.

Por enquanto, tudo bem. Mas depois de uma semana, quando nos encontramos novamente, eles estavam cheios de mal-entendidos sobre o que precisava ser feito. Quando perguntei a um dos desenvolvedores se ele conhecia o XMPP, ele disse que estava trabalhando com ele pela primeira vez. Na nossa primeira reunião, eu mencionei muito especificamente a complexidade do projeto e as tecnologias envolvidas. Além disso, eu havia pedido repetidamente que escrevessem uma especificação funcional de exatamente como eles o fariam. Mas eles disseram NÃO e insistiram que prefeririam escrever o código. Eu disse ok.

O projeto foi concluído após três semanas e eles entregaram o que era necessário. Nesse ponto, comecei a revisar o código. Foi bom para a maior parte, mas existem alguns problemas importantes:

• eles codificaram algumas das coisas que precisavam ser separadas em um arquivo de configuração
• havia vários arquivos de configuração que eu precisava consolidar em um
• eles escreveram absolutamente nenhuma documentação
• algumas outras pequenas mudanças

Pedi a eles para fazer essas alterações (exceto a documentação) - E tivemos uma discussão.

Eles disseram que, como o preço era fixo, eu estava sendo injusto ao pedir a eles que fizessem alterações depois que eles concluíssem o código de trabalho. Que eles haviam trabalhado por uma quantidade razoável de tempo no projeto e agora estava completamente errado pedir qualquer coisa.

Finalmente, agora eles fizeram as alterações e o projeto acabou. Mas deixa algumas perguntas em minha mente ...

• Eles fizeram o que era necessário, mas eu o fiz corretamente e, portanto, as mudanças. eu era realmente injusto?

• Por que concordei em deixá-los codificar sem ter uma especificação funcional?

• Por que não tive certeza de que eles entendessem tudo da primeira vez?

Alguém se encontra na mesma posição? Você acha que existe uma maneira melhor de gerenciar projetos terceirizados?

- ATUALIZAÇÃO -

Obrigado por todas as opiniões - depois de refletir sobre toda a experiência, posso concluir ...

• Embora eu não fosse vago nas especificações do meu lado, certamente não as deixei duras, como sugerido. Portanto, a questão é: sempre seja o mais específico possível - leia também as especificações da perspectiva deles e veja se você perdeu alguma coisa. Repita pelo menos três vezes.

• Apenas especificar o que o código deve fazer não é suficiente. Você deve especificar a aparência do código. Qual será a estrutura de diretórios; até os nomes dos arquivos, se possível. Isso o salvará de muito aborrecimento mais tarde. Especifique estritamente as diretrizes de codificação, as convenções de nomenclatura das variáveis, o formato da documentação interna, etc. Verifique se eles cumprem essas diretrizes e, se não, gritam.

• Exija uma especificação funcional do lado deles - insista para que seja escrita antes de qualquer código. Isso acabará com muitas confusões e mal-entendidos.

• Revise o código conforme ele está sendo desenvolvido, para identificar as anomalias anteriormente e corrigi-las. Fale com eles pelo menos uma vez em dias alternados.

• Por fim, tente fazer um bom relacionamento com eles. Faça-os sentir que você aprecia o trabalho deles. Não exagere neles de forma exagerada para se adequar às suas diretrizes. Em vez disso, peça que eles o façam e diga que isso tornaria a manutenção do código muito mais fácil para você depois que eles concluírem o projeto.

Primeiro, isso não é uma questão de escoramento, é uma questão de gerenciamento de fornecedores

Sim, você cometeu muitos erros ...

Eles fizeram o que era necessário, mas eu o fiz corretamente e, portanto, as mudanças. eu era realmente injusto?

Sim, é justo. Se você quisesse fazer isso de uma certa maneira, deveria ter dito isso antes que o preço fosse acordado, para que eles possam fazer lances de acordo.

Por que concordei em deixá-los codificar sem ter uma especificação funcional? Porque você não queria PAGAR pelas especificações! A documentação é demorada e cara, eles deveriam fazer isso de graça?

Por que não tive certeza de que eles entendessem tudo da primeira vez?

Eles entenderam. Mas em sua primeira reunião APÓS o contrato foi assinado (e o preço fixo acordado) é quando você o EXPAINTA! Portanto, o necessário para cortar custos (horas) onde todos eles pudessem .. Basicamente, realizando apenas uma reunião por semana, sem fornecer opções de confutação.

Aqui está como fazer isso da próxima vez ... Em duas fases ...

Fase 1: Peça para eles Reunirem os requisitos, realizarem a análise dos sistemas e escreverem o Projeto Técnico e / ou as Especificações funcionais (ou escrever você mesmo). Concorde com um preço para esta fase. Certifique-se de explicar que não há compromisso de sua parte em dar-lhes a fase de desenvolvimento. Não deixe de incluir tempo para a reunião no preço.

Fase 2: Faça com que eles ofereçam o desenvolvido com base nas especificações agora que eles (e você) o possuem e realmente sabem que o esforço está envolvido. Novamente, certifique-se de incluir tempo para as reuniões no preço. Porque incluir um pequeno orçamento opcional para alterações.

Editar: quero acrescentar um ponto adicional. O fornecedor também é o culpado aqui, parte do trabalho também ajuda a guiá-lo no gerenciamento do projeto e informa onde há falta de tempo no processo.

Eu precisava disso feito corretamente

Em seguida, não terceirize, ou, se o fizer, verifique se eles funcionam na sua equipe do projeto e se você participa das revisões de código no momento.

O projeto foi concluído após três semanas e eles entregaram o que era necessário. Nesse ponto, comecei a revisar o código.

Novamente, você deveria ter revisado o código durante o projeto, não depois.

Eles disseram que, como o preço era fixo, eu estava sendo injusto ao pedir a eles que fizessem alterações depois que eles concluíssem o código de trabalho.

Você pagou a eles preço fixo pelo código de funcionamento. Opa Isso não é culpa deles, é seu. Pague pelo tempo deles para participar de sprints que você controla e não terá esse problema. Você deve pagar pelo tempo e pelas histórias de usuário aceitas, não pelo código.

Na minha primeira reunião com eles (sempre como primário), expliquei minuciosamente o que eles precisavam fazer. Eles pareciam entender - e estavam muito confiantes de que isso seria feito facilmente.

Ao lidar com um projeto completamente terceirizado, você precisa garantir que suas especificações sejam rígidas. Se você precisar explicar algo que demore mais do que algumas frases, suas especificações não estarão completas. É por isso que eles se afastaram das especificações.

Quando perguntei a um dos desenvolvedores se ele conhecia o XMPP, ele disse que estava trabalhando com ele pela primeira vez.

É comum ao terceirizar para países populares de terceirização de baixo custo os desenvolvedores inflarem demais seus currículos e habilidades apenas para conseguir o emprego. Muitas vezes eles não se preocupam com suas habilidades até chegarem a ela, porque muitos deles estão apenas retomando a construção para conseguir o show que realmente paga um salário digno.

Por que concordei em deixá-los codificar sem ter uma especificação funcional?

Somente você pode responder por si mesmo, mas considere isso como uma experiência de aprendizado para a próxima vez.

A empresa os contratou através da Elance a um preço fixo. Nesse ponto, meu chefe me deixou sozinha para lidar com eles e fazer o trabalho. Eu criei uma especificação detalhada da coisa completa que precisava ser feita.

Então vocês dois primeiro fez um contrato e , em seguida, eles permitem que você escrever uma especificação, e eles aceitaram essa especificação para se tornar parte do seu contrato? Se foi assim, não é culpa sua, é culpa do seu contratante. Você poderia escrever facilmente uma especificação, dando a eles 3 meses de trabalho em vez de 3 semanas - tudo pelo mesmo preço.

Foi bom para a maior parte, mas existem alguns problemas importantes:

• eles codificaram algumas das coisas que precisavam ser separadas em um arquivo de configuração
• havia vários arquivos de configuração que eu precisava consolidar em um
• eles escreveram absolutamente nenhuma documentação
• algumas outras pequenas mudanças

Essas coisas faziam parte de suas especificações? Se foram, a culpa é deles. Caso contrário, é seu. Se não ficou claro se essas coisas estão contidas nas especificações, também é sua culpa, desde que você escreveu o documento. Tente escrever uma especificação melhor na próxima vez.

Fiz uma apresentação há pouco tempo sobre offshoring. Foi chamado "Global Outsourcing, 10 dicas para fortalecer seu negócio". Aqui está um resumo das 10 dicas (isso vem de até 400 projetos terceirizados):

Uma escolha

1. Evite os licitantes mais baixos e mais altos . Isso é óbvio: você não quer correr riscos com os licitantes mais baixos e os mais altos tendem a ser menos valiosos (valor / preço) do que a mediana.

2. Verifique as classificações (ou referências) . Eu sempre verifico referências e classificações.

3. Priorize a motivação . Pelo preço igual, escolho o lance motivado. Por exemplo, fazer o licitante falar sobre seu projeto corretamente é um sinal muito bom.

B. Supervisão

1. Proteja sua propriedade intelectual . Este é um dos maiores erros. Geralmente manipulado pela plataforma que você usa (como vworker ou elance).

2. Recusar estruturas personalizadas . Ou você corre o risco de estar vinculado a ele, ou mais especificamente ao desenvolvedor que o escreveu;)

3. Impor padrões . Relacionado à dica anterior. O uso do padrão aumenta o valor do seu código-fonte, pois é compreensível para uma quantidade maior de desenvolvedores.

4. Revise cedo, revise frequentemente . A maioria dos problemas pode ser "ajustada" se você revisar o código fonte após a primeira semana ou no trabalho.

C. Estratégia

1. Teste fornecedores com pequenos projetos . Antes de dar um grande projeto a um provedor, testo-o com um ou dois projetos menores.

2. Aceite vários licitantes para reduzir o risco . Para projetos críticos, seleciono dois ou três licitantes e, em seguida, faço a melhor implementação. Trabalhe melhor com pequenos projetos (menos de US $ 5000).

3. Monte os componentes . Outra estratégia é terceirizar os componentes que você monta mais tarde. Uma vantagem é que você pode alternar facilmente entre provedores e nenhum realmente obtém acesso à coisa toda (reduz os riscos de propriedade intelectual).

Concordo inteiramente com a resposta do maple_shaft.

Você aceitou o código e presumo que tenha feito o cheque, depois revido o código, você meio que fez tudo ao contrário.

Por que concordei em deixá-los codificar sem ter uma especificação funcional?

Porque você não escreveu no contrato. Desde que você queria que o trabalho fosse feito, você aceitou os motivos deles, mesmo que isso tenha causado o problema.

Por que não tive certeza de que eles entendessem tudo da primeira vez?

Você deveria ter fornecido a eles um design que achou que teria funcionado. Então, realmente não importaria se eles não entendessem completamente. Quero dizer que você não pagou para eles fazerem, então quem vai fazer isso? Como esse código será mantido sem nenhuma documentação e especificações de design. A resposta provavelmente não será .

Eles disseram que, como o preço era fixo, eu estava sendo injusto ao pedir a eles que fizessem alterações depois que eles concluíssem o código de trabalho.

Você tem sorte que eles fizeram as alterações que você queria. Eles poderiam ter dito: azar

Alguém se encontra na mesma posição? Você acha que existe uma maneira melhor de gerenciar projetos terceirizados?

É claro que outras pessoas estão na sua posição, caso contrário, todo o setor de "terceirização" não seria prejudicial, muitas empresas estão começando a perceber que ter que pagar (ou esperar) para fazer isso 3 e 4 vezes é mais caro do que fazer certo uma vez .

Pelo menos, você mesmo pode verificar o status do projeto diariamente. Se você está atrasado, existem coisas que você pode fazer para controlar os danos, pelo menos em teoria.