O puffin (puffin em inglês) é um perfil que, liderando uma equipe de desenvolvedores, possui infinitas funções de software com pouco ou nenhum impacto no negócio, clientes ou demais colaboradores.
A PUFFIN —(Planeja iniciativas intermináveis de fábrica de recursos), em espanhol seria equivalente a planos infinitos de iniciativas de recursos.
Este termo de perfis supõe custo e nenhum benefício, além de uma grande frustração das equipes que não possuem visibilidade na organização.
O termo Feature Factory surgiu quando um desenvolvedor de software amigo meu reclamou que ele estava "apenas sentado na fábrica, construindo recursos e enviando-os para outros desenvolvedores".
Como saber se você está trabalhando em uma fábrica de funções? Existem sintomas claros que permitem identificar essas estruturas.
- Sem custo financeiro Métricas. As equipes não precisam medir o impacto de seu trabalho. Ou, se a medição for feita, ela é feita isoladamente pela equipe de gerenciamento de produtos e compartilhada seletivamente. Não se sabe se o trabalho realizado funcionou corretamente.
- Mistura rápida de equipes e projetos (também conhecido como Team Tetris). Em vez de missões ou iniciativas sensatas e compreensíveis, as equipes lidam com atribuições de funções e projetos sem saber por que ou quem deve ser responsável pelo quê. Multitarefa em todas as operações e uso excessivo de recursos.
- teatro de sucesso em torno do “transporte” com pouca discussão sobre impacto. Muito pode ser dito sobre uma organização pelas questões que ela comemora.
- Falhas infrequentes (reconhecidas) e trabalho descartado. Sem eliminar ou melhorar significativamente as funções anteriores. A principal medida de sucesso são os recursos entregues, não os resultados entregues. O trabalho raramente é dispensado à luz dos dados e do aprendizado. O equipamento carece da medida necessária para admitir falhas de produção.
- Nenhum link para métricas de negócios. Conversas sobre clientes ou resultados de negócios não existem ou são infrequentes. A equipe não consegue relacionar o trabalho com as principais métricas de negócios e satisfação do cliente. Não é possível conectar o trabalho com lou negócios substanciais.
- Sem análise de impacto. Os gerentes de produto não revisam periodicamente a qualidade das decisões de produto e, portanto, não comparam os benefícios esperados com os benefícios reais alcançados. Os desenvolvedores têm "requisitos aprovados", mas os gerentes de produto não têm metas de negócios. Apenas a velocidade e a produção são levadas em consideração como um indicador-chave de desempenho
- Obsessão por priorização. As discrepâncias aparecem entre o rigor da priorização (decidir sobre o que trabalhar) e o rigor da validação (decidir se, de fato, era a coisa certa a se trabalhar). O rigor da priorização é projetado exclusivamente para temperar as agendas internas para que as pessoas "se sintam seguras". Muito trabalho é feito para determinar quais ideias trabalhar, deixando pouco espaço para ajustes e improvisações baseados em resultados. Roteiros, planos, mostram uma lista de recursos, não áreas de foco e/ou entregas.
- sem ajustes. Uma vez que o trabalho é "feito" (de acordo com os princípios dos gerentes de desenvolvimento), a equipe imediatamente passa para o próximo "projeto", não deixando tempo para iterar com dados qualitativos e quantitativos que levem a melhorias e planos de melhoria.
- Cultura de transferência da entrega. A equipe não está diretamente envolvida na pesquisa, exploração dos problemas/desafios a serem enfrentados ou experimentação e posterior validação. Uma vez concluído o trabalho, o desenvolvedor tem pouco contato com o suporte, a satisfação do cliente e os resultados do negócio.
- Ótimos conjuntos de pacotes. Sem o mandato de experimentar, os recursos são entregues em grandes pacotes de recursos, em vez de versões incrementais. Se a metodologia for aplicada ágil, pode ser que, ainda trabalhando em sprints, mas nada de novo chegue aos clientes ao final de cada entrega.
- Busque renda com antecedência. As funções são implementadas para fechar novos negócios pontuais. Embora essa abordagem não seja inerentemente errada, as justificativas econômicas geralmente são fracas (na melhor das hipóteses) e não levam em consideração o aumento não linear na complexidade do produto (benefícios de curto prazo que se acumulam posteriormente). ). Novamente, reforça-se a ideia de que as características são a unidade de medida do valor. As decisões sobre produtos carecem de uma visão e estratégia econômicas sólidas.
- projetos "estrelas". A entrega constante de novos recursos ofusca outros tipos de iniciativas necessárias. Trabalhos de reengenharia, redução de custos e entrega de valor têm pouca visibilidade. Concentrar-se nesses recursos estrela diminui as tarefas sobre o impacto dos novos recursos na usabilidade, manutenção, escalabilidade e assim por diante.
