Boas Práticas de Colaboração com Produto
Produtos Solana falham devagar quando engenharia e produto falam línguas diferentes: "ship sexta" vs "auditoria bloqueou". Estas práticas alinham roadmaps, specs e comunicação sem transformar engenheiros em máquinas de ticket ou PMs em revisores acidentais de segurança.
Como Usar Esta Lista
- Revise no kickoff eng+produto a cada trimestre
- Referencie no sprint planning quando a fricção subir
- Item de leitura de onboarding de PM novo
A - Discovery & Specs
- Sem commit de sprint sem tech spec escrita ou stub de RFC. Mesmo one-pager para features pequenas.
- Produto define resultado do usuário e métrica de sucesso. Engenharia define mudança de estado on-chain.
- Seção de non-goals obrigatória. Evita integrações CPI do tipo "já que você está aqui".
- Mudanças de tokenomics incluem modelo de autoridade. Multisig vs governança vs imutável.
- Design review agendado antes de finalizar estimativa. Para qualquer toque em fundos do usuário.
B - Planejamento & Estimativas
- Estimativas de três pontos compartilhadas com PM. Otimista / provável / pessimista visíveis.
- Buffers de auditoria e deploy fora da estimativa da feature. Nomeados no slide de roadmap.
- 20% de capacidade para harden/plataforma visível no roadmap. Não trabalho secreto de eng.
- Grafo de dependências compartilhado internamente. Cliente bloqueado em IDL visível para PM.
- Gatilho de re-estimativa definido. Mudança de spec, auditoria Sev-High, spike falhou.
C - Execução & Comunicação
- Sync semanal eng-produto 30 min. Bloqueadores, não leitura de status.
- Demo inclui link do explorer ou fluxo de carteira. Demos só de slides insuficientes.
- Comandante único de incidente aprova posts externos. PM e eng alinhados nos fatos.
- Anúncios de atraso incluem trade-off e próximo checkpoint. Sem slip silencioso.
- Status de auditor no tracker compartilhado. PM não surpreendido por escalação da firma.
D - Confiança & Cultura
- Disagree-and-commit documentado. PM é dono da aposta do usuário; tech lead é dono do piso de segurança.
- Near-misses discutidos no retro sem culpa. Produto incluído mensalmente.
- Engenheiros convidados a calls de cliente/comunidade periodicamente. Empatia com ground truth.
- PM não compromete data mainnet sem gate devnet-done de eng.
- Vitórias incluem marcos de segurança e ops no all-hands. Não só GIFs de feature.
FAQs
Profundidade técnica do PM necessária?
Suficiente para ler specs e fazer perguntas inteligentes; security review fica com engenharia.
Quem é dono do roadmap?
PM prioriza resultados; tech lead injeta harden/scale com veto em gates de segurança.
Resolução de conflito?
ADR para fork técnico; exec para data vs segurança com risk memo escrito.
Produto DAO?
Fórum de governança para params; blog de eng para implementação - PM faz ponte entre os dois.
Colaboração remota?
Specs escritas sobre verbal; grave design reviews para PM async em outro fuso.
Métricas compartilhadas?
DORA + métricas de usuário no mesmo slide de QBR - conecte entrega a resultados.
Papel do produto em feature flags?
PM define cohort de rollout; eng implementa guards on-chain + cliente.
Quando PM na bridge de incidente?
Papel de líder de comms; não todo par eng-PM - rotacione treinamento.
Design terceirizado?
PM ainda assina aceitação da spec antes do build de eng.
Primeiros 90 dias de PM novo?
Leia ADRs, participe de drill de incidente, ship uma feature devnet pequena em pair com eng.
Relacionado
- Requirements to Technical Specs - qualidade da spec
- Stakeholder Communication - alinhamento externo
- Leadership Best Practices - lado do tech lead
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.