Existem 15 pessoas no meu estúdio, metade das quais são programadores. O estúdio é especializado no desenvolvimento de lojas online, portanto os programadores são nosso principal recurso.
Três coisas são sempre exigidas dos programadores
- Entrega mais rápida de projetos.
- Fique em sua própria avaliação dos custos trabalhistas.
- Crescer e desenvolver
Mas, por várias razões, eles nem sempre estão prontos para isso. Como motivamos os programadores a melhorar nas três áreas, que dificuldades eles encontraram e o que resultou disso, vou contar no artigo.
Como começamos a enviar projetos mais rapidamente
Falaremos imediatamente sobre por que isso é importante: se um programador envia um projeto mais rapidamente, a empresa ganha mais dinheiro na inicialização e, finalmente, o programador ganha mais rapidamente. Uma vez que ele rapidamente passa para o próximo projeto, e o anterior vai para suporte e promoção. Parece que tudo é óbvio, mas vimos que os programadores não concluem tarefas e entregam projetos o mais rápido possível, e decidimos ajudá-los a acelerar
Quão motivado
Primeira etapa
A primeira opção era fazer com que o salário do programador fosse metade do salário e metade dos bônus do projeto. Como resultado, a empresa e o desenvolvedor estarão “no mesmo barco”, e o sucesso de um afetará diretamente o sucesso do segundo. Parece que tudo é lógico, resta apenas acelerar.
O que é necessário para concluir um projeto mais rapidamente?
Obviamente, você precisa programar mais rapidamente. Como fazer isso? Menos distrações e tudo é bom para fazer imediatamente, para que você não precise refazê-lo.
Mas aqui encontramos outro problema: os programadores nem sempre são distraídos por culpa própria ou por vontade própria. Por exemplo, um gerente pode transferir um programador para resolver problemas de suporte a projetos anteriores.
Além disso, entre o desenvolvimento e a entrega do projeto, há um processo de integração longo e problemático. Portanto, o programador recebeu bônus pelo desenvolvimento de um projeto ainda não entregue. Como isso não parecia muito lógico, continuamos a procurar opções.
Segunda etapa
A segunda decisão foi pagar bônus na entrega do projeto, e não na conclusão do projeto.
Agora, os programadores se tornaram ainda piores: não apenas tarefas relacionadas influenciaram seus bônus de recebimento, mas também, por exemplo, a velocidade de fornecer acesso ao cliente para integrar-se ao pagamento e entrega (e às vezes são vários meses), e a velocidade de seus especialistas 1C (para integração com 1C )
Além disso, na fase de programação, todos os erros das etapas anteriores são revelados: planejamento, design, design. E o programador precisa corrigi-los virtualmente por um salário básico (e ele era muito pequeno na estrutura deste sistema).
Acontece que o programador permanece sem bônus (e eles são significativos) sem culpa própria.
Esse alinhamento foi inaceitável e o experimento com bônus para projetos teve que ser reduzido.
Aqui, é hora de pedir desculpas à equipe de desenvolvimento por esses experimentos. Ainda estou surpreso como todos eles não fugiram naquela época.
O resultado do experimento foi o entendimento de que os programadores estão bastante motivados para executar a tarefa rápida e bem, se não interferem. E eles não precisam de incentivos adicionais.
Então, a motivação material é necessária neste caso?
Eu preciso disso Um pequeno bônus após a conclusão do projeto motiva o programador a não "trabalhar melhor" (para isso, em nossa experiência, ele não precisa de incentivo), mas a se aprofundar em áreas relacionadas. Por exemplo, um programador, juntamente com um gerente de projeto, estuda os layouts de design antes de mostrá-los a um cliente, procurando inconsistências e áreas problemáticas neles. Como resultado, os projetos são muito mais fáceis de programar e entregar ao cliente.
A proporção de salário e bônus ao mesmo tempo no nível de 80/20%.
Nós motivamos a se encaixar na sua avaliação dos custos trabalhistas
Se é impossível entregar projetos mais rapidamente devido à motivação material dos desenvolvedores, talvez valha a pena motivar os programadores a se ajustarem às suas próprias estimativas dos prazos das tarefas?
Do que estamos falando: com base em estimativas da complexidade das tarefas, é planejado que os programadores trabalhem - as tarefas são definidas para a perspectiva de curto prazo (semana) e longo prazo (1-2 meses). Consequentemente, se o programador não cumprir o prazo, todo o cronograma de trabalho cairá, os prazos passarão para os projetos que dependem dele e assim por diante.
Como ajudar o programador a se manter dentro do prazo planejado?
É possível recompensar se você tiver atingido a marca. Você pode ser privado, se não for atendido.
No entanto, a primeira e a segunda decisões sugerem que o ponto aqui é apenas a motivação, e não por razões externas. Já descobrimos que os programadores, se não forem perturbados, funcionam da melhor maneira possível.
Começamos a conduzir retrospectivas para descobrir por que uma tarefa específica demorou mais do que o planejado, a fim de encontrar “gargalos” na própria tarefa, ou no contexto de sua execução, ou no conhecimento do programador.
Isso ajudou, as tarefas começaram a ser realizadas com mais frequência no tempo previsto. Tornou-se óbvio que você precisa descobrir sobre as tarefas prolongadas antes que elas saiam do prazo.
Para isso, criamos "retrospectivas preliminares". Quando mais da metade do tempo alocado para a tarefa já passou e a tarefa ainda não está perto da metade, o programador informa o gerente sobre isso e, juntos, eles procuram razões.
Então, por causa do que você não pode cumprir o prazo para a tarefa
A tarefa foi avaliada inicialmente incorretamente.
A complexidade foi avaliada incorretamente ou a solução escolhida durante a avaliação não se encaixou no final. Isso significa que o programador possui uma lacuna de conhecimento em uma área específica. Importante! Esta informação é usada para treinamento, não para punir o programador.
A tarefa cresceu demais com detalhes ao longo do caminho.
Se os detalhes vieram do cliente e no início eles não eram óbvios, o programador corrige a avaliação e o gerente vende as horas ausentes e muda o prazo.
Se os detalhes fossem óbvios, mas o gerente sentisse falta deles
Isso já fala sobre as lacunas no conhecimento do gerente. Entendemos que o gerente deve estudar para que problemas semelhantes não surjam mais.
Mas você precisa de motivação financeira aqui
Eu preciso disso Consideramos o prêmio pelo número de horas vendidas ao cliente e calculadas pelo programador. O objetivo permanece o mesmo: motivado para fazer uma avaliação precisa, o programador se aprofunda na tarefa, ora orientando-a a esclarecer, ora oferecendo suas próprias versões.
Treinamento de programadores e motivação para o desenvolvimento
Na fase retrospectiva, encontramos lacunas no conhecimento dos programadores, mas como fazê-los estudar e fechar essas lacunas?
Estamos localizados em Krasnodar, e aqui em geral existe um estúdio de comércio eletrônico (na verdade, nós). Isso significa que não há para onde tirar pessoal pronto. E todos precisam crescer do zero ou "crescer" do nível que tinham em outros estúdios.
O que um programador deve saber
- Frontend
- Backend
- Engine
- Integração (1C e assim por diante)
- Linux, Nginx, Apache
Assim, temos 5 áreas de competência. Cada um deles possui um certo conjunto de habilidades a partir das quais o mapa de competências de um programador é formado. Ele determina a divisão dos desenvolvedores em níveis (Trainee, Júnior, Médio, Sênior).
À medida que o nível aumenta, o salário aumenta.
Como criamos desenvolvedores
Hipótese 1
A primeira idéia foi fornecer aos desenvolvedores um mapa de competências e materiais metodológicos e nos oferecermos para desenvolvê-los.
Na Bitrix24, iniciamos tarefas automáticas nas quais todos tinham que informar sobre o progresso no treinamento.
E então eu corri para o primeiro problema. Por alguma razão, os programadores não queriam estudar e não queriam crescer no mapa de competências.
Depois de alguns meses de tentativas inúteis, imaginei perguntar: o que há de errado?
Verificou-se que há muita diferença de competências entre diferentes níveis. E ela não se motiva a estudar.
Hipótese 2
Decidi dividir os níveis em vários níveis (como uma porcentagem do mapa de competências estudado). E para cada nível para dar um pequeno aumento no salário.
Ficou um pouco melhor. Programadores procuraram estudar e fazer exames. Mas ainda é muito lento.
O seguinte problema ficou claro: não há tempo ou energia para estudar materiais em casa e, no trabalho, os programadores estão ocupados com as tarefas. Assim, aqueles que têm meio dia de auto-educação gratuita avançaram no mapa de competências e aqueles que não permaneceram no mesmo nível, o que os desmotivou friamente.
Hipótese 3
Dê tempo livre. Entre as tarefas, os programadores começaram a sair várias horas por semana para treinamento.
E assim funcionou. Os programadores começaram a se envolver no autodesenvolvimento, fazer testes e aumentar os salários.
Aqueles que não estão prontos para aprender, sujeitos ao tempo e às perspectivas de crescimento previstos, devem simplesmente ser deixados em paz. Existem pessoas que se sentem à vontade no nível delas e se podem fechar algumas tarefas, por que não?
Conclusões
Em nossa experiência, os programadores têm motivação interna suficiente e, se não forem perturbados, funcionam da melhor maneira possível.
Os prêmios servem como um motivador adicional, tanto pela qualidade do trabalho quanto pela imersão no trabalho de especialistas relacionados (procure por áreas problemáticas no design e no TK antes de finalmente ser acordado).
Todas as ferramentas de aprendizagem não têm sentido, a menos que haja duas coisas importantes. Sentimentos de progresso (incluindo recompensas alcançáveis) e o tempo alocado para isso. Acredite em mim, quando um programador, que mal conseguiu encerrar a tarefa em um dia, chega a sua casa do trabalho uma hora, depois disso ele não está absolutamente de acordo com o seu "plano de desenvolvimento". E estou pensando que "você aprenderá agora e terá tempo livre" dará origem a apenas uma reação silenciosa: "Não acredito".