Como eu, líder de equipe, avalio projetos

Os timlids geralmente valorizam projetos, e nem todos o fazem bem. Aqui, depende muito da personalidade do próprio líder da equipe, bem como de sua compreensão da equipe. Existem muitas técnicas para avaliar projetos do método "por analogia" ao PERT. Hoje, porém, falarei sobre como uso o planejamento do pôquer e outras técnicas para avaliar com mais precisão e maior benefício.




Antes de falar sobre abordagens específicas, vale a pena insistir nas principais dificuldades do processo.

Sempre há dois lados em uma avaliação: uma equipe e um cliente. Estando entre eles, o líder ou gerente da equipe é forçado a buscar um equilíbrio de interesses opostos. É impossível superestimar a estimativa, pois o cliente se recusará a pagar mais. Subestimar também não vale a pena. Nesse caso, você terá que interromper o ritmo da equipe, arriscando fadiga excessiva, desgaste e o fato de o código entrar em produção sem controle.

A profundidade do estudo da tarefa de avaliação é uma questão filosófica. As tarefas podem ser discutidas por um longo tempo, e a avaliação de todo o sprint será adiada. Mas se você não se aprofundar na essência, poderá perder algo importante que afeta o prazo.

Desenvolvedores fracos e fortes agem de maneira diferente. Se um desenvolvedor forte aprecia a tarefa, o fraco não cumprirá seus prazos. Por outro lado, os fortes tornarão a tarefa muito mais rápida do que os fracos apreciados. Considerando a diferença na velocidade do trabalho, diferentes erros "sociais" são possíveis na avaliação, por exemplo, quando um desenvolvedor fraco "espia" a que horas um avaliador avalia uma tarefa e define os mesmos prazos para não explicar por que sua "estimativa" é mais longa: " Ele ligou na semana, não posso dizer que vai demorar três? Eu vou dizer pelo menos uma vez e meia ... ".

O chamado planejamento do poker ajuda a contornar esse problema, quando toda a equipe participa da avaliação, sem saber quem será a tarefa, e a avalia cegamente, sem ver o que os colegas oferecem.


Autor: Hkniberg, da Wikipedia em inglês - Movido de en.wikipedia para o Wikimedia Commons., Domínio público Todo mundo escaneia uma

tarefa em sua cabeça. Se os termos declarados pelos membros da equipe forem muito diferentes, a discussão começará. Nesses momentos, geralmente a equipe não percebeu nenhum recurso que teria que ser implementado como parte da tarefa. Depois disso, todos voltarão a votar. E não houve alegações de que alguém tivesse estimado algo errado - todos participaram. Mesmo que haja um erro, ninguém perderá tempo procurando os culpados, haverá uma conversa mais construtiva sobre quais novos fatores apareceram e mudaram o alinhamento (e como levá-los em consideração no futuro - trabalhando com erros, escrevi sobre isso em um artigo anterior em ponto 5 ).

Uma avaliação mais precisa do projeto ajuda perguntas adicionais ao cliente. Mas aqui você pode facilmente ir longe demais. Alguns desenvolvedores não precisam fazer uma avaliação precisamente porque bombardeiam o cliente com um grande número de cartas de esclarecimento. Do ponto de vista do relacionamento com o cliente, é melhor minimizar o número de perguntas adicionais, o que aumenta a incerteza da tarefa.

Algumas dicas sobre como evitar erros

Para minimizar o erro na avaliação, sigo algumas regras simples.

Inicio uma chamada introdutória com o cliente antes de ler o ToR. Nesta ligação, peço que você fale sobre o problema do ponto de vista de quem: quem será o usuário final, como eles aplicarão o resultado, quais dispositivos estarão envolvidos (com essas permissões), como será o back-end se ele já existir, etc. Depois disso, você pode começar a ler TK.

Lendo o ToR, faço uma lista de perguntas para o cliente. Ao estudar a tarefa, você deve tentar "codificar" todo o projeto - imagine como ele será. A lista de perguntas deve ser tal que, depois de receber respostas, seja possível formar uma avaliação confiável.
A idéia principal aqui é que as perguntas não devem ser feitas gradualmente, mas de cada vez. E muitas vezes é melhor recorrer a uma lista preparada de perguntas para não esticar a correspondência. Ainda assim, o texto transmite muito menos informações. Na ligação, você pode vasculhar a tela se isso esclarecer a situação.

