Mejores Prácticas de Colaboración de Producto

Los productos de Solana fallan lentamente cuando ingeniería y producto no se entienden: "lanzar el viernes" vs "auditoría bloqueada". Estas prácticas alinean roadmaps, especificaciones y comunicación sin convertir a los ingenieros en máquinas de tickets ni a los PMs en revisores de seguridad accidentales.

Cómo Usar Esta Lista

• Revisar en el kickoff de ingeniería + producto cada trimestre.
• Referenciar en la planificación del sprint cuando aumente la fricción.
• Elemento de lectura para la incorporación de nuevos PMs.

A - Descubrimiento y Especificaciones

• No comprometer sprint sin especificación técnica escrita o borrador de RFC. Incluso un documento de una página para características pequeñas.
• Producto define el resultado del usuario y la métrica de éxito. Ingeniería define el cambio de estado en la cadena.
• Se requiere sección de no-objetivos. Previene integraciones CPI de "ya que estás en ello".
• Los cambios en tokenomics incluyen el modelo de autoridad. Multisig vs gobernanza vs inmutable.
• Revisión de diseño programada antes de la finalización de la estimación. Para cualquier toque de fondos de usuario.

B - Planificación y Estimaciones

• Estimaciones de tres puntos compartidas con el PM. Optimista / probable / pesimista visibles.
• Buffers de auditoría y despliegue fuera de la estimación de la característica. Nombrados en la diapositiva del roadmap.
• 20% de capacidad para endurecimiento/plataforma visible en el roadmap. No trabajo secreto de ingeniería.
• Gráfico de dependencias compartido internamente. El cliente bloqueado en IDL es visible para el PM.
• Se define el disparador de re-estimación. Cambio de especificación, auditoría Sev-High, spike fallido.

C - Ejecución y Comunicación

• Sincronización semanal de ingeniería-producto de 30 minutos. Bloqueos, no lectura de estado.
• La demo incluye enlace al explorador o flujo de billetera. Las demos solo con diapositivas son insuficientes.
• Un único comandante de incidentes aprueba las publicaciones externas. PM e ingeniería alineados en los hechos.
• Los anuncios de retraso incluyen el compromiso y el próximo punto de control. Sin deslizamientos silenciosos.
• Estado del auditor en un rastreador compartido. El PM no se sorprende por la escalada de la firma.

D - Confianza y Cultura

• Desacuerdo y compromiso documentado. El PM posee la apuesta del usuario; el líder técnico posee el piso de seguridad.
• Casi accidentes discutidos en la retrospectiva sin culpas. Producto incluido mensualmente.
• Ingenieros invitados a llamadas de clientes/comunidad periódicamente. Empatía de verdad.
• El PM no se compromete con la fecha de mainnet sin la puerta de enlace devnet-done de ingeniería.
• Las victorias incluyen hitos de seguridad y operaciones en las reuniones generales. No solo GIFs de características.

Preguntas Frecuentes

Relacionado

• Requisitos a Especificaciones Técnicas - calidad de la especificación
• Comunicación con Stakeholders - alineación externa
• Mejores Prácticas de Liderazgo - lado del líder técnico

Versiones de Stack: Esta página fue 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, y LiteSVM 0.6.x.