Servicios01 / 07

Equipos que sostienen lo que construyen

La mayoría de los equipos que encuentro no tienen un problema de talento: tienen un problema de criterio compartido. Cada persona decide bien por su cuenta y el conjunto avanza en direcciones ligeramente distintas, hasta que integrar cuesta más que construir. Eso no se arregla con una herramienta nueva ni con más reuniones; se arregla haciendo explícito lo que hasta ahora vivía en la cabeza de dos o tres personas.

Mi trabajo aquí es dejar el criterio escrito y practicado. Escrito, en forma de especificaciones, ADRs y estándares que se pueden discutir y cambiar. Practicado, en revisiones de código donde se explica el porqué y no solo el qué. El objetivo declarado de cada acompañamiento es volverse innecesario: si a los seis meses el equipo sigue dependiendo de mí para avanzar, hice mal el trabajo.

Trabajo especialmente bien con equipos de plataforma y de pagos, donde una decisión de diseño equivocada no produce un bug visible sino una discrepancia contable que aparece un trimestre después. En esos contextos el liderazgo técnico no es motivacional: es la disciplina de escribir lo que se va a construir antes de construirlo.

Formato
Acompañamiento
Equipo
15 personas
Eficiencia
+40%
Entrega
−60%
Escribirme
Alcance

¿Qué involucra?

  1. 01Mentorización de equipos de desarrollo
  2. 02Establecimiento de estándares técnicos
  3. 03Planificación estratégica de tecnología
  4. 04Gestión de equipos multidisciplinarios
  5. 05Optimización de procesos de desarrollo
Método

¿Cómo se aborda?

  1. Paso 01

    Diagnóstico del sistema y del equipo

    Reviso el repositorio, el pipeline y el tablero antes que las personas. El código dice cómo se decide de verdad: dónde hay pruebas, dónde hay parches, qué se toca con miedo. De ahí sale un mapa de riesgos técnicos ordenado por lo que cuesta si falla, no por lo que molesta.

  2. Paso 02

    Spec-Driven Development como norma

    Antes de escribir código se escribe la especificación: qué problema resuelve, qué invariantes debe mantener, qué queda explícitamente fuera. SDD parece burocracia hasta que evita la tercera reimplementación de la misma regla de negocio. Cada decisión estructural queda además como ADR fechado, así que dentro de un año se sabrá por qué se hizo así.

  3. Paso 03

    TDD donde el costo del error es alto

    No pido cobertura por cobertura. Pido pruebas donde el dinero cambia de manos: cálculo de comisiones, conciliación, idempotencia de reintentos. Ahí el test se escribe primero, porque es la única forma de saber que la regla quedó entendida antes de codificarla. En el resto, pruebas de contrato e integración que sí atrapan regresiones reales.

  4. Paso 04

    Ceremonias que producen especificación

    El kickoff se transcribe y produce un borrador; el refinamiento lo convierte en especificación aprobada. Suena a proceso añadido y en la práctica quita trabajo: elimina el acta que nadie escribe y la discusión que se repite dos semanas después.

  5. Paso 05

    Traspaso y medición

    El acompañamiento termina con el equipo tomando decisiones sin mí, y eso se mide: tiempo de ciclo, tasa de fallo en despliegue, tiempo de recuperación. Son las métricas DORA, y sirven porque no se pueden actuar sin cambiar de verdad cómo se trabaja.

Ciclo de entrega asistido

Del kickoff transcrito al punto de capacidad

Lo que se acuerda hablando en un kickoff se pierde. Dos semanas después nadie recuerda por qué se descartó la alternativa obvia, y la discusión se repite entera. La primera pieza del ciclo es simple: la reunión se transcribe y de ahí sale un borrador de especificación —qué se dijo, qué se decidió, qué quedó abierto—. No es la especificación final; es el acta que nadie iba a escribir.

Ese borrador entra a la ceremonia de refinamiento y ahí se corrige con el equipo. Es la parte que no se puede saltar y donde la regla es la de siempre: la IA prepara, el equipo decide. Se marcan los invariantes, se parte lo que es demasiado grande, se descarta lo que se coló mal transcrito. Lo que sale aprobado ya es una especificación de verdad.

A partir de ahí se ejecuta como Spec-Driven Development: la especificación es la fuente, el código la sigue, y cada decisión estructural queda como ADR fechado. La diferencia con SDD a secas es de dónde vino la primera versión — de una conversación real, no de un documento que alguien redactó a solas tres días después.

El ciclo cierra en git. Cada entrega deja una traza completa: especificación, commits, pull request, despliegue. Cuando eso se acumula durante unos meses hay un histórico que relaciona la forma de una especificación con lo que costó de verdad entregarla, por persona y según cuánto se apoyó en IA. De ahí salen dos cosas que normalmente se adivinan: los puntos de capacidad de una tarea, estimados contra casos parecidos que ya ocurrieron, y los KPIs de entrega —tiempo de ciclo, tasa de fallo en despliegue, tiempo de recuperación— calculados del mismo registro en lugar de reportados a mano.

  • Kickoff transcrito → borrador de especificación con decisiones y preguntas abiertas
  • Refinamiento con el equipo: la IA prepara, las personas deciden
  • Especificación aprobada como fuente, ADR para lo estructural (SDD)
  • Traza completa en git: especificación → commits → pull request → despliegue
  • Capacidad estimada contra el histórico real, no contra la intuición
  • KPIs y métricas DORA calculadas del registro, no reportadas a mano
Evidencia

¿Dónde lo he hecho?

Yummy Inc. · Tech Leader
Equipo de 7 desarrolladores en Pagos y Finanzas de una super-app de LATAM
7 personas
Cencosud S.A. · Developer Lead
Módulos de contabilidad con integración SAP y optimización de procesos batch
−60% tiempo
Sky Airline · Sr. Software Engineer
Escalé hasta Tech Leader Backup mientras sostenía la versión anterior en producción
1M+ tx/mes

Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.

Ejecución

Prácticas y entregables

Prácticas

  • Spec-Driven Development
  • Test-Driven Development
  • Ceremonias de refinamiento
  • Estimación contra histórico
  • Trunk-based development
  • Revisión de código en profundidad
  • ADRs
  • Métricas DORA

Entregables

  • Mapa de riesgos técnicos priorizado
  • Estándares de ingeniería y guía de estilo
  • Plantillas de especificación y ADR
  • Plan de formación por persona
  • Métricas de entrega con línea base
  • Ciclo kickoff → especificación → SDD instrumentado

Stack

  • TypeScript
  • Node.js
  • React
  • GitHub Actions
  • spec-kit
Preguntas

Lo que suelen preguntarme

¿Reemplazas a un Tech Lead interno?
No, lo formo. Cuando ya existe la persona, trabajo con ella; cuando no, ayudo a identificarla dentro del equipo y a que asuma el rol. Contratar liderazgo externo permanente es un síntoma, no una solución.
¿Cuánto dura un acompañamiento?
Entre tres y seis meses en la mayoría de los casos, con dedicación parcial. Menos de tres no alcanza para que un hábito nuevo se sostenga solo; más de seis suele significar que estoy tapando un problema de estructura en vez de resolverlo.
¿Trabajas con equipos que no son de pagos?
Sí. Los hábitos —especificar antes de construir, probar donde duele, medir la entrega— son los mismos. Lo que cambia es dónde está el riesgo, y eso lo identifico en el diagnóstico.
¿La IA estima las tareas por el equipo?
No estima: propone un rango contra tareas parecidas que ya se entregaron, con su traza en git. El equipo lo acepta o lo corrige en el refinamiento, y esa corrección también entra al histórico. Lo que se elimina es la estimación a ojo sobre una tarea que ya se hizo tres veces.
¿Qué necesitas del equipo para empezar?
Acceso de lectura al repositorio y al pipeline, y una hora con quien conozca la historia del sistema. Con eso puedo decir en una semana dónde está el riesgo real.
Catálogo
Ver todos

Otros frentes