5 erros chumbo iniciante

Cada líder de equipe tem seu próprio cemitério de funcionários com erros de gerenciamento. Todos os dias são publicados novos artigos: “5 erros de um desenvolvedor iniciante”, “7 exemplos de como você não precisa gerenciar processos”, “100 e 1 maneira de cumprir os prazos”. E isso é demais!


O rake de outra pessoa economiza seu tempo, deixa você ousado, dá um tapinha no ombro e deixa claro que você não é o único que "me fez", e tudo isso passou.



Um erro de acordo com Ozhegov é um erro nos pensamentos ou ações e, possivelmente, ao mesmo tempo. Mas como pode um novato com uma nova gama de responsabilidades passar sem eles? Talvez nada, mas você pode tentar suavizar os golpes. No meu exemplo, vou falar sobre os erros que não pude evitar no processo de me tornar um líder. Espero que cada história sorria para você, porque você se lembrará de si infância o início de sua jornada, ou isso fará você pensar em como evitar pisar em um rake.


Antecedentes


Nos últimos 6 anos, dediquei os testes à mudança de várias empresas e equipes, a fim de obter conhecimento relevante e confiável sobre como criar um produto de alta qualidade e qual o papel dos testadores e engenheiros nesse processo. Às vezes, o motivo da partida foi a falta de oportunidade de aprender com colegas fortes de testadores (e isso é necessário no início do caminho), porque eles simplesmente não existiam. Testei minha força em testes manuais e automatizados. E foi justamente depois que eu desenvolvi a automação que tive a oportunidade de me testar como testador líder de um coach Agile experiente.


Para mim, é como se o mundo estivesse de cabeça para baixo naquele momento. O hábito de propor soluções e implementá-las de forma independente tornou-se mais forte e não queria me deixar. Verificou-se que o estilo de trabalho do engenheiro de automação não se encaixa no novo papel do líder de um pequeno grupo de pessoas. Vamos aos detalhes.


Erros


Gerente nº 1 "aqui e agora"


Eu era melhor na resolução de questões pontuais “aqui e agora”, mas isso nem sempre aproxima a equipe do objetivo declarado.


Considere um exemplo. No começo da formação do novo formato de controle de qualidade no Dodo, depois de me familiarizar com o funcionamento dos testes e com o desejo de todos de iniciar a automação ontem, decidi que deveria ser iniciado em um futuro próximo. (Como alteramos os processos podem ser encontrados no relatório “Alice no país do controle de qualidade” ). Todos nós realmente queríamos salvar o pessoal da rotina diária de testes de regressão manual em 9 países.


Seguindo o princípio de "resolver problemas aqui e agora", organizamos uma reunião com os testadores, fizemos um mapa de ações, definimos prioridades, alocamos tempo para cada testador automatizar e começamos a implementar tarefas a partir do mapa. Antes de tudo, decidimos sobre a ferramenta e apresentamos nosso plano para acelerar a regressão na assembléia geral de TI. Os testadores se alegraram com os testes que apareceram e acreditavam no descarte antecipado da rotina manual.


No entanto, verificamos que cobrimos com testes o que consumia muito tempo do testador, mas, ao mesmo tempo, praticamente nunca era alterado pelos desenvolvedores e tinha pouco efeito nos processos de negócios.


O que fazer Cap Tips


Para entender o problema mais profundamente, procurar causas, não consequências. É muito provável que suas expectativas de que os testadores sejam o principal depósito de conhecimento sobre o sistema do ponto de vista do usuário sejam exageradas. Vale a pena chamar vários representantes da empresa de TI para as primeiras reuniões, pedindo ajuda para facilitar a reunião com o scrum-master, discutindo previamente com ele qual resultado você gostaria de receber.

Gerente No. 2 "Engenheiro Experiente"


Meu segundo arquivo é a "tampa" de um engenheiro experiente. Todas as tarefas mais difíceis vieram para mim.


A formação do PageObject, a implementação do conjunto básico de métodos para trabalhar com o nosso sistema, os scripts de lançamento no CI / CD - eu decidi assumir o hábito. Não comecei a delegar comunicação com equipes de produtos, engenheiros de infraestrutura e entrevistas e textos de vagas. Segundo o mentor, nossa equipe de controle de qualidade era "verde" (iniciantes) em todos os sentidos. Obviamente, decidi primeiro ensinar aos rapazes o que eu me conhecia, observando o trabalho deles para compartilhar minhas tarefas ao longo do tempo.


O problema é que, com o número de reuniões (reuniões gerais, reuniões de equipe, treinamento interno, 1 e 1, entrevistas, dias de testes) que caíram sobre meus ombros, eu parei de cair no horário de trabalho com minhas tarefas. Oito horas por dia não eram suficientes, e comecei a compensar isso com meu tempo livre, que gastei em codificação, textos, preparação para entrevistas com candidatos. O resto do relógio precioso que passei com os caras juntos, com o objetivo de treinar e o desenvolvimento gradual do projeto com testes automáticos. Meu contexto de alternar a cada hora ou duas nos atrasava em todas as frentes: automação, comunicação de controle de qualidade com comandos e muito mais. A baixa taxa de formação de engenheiros legais de controle de qualidade e automação de processos me levou a trabalhar no fim de semana para fazer um plano de cinco anos em alguns meses.


O que fazer Cap Tips