Se for impossível telefonar por algum motivo, estou procurando um Documento do Google, onde adicionarei essas perguntas e o cliente as responde à medida que chega a hora. Essa é uma maneira mais eficaz de se comunicar em uma tarefa do que em um bate-papo ou email pessoal. Este documento pode ser enviado posteriormente aos desenvolvedores que participarão do projeto - eles não precisarão fazer as mesmas perguntas novamente.

A propósito, é desejável que a pessoa responsável pelo projeto responda às perguntas do lado do cliente, e não o ex-secretário do diretor, que simplesmente desempenha o papel de um telefone danificado. Isso reduzirá o risco de que os parâmetros do projeto sejam alterados diretamente durante a operação.

Se possível, trago desenvolvedores para o campo.Compreender como o produto será usado na realidade ajuda a pontuar o "e" e melhorar a pontuação. Por exemplo, um software para caixas registradoras está sendo desenvolvido. E seus desenvolvedores estão sentados no computador há 15 anos e não viram o caixa nos seus olhos. Você os traz para os usuários finais, pede para fazer uma compra não em algum lugar, mas especificamente nesta loja. E eles vêem que tia Masha está sentada lá, que aperta dois botões simultaneamente com os dedos e não consegue ver as letras nos óculos no monitor. Como resultado, muitas perguntas sobre o projeto desaparecem por si mesmas - a fonte fica maior, a confirmação das operações é adicionada. É difícil imaginar essas coisas na minha cabeça. E o sentimento de realidade recebido em uma visita pessoal alimentará o desenvolvedor por mais um ano.
Infelizmente, essa imersão não é possível em todos os projetos.

Não avalio a tarefa se a condição for "e" / "ou". Por exemplo, se for proposto "fazer autorização e registro". Não há problema em dividir esse ponto em duas tarefas e avaliar cada uma delas individualmente. Essa avaliação será mais precisa, porque você não misturará entidades semelhantes, mas ainda diferentes. Quanto melhor a decomposição, mais preciso é o resultado.

"Ou" é ainda pior, é sempre idêntico ao TK desfocado, do qual é impossível criar estimativas precisas. É necessário ou não autorizar através de redes sociais? E se houver alguma API específica para o back-end? Se você não conhece os detalhes, simplesmente não pode dar uma avaliação precisa.


Figura: Michael Dubakov @ Medium

Não há avaliação de 40 horas para a tarefa.Essa é outra variação da regra anterior. O Agile recomenda decompor um projeto em tarefas de no máximo 20 horas. Não deve haver tarefas indivisíveis por uma semana de trabalho. Em pequenas porções, a estimativa é muito mais precisa.

Ao decompor uma tarefa, tento registrá-la. É útil ao mesmo tempo de dois ângulos.

Em primeiro lugar, simplifica o processo. Assim que você começa a escrever pensamentos sobre um determinado tópico, o cérebro os desenvolve com prazer. A propósito, é por isso que não recomendo que a decomposição seja misturada com a estimativa, ou seja, selecione uma tarefa e avalie cada uma delas imediatamente. É melhor dividir o projeto inteiro em componentes, corrigi-lo e avaliá-los de uma só vez, para não fazer sua cabeça funcionar em dois modos ao mesmo tempo.

Em segundo lugar, o “log” da decomposição ajuda a explicar a possível discrepância entre estimativas e realidade no futuro. De fato, você tem uma descrição completa da tarefa que está sendo formada - quais opções você considerou. Por exemplo, você levou em consideração a autorização por login e senha com um token, renovação de token etc., e o cliente, ao que parece, ainda queria autorização pelas redes sociais, apenas não escreveu sobre isso. Sua decomposição do “log” ajudará a proteger a equipe das alegações de que você apreciou algo, mas não cumpriu os prazos.

Eu ensino a equipe a não pegar as tarefas relacionadas antes que elas sejam concluídas.Os desenvolvedores gastam muito tempo com recursos adicionais. Eles autorizam, ao longo do caminho, que vêem que algo precisa ser corrigido em algum lugar, e mergulham nesse processo paralelo. Eu tento trazer um reflexo: vi uma tarefa de acompanhamento - formar um bilhete separado. Você nem precisa executar a tarefa através do líder ou gerente da equipe. Quando o líder da equipe analisa as tarefas, ele próprio as vê e as envia para resolver, se necessário. Portanto, você não precisa tirar ninguém do trabalho (criou uma tarefa e a esqueceu) e a precisão da avaliação será preservada.

