O que quase cinco anos em compras me ensinaram sobre requisitos de produto

Comecei a carreira em compras e suprimentos em 2018, como aprendiz. Passei por Manserv, Autometal, CATA e PKG Brasil antes de fazer a transição para tecnologia, em 2023. Desde 2024 sou Product Owner na NVGO.

Quando conto isso, a reação costuma ser de surpresa, como se fossem mundos sem relação. Mas a verdade é que o trabalho central é o mesmo: alguém tem uma necessidade, descreve essa necessidade do jeito que consegue, e o meu papel é transformar isso em algo que pode ser entregue sem surpresas.

Estes são os aprendizados de compras que mais uso hoje.

1. O pedido não é a necessidade

Uma requisição de compra diz o que a pessoa acha que precisa, não o problema que ela quer resolver. Analisando requisições, aprendi a perguntar "para que vai ser usado?" antes de "qual a especificação?". Muitas vezes a resposta mudava o item, a quantidade ou o prazo.

Em produto é igual. Quando um cliente pede um botão, uma tela ou um relatório, a pergunta que vale é o para quê. É por isso que a parte mais importante de uma user story não é o "eu quero", é o "para que".

2. Especificação ambígua custa caro, e o custo chega depois

Em compras, um requisito mal descrito vira um item errado chegando semanas depois, com prazo perdido, devolução e retrabalho. O erro é barato de evitar na especificação e caro de corrigir na entrega.

Em software, o equivalente é a funcionalidade que passa no desenvolvimento e é rejeitada na homologação. Critérios de aceite são a minha versão da especificação técnica de compras: o que precisa ser verdade para que a entrega seja aceita.

3. Cada área acha que a sua prioridade é a mais urgente

Na CATA, fui o ponto focal entre três unidades, em Camaçari, Mata de São João e Rondonópolis, no abastecimento do almoxarifado. Cada unidade tinha as suas urgências, e todas eram legítimas. O trabalho era alinhar demandas e prioridades sem que ninguém sentisse que tinha sido ignorado.

Priorizar backlog com vários stakeholders é exatamente isso. Não dá para atender todos ao mesmo tempo, então a priorização precisa de critérios claros e visíveis, e não de quem pediu mais alto.

4. Negociar é equilibrar prazo, custo e qualidade

Na PKG Brasil, eu traduzia requisitos técnicos e de qualidade das áreas em especificações e negociava com fornecedores para atendê-los. Toda negociação tinha o mesmo triângulo: dá para ser mais rápido, mais barato ou melhor, mas raramente as três coisas.

Hoje negocio escopo com clientes e com o time de desenvolvimento. É o mesmo triângulo. A diferença é que, em produto, o trade-off precisa ser documentado, para que todo mundo saiba do que se abriu mão e por quê.

5. Estoque parado também é desperdício, e backlog é estoque

Na Autometal, cuidei do estoque de itens não produtivos (MRO). Estoque em excesso parece segurança, mas é dinheiro parado, item que envelhece e espaço ocupado.

Backlog funciona igual. Uma lista enorme de histórias escritas com antecedência parece planejamento, mas boa parte delas envelhece antes de ser feita. Prefiro manter detalhado só o que está perto de entrar no desenvolvimento.

O que a transição me trouxe de novo

Compras me deu a base de requisitos, negociação e stakeholders. A transição para tecnologia, com desenvolvimento web, banco de dados, infraestrutura e metodologias ágeis, me deu a outra metade: entender como a solução é construída, para conversar de igual para igual com o time técnico.