12 sinais de que você está trabalhando em uma Fábrica de Features

Publicado originalmente em 6 de janeiro de 2021.

12 sinais de que você está trabalhando em uma Fábrica de Features

A ideia de traduzir esse artigo veio depois de algumas conversas com alguns colegas brasileiros em que debatemos sobre gerenciamento de produtos, a irracionalidade de algumas metodologias e frameworks que são altamente prescritivos em quase tudo o que os desenvolvedores *precisam fazer, mas convenientemente esquecem de prescrever aspectos fundamentais de *gerenciamento de produtos como (i) satisfação do cliente final e (ii) resultados/impacto.

O resultado de tudo isso: Muito output, boss management, pessoas estressadas e sobrecarregadas, [cargo cult](https://www.youtube.com/watch?v=F42A3R28WMU), times disfuncionais, e empresas literalmente queimando dinheiro em inúmeras iniciativas que são um poço [custo de oportunidade](https://pt.wikipedia.org/wiki/Custo_de_oportunidade). O objetivo da tradução do artigo e mostrar em língua portuguesa um pouco destes sinais, em especial quando se trabalha em uma fábrica de features.

John escreve sobre gerenciamento de produtos em seu site e no Twitter. Ele escreve também no seu site chamado [Beautiful Mess](https://johnpcutler.github.io/tbm2020/) e atualmente e Head de Educação da Amplitude.

Desde já agradeço ao John pela gentileza de me deixar traduzir o seu ensaio.

12 sinais de que você está trabalhando em uma Fábrica de Features

Escrito por John Cutler (@johncutlefish) e traduzido por Flavio Clesio do artigo original chamado 12 Signs You’re Working in a Feature Factory que foi publicado em 17 de novembro de 2016.

 ([@johncutlefish](https://twitter.com/johncutlefish))

(Observação: isso foi escrito em 2016. Recentemente — no final de 2019 — escrevi um post sobre algumas coisas que aprendi desde então.)

Eu usei o termo Fábrica de Features *[NT0] em algumas conferências nos últimos dois anos. Comecei a usar o termo quando um amigo desenvolvedor de software reclamou que estava “apenas sentado na fábrica, desenvolvendo features e despachando para a linha de produção*”.

Como você sabe se está trabalhando em uma Fábrica de Features?

1. Sem mensuração do impacto em relação ao que foi feito. As equipes não medem o impacto do trabalho realizado. Ou, se a medição acontecer, ela é feita isoladamente pela equipe de gerenciamento de produto e compartilhada seletivamente. Você não tem ideia se seu trabalho deu certo;

2. Troca repentina de equipes e projetos (também conhecido como Equipe Tetris). Em vez de missões ou iniciativas convincentes e justificáveis, as equipes lidam com features e tarefas de projetos. Os times tem problemas crônicos de multitarefa e exploração/burnout [NT1];

3. *Teatro de sucesso *[NT2] em torno de “entregas” com pouca discussão sobre o impacto. Pode-se saber muito sobre uma organização de acordo com as métricas que ela celebra;

4. *Falhas reconhecidas de forma infrequente **e trabalho desperdiçado. Nenhuma *feature removida. A principal métrica de sucesso são as features entregues, e não os resultados atingidos através da feature. O trabalho raramente é descartado à luz dos dados para um posterior aprendizado. Frequentemente, a equipe não tem segurança psicológica como pré-requisito para admissão de falhas caso elas ocorram;

5. Falta de conexão com as principais métricas do negócio. Discussões sobre os desejos dos clientes e resultados do negócio são feitas de maneira esporádica. Com isso a equipe não consegue fazer a ligação entre o trabalho (esforço) aos principais indicadores do negócio, e muito menos nas métricas de satisfação dos clientes. E impossível conectar as iterações com “o que é mais importante a ser feito”;

6. Sem retrospectivas por parte da equipe de gerenciamento de produto. Os gerentes de produto não conduzem retrospectivas regulares sobre a qualidade de suas decisões de produto, ou mesmo comparam os benefícios esperados com os atingidos na realidade. Os desenvolvedores precisam que o seu software passe nos testes tanto de desenvolvimento quanto de aceitação, mas os gerentes de produto não. Os gerentes de produto veem a velocidade e produção como seus principais indicadores de desempenho;

7. Obsessão por priorização. Descompasso entre o rigor de priorização (decidir o que será trabalhado) e o rigor de validação (decidir se era, de fato, a coisa certa para se trabalhar). O rigor da priorização é projetado exclusivamente para mimar agendas internas para que as pessoas “se sintam confiantes”. Muito trabalho é necessário para determinar quais ideias serão trabalhadas, deixando pouca margem para ajustes e improvisação com baseada em dados. Os Roadmaps mostram uma lista de features, não áreas de foco e/ou resultados;

8. Sem ajustes finos. Uma vez que o trabalho está “feito”, a equipe segue imediatamente para o próximo “projeto”, sem deixar tempo para iterações (com base em dados) com foco na melhoria do produto;

9. Cultura de transferência de responsabilidades [NT3]. Enormes processos para “adiantar o trabalho” (i.e. preencher o JIRA com tickets) de forma que os itens estejam “prontos para que o time de desenvolvimento possa implementar”. A equipe de desenvolvimento não está diretamente envolvida na pesquisa, exploração do problema, ou experimentação e validação. Uma vez que o trabalho é entregue, a equipe tem pouco contato com o suporte, satisfação do cliente e com as vendas provenientes do que foi entregue;

10. Grandes lotes de features. Sem a obrigação de experimentar, as features são entregues em grandes lotes únicos, ao invés de serem entregues de forma incremental. Você pode ate trabalhar em sprints (yay, usamos “métodos ágeis”), mas nada novo é entregue aos clientes na conclusão de cada sprint;

11. Perseguição de receita de curto prazo. Features são implementados para fechar novos negócios/contratos. Embora não sejam inerentemente erradas, as justificativas econômicas costumam ser frágeis (na melhor das hipóteses) e não levam em consideração o aumento não linear na complexidade do produto (você faz o trimestre, mas paga por ele muitas vezes depois). Novamente, isso reforça a ideia de que as features são a unidade de medida de valor. As decisões de produto carecem de uma base econômica sólida;

12. Apelo ao hype **[NT4]*. Baixa visibilidade para trabalho de refatoração e redução de débitos de produto ou técnicos. Baixa visibilidade de valor geral em relação ao que foi entregue. Conforme mencionado anteriormente, a principal medida de sucesso é a entrega de novas *features. Pouca consideração pela saúde do produto como um todo em oposição a brilhantes e novas features frutos de hype. Pouca consciência sobre o impacto das novas features na usabilidade (e capacidade de manutenção e extensibilidade) do produto existente.

Notas de tradução

[NT0] — O termo original “features” será utilizado no lugar de “funcionalidades” devido ao fato de que este anglicismo é muito comum tanto em times de desenvolvimento de software, engenharia e gerenciamento de produto.

[NT1] — O termo original “over-utilization” pode ser traduzido superutilização, mas como estamos falando de contexto de software e de times de pessoas, o termo exploração me pareceu o mais adequado.

[NT2] — Do original “Success Theater” em que times com baixo desempenho celebram de forma teatral métricas irrelevantes que por algum motivo mostram alguma performance, mas que na verdade não tem nenhum impacto prático. Ex: Aumento de trafego de 25% (métrica supostamente boa) depois de aumento de investimento em marketing de 10% (o quanto tudo custou a mais) mas com vendas estagnadas em 1% (a métrica que realmente importa).

[NT3] — Do original “hand-offs”. Isso significa quando o trabalho passa de muitas mãos em que cada parte e pouco envolvida ao longo de todo o processo. Semelhante a um trabalho em linha de produção em que cada elemento da linha é apenas responsável por uma parte e não tem conhecimento do todo.

[NT4] — O termo “Shiny Objects” tem como tradução direta como “Objetos brilhantes”, mas não é uma expressão comum em PT-BR. Como o post foi escrito em 2016 eu resolvi adaptar e colocar a palavra hype apenas para dar um pouco mais de contexto de algo que soa como “novinho em folha e que tem um alto apelo” para quem estiver lendo em PT-BR.