Estou dando tempo para o teste.Ao avaliar, muitos esquecem dos testadores. Mas, de fato, qualquer tarefa, especialmente a mais difícil, deve passar por testes por pessoas vivas - elas devem pensar sobre isso, procurar bugs. Se eles encontrarem algo, os erros serão direcionados aos desenvolvedores que já conseguiram mudar para um contexto diferente. Eles terão que mergulhar no tópico novamente. E esse ciclo pode ser repetido mais de uma vez.
O tempo para o teste deve ser estabelecido. Como regra, essa avaliação é feita separadamente do que o desenvolvedor disse.

Levo em consideração o tempo para a programação em pares e outros recursos do trabalho.A programação em pares ajuda a trocar experiências e motivar os desenvolvedores. Eles se sentam juntos ou remexem na tela, discutem a tarefa e as ferramentas usadas e fazem algumas alterações. Essa abordagem compensa para a equipe, mas do ponto de vista do cliente, a tarefa não se move duas vezes mais rápido. Nos projetos em que trabalhei, não praticamos programação em pares constantemente, mas algumas tarefas eram convenientes para fazer exatamente isso. E levamos isso em consideração na fase de avaliação.

Da mesma forma, você precisa reservar um tempo para uma demonstração ao cliente, telefone, correspondência etc. E, em geral, para se encaixar na avaliação, o desenvolvedor deve trabalhar de forma eficiente e, para isso, precisa dormir o suficiente, descansar normalmente (e não toda a equipe de plantão no fim de semana de produção) e não dirigir o trabalho cada vez mais rápido. Portanto, a avaliação deve sempre ser baseada na prática real do trabalho, e não na previsão otimista de que todos nos sentaremos e “faremos o plano de cinco anos em três anos”.

Estou dando tempo para o cálculo do projeto. Existem quatro tipos de estandes - desenvolvimento, teste, pré-produção e produção. É melhor implantar esses estandes no início do projeto e estabelecer imediatamente esse período. Se isso não for feito, a sincronização do desenvolvimento, teste e implantação será interrompida, o que pode se transformar em uma verdadeira confusão.

Não faço avaliações de cima e de baixo - chamo um termo específico. De acordo com as regras de marketing, quando um desenvolvedor diz "de 4 a 12 horas", ele quer dizer "faça isso mais rápido que 12 horas". O cliente ouve "4 horas". Se a tarefa for concluída em 11, o desenvolvedor considerará que está tudo bem e o cliente ficará insatisfeito. Acontece que o cliente está insatisfeito, mesmo que a tarefa seja concluída em 4 horas e 15 minutos. Portanto, mesmo que uma etiqueta com um prazo mínimo e máximo seja compilada dentro da equipe (empresa) e a média seja calculada (há algum sentido nessa abordagem), apenas o resultado final é mostrado ao cliente.

Eu nomeio as datas apenas em horas - não em dias ou meses.Muitas pessoas pensam que, se o projeto for estimado em 96 horas, ele será concluído em 12 dias por 8 horas, desde que apenas uma pessoa trabalhe nele. A situação é facilmente extrapolada para dois desenvolvedores, nomeando uma classificação de 6 dias. mas isso não é verdade. Existem muitas tarefas que dependem uma da outra. Em primeiro lugar, os desenvolvedores não podem começar a trabalhar até que um modelo de projeto tenha sido criado com todos os sistemas e estandes de montagem (e são criados de 2 a 3 dias, levando em consideração os desejos do cliente). Em segundo lugar, tudo para quando há pedidos de planejamento. Em terceiro lugar, existem erros de bloqueio que impedem você de seguir em frente. Em outras palavras, 96 horas no local de trabalho não significa que 100% do tempo (8 horas por dia) seja dedicado especificamente a essas tarefas. Para avaliação em dias, podemos supor que o desenvolvedor não tenha 8, mas, digamos,6 horas de trabalho por dia (o valor exato deve ser determinado a partir da prática).

Eu sempre pergunto aos desenvolvedores quantas horas uma tarefa levará de um computador (e não "depois de quanto tempo ela estará pronta"). Isso é uma consequência do parágrafo anterior. Interagindo com a equipe como parte da avaliação, é importante formular corretamente a pergunta.

Eu levo em consideração o "coeficiente de equipe".Geralmente, os idosos de ontem vão aos timlids. Eles avaliam tarefas com base em sua experiência, mesmo que possuam intermediários em sua equipe. Talvez o idoso não trabalhe muito mais rápido, mas depois dele quase não há bugs. O meio não é essa qualidade. Portanto, no Agile, existe o chamado "coeficiente de equipe", que mostra a diferença entre o otimismo do avaliador e a vida real de uma equipe em particular. É calculado apenas na prática: uma estimativa teórica é comparada com uma real para os últimos sprints. Quanto melhor o líder da equipe conhecer sua equipe (e quanto melhor ele colocar a mão na avaliação), mais próximo esse coeficiente será de 1.

Entre outras coisas, o "coeficiente de equipe" também leva em consideração o chamado "otimismo dos desenvolvedores" na avaliação. As tarefas são sempre avaliadas com base na ausência de erros, saciedade e bom humor dos artistas, na ausência de problemas no ambiente. Mas a realidade está repleta de contingências e não há como se proteger disso. A “proporção da equipe”, calculada durante um período de tempo razoável, permite que isso seja levado em consideração.

Tentando colocar a influência da equipe, às vezes, na avaliação interna, elas passam de horas a pontos da história. Sabendo que a tarefa terá 8 pontos de história, eles lembram que na semana passada 1 ponto de história custou 8 horas. A partir disso, preveja os custos trabalhistas. Mas é mais fácil pensar em horas.

Não introduzo fatores extras para não confundir outros participantes no processo.Muitas vezes vejo pessoas conduzindo uma avaliação no nível da equipe, dando tempo para barganhar nela. Mas a unidade de avaliação não deve colocar esse estoque ou levar em consideração outras coisas estranhas. Acontece que o desenvolvedor classificou a tarefa às 8 horas, mas multiplicou por 2 por fidelidade.O Timlid dobrou sua classificação novamente, adaptando-se à equipe. E o gerente de 32 horas fez 40 para o cliente (para uma conta par ou apenas para negociar por 30 horas depois). É mais como adivinhação com base de café. Sim, e o cliente, vendo uma estimativa de 40 horas para uma tarefa de 8 horas, decidirá que a equipe não sabe como.

Como observei acima, no nível da equipe, você só precisa levar em consideração os recursos da própria equipe, concordando com quem coloca maior força na avaliação (e isso deve ser levado em conta, pois sempre avaliamos as tarefas, assumindo que o editor de código não solicite uma licença, desenvolvedores não tenha licença médica, etc.).

Firme minha posição em defender a avaliação. O corolário do parágrafo anterior - eu sempre mantenho firmemente minha avaliação. Se eu souber que o projeto será realizado por 6 meses e eles esperarem uma avaliação de 3 de mim, nunca nomeará 4 meses para "agradar" o cliente ou gerente.
Note-se que, às vezes, existem negociações internas. Quando você sabe que o projeto deve estar pronto para o Ano Novo, você inconscientemente começa a manipular os resultados da avaliação para atender ao tempo restante. O cérebro aciona essas coisas perfeitamente. Mesmo se você tiver uma lista de 200 subtarefas lá, elas convergirão de forma a atender a véspera de Ano Novo.

Apesar de tudo isso, estou pronto para a avaliação mudar. Isso é normal - os projetos vivem, se desenvolvem. Formando qualquer avaliação, entendo que essa é uma característica do projeto neste momento específico.

E a palavra final de despedida: não force os desenvolvedores que não cumprem os prazos a escreverem longas cartas aos gerentes sobre este tópico. Em primeiro lugar, é provável que sejam tímidos. Em segundo lugar, o gerente provavelmente perguntará algo e mais uma vez distrairá. Terceiro, sua carta de explicação será simplesmente perdida na correspondência. Normalmente, peço que você escreva um comentário sobre uma tarefa em Jira. Sem a participação de uma pessoa viva (gerente), geralmente é mais simples e rápido. E durante o interrogatório será fácil encontrar. E timlidu plus - todas as tarefas que estão fora da marca serão comentadas. Mais uma vez, trabalhe nos bugs para melhorar a qualidade da avaliação no futuro.

O autor do artigo: Eugene Wetzel ( @imater )

PS Publicamos nossos artigos em vários sites da Runet. Assine nossas páginas emCanal VK , FB , Instagram ou Telegram para conhecer todas as nossas publicações e outras notícias do Maxilect.