|
Produto e Engenharia precisam ter objetivos comuns e precisam trabalhar juntos rumo a esse objetivo. Já falei em outra edição que um erro comum é ter OKRs de Engenharia e OKRs de Produto como coisas separadas. Um atrito muito comum é ouvir da área de Produto que "Engenharia não entrega" e ouvir da área de Engenharia que "Produto não sabe o que quer". Isso não pode acontecer na sua empresa! Se esse pensamento passar pela sua cabeça, e ele vai passar, respire fundo e converse abertamente com seu par da outra disciplina. "João, estou preocupado que não estamos entregando rápido o bastante. Você sente a mesma coisa? Como eu posso ajudar?" Essa pergunta não deveria soar como cobrança e deveria fomentar uma discussão construtiva sobre como aumentar a velocidade (ou a percepção de velocidade) de entrega do time. De repente acabaram de entrar pessoas novas que ainda estão conhecendo o código e o produto? Ou PM poderia deixar mais claros alguns critérios de aceite? Ou é hora de fazer algumas modificações pra melhorar a organização de trabalho do time? Ou é apenas um problema de percepção? Produto é responsável por 80% do Discovery e 20% do Delivery. Engenharia é responsável por 80% do Delivery e 20% do Discovery. Um não vive sem o outro. Produto e Engenharia são 100% responsáveis pelo produto que vai chegar nas mãos do cliente. |
Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.
Durante los últimos meses construí un proyecto personal usando Claude como mi principal herramienta de desarrollo. La idea parecía simple: Crear una quiniela del Mundial donde los participantes hacen todos sus pronósticos antes de que empiece el torneo, como hacíamos en Excel hasta hace poco. El software estuvo listo mucho más rápido de lo que imaginaba. Pero lo más interesante fueron los aprendizajes a lo largo del camino. Algunos de ellos: Los tests son obligatorios. En un momento decidí...
Nos últimos meses construí um projeto pessoal usando Claude como principal ferramenta de desenvolvimento. A ideia parecia simples: Criar um bolão da Copa do Mundo onde os participantes fazem todos os palpites antes do torneio começar, como fazíamos em excel até pouco tempo atrás. O software ficou pronto muito mais rápido do que eu imaginava. Mas o mais interessante foram os aprendizados ao longo do caminho. Alguns deles: Testes são obrigatórios. Em um momento eu decidi que iria ler todos os...
Uma ideia muito forte do Uncle Bob sobre IA: “Sem restrições, os agentes fazem qualquer coisa.” Por isso ele insiste muito na criação de “physical barriers”. Ou seja: mecanismos concretos que limitam o que a IA pode fazer dentro do sistema. O checklist que ele sugere é interessante: unit tests com cobertura extremamente alta (os agentes usam os testes para entender o comportamento esperado do sistema) acceptance tests escritos em Gherkin/BDD (testes legíveis por humanos funcionando como...