Un ingeniero actualiza una página de solicitud de extracción por cuarta vez. Aparecen nuevos comentarios. Se etiquetan más críticos. El cambio lleva días listo, pero la aprobación espera.
El escenario es familiar en toda la industria: código que tarda 15 minutos en escribirse pero 15 días en ser aprobado. La frustración no se debe a un desacuerdo sobre la calidad o la seguridad. Los ingenieros quieren ofrecer algo sencillo, pero se encuentran navegando por comentarios, revisiones, reuniones de alineación e hilos de estado.
Si alguna vez ha visto cómo una solicitud de extracción dedica más tiempo a la discusión del que se necesitó para crear la función, habrá visto el costo silencioso del proceso a escala. La gobernanza comienza con buenas intenciones. Aporta claridad y protege la calidad. Pero más allá de cierto punto, diluye la propiedad, ralentiza la ejecución y agota la moral.
Las organizaciones de software no se desaceleran porque a la gente deja de importarle. Se desaceleran porque la responsabilidad se distribuye entre los propietarios, los revisores y los comités, mientras que el trabajo requerido para impulsar cualquier cosa se vuelve más pesado cada trimestre. El desafío para los líderes es ajustar continuamente la gobernanza para que la claridad y la velocidad aumenten juntas.
La creciente trampa de la propiedad
El patrón se desarrolla de manera similar en empresas que superan los pocos cientos de ingenieros. Al principio, las cosas avanzan rápidamente porque la propiedad es clara. Entonces el crecimiento crea nuevas presiones. Un despliegue provoca una interrupción y el liderazgo añade supervisión. Una vulnerabilidad de seguridad llega a producción y, de repente, cada cambio requiere una revisión de seguridad.
Cada respuesta tiene sentido de forma aislada. El problema surge cuando las organizaciones siguen agregando capas sin eliminarlas. Las juntas de revisión de arquitectura y las listas de verificación de preparación para el lanzamiento se acumulan sin poda y se expanden para incluir todas las voces de alto nivel. Los impulsores más profundos suelen ser emocionales. Los incidentes visibles desencadenan una sobrecorrección con múltiples capas de aprobación para aliviar la ansiedad. Los equipos de calidad son recompensados por prevenir riesgos en lugar de permitir la velocidad. Tener un proceso se convierte en un símbolo de competencia gerencial.
El análisis académico de más de medio millón de registros de GitHub en alrededor de dos mil repositorios de código abierto de alta actividad reveló algo sorprendente. Los repositorios con más de 10 propietarios tardaron más del triple de tiempo en fusionar los cambios en comparación con aquellos con uno o dos propietarios claros (fuente). A medida que la propiedad se vuelve más amplia, la rendición de cuentas se vuelve más escasa. Cada revisor asume que otros detectarán los problemas. Fusionar tiempos de cráter mientras la calidad se mantiene estable.
Considere una revisión de la preparación operativa en la que las invitaciones a ingenieros superiores y líderes técnicos hayan creado una reunión permanente con entre 10 y 15 personas. Cuanto más grandes se vuelven estas reuniones, más engorrosa se vuelve la toma de decisiones. Cuando se reduce a un grupo más pequeño con un ingeniero senior que realmente posee la aprobación, nada se rompe. Los resultados mejoran porque una rendición de cuentas clara impulsa un juicio cuidadoso, mientras que la responsabilidad difusa invita a suponer que alguien más se dará cuenta de los problemas.
Por qué los procesos deben evolucionar, no fosilizarse
Los equipos caen en una trampa donde una regla que alguna vez fue útil se convierte en una tradición y luego en una barrera. Cuando alguien pregunta por qué existe una aprobación particular, la respuesta se vuelve circular: porque ese es nuestro proceso.
La buena gobernanza se adapta a las necesidades actuales, no a las históricas. Para cada puerta de proceso, alguien debería articular qué riesgo específico mitiga y qué pasaría sin él. Si la respuesta es “siempre lo hemos hecho así”, es necesario reevaluar la puerta.
Las culturas de ingeniería más exitosas incorporan mecanismos para el retiro de procesos. Cualquier nuevo proceso viene con una fecha de vencimiento. Después de seis o 12 meses, la regla se retira automáticamente a menos que alguien defienda activamente su renovación con datos que demuestren su necesidad. Cada regla debe tener un propietario documentado y una justificación de una frase. Si el equipo actual no puede indicar el motivo, el proceso debe retirarse.
Cinco formas prácticas de mantener alta la velocidad y la propiedad
A continuación se presentan algunas formas prácticas de mantener afinados los mecanismos de gobernanza y garantizar que los procesos sigan siendo ágiles.
Limitar la propiedad a aquellos verdaderamente responsables
Para proyectos importantes, identifique un pequeño grupo de dos o tres personas genuinamente responsables de los resultados. Realice un seguimiento de la fusión y revise la latencia como señales de estado de gobernanza. Diseñe los límites del equipo que minimicen los requisitos de coordinación, garantizando que los límites arquitectónicos se alineen con los límites organizacionales.
Crear vías para que el trabajo de bajo riesgo avance rápidamente
No todos los cambios conllevan el mismo riesgo. Permita que las actualizaciones de rutina, como documentación, cambios de prueba y configuraciones reversibles, eviten ciclos largos mediante la aprobación de un solo revisor, la implementación de autoservicio y el escaneo automatizado. Deje claro qué desencadena la ruta de excepción para cambios de alto riesgo.
Mantenga los círculos de revisores pequeños y decididos
Para la mayoría de los cambios, limite los revisores a dos o tres personas con contexto directo. La visibilidad más amplia debería ser la excepción, reservada para cambios que introduzcan nuevos patrones arquitectónicos o requieran una alineación entre organizaciones. En esos casos, utilice notas de decisión, como registros de decisiones de arquitectura, para informar a las partes interesadas sin requerir la aprobación de todos. Establezca breves períodos de comentarios medidos en días, no en semanas, y deje claro quién tiene la decisión final.
Asignar un único responsable de fusión para cada cambio
Designar una persona responsable de fusionar cada cambio. Incluso cuando se necesitan varios revisores, solo una persona debe ser dueña de la decisión y el cronograma. Establezca plazos para tomar decisiones, no requisitos de consenso. Esto evita esperar a un consenso que tal vez nunca llegue.
Trate la escalada como eficiencia, no como conflicto
Cuando una decisión se estanca más allá del SLA de revisión esperado de su equipo, fomente una derivación rápida a un líder o arquitecto. La escalada debe ser elogiada, no evitada.
El coste humano y cultural de las capas innecesarias
El efecto más corrosivo de una gobernanza ineficiente no es la pérdida de velocidad. Es el impacto en las personas.
Los ingenieros talentosos pierden gradualmente su chispa en organizaciones con demasiadas capas de revisión. Pasan meses guiando una característica a través de ciclos de revisión, remodelados por los comentarios de seis partes interesadas diferentes. Cuando se envía el código, el constructor original apenas lo reconoce.
Aquí es cuando la optimización pasa del impacto a la aprobación. Los ingenieros dejan de enorgullecerse de soluciones elegantes o de proponer ideas ambiciosas porque los costos de coordinación son prohibitivos. Se convierten en contratistas que ejecutan la visión de otra persona en lugar de constructores que crean algo nuevo.
La forma más rápida de aplastar el espíritu de innovación en los equipos de desarrollo es premiar el teatro de alineación por encima del impacto de la creación. Cuando los ingenieros dedican más tiempo a la preparación previa a las reuniones, a los correos electrónicos de gestión de las partes interesadas y a pulir las presentaciones que a la creación y validación de soluciones, la estructura de incentivos se ha invertido. Y los mejores se van.
Cómo los equipos grandes pueden moverse como equipos pequeños
Las grandes organizaciones preservan la velocidad de los equipos pequeños a medida que escalan centrándose en la autonomía y los límites claros. Los principios rectores: contrate personas en las que confíe, establezca límites claros en torno a los requisitos de seguridad, los principios arquitectónicos y las reglas de cumplimiento, luego permita que los equipos trabajen de forma independiente dentro de esos límites.
Diseñar estructuras de equipo que minimicen la coordinación. Alinee los límites del equipo con los límites del sistema para que los equipos puedan crear, probar e implementar de forma independiente. Cuando la propiedad arquitectónica coincide con la propiedad organizacional, los equipos dedican menos tiempo a alinearse y más tiempo a realizar envíos.
Utilice la automatización para hacer que el camino más seguro sea también el más fácil. Por ejemplo, cree controles de seguridad básicos directamente en el proceso de implementación, como escaneo automático y registro de auditoría que se ejecutan silenciosamente en segundo plano. Esto permite a los equipos implementar con confianza, lo que resulta en una entrega más rápida sin reducir la seguridad.
Antes de agregar un nuevo proceso de aprobación, pregunte si el problema real es la deuda técnica, las pruebas débiles o la arquitectura frágil. Los sistemas frágiles crean miedo, y el miedo lleva a las personas a añadir capas de procesos defensivos. Arreglar el sistema subyacente es mejor que agregar más revisiones.
Cuando la gobernanza es demasiado ligera
El objetivo no es una gobernanza cero. Los sistemas maduros necesitan coherencia arquitectónica, revisión de seguridad para cambios de alto riesgo y procesos de cumplimiento en contextos regulados. Las señales de advertencia de una mala gobernanza incluyen incidentes repetidos del mismo tipo, acumulación de deuda técnica debido a decisiones inconsistentes o ingenieros que toman decisiones sin comprender las limitaciones de todo el sistema. Haga coincidir la gobernanza con la madurez del equipo, con planes explícitos para reducir las limitaciones a medida que se desarrolla el juicio.
La auditoría continua
Hacer de la revisión de la gobernanza una disciplina regular. Cada seis meses, enumere cada paso de aprobación requerido, reunión recurrente y puerta de proceso. Luego pregunte: si hoy empezáramos desde cero, ¿crearíamos esto? Aproximadamente un tercio de las veces, por lo general, la respuesta es no.
Si estás heredando un desastre de gobernanza, empieza por instrumentar el dolor. Realice un seguimiento de los tiempos de fusión, la latencia de revisión y el porcentaje de tiempo que los ingenieros dedican a codificar frente a esperar en los ciclos de revisión. Luego, aborde primero el proceso de mayor apalancamiento. Por lo general, este es el proceso con la peor relación señal-ruido, donde las revisiones rara vez encuentran problemas pero siempre crean retrasos.
Centrar los esfuerzos de poda en procesos discrecionales, no en puertas que exigen cumplimiento en entornos regulados.
Elegir la velocidad sobre el teatro
La parte más difícil de dimensionar adecuadamente la gobernanza es decir no a las personas con buenas intenciones. El arquitecto senior que quiere revisar cada cambio en la base de datos realmente se preocupa por la integridad de los datos. Pero cuidar no es lo mismo que agregar valor.
Las organizaciones de software son sistemas vivos. La gobernanza debe evolucionar, reducirse y adaptarse tan rápidamente como lo hacen el código y la cultura. Avanzamos no preguntando cuánto proceso agregar, sino preguntándonos si una regla todavía merece su lugar.
Existe proceso para atender a los constructores. Cuando el proceso se convierte en trabajo, el trabajo sufre. Los líderes más eficaces no celebran el tamaño de su sistema de gobierno. Celebran la velocidad y la confianza de sus equipos.
La verdadera propiedad no se asigna. Está protegido.
