Leitura recomendada:
No processo de trabalho da equipe técnica, alguns problemas clássicos costumam se repetir, o que afetará seriamente a eficiência do trabalho da equipe e também terá um impacto significativo na moral da equipe.
A seguir, vamos discutir os cenários específicos onde esses problemas ocorrem, as causas dos problemas e como prevenir e resolver esses problemas.
Hoje, vamos discutir o terceiro problema comum: o trabalho contínuo de alta pressão levou toda a equipe a um estado de caos e uma emergência fez com que a equipe culpasse e reclamasse. O que você deve fazer neste momento?
Culpe o céu voando
Imagine um cenário como este: quando um projeto entra em uma fase crítica, ou uma equipe continua a trabalhar sob alta pressão, um problema que aparece repentinamente causa uma série de problemas, o progresso do trabalho de todos é afetado e toda a equipe é Entrando em um estado caótico, todos começaram a se culpar e reclamar uns dos outros, e a situação da equipe piorou ainda mais.
Já experimentei e testemunhei situações semelhantes muitas vezes. Naquela época, a equipe estava trabalhando intensamente por muitas semanas. O horário de trabalho diário variava de 9 a 14 horas. Um problema inesperado (o banco de dados do ambiente de teste foi excluído por engano por um engenheiro) interrompeu o trabalho de todos e a reação da equipe A alta probabilidade é atribuída ao indivíduo.
Obviamente, essas condições de trabalho contínuas de alta pressão certamente causarão erros, mas aconteceu que o engenheiro apagou acidentalmente o banco de dados.
Além de ser um problema urgente e sério conforme descrito acima, culpar o indivíduo por qualquer erro não é um ato benéfico para o grupo como um todo.
É fácil culpar a pessoa que fez a última alteração no módulo ou tratou do problema, mas alguém foi apontado. No entanto, esse é realmente o problema? Normalmente existem problemas mais profundos.
A razão por trás
Por que essa acusação e reclamação são questões importantes que afetam a eficácia e o moral da equipe? As principais razões são as seguintes: Primeiro, a primeira razão é porque ela é ineficiente . Culpar e punir um membro da equipe não resolverá o problema atual. Os dois pontos para lidar com o problema são: o primeiro foco deve ser resolver o problema, o segundo foco deve ser resolver a causa raiz do problema.
Em segundo lugar, culpar alguém o impedirá de encontrar a origem do problema . A causa raiz pode ser excesso de trabalho, permissões inadequadas do sistema, processo de liberação irregular, falta de automação, estratégia de teste deficiente ou uma combinação desses problemas. Se a causa raiz não for resolvida, você terá o mesmo problema novamente.
Terceiro, culpar o jogo apenas aumentará ainda mais a pressão e a tensão da equipe . Quando erros são atribuídos a indivíduos ou, pior, culpados publicamente, isso é prejudicial à participação do desenvolvedor e à saúde mental.
Finalmente, ele ignora dois fatos básicos do desenvolvimento de software :
- O desenvolvimento de software é um trabalho em equipe
- Bugs e problemas não podem ser completamente evitados
É por isso que temos uma equipe de QA, ferramentas para verificar problemas, testes de unidade, processo de lançamento, etc. Desenvolvimento e teste, bugs no processo de implantação, não são a causa do fracasso.
A solução
Encontrar a causa raiz do problema é a chave para evitar mais problemas no futuro . Uma vez que a causa raiz é determinada, a melhoria mais eficaz pode ser iniciada para reduzir a possibilidade de recorrência do problema.
Existem problemas frequentes e as razões profundas que levam a equipe a culpar e reclamar são as seguintes:
Alta pressão e horas extras contínuas
Em primeiro lugar, o trabalho contínuo de alta pressão causará problemas frequentes . Se for causado por horas extras ou estresse contínuo, você precisa ver se seus arranjos de trabalho são razoáveis. Como todos sabemos, horas extras e estresse podem levar a erros e redução da eficiência. Uma vez que esses erros ocorram, eles acontecerão cada vez com mais frequência. O aumento de erros e erros de tomada de decisão ocorre, na verdade, no caso de aumento da produção em um curto período de tempo, as horas extras irão diminuir a velocidade de desenvolvimento.
Embora muitos estudos tenham mostrado que o tempo máximo efetivo para horas extras pode ser de 3 ou 4 semanas. Mas devemos lembrar que mesmo que este seja um período preciso, essas são médias para toda a equipe e irão variar de acordo com o grau de horas extras. Alguns membros da equipe não conseguem segurar por tanto tempo, e alguns vão segurar por mais tempo. Tudo depende do indivíduo e de seu ambiente. Lembre-se disso ao planejar sua programação.
Fluxo de trabalho ausente
Em segundo lugar, a causa raiz de problemas frequentes são os problemas de processo, e o processo precisa ser otimizado ainda mais . Os problemas do processo podem ser processos incompletos, casos extremos não descobertos, contornar os nós-chave do processo ou outros motivos, etc.
O objetivo da equipe técnica de construir ou liberar o processo é esclarecer o ritmo e as especificações do trabalho. Se esse processo for complicado ou demorar muito, ele pode ser ignorado. Se um membro da equipe não estiver familiarizado com este processo, ele não o seguirá bem. Acontece que o próprio processo pode estar faltando algumas etapas principais.
Os objetivos de qualquer liberação ou processo de construção devem incluir:
- Fornece um caminho claro para a meta e elimina a ambiguidade
- Determine todas as etapas, incluindo tecnologia e gerenciamento (como aprovação)
- Fornece verificação de segurança correta, com lista de verificação
- Reduzir nós para aprovação da gerência
- Reduza o trabalho físico e fortaleça a automação
Automação insuficiente
Terceiro, a falta de automação leva ao aumento da probabilidade de erro nas operações manuais.Quando possível, todas as etapas do processo devem ser automatizadas. Se ninguém estiver envolvido, não haverá erros humanos. Automatize todas as coisas possíveis. No longo prazo, a automação é mais barata, mais conveniente e mais eficaz.
Muitas permissões pessoais
O terceiro motivo pode ser que os desenvolvedores têm muito acesso ao sistema , o que eles não deveriam ter. Talvez eles tenham configurado muitos servidores ou excluído o sistema de arquivos no servidor errado. Não importa o que seja, deve haver permissões e cotas adequadas para evitar que tais acidentes aconteçam.
Muitos desenvolvedores podem fechar os olhos imediatamente a esta conversa. Em muitas empresas, essa luta leva muito tempo para obter permissões adicionais para que os desenvolvedores maximizem sua produtividade e usem todas as suas ferramentas. Como desenvolvedor, sei o quanto a amada "autoridade administrativa" beneficia os desenvolvedores. No entanto, a separação adequada de permissões pode evitar muitos acidentes graves de produção.
Finalmente
Em primeiro lugar, o desenvolvimento de software é uma engenharia de sistemas complexa, um trabalho que requer um trabalho em equipe para ser melhor realizado, sendo impossível evitar completamente os problemas no processo de trabalho.
Para problemas frequentes, culpar e reclamar de alguém não conduz à solução do problema.
Resolver problemas exige que analisemos e pensemos fundamentalmente, encontremos a verdadeira causa do problema e resolvamos o problema do nível mais essencial, como controlar o ritmo e a pressão, estabelecer um processo otimizado, aumentar a distinção da autoridade ambiental e fortalecer a automação.
Acusações e reclamações são um veneno que pode afetar seriamente o moral da equipe. Diante dos problemas, a equipe como um todo deve permanecer aberta e honesta , e os gerentes devem orientar efetivamente a equipe para resolver ativamente os problemas.