Não tenha medo de delegar tarefas. Todo mundo tem o direito de cometer um erro e você não deve removê-lo, não importa como você seja hipnotizado pelos líderes de outras equipes ou pelo mentor. Seu pessoal deve querer confiar em você e segui-lo, sempre experimente. Reúna-se, determine qual dos processos pode ser aprimorado, quais estão prontos para promovê-los e talvez alguns deles possam ser transferidos para fora da sua equipe. Um facilitador experiente ajudará a garantir que as soluções escolhidas juntas não estejam apenas no papel. Uma equipe independente e eficaz é o que todo líder deve buscar.

Gerente No. 3 “O verso da microgestão”


Outro erro é geralmente o microgerenciamento. Eu tive que enfrentar o outro lado - controle rígido implícito.


Tentando evitar monitorar cada passo das crianças e limitar a frente do trabalho, comecei a "impor" as possibilidades "ilimitadas" às crianças: planos de desenvolvimento, tarefas de pesquisa, discursos, cursos, organização de reuniões, visitas a outras empresas e outras atividades. Boas intenções - treinando, aprimorando e aprimorando habilidades, ampliando os horizontes, conhecendo a esfera profissional. Isso é tudo o que me faltava quando comecei a trabalhar como testador. O problema é que a equipe quer o direito de escolher: falar ou não, assistir ou não, mas eu os levei a uma estrutura rígida.


- Pessoal, estamos fazendo um mitap. Precisamos dos seguintes papéis, presentes, haverá tais palestrantes. Sem a sua ajuda, não podemos fazer um evento memorável.
- Pessoal, em dezembro haverá Heisenbug. Já pedi uma transmissão on-line para nós, reservei uma sala de reuniões e, no sábado, transmitirei a partir do meu computador em casa. Tudo para?
- Pessoal, nesta semana vamos visitar Odnoklassniki para nos familiarizarmos com a forma como a automação é construída.


Essas oportunidades foram percebidas como limitações, das quais todo mundo não gosta. Minha iniciativa parecia incontestável e, o mais importante, não foi tão eficaz quanto o esperado.


O que fazer Cap Tips


O cuidado excessivo da criança leva ao fato de ela crescer infantil ou começar a fazer o contrário, apesar dos pais. Parece que o mesmo pode ser dito sobre o cuidado do líder sobre sua equipe. Motive, não force, reúna um tópico sobre o tópico "Como podemos expandir nossos horizontes em TI?" e ouça atentamente os colegas, não comece pelo limite para nomear todas as maneiras que você conhece. E o mais importante, não corra atrás de seus colegas com a proposta de falar em uma conferência e obter uma aula interessante. Anuncie a oportunidade - isso será suficiente.

Gerente No. 4 “Em todos os lugares que fizeram”


Talvez algumas das soluções que funcionaram anteriormente para você em outra equipe / empresa não encontrem suporte nas novas condições e a idéia de um colega que esteja longe do campo de teste de software, mas que tenha bom desenvolvimento, seja realizada. O argumento de que sua decisão foi apoiada e continua sendo desenvolvida ativamente já com base na comunidade provavelmente não convencer ninguém a fazer o mesmo, mas na pilha de tecnologia local.


O que fazer Cap Tips


O principal é não começar a se oprimir pelo fato de que suas habilidades e conhecimentos profissionais estão sendo questionados e não são levados em consideração na tomada de decisões. Procure argumentos dignos que encontrem apoio da equipe ou concorde com a equipe.

№5 gerente "histérico"


Um papel importante no processo de se tornar você como um profissional / mestre de seu ofício é desempenhado por um mentor. Mas há uma ressalva: sua percepção da ajuda de um mentor. Se entre vocês desconfiam um do outro, é improvável que o efeito de atividades conjuntas agrade à equipe e a todos os demais.


Conselhos, recomendações, enfatizando os pontos fortes e fracos das decisões tomadas - esse é o principal valor de trabalhar com um professor para mim. No entanto, os treinadores costumam usar um formato de treinamento diferente: eles organizam uma situação difícil para você sem aviso, por exemplo, um conflito em uma equipe baseado em uma escolha de tecnologias, lava as mãos e observa suas ações. Para mim, tudo acabou com o fato de que o projeto com autoteste passou a ser responsabilidade das equipes de desenvolvimento devido ao alto limite de entrada que o treinador insistia. Esse alinhamento é adequado a todos e não faria sentido continuar a batalha pela simplicidade.


O que fazer Cap Tips


Será importante aprender esse momento: gritos, lançamentos de papéis, exclusão do código um do outro, a apresentação por você e pelo mentor de diferentes visões da estratégia e das etapas táticas, as lágrimas não ajudarão. Portanto, você apenas prolonga o processo de aproximação à meta e talvez revire constantemente, porque tem medo de lidar, senta-se no mesmo andar, duvida da solidez de suas idéias. Tente não tomar decisões rápidas, descubra por que o treinador precisava desse conflito, por que você é fraco e como resolver a situação sem explodir por nada.

Resumir


Acima, descrevi 5 pontos de gerenciamento fraco de um engenheiro de automação experiente. Você pode encontrar as dificuldades descritas acima, e quão bem-sucedida será sua batalha e quão unida e forte sua equipe dependerá de sua preparação e caráter. Minha história terminou com a consecução do objetivo.


Os testadores agora fazem parte das equipes de desenvolvimento, os caras são muito independentes e são capazes de tomar decisões sobre implementação técnica e cooperação com outras equipes. Eles escrevem scripts por conta própria, selecionam novos testadores, mantêm mitaps e muito, muito mais. Sim, participamos disso há mais de um ano, mas ninguém prometeu que gerenciar pessoas é fácil.

Source: https://habr.com/ru/post/pt456068/


All Articles