La naturaleza invisible del software

10 min de lectura

Lo que no puede ver, normalmente lo gestiona mal.

El software es real. Solo no se comporta como trabajo físico.

Los líderes no son estúpidos por luchar con esto. Están reaccionando a la señal equivocada porque el software emite muy poca de la señal en la que les enseñaron a confiar.

Si usted gestiona logística, manufactura, retail, construcción u operaciones de campo, el trabajo deja rastros que puede inspeccionar con los ojos. Llegan materiales. Se llenan estantes. Se mueven máquinas. Se vierten pisos. Salen camiones. Incluso los retrasos son visibles. Algo está allí, a medio construir o sin moverse.

El software no funciona así. La parte más difícil muchas veces ocurre antes de que aparezca algo evidente en una pantalla. Un desarrollador puede pasar dos horas entendiendo por qué un cambio inocente corrompería datos de facturación en tres países. Otro puede pasar un día reduciendo riesgo al simplificar una ruta de despliegue, y el único resultado visible es que la semana siguiente no pasa nada dramático. Un equipo puede borrar quinientas líneas de código frágil y mejorar el producto más de lo que lo habría hecho añadiendo cinco mil nuevas.

Para la gente fuera del trabajo, eso puede parecer deriva, vacilación o baja producción. Dentro del trabajo, suele ser exactamente lo contrario. Es progreso a través de comprensión.

Ese es el problema. El software está lleno de valor que no se anuncia haciendo ruido.

El trabajo está oculto en decisiones, no en movimiento.

Muchos errores de liderazgo empiezan al tratar el trabajo de software como si el artefacto visible fuera el trabajo en sí.

No lo es.

La interfaz no es el sistema. La demo de una funcionalidad no es la arquitectura. El estado del ticket no es la realidad de la entrega. El commit de código no es el pensamiento que hizo que el código fuera seguro, mantenible o siquiera útil.

Gran parte del desarrollo de software es invisible porque vive dentro de decisiones:

• entender requisitos en conflicto
• reconocer acoplamientos ocultos entre sistemas
• detectar riesgo regulatorio, de seguridad u operativo
• decidir qué tradeoff es aceptable y cuál le castigará después
• diseñar para el cambio, no solo para la demo del camino feliz
• rechazar un atajo que hoy parece rápido y mañana quemará dinero

Ese trabajo no se deja fotografiar bien. Nadie enmarca una imagen que diga: “evitamos una inconsistencia catastrófica de datos al no lanzar la versión ingenua”.

Así que las organizaciones recurren a proxies. Cantidad de tickets. Horas registradas. Actividad visible en herramientas. Volumen de reuniones. Aprobaciones de ramas. Presentaciones. Hojas de ruta con líneas sospechosamente rectas. Todo eso consuela porque puede verse. Muy poco de eso dice la verdad.

Complejidad en Software: Guía para Líderes describe el mismo error desde otro ángulo: la gente confunde lo que es fácil de observar con lo que realmente determina el resultado.

El trabajo invisible pone nerviosos a los ejecutivos

Esta es la parte que a nadie le gusta admitir.

Con frecuencia se juzga a ejecutivos, directores y jefes de departamento por el control. Se espera que expliquen progreso hacia arriba, justifiquen gasto, reduzcan incertidumbre e intervengan antes de que el fracaso se vuelva público. Si el trabajo que supervisan es difícil de ver, la presión por producir prueba visible se vuelve intensa.

Esa presión es entendible. También es peligrosa.

En el momento en que un líder se siente ciego, la tentación es instalar algo que parezca visión:

• más reuniones de estado
• más estimaciones obligatorias
• más puertas de aprobación
• planes de proyecto más detallados
• más capas de reporte
• más desglose de tareas
• más artefactos visibles producidos para gestión y no para el producto

Nada de eso resuelve el problema subyacente. Solo convierte incertidumbre invisible en burocracia visible.

Es fácil ver por qué ocurre. Una hoja de cálculo llena de hitos parece más tranquilizadora que un desarrollador senior diciendo: “todavía estamos aprendiendo dónde está realmente el riesgo”. Una cosa suena controlada. La otra suena desordenada.

La tragedia es que el software es desordenado exista o no la hoja de cálculo.

La hoja de cálculo solo les da a las personas una forma educada de mentirse entre sí unas semanas más.

Las consecuencias no deseadas son predecibles

Aquí es donde la percepción se convierte en daño operativo.

Cuando la gente que controla el entorno no puede ver correctamente el trabajo de software, empieza a premiar todo lo que desde fuera parece trabajo. Los equipos se adaptan. No porque sean inmorales. Sino porque las organizaciones enseñan a la gente cómo se ve sobrevivir.

Estas son algunas de las consecuencias más comunes.

Los lotes grandes sustituyen a los cambios pequeños y seguros.

Los cambios pequeños integrados de forma continua son más difíciles de notar para líderes fuera del trabajo. No crean hitos dramáticos. Un gran lanzamiento, en cambio, parece importante. Crea una fecha, una reunión, una presentación, una sensación de ocasión.

Así que los líderes a menudo prefieren exactamente el patrón de entrega que crea más riesgo.

Esa es una razón por la que las organizaciones se alejan de la integración continua y se acercan a colas de ramas, teatro de aprobación y dolor de merge tardío. Los Pull Requests nunca fueron pensados para tu equipo muestra cómo los pull requests se convierten en muebles de gestión en lugar de una frontera útil entre auténticos extraños.

El trabajo que evita el fracaso queda relegado.

Pruebas, refactorización, instrumentación, higiene de despliegue, limpieza de arquitectura, documentación de la buena y eliminación de complejidad peligrosa rara vez producen capturas llamativas. Su beneficio es sobre todo espacio negativo: menos incidentes, menos regresiones, recuperación más rápida, menos fragilidad.

En entornos mal gestionados, eso parece mantenimiento opcional porque el beneficio es invisible hasta el día en que deja de serlo.

Así que se empuja a los equipos hacia salida de funcionalidades mientras la integridad estructural del sistema se pudre en silencio.

Se obliga a los desarrolladores a narrar en vez de construir.

Cuando el liderazgo no confía en la evidencia que sale del sistema de entrega, exige capas de traducción. Más presentaciones. Más resúmenes de estado. Más check-ins. Más explicación de por qué la realidad no obedeció al plan anterior.

Ese tiempo sale de algún sitio.

Normalmente de la misma gente que se suponía que resolvería el problema en primer lugar.

Se recompensa la falsa certeza.

La persona que dice “sí, podemos comprometernos con ese alcance exacto y esa fecha” suena más útil en la sala que quien dice “primero tenemos que reducir la incertidumbre”. La primera ofrece confianza. La segunda ofrece realidad.

La realidad pierde esos concursos todo el tiempo.

Luego el proyecto falla, todos actúan sorprendidos y la misma organización que premió la fantasía culpa a la ejecución.

La visibilidad local vence a la salud del sistema.

Un gerente puede señalar un dashboard, una hoja de ruta o un conteo alto de tickets y decir que el equipo avanza. Mientras tanto, los despliegues son dolorosos, la recuperación de incidentes es lenta, las dependencias están sin gestionar y nadie tiene suficiente espacio para mejorar el sistema.

La capa de reporte se mantiene en verde mientras el sistema de entrega se vuelve frágil.

Ese patrón es común porque la gestión visible suele imponerse a la competencia invisible.

Por qué los equipos de software reaccionan tan fuerte a malas restricciones

Desde fuera, los desarrolladores pueden parecer tercos, escépticos o extrañamente alérgicos a rituales de gestión. Hay una razón.

Cuando una mala decisión golpea una fábrica, sus efectos pueden tardar en aparecer mediante inventario, tasas de defectos, tiempo muerto o datos de calidad. En software, una mala restricción de gestión puede empezar a dañar el trabajo ese mismo día.

Un plazo forzado fomenta atajos mayores. Un ritual de reporte rompe la concentración. Una cola de aprobación retrasa la integración. Una demanda de certeza demasiado pronto encierra a los equipos en compromisos falsos. Un plan construido para la óptica puede forzar la secuencia equivocada de trabajo. Una regla presupuestaria puede impedir la limpieza necesaria que habría hecho más rápida la entrega futura.

Los equipos de software sienten estas distorsiones rápidamente porque el medio responde mucho. Eso no vuelve delicados a los desarrolladores. Vuelve al trabajo sensible a las condiciones que lo rodean.

Tratar a los desarrolladores con respeto no trata de halagos. Trata de reconocer que la gente más cerca del sistema suele ver la fragilidad mucho antes que la gestión.

Cómo se ve un liderazgo mejor

La respuesta no es romantizar el software y declararlo demasiado misterioso para la gestión normal. Eso sería absurdo.

La respuesta es dejar de usar hábitos industriales de visibilidad como sustituto de comprensión.

Si usted lidera personas que construyen software, haga en cambio unas cuantas cosas más simples y más útiles:

1. Pida evidencia del sistema de entrega, no teatro de rendimiento. Mire frecuencia de despliegue, tiempo de entrega, defectos escapados, tiempo de recuperación, fiabilidad de pruebas y si el trabajo llega con seguridad a producción. Esas señales son más difíciles de falsificar que los adjetivos de estado.

2. Recompense la reducción de riesgo aunque sea visualmente aburrida. Una ruta de liberación más segura, un diseño más simple, mejor observabilidad, pruebas más limpias y menos dependencias pueden crear más valor de negocio que otra demo amigable para gestión.

3. Permita que los equipos expongan incertidumbre sin castigo. Si la gente solo puede llevar confianza a la sala, esconderá la ambigüedad hasta que explote. No se obtiene previsibilidad prohibiendo la duda honesta.

4. Prefiera ciclos cortos de feedback a pronósticos detallados. La mejor manera de gestionar trabajo invisible no es exigir clarividencia. Es acortar el ciclo entre decisión, implementación, evidencia y corrección.

5. Aprenda la suficiente realidad del software como para dejar de premiar tonterías. No necesita convertirse en desarrollador. Sí necesita la alfabetización suficiente para distinguir señal de ruido ceremonial.

El verdadero fracaso de gestión

La naturaleza invisible del software no es el verdadero problema.

El verdadero problema es lo que las organizaciones hacen como respuesta.

Algunos líderes aceptan que el trabajo está parcialmente oculto e invierten en mejores formas de verlo: prácticas técnicas, métricas fiables, contacto directo con la gente que hace el trabajo y suficiente humildad para admitir lo que todavía no entienden.

Otros entran en pánico. Sustituyen comprensión por vigilancia, feedback por reporte y evidencia de entrega por artefactos de presentación.

Entonces crean exactamente la disfunción que estaban intentando prevenir.

Si usted ocupa un rol de liderazgo, su trabajo no es fingir que el software debería parecer construcción, logística o producción de fábrica. Su trabajo es entender que está gobernando un tipo distinto de trabajo.

El software es invisible del mismo modo que la estrategia es invisible, la confianza es invisible y el buen juicio es invisible. Se nota con más claridad cuando falta.

Para entonces, por supuesto, normalmente ya es caro.