Halloween é a hora de falar sobre medos. Eu trabalho como gerente de produtos em uma empresa de TI, então isso será sobre os pesadelos dos desenvolvedores. Mas não é comum, mas aqueles que aparecem durante os tempos de mudança.
Quando uma empresa se desenvolve, ela muda sua abordagem para o desenvolvimento, cria novos produtos e expande as capacidades dos atuais, leva dezenas de funcionários e aqueles que trabalharam da maneira antiga podem achar difícil reestruturar. Nos alegramos com as mudanças, mas às vezes, por que esconder, temos medo delas. Trabalho como gerente de produto há um ano e, durante esse período, enfrentei cinco grandes medos da minha equipe. Hoje vou falar sobre esses medos e como conseguimos superá-los.
1. Medo de largar tudo
O teste é uma maneira de liberar um produto sem erros. Mas, às vezes, não há equipamento para verificar o código.
Nós
criamos o DCImanager , um painel para gerenciar servidores e data centers, e muitas vezes é impossível criar condições nas quais o código funcione em um ambiente virtual. Por exemplo, adicionamos suporte ao novo modelo de comutador, roteador ou PDU ao painel de controle, mas não existe esse equipamento na bancada de testes.
Em alguns casos, os testes podem ser negligenciados, mas não os nossos. O erro é caro. Você não inicializa apenas uma variável e, na metade dos casos, o sistema operacional deixa de ser instalado. Você está enganado em algumas linhas de código - e o data center "cairá". Como você sabe, ninguém quer ser responsável pelo data center "caído", portanto esse medo está em primeiro lugar na minha equipe (embora não esteja relacionado às transformações na empresa).
Como superar o medo de largar tudo- Todos os desenvolvedores da equipe fazem uma revisão do código de cada recurso.
- Mantemos listas de coisas sem as quais a tarefa não pode ser liberada.
- Após o lançamento do desenvolvimento, analisamos que não o levamos em consideração. Descrevemos em detalhes o que foi feito e qual comportamento foi observado, para que a qualquer momento você possa retornar à tarefa e restaurar tudo na memória.
- Atualizando constantemente a base de conhecimento. Dedicamos tempo à documentação para desenvolvedores, compartilhamos conhecimento entre nós. treinamento e stand-ups.
- E por último mas não menos importante. Testamos desenvolvimentos personalizados para os clientes com eles no equipamento fornecido.
Depois de adicionarmos o controle de agregação de portas para os switches existentes. Se um erro fosse cometido, a operação do equipamento de rede no data center seria completamente interrompida. O cliente chegou ao seu datacenter às três horas da manhã e controlou a situação para que, nesse caso, ele voltasse rapidamente à versão antiga e retomasse a operação do equipamento. Poderíamos perder o acesso remoto e o data center ficaria paralisado.
2. Medo de ficar sem testador
Nossos desenvolvedores escrevem testes de unidade e pessoas individuais são envolvidas em testes manuais. Mas uma vez houve uma força maior, e a equipe ficou sem um testador manual. Como não pudemos liberar recursos, os desenvolvedores tiveram que verificar um ao outro.
Foi um golpe de orgulho. Aconteceu que todos os programadores da minha equipe deixaram os testadores (manual e automático). Volte ao teste manual para eles - dê um passo atrás. Os caras tinham medo de que, se pudessem lidar sozinhos, os testadores não retornariam a eles. Mas o medo acabou sendo infundado, depois de algumas corridas, o testador assumiu seu lugar na equipe e, com a experiência, aprendemos muitas coisas úteis.
Qual é o benefício do teste cruzado- Eles se lembraram de “juventude” e novamente olharam para o desenvolvimento do lado do testador. Em alguns casos, foram adicionadas ações adicionais para facilitar a vida do testador. Por exemplo, gerando estatísticas para verificação.
- Eles confirmaram o fato conhecido de que o desenvolvedor não pode testar seu código, pois fecha os olhos para algumas coisas. Portanto, os caras testaram o código um do outro.
- Mais uma vez, estávamos convencidos de que os testadores são uma parte importante da equipe. Eles são responsáveis pela qualidade dos recursos lançados no lançamento.
3. Medo de entrar em outra equipe
O DCImanager foi lançado em 2013. Por seis anos, a tecnologia mudou, é hora de fazer uma nova versão, decidimos fazê-lo do zero. Desenhamos protótipos, determinamos o MVP e priorizamos. O desenvolvimento da versão antiga foi congelado, mas eles não puderam iniciar a nova - dois novos produtos já estavam sendo preparados para o lançamento, todas as forças foram dedicadas a eles, tivemos que esperar um pouco. Durante a pausa, meus desenvolvedores se tornariam a equipe de projeto do
BILLmanager , nosso outro produto para automação de hospedagem.
E então outro medo apareceu. Os desenvolvedores de engenharia, em todos os sentidos da palavra produto, tinham medo de assumir o faturamento. Pareceu-lhes que essa não era a área deles, que era desinteressante entender um monte de contas. Eu estava preocupado que desmotivasse meus desenvolvedores. Ao contrário de nós, a equipe de cobrança se alegrava com o descarregamento.
Por alguns sprints, fomos trabalhar no BILLmanager, e essa experiência também foi útil.
Brevemente sobre como a implementação ocorreu- Para minimizar o estresse de mudar para outro produto, a equipe continuou sendo uma equipe e não dependia dos funcionários do BILLmanager.
- As tarefas foram escolhidas de acordo com o princípio de "precisam ser feitas ontem, mas não há mãos suficientes". Os Productologists discutiram as tarefas e, ao planejar o próximo sprint, eu as traduzi para a equipe.
- Os desenvolvedores do BILLmanager foram nossos mentores. O recepcionista respondeu a todas as perguntas e o líder da equipe disse o que e como deveria funcionar.
- Tivemos dois standups. No início, fomos para o faturamento e discutimos os resultados em nossa equipe.
Quais benefícios os desenvolvedores trouxeram da introdução para outra equipe- Outro produto é o código de outra pessoa que você precisa entender; além de outra lógica de trabalho para entender. Graças à mentoria e à paciência do executor, nos acostumamos com sucesso ao faturamento, desenvolvemos novas habilidades e vimos as melhorias rapidamente.
- Obviamente, espionamos como algumas coisas funcionam dentro de outra equipe. Pode parecer que tudo é o mesmo para todos, mas não importa como. As diferenças estão nos detalhes. Como regra geral, eles tomavam o melhor e o mais conveniente para si mesmos (por exemplo, espionavam e, alterando-se levemente, começaram a usar um quadro de scrum, adotaram alguns pontos no estilo do código etc.).
4. Medo de se tornar um mentor / permanecer sem um líder de equipe
A empresa precisa de tantos programadores fortes quanto possível; portanto, quando um desenvolvedor aprimora suas habilidades e passa para o nível médio, o treinamento para iniciantes se torna sua responsabilidade. Mas a orientação geral geralmente recai sobre o líder da equipe. Assim, ocorreu em nossa equipe, até que a experiência de um desenvolvedor líder fosse urgentemente necessária em outro produto. Os programadores que ficaram sem equipe tiveram que treinar tanto os iniciantes quanto os outros.
Ser um mentor é assustador. Você precisa se distrair de suas tarefas, sintonizar-se com outra pessoa, explicar o que às vezes entende no nível da intuição e explicar de maneira a ser entendido. Se o Padawan não entendeu, este é o seu problema. Se ele cometeu um erro e você não percebeu, você responde.
Não darei conselhos sobre como se tornar um bom mentor, este é um tópico para um artigo separado. Mas conseguimos e, com essa experiência bastante estressante, aprendemos o seguinte:
- Ao explicar, é necessário dar mais contexto. Tudo é bonito na cabeça e, quando você diz, acaba sendo arrancado e incompreensível.
- Não se deve apenas olhar para um código em uma revisão, mas entender o que uma pessoa tentou resolver com esse código. Então é mais fácil entender sua lógica e encontrar erros.
- Compartilhar conhecimento é útil: aprender a formular pensamentos; coloque tudo nas prateleiras da sua cabeça; enquanto você explica, você encontra a melhor solução para o problema.
5. Medo de não aprender novas tecnologias
Quando a pausa acabar, é hora de iniciar uma nova versão do produto DCImanager. Parece que aqui é o momento tão esperado. Agora, com uma equipe cheia de pessoas ambiciosas, começaremos tudo do zero - sem olhar para erros antigos e historicamente desenvolvermos dependências estranhas no código. Mas havia um lugar para o medo.
Por vários anos, a tecnologia foi muito à frente. Escrevemos a versão antiga em C ++ 11 e, usando o make, para a nova, escolhemos C ++ 17, CMake, Conan e Docker. A equipe precisa aprender tudo isso e aprender como se inscrever. A próxima saída da zona de conforto, o desafio e o pensamento "e se eu não puder e for pior do que os outros", "e se houver mais problemas esperando por mim, eu não vou descobrir e me expulsar". Ainda estamos dominando as novas tecnologias, e a luta contra esse medo ainda está em processo.
Como aprender novas tecnologias mais rapidamente- Não tenha vergonha de perguntar a colegas mais velhos e experientes, não tenha medo de parecer estúpido.
- Documentar, a fim de acelerar o processo de imersão dos recém-chegados e não contar a mesma coisa 10 mil vezes. Manter uma base de conhecimento.
- Ok, o Google está sempre lá para ajudar. Se não funcionar, consulte o ponto 1.
Não temores, mas desafios
Aproveito os experimentos como uma oportunidade para aprender coisas novas, para melhorar, e tento que minha equipe também veja seus medos. Eu acho que o humor dos caras depende muito de mim. Quando você acredita em um produto e em desenvolvedores, ouça-os em pé e analise problemas em retrospectivas, apóie-os em problemas e explique a necessidade de mudança, então é mais fácil para eles superar os medos.
Mas, sejamos honestos, ainda temos algumas fobias invictas em estoque. Medo de prazos, por exemplo, ou medo de não se dar bem com iniciantes. Até agora, parece que nada pode ser feito sobre eles - apenas acondicionados. Mas talvez com o tempo nossa visão mude.
Por que você está com medo?
PS Se você quiser ser o primeiro a ver a versão demo do DCImanager - envie contatos para bizdev@ispsystem.com com o assunto "Quero ver o novo DCImanager". Quando estiver pronto, escreveremos para você. Ou se você precisar de um produto para gerenciamento de servidores, mas o DCImanager atual, por algum motivo, não se encaixar e não houver solução adequada no mercado, escreva seus desejos para esse software, talvez incluamos algo no plano de desenvolvimento.