Falando com não tecnologistas: os motivos de todo time de tecnologia parecer lento
Olá!
Hoje quero falar sobre um conflito que, na minha percepção, é praticamente onipresente: a percepção por pessoas de fora da área de que times de tecnologia são lentos. Se você trabalha com produto, provavelmente já sentiu essa frustração. Mas será que o problema é realmente a velocidade do time? Ou será que estamos olhando para os incentivos errados?
Eu já adianto que tentei enxugar ao máximo o texto, porém, para melhorar o entendimento, dê uma atenção especial às referências externas, nelas estarão conceitos relacionados se você quiser se aprofundar.
Um panorama geral do que influencia a velocidade de um time de tecnologia
Se o seu time de tecnologia parece lento, é provável que isso tenha mais a ver com problemas sistêmicos do que com a capacidade dos engenheiros em si, por incrível que pareça.
Não estou negando que existam profissionais ruins na área de tecnologia, mas, de uma maneira geral, a cultura e os sistemas de incentivos acabam tendo um impacto muito maior do que vontades individuais.
Se você quer saber o motivo qual eu digo isso, a explicação do porquê o impacto máximo de uma pessoa em um sistema é de no máximo 6% está aqui.
Incentivos internos e o mercado
O time de tecnologia não opera isolado, ele responde a incentivos internos (na forma de especificações do time de negócio, cultura e metas) e externos (seja concorrentes, flutuações de mercado, taxas de juros, etc).
Em se tratando de incentivos de controle da empresa, se as prioridades mudam o tempo todo ou se há pressão por entregas sem fundamentação, a eficiência vai cair.
E quando eu digo “sem fundamentação”, entenda que as causas podem ser inúmeras, mas as principais costumam ser:
Má comunicação: se algo é importante a ponto de ser feito de forma corrida para o negócio não explodir, isso tem que ser trazido de forma clara pela gestão para o time. A maioria das pessoas sabe agir como adultos em face de uma crise. Agora, o que não funciona é uma gestão baseada em pressa, isso sim deixa as pessoas doentes. Mais detalhes aqui.
HIPPO: a comunidade ágil popularizou esse termo, que significa Highest Paid Person Opinion. Basicamente, é quando alguém ganha uma discussão simplesmente porque tem o salário mais alto.
Silos: em culturas com alto grau de hostilidade interna, geralmente as pessoas envolvidas se fecham em suas respectivas áreas e não interagem e/ou ajudam outras áreas. Isso gera produtos míopes, que são pensados de forma isolada ao invés de integrada. O resultado sistêmico (e o impacto no time de tecnologia), é explicado pela Lei de Conway.
Conceitos multidisciplinares relacionados
Existem alguns conceitos relevantes de outras áreas do conhecimento que explicam satisfatoriamente a maior parte das dinâmicas envolvidas em um time ser lento. Vou comentar brevemente sobre cada um deles.
Ciclo de feedback com atraso: entenda feedback nesse ponto como “resultado de algo”, ao invés da técnica popular de gestão de falar pontos a melhorar em pessoas.
Em um sistema complexo, decisões tomadas hoje podem demorar meses ou até anos para ter suas consequências percebidas. A metáfora é fácil de entender: se você negligenciar exercícios e boa alimentação hoje, você só irá sentir os impactos após sair da juventude. A mesma coisa acontece com sistemas feitos sem levar em consideração impactos de longo prazo. As consequências de decisões ruins de processos, negócios e tecnologia muitas vezes só são sentidas alguns anos depois, na maioria dos casos, dado a rotatividade das empresas, são sentidas por pessoas que nem estavam lá no momento da decisão ruim.
Esse conceito é de uma disciplina dentro da administração chamada Pensamento Sistêmico. Eu introduzo esse conceito aqui se você quiser se aprofundar.
Só um detalhe: se eu tivesse que escolher uma única habilidade a ser aprendida por trabalhadores do conhecimento, seria desenvolver essa percepção de consequências. Tamanha é a importância desse tópico no entendimento de como o mundo funciona.
Leis de potência: um padrão comum observável na natureza é o seguinte: poucas causas para muitos efeitos diferentes. Um nome popular para isso é o princípio de Pareto.
Isso é bem verdade em empresas. Geralmente, o time de tecnologia é impactado por poucas coisas, mas que são muito significativas (como uma pessoa tóxica na liderança, falta de planejamento, ninguém prioriza dívidas técnicas, etc). Mais detalhes do impacto dessas leis de potência aqui.
A mensagem neste ponto é simples: para um impacto relevante, resolver poucas causas estruturais costuma funcionar melhor.
Cultura do herói: se a solução para os problemas é sempre um “esforço extra” de algumas poucas pessoas, a absorção desses problemas está mascarando problemas estruturais. Portanto, se isso acontece onde você trabalha, é uma disfunção que precisa ser resolvida. Essa é a principal causa de burnout em profissionais de tecnologia. A famosa cultura do “apagador de incêndio” precisa ser eliminada e não incentivada.
Falta de letramento digital e técnico: Se o time de produto não entende conceitos básicos de tecnologia e processos, as decisões serão mal informadas. O time de tecnologia até pode tentar explicar alguns conceitos mais complicados. Mas a responsabilidade de saber o mínimo de como os sistemas funcionam é sua. Você não precisa saber como projetar uma arquitetura distribuída, mas entender o básico de convenções comuns (como boas práticas de UX), lógica de fluxo e o básico do que dá para fazer com cada tecnologia, é o mínimo necessário.
Agilidade: entender a importância da gestão visual do trabalho, identificação de gargalos e estimativas baseadas em estatística (e não em achismo) é obrigatório.
Só um comentário nesse ponto: seres humanos não sabem estimar em horas e sim em esforço. Ou seja. é mais fácil para as pessoas pensarem em uma tarefa em termos de pequena, média, grande ao invés de 2,5 horas ou 3 dias e meio.
Portanto, qualquer pergunta do tipo: quanto tempo isso vai levar? Está sendo feita do jeito errado. Se você quer saber porque os métodos tradicionais (story points e pontos de função) não funcionam bem, está aqui (mito #20). A abordagem correta seria o seguinte: estimar as tarefas de forma padronizada e usar estatística para extrair previsões é MUITO mais assertivo.
Nesse texto eu comento sobre agilidade como um todo e neste outro eu comento sobre o sistema Toyota e o que uma coisa tem a ver com a outra.
Cultura importa muito: eu entendo que boa parte do comportamento das pessoas nas empresas é por causa das punições que recebem ao fazer ou propor determinadas ações. Ao longo do tempo, as pessoas aprendem o que fazer ou evitar naquele ambiente. Portanto, se você quer de fato entender os mecanismos e tipos de cultura para saber como lidar melhor com as idiossincrasias da sua empresa e como ser mais efetivo(a) no seu trabalho, esse texto aqui é fundamental.
Erros comuns do time de produto
Resolver os problemas errados: eu costumo explicar esse ponto com a seguinte piada:
Você chega em casa e encontra o cônjuge no sofá com outra pessoa. O que você faz?
Simples! Você vende o sofá.
Em empresas, um outro termo para explicar essa abordagem de resolver os problemas errados chama-se Teoria do Cavalo Morto. A explicação é essa.
Em vez de agir como intermediário de solicitações do negócio, o time de produto deveria focar em entender e resolver problemas reais. Ao meu ver, é nessa aplicação de expertise de análise e modelagem de uma solução de negócio que o valor de ter um produteiro reside.
Caso a situação fique nesse marasmo de tiragem de pedidos resolvendo os problemas errados, é óbvio que o time de tecnologia irá parecer incompetente e lento.
Pense nos casos que podem dar errado: essa é uma frustração de muitas pessoas desenvolvedoras que eu conheço. Não basta apenas planejar para o “caminho feliz“ no desenho de um produto. A responsabilidade nesses casos é compartilhada entre produto, tecnologia e QA. Mas, em produtos digitais, ser um pouco pessimista e antecipar o que pode dar errado é uma abordagem que costuma funcionar.
Tá, mas o que fazer então?
Se queremos resolver o problema da “lentidão”, precisamos mudar a abordagem, para começo de conversa. Gostaria que você — produteiro — se enxergasse como parte da engrenagem que gera insumos para um time de tecnologia.
Experimente fazer os pontos abaixo:
Produto só vira produto com hipótese validada: Se não há evidência de que algo é necessário, por que estamos construindo? Se o time de tecnologia é alocado em tarefas inúteis sem validação de hipótese (ou seja, sem dados que comprovem a necessidade de desenvolvimento), obviamente vai parecer para quem olha de fora que eles são lentos.
Discoveries precisam ser rápidos: A abordagem incremental recomendada pela agilidade de pequenas mudanças + iterações rápidas (diminuindo os ciclos de feedbacks com atraso) deveria ser mais aplicada. Demorar meses validando uma ideia gera mais entropia do que resultados. Geralmente, não é falta de tempo de discovery e sim, excesso de tempo gasto validando um problema errado.
O resumo seria algo como: a demanda é o que importa. Se as pessoas de fato querem a sua ideia, é fácil validar isso. Você não precisa gastar 6 meses perguntando para centenas de pessoas se elas querem aquilo, isso é desperdício de energia.
Ah, isso resolve top-down também. Executivo funciona muito da seguinte forma: se ninguém resolveu, eu resolvo. Logo, se você está demorando a se comprometer com alguma decisão, alguém vai decidir por você.
Se seu time de tecnologia está focado em fazer análises, ele não está entregando features: Tecnologia é um meio para um fim. Se o foco for só análise, as entregas ficam em segundo plano. Uma das formas de se melhorar isso é ter um analista de dados a tiracolo de um produteiro. Como isso não é possível por questões de custo, letramento digital em dados (principalmente SQL) é uma abordagem importante. Quanto mais independente você for, mais rápido seu time de tecnologia vai andar. Letramento digital não é opcional. Se você trabalha com produto e não sabe extrair insights dos dados, está tomando decisões no escuro (o que nos leva de volta à situação de resolver os problemas errados).
TL;DR
- A lentidão dos times de tecnologia é mais influenciada por fatores como mudanças constantes de prioridade, má comunicação, HIPPO, silos organizacionais e falta de entendimento técnico por parte do time de produto do que má-vontade ou incompetência.
- Conceitos como pensamento sistêmico, ciclos de feedback com atraso, leis de potência e cultura do herói explicam por que más decisões têm efeitos que só são percebidos com atraso e como resolver poucas causas estruturais pode ter grande impacto.
- Para melhorar a eficiência, times de produto devem validar hipóteses antes do desenvolvimento, acelerar processos de discovery, evitar a cultura do “apagador de incêndio” e adquirir letramento digital para tomar decisões baseadas em dados. O problema não é apenas da tecnologia, mas sim da forma como a empresa define e gerencia suas demandas.
Espero que este texto seja útil para você de alguma forma.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
