El problema de escalar sin gobierno

Nadie piensa demasiado en el gobierno (governance) del proyecto cuando empieza una nueva iniciativa. Y creo que tiene sentido, porque al principio todo se mueve rápido, estamos llenos de la energía que trae consigo la novedad, negocio está involucrado y los equipos tienen ganas de empezar a aportar.

La primera aplicación sale, después otra aplicación, empiezan a aparecer otros casos de uso, nuevos departamentos que quieren entrar, más conversaciones sobre automatizar más procesos…y durante un tiempo, la velocidad tapa casi todos los problemas. Ese es precisamente el momento más peligroso. La organización todavía cree que está construyendo aplicaciones, cuando en realidad está ya construyendo una plataforma, y aunque parecido, son cosas completamente distintas.

Lo curioso es que los problemas importantes rara vez aparecen al principio. Nadie tiene un incidente grave en la primera aplicación en producción por falta de governance. La plataforma incluso puede parecer un éxito durante bastante tiempo hasta que empiezan a pasar cosas pequeñas.

Dime si algo de lo siguiente te suena familiar:

• Un equipo desarrolla componentes de una manera, pero otro equipo lo hace completamente distinto.
• Las decisiones sobre arquitectura empiezan a depender de quién construyó primero.
• La seguridad deja de ser consistente.
• Nadie sabe exactamente qué objetos se pueden reutilizar y cuáles no.
• Empiezan las discusiones sobre ownership.
• Los releases se vuelven más tensos.
• Las estimaciones dejan de ser fiables.

En ese nuevo escenario, la velocidad que antes era natural y la protagonista de los desarrollos, empieza a costar esfuerzo. He visto clientes donde eso ocurrió casi sin darse cuenta, provocando poco a poco más esfuerzos en coordinación, en refactorización o control de dependencias, lo que me hacía participar en conversaciones donde el topic era “¿Por qué cada vez nos cuesta más avanzar?”

Y como hemos visto aquellos que llevamos tiempo en consultoría, sabemos que la respuesta no está en la tecnología, sino en todo lo que la organización decidió no estructurar mientras las cosas parecían funcionar.

Creo que durante mucho tiempo además se ha asociado gobierno con tediosa burocracia, como si gobernar una plataforma significara ralentizar equipos, cuando la realidad es que las iniciativas maduras rara vez entiende el gobierno así.

De hecho, una de las cosas más interesantes del enfoque de gobierno que se aplica en Appian es precisamente que intenta evitar modelos pesados. Las interacciones que se proponen en el modelo de gobierno son bastante ligeras y aparecen en momentos muy concretos del ciclo de desarrollo, tratando de no detener a los equipos constantemente pero con el firme propósito de detectar decisiones que después cuestan meses corregir.

En mi experiencia, la mayoría de la deuda que complica una iniciativa no nace de malas intenciones ni tampoco de decisiones razonables que fueron tomadas quizás demasiado rápido. Nace de conversaciones del tipo: “ya lo arreglaremos después”, “necesitamos salir ahora”, “no merece la pena revisarlo todavía”, “ya veremos más adelante cuando aumente el volumen”…

Lo que sucede es que en ocasiones la plataforma empieza a crecer más rápido que la capacidad de la organización para ordenarla, y esto nos lleva a mantener las conversaciones sobre gobierno que no quisimos tener cuando empezamos el proyecto, con la diferencia que esas conversaciones son ahora incómodas, tensas y probablemente con negocio mirando con lupa porque están en riesgo los SLAs de la actividad.

Y esta es la razón por la que probablemente las iniciativas Appian más sólidas suelen tener algo en común: hay personas pensando constantemente en el correcto gobierno de la plataforma, no solamente en los hitos del delivery. La metodología de Appian, entre otras cosas, habla sobre la importancia de la asignación de roles dentro del modelo de gobierno, pero más allá de los nombres, la diferencia radica en ese alguien que está mirando el programa completo mientras todos los demás están concentrados en entregar.

Porque cuando nadie hace eso, la plataforma empieza a fragmentarse sin que nadie lo note demasiado y después corregir esos errores ya sabemos que sale caro. Y claro, no es que la tecnología no escale, sino que las organizaciones normalmente no preparan a tiempo la estructura necesaria para escalar con ella.