Como defendo programadores caros?

Em nossa empresa, precisamos fazer muitas coisas aparentemente não complicadas, como desenvolver a interface do usuário móvel.

Digamos que os programadores experientes nos custem 4x tanto quanto os iniciantes.

Ambos são basicamente capazes de concluir as coisas aparentemente simples na mesma quantidade de tempo.

A diferença é que os programadores experientes produzem menos bugs e seu código é mais estável etc. Os programadores iniciantes perdem muito tempo com todo mundo (PM, clientes, etc.). Mas eles são significativamente mais baratos.

O contra-argumento é que leva experiência e iniciante a mesma quantidade de tempo para criar uma tabela em HTML. Portanto, é um luxo contratar programadores experientes para fazer o que os programadores iniciantes também podem conseguir.

Devemos investir em mais e melhores programadores ou em mais e melhores PM, uma vez que a diferença entre programadores experientes e novos em nosso campo pode ser 4x.

Tenho experiência em primeira mão de ambas as teorias sendo testadas no mundo real - no mesmo projeto, na verdade.

Antes de eu chegar, havia sido tomada a decisão de contratar BAs mais caros e programadores muito baratos - a idéia era ter especificações de boa qualidade sendo seguidas servilmente por programadores muito juniores.

Após mais de 6 meses do projeto principal, assumi o cargo de gerente de desenvolvimento. Depois de corrigir alguns fatores de higiene, o problema da qualidade do código permaneceu. Eu tinha um orçamento disponível e contratou um programador muito experiente (bem, mais um arquiteto de soluções) com habilidades de comunicação fora dos gráficos e uma vida anterior como instrutor em C # (o idioma em que o projeto foi escrito). A idéia era melhorar a qualidade dos outros codificadores, fornecendo orientação e treinamento efetivamente gratuito.

Depois de um mês ou dois, ficou dolorosamente óbvio que mesmo isso não iria funcionar, então a equipe original foi removida do projeto e mais alguns programadores de primeira linha foram adicionados. Eles entregaram o projeto que a equipe original falhou completamente em mais de 8 meses de tentativas em três corridas de um mês a partir do zero, porque o código original era irrecuperável.

Se os seus requisitos forem muito básicos, você poderá se safar do uso de um programador júnior, mas a probabilidade é que eles custem muito mais a longo prazo. Às vezes, os requisitos "simples" evoluem para uma grande complexidade.

Se eu não tivesse feito a escolha difícil de mudar de direção, eles provavelmente ainda estariam trabalhando nisso :) - Mais seriamente, neste exemplo, a falta de comunicação e competência da equipe original significava que eles não levantariam problemas com o especificação, mas apenas tentaria fazer o que fosse solicitado, se fazia sentido arquitetonicamente ou não. Um desenvolvedor mais experiente e confiante fez perguntas e se ateve aos requisitos subjacentes e, portanto, acabou produzindo a solução certa pela primeira vez.

Oh, mais uma coisa. Não pense que você pode contratar imediatamente um ótimo programador. Há muita gente por aí com muitos anos de experiência em mediocridade que proporcionará um resultado quase tão ruim quanto um júnior, mas custará o mesmo que uma superestrela (às vezes até mais). Eu tenho uma "taxa de acerto" muito boa, mas isso vem com a experiência e eu tenho muito. Esse é o assunto de uma conversa totalmente diferente, que está fora de tópico aqui ...

TL; DR Bons programadores são uma pechincha. O difícil é encontrá-los e criar um ambiente de trabalho atraente o suficiente para mantê-los.

Se você possui extensas estatísticas de desempenho, pode argumentar com a matemática. Isso poderia mostrar que a velocidade de desenvolvimento compensaria o aumento de preço, ou melhor ainda, que um design robusto poderia economizar mais em manutenção e desenvolvimento de versões subseqüentes. Infelizmente, esses números não estão disponíveis com tanta frequência - especialmente para tecnologias mais recentes.

Outro argumento pode ser o tempo de lançamento no mercado. Isso é mais facilmente compreendido pela alta gerência. No entanto, se o tempo não for realmente crítico, isso não ajudará.

Em último caso, encontre uma foto de Red Adair , o famoso bombeiro, que foi chamado em um grande desastre após várias tentativas malsucedidas de homens menos experientes. Sua famosa citação:

Se você acha caro contratar um profissional, aguarde até contratar um amador.

... merece ser impresso em cores e exibido com destaque na porta do escritório, para que todos entendam do que se trata ;-)

Gosto e votei na resposta de mcottle, mas quero cobrir algumas outras dinâmicas e argumentos que as outras respostas ainda não levantaram.

Primeiro, implícito na resposta de mcottle está o fato de que, abaixo de um certo nível de habilidade, alguns problemas são simplesmente impossíveis. Infelizmente, a maneira como você descobre isso é por sua equipe tentando e falhando, o que é muitocaro. Depois de falhar, há duas lições possíveis para aprender com isso. Uma opção é você aprender que precisa de desenvolvedores mais competentes, contratá-los e concluir o projeto significativamente acima do orçamento e do cronograma, mas pelo menos estará preparado no futuro. A outra opção é que esse projeto seja "muito difícil" para sua equipe e essas coisas não deverão ser tentadas no futuro, ou seja, você desiste do projeto e efetivamente quaisquer outros semelhantes. Obviamente, raramente será formulado como "somos burros demais para fazer isso", mas será racionalizado como "nossos sistemas são muito complexos" ou "temos muito código legado" ou outros. Essa última visão pode distorcer significativamente a perspectiva de uma empresa sobre o que é possível e quanto tempo / desenvolvimento deve ser caro. "

Uma pergunta é: qual é exatamente o plano da sua empresa? Ok, eles contratam programadores juniores baratos. Três anos se passaram, e agora? O que eles fazem com o desenvolvedor que está com eles ao longo desses três anos? Eles nunca deram a ele / ela um aumento? As opções aqui são as seguintes:

• Eles dão aumentos competitivos para reter os funcionários. Nesse caso, por que eles teriam um problema em pagar taxas de desenvolvedor sênior agora? Voltarei a isso embora.
• Eles têm taxas estagnadas, o que significa que, eventualmente, vão "resumir-se" a funcionários que não têm motivação e / ou habilidade.
• Eles ativamente removem mais funcionários seniores.

Os segundos dois casos implicam muita rotatividade de funcionários, o que significa perda de conhecimento da empresa e pagamento para aumentar continuamente os funcionários. No segundo caso, você está selecionando essencialmente desenvolvedores ruins e, portanto, os custos aumentam na forma de agendas crescentes. A maneira como isso acontece é que tudo está indo bem no projeto X, até que Jim sai de repente, que foi um dos melhores desenvolvedores, porque ele não recebe um aumento há dois anos, agora o projeto "compreensivelmente" levará muito mais tempo, pois você precisa contratar e treinar novos desenvolvedores juniores que (presumivelmente) não serão tão bons quanto Jim. É assim que você recalibra as expectativas.

Mesmo no caso de aumentos competitivos serem fornecidos, se você só tem desenvolvedores juniores, onde e como eles devem aprender? Você basicamente espera que um deles aprenda as boas práticas por conta própria , apesar do ambiente de trabalho e, eventualmente, mentore os outros (em vez de partir para pastos mais ecológicos). Faria muito mais sentido "preparar a bomba" com alguns bons desenvolvedores. É mais provável que você desenvolva uma cultura de especialistas iniciantes . O resultado é que você acabará pagando taxas de desenvolvedor sênior para pessoas que são apenas um pouco melhores que desenvolvedores juniores e são culturalmente tóxicas.

Um benefício, particularmente, de desenvolvedores muito bons, que estou surpreso que ninguém mais mencionou, é que eles podem ser facilmente um fator multiplicativo . Pode ser que um desenvolvedor júnior e um desenvolvedor sênior levem a mesma quantidade de tempo para fazer uma mesa. No entanto, um bom desenvolvedor não fará isso. Eles farão um gerador de mesa que reduz o tempo para que todos façam uma mesa. Alternativamente / adicionalmente, eles elevam o limite do que é possível para todos . Por exemplo, os desenvolvedores que implementaram a estrutura MapReduce do Google provavelmente eram extremamente qualificados, mas mesmo se os usuáriosdo MapReduce são totalmente incapazes de criar uma versão massivamente distribuída de seu algoritmo por conta própria, agora podem facilmente com o MapReduce. Muitas vezes, essa dinâmica é menos flagrante. Por exemplo, melhores práticas de controle, teste e implantação de fontes melhoram a todos , mas pode ser mais difícil rastrear uma pessoa específica.

Para discutir um pouco o outro lado, talvez os superiores estejam certos. Talvez desenvolvedores mais experientes não sejam necessários. Se for esse o caso, parece que o desenvolvimento não é uma parte significativa da empresa. Nesse caso, eu apenas eliminaria completamente os desenvolvedores e usaria software de prateleira ou contrataria empreiteiros sob demanda. Talvez valha a pena explorar por que eles não usam apenas contratados, e não uma equipe interna. Se você vai ter muita rotatividade de funcionários de qualquer maneira, aumentar as empresas contratadas não deve ser um problema.

Esta não é uma situação de ou / ou.

Especialmente em um projeto maior, você rotineiramente tem algumas pessoas relativamente experientes em cargos seniores e várias pessoas menos experientes em cargos juniores. Dessa forma, os idosos não podem apenas ajudar diretamente no projeto escrevendo código e ajudando a tomar decisões mais difíceis, mas também podem ajudar indiretamente, orientando os juniores.

Com algum cuidado, isso também pode ajudar a impedir que os engenheiros seniores se esgotem rapidamente, sendo solicitados a fazer constantemente um trabalho que carece de desafio ou interesse por eles. Pelo menos na minha experiência, mesmo um pouco de tempo para orientar algumas pessoas entusiasmadas de nível júnior (ou mesmo interno) pode tornar o sprint muito mais interessante.

Para ser sincero, devo acrescentar que esse tipo de posição provavelmente não será adequado a todos os engenheiros seniores. Requer uma ênfase muito maior na arquitetura e design, comunicação, documentação e assim por diante. Especialmente desde o início, também exige muita disciplina - para alguém que fez uma carreira de redação de código, é tentador simplesmente escrever o código, em vez de ensinar a um engenheiro júnior como fazê-lo. Também é frequentemente tentador fazer uma reescrita completa desde o início, quando o código não é o que você preferiria pessoalmente - mesmo que seja perfeitamente adequado para o trabalho.

Se, no entanto, você realmente não pode convencer a gerência a usar uma mistura de níveis de experiência, basicamente não há dúvida de que você precisa buscar mais experiência. Se você deixar um projeto inteiramente para o pessoal júnior, é bem provável que você nunca consiga obter um produto utilizável. Pior, eles não perceberão que o que estão fazendo não está fornecendo nenhum progresso real em direção a um produto utilizável; portanto, continuarão trabalhando na direção escolhida muito tempo depois que uma pessoa mais experiente perceberá que fez um erro fundamental desde o início e precisa fazer backup, reagrupar-se, orientar-se e começar uma nova direção para ter alguma esperança de chegar a um destino significativo.

Qualquer projeto do mundo real é orientado pela demanda do cliente e, portanto, envolve tarefas que são de baixa complexidade (por exemplo, criando formulários CRUD) e alta complexidade (por exemplo, criando um sistema de notificação orientado a eventos). A única maneira de realizar apenas tarefas de baixa complexidade é dizer repetidamente aos clientes a palavra "não", que nenhum departamento de vendas que eu já ouvi falar está disposto a fazer.

Se você tiver apenas desenvolvedores de nível júnior, isso significa que você poderá executar tarefas de baixa complexidade e, portanto, criar um produto de baixo valor e se esforçar mais no mercado para diferenciar seus produtos. Se você quiser se diferenciar, precisará criar funcionalidades de alto valor, que inevitavelmente se traduzem em tarefas de alta complexidade. Afinal, se fosse fácil, não seria valioso. Isso significa que você precisa de pessoas para executar essas tarefas de alta complexidade e precisa de desenvolvedores de nível sênior.

Se você tiver apenas desenvolvedores de nível sênior, desperdiçará suas habilidades em trabalhos de baixo valor, terá problemas em retê-los ao forçá-los a fazer o trabalho, além de arriscar que eles entrem na terra da astronomia da arquitetura na tentativa de realizar tarefas simples. interessante trabalhar. Isso significa que você também precisa ter alguns desenvolvedores inexperientes para realizar essas tarefas.

Uma equipe saudável que trabalha com produtos direcionados ao cliente geralmente é uma mistura. A proporção entre desenvolvedores juniores e seniores depende da proporção entre tarefas de baixa e alta complexidade, e isso depende da sua estratégia de negócios. Se você procurar ativamente grandes volumes de trabalho de cortador de biscoitos de baixa margem e de fácil compreensão, não terá muitas tarefas de alta complexidade e provavelmente contratará principalmente desenvolvedores de nível júnior. Se você procurar ativamente diferenciar e direcionar nichos não atendidos a margens de lucro mais altas, terá muitas tarefas de alta complexidade e procurará principalmente desenvolvedores de nível sênior.

Na minha resposta, argumentarei que programadores seniores não necessariamente codificam mais rápido que desenvolvedores juniores. De fato, os programadores mais rápidos são, na média, caras que acabaram de sair da universidade.

O conhecimento do domínio é a chave do desenvolvedor sênior. Um bom desenvolvedor sênior deve ter um forte conhecimento do campo, algo que o desenvolvedor júnior pode não ter. Desenvolvedores experientes entendem o problema, o que resolver e como resolvê-lo. Eles podem resolver problemas mais complicados para os negócios do que a maioria dos desenvolvedores juniores.

A programação é um conjunto de habilidades relativamente barato, é o conhecimento especializado que conta.

Não tente 'defender o caso' O mercado define o preço para os funcionários. Se o mercado está disposto a pagar 4x mais a experiência, é porque as empresas como um todo descobriram que há um aumento de produtividade em 4x.

Agora, obviamente, o mercado pode estar errado, talvez seja 3,5 ou 5x, mas, a menos que você seja uma agência digital, concorra com o mercado ou algo desse tipo não seja importante.

O seu verdadeiro problema é: Você é bom o suficiente em entrevistas para poder distinguir entre um desenvolvedor experiente e bom e apenas um desenvolvedor antigo que está incomodando.

Sua segunda pergunta de PM vs Orçamento de desenvolvedor. Eu diria que um desenvolvedor pode ficar sem um PM, mas um PM não pode ficar sem um desenvolvedor. Primeiro, classifique seu mecanismo de desenvolvimento e, em seguida, solicite um PM para tirar o administrador de suas mãos.

Você não encontrará ninguém em seu próprio país por um quarto do custo de um desenvolvedor realmente bom. Você pode encontrar alguém com metade do salário, e isso será um iniciante absoluto. Para alguém com um quarto do salário, você precisa sair do país e terá problemas com comunicações, pessoas que seguem cegamente as especificações e todo tipo de problema.

Você precisa de um bom desenvolvedor. Se você adicionar mais programadores juniores, precisará de um bom desenvolvedor com fortes habilidades de comunicação, disposto e capaz de manter um olho nos juniores. Sem um bom desenvolvedor, você está perdido. Você pode ter sorte em encontrar um iniciante extraordinário e talentoso, mas depois que ele descobrir que eles são bons, eles vão querer um salário maior.

Se você não tem um bom desenvolvedor, não tem ninguém que veja a imagem maior e ninguém que possa resolver problemas que não podem ser resolvidos usando o stackoverflow. E você terá um código que cheira mal e é impossível de manter, porque os desenvolvedores juniores não sabem como criar código sustentável. Eles podem aprender, mas não terão sem um bom desenvolvedor da equipe.

Existem alguns obstáculos que sua empresa precisaria superar antes de decidir se contratar melhores programadores seria rentável. Desculpe se estou fazendo algumas suposições negativas sobre onde você trabalha, mas não estou convencido de que eles saibam o que estão fazendo.

1. Eles avaliaram com precisão a complexidade do software que você cria? Parece que eles não acham muito difícil o que você está fazendo, então por que contratar pessoas melhores? Você já defendeu os erros e como as melhores soluções e produtividade renderiam dinheiro? Economizar tempo é ótimo, mas muitas empresas preferem desperdiçar uma semana inteira com um programador do que lhes dar dinheiro para comprar um mouse pad.
2. Sua empresa é atraente para bons programadores? Eles são capazes de identificá-los? Nada pior do que contratar um Desenvolvedor Sênior, pague mais dinheiro e eles arrastam toda a equipe devido à falta de habilidades e / ou liderança.
3. Sua empresa pode utilizar um bom programador? Se tudo o que eles farão é lançar especificações ruins e apenas pedir que construam, qual é o objetivo? Eles vão dar a eles liberdade para fazer as coisas do seu jeito? Afinal, um bom programador, por definição, sabe como utilizar melhor seu tempo. Eles impactam as pessoas ao seu redor e fazem com que outros programadores melhorem. Eles introduzem melhores projetos e arquiteturas que os demais desenvolvem para tornar o produto muito melhor.

Desculpe, mas sinto que sua empresa não saberia o que fazer com um bom programador, então convença-os a contratar primeiro gerentes melhores e resolver esses problemas internos.