Cada uno a su manera
Capyvara tiene dos productos y un equipo pequeño y mixto: desarrolladores, diseño, personas de negocio y estudiantes al inicio de su carrera. Cada uno trabajaba a su manera, y lo que definía si algo estaba "listo" era la opinión de quien lo hizo.
En un equipo así, el riesgo no es la falta de talento. Es que cada entrega dependa de quién se acordó de probar, de quién revisó y de quién sabía cómo publicar.
Un estándar para todo PR
El primer paso fue escribir lo que hasta entonces vivía en la cabeza de las personas. Creé el baseline de ingeniería de la plataforma y una plantilla de PR obligatoria. Todo PR pasó a decir qué cambió y por qué, a pasar por un checklist de permisos y de fallas esperadas, a registrar las pruebas hechas con y sin permiso, y a traer el impacto y las evidencias.
Especificación antes del código
Después adopté el desarrollo guiado por especificación. Cada funcionalidad empieza como una spec con criterios de aceptación, que luego se convierte en un plan y una lista de tareas. Para que el tablero de trabajo no se despegara de la spec, automaticé la publicación de esas tareas como tarjetas en Trello, con responsable, labels y una reejecución que no duplica tarjetas ya abiertas. El tablero pasó a reflejar la spec, y no al revés.
Un solo camino hasta producción
Organicé el flujo de desarrollo, homologación y producción por PRs, para que nada llegara al cliente sin pasar por el entorno de pruebas. También hice que el pipeline comente en el propio PR el fragmento del log y la lista de fallas cuando algo se rompe. Así, cualquier persona del equipo, incluso quien está empezando, entiende qué salió mal sin tener que pedir ayuda.
Antes de un lanzamiento, escribí un dictamen de preparación con el estado real del producto: qué estaba listo, qué no, y un plan día a día hasta la decisión de lanzar o no.
Prioridades con criterio
También estandaricé cómo registrar deudas técnicas y pedidos de producto: prioridad, impacto, a quién le duele, esfuerzo y qué hacer. Con eso, la conversación sobre qué hacer primero se convirtió en una comparación entre tarjetas, y no en una competencia de quién habla más fuerte. Conduje reuniones con usuarios y clientes y convertí su feedback en historias con criterios de aceptación, separando lo que era ajuste de interfaz de lo que era decisión de producto.
El conocimiento fuera de una sola cabeza
Para que el equipo no dependiera de mí, documenté el onboarding de QA, el proceso de publicación, un mapa de conocimiento del producto y los registros de decisión. Del lado del cliente, escribí el documento de criterios de éxito con un cliente del sector público y los indicadores de éxito del producto.
Qué cambió
El equipo pasó a tener una definición común de listo, escrita en la plantilla de PR. Las entregas pasaron por un único camino hasta producción, con homologación en el medio y una decisión de lanzamiento basada en evidencia. Y la planificación quedó trazable, de la spec a la tarjeta y de la tarjeta al PR.
Lo que me llevo
Las buenas prácticas solo prenden cuando cuestan menos que no seguirlas. Un checklist en la plantilla de PR, un pipeline que explica su propia falla y tarjetas generadas a partir de la spec funcionaron mejor que cualquier conversación sobre disciplina.
Liderar un equipo pequeño es, en buena parte, decidir qué no hacer ahora, y dejar esa decisión escrita, con criterio, para que todos la vean.