2 cosas que los informáticos sabíamos pero que el mundo no entendía (hasta hace poco)

Ahora, las de más abajo, te pueden parecer obvias, antes, aunque también lo eran, no eran lo evidente, ni lo recomendado, ni lo políticamente correcto.

La complicada y peligrosa herencia industrial y de las profesiones que hacían cosas físicas, que guio durante años la antiguamente llamada ingeniería del software, llámala la parte de gestión en software, ese intento de parecerse a otras profesiones, del que te he hablado en muchas ocasiones, intentó, durante años, buscar caminos alternativos, hacernos hacer cómo hacían otros. E incluso hizo que muchas cosas obvias, que ya sabíamos, fuesen cuestionadas y sustituidas (con poco éxito).

Lo que hoy ocupa, y en parte sustituye, a aquellas antiguas creencias, todo el gran área que hoy llamamos agilidad, nos reafirmó como una profesión diferente, sin vergüenzas ni complejos, revitalizo nuestra identidad, nuestras diferencias con el mundo de la creación de casas, coches, hardware, etc.

Y aquellas obviedades que parecía que no estaba bien usar, que no gustaban en la gestión tradicional, en la gestión de proyectos clásica, se convirtieron (o están en camino de) en algo normal, en una identidad y, hasta para algunos, en una ventaja competitiva.

Cortando el rollo filosófico transcendental… ¿a qué me refiero? Pues a cosas como las siguientes, que, como verás, tú también las sabías desde siempre, aunque durante años no se enseñaran, recomendaran o estuviera tan bien visto aplicarlas:

De siempre supimos que sabemos lo que quiere el usuario… cuando él lo ve

Así es, nosotros lo sabíamos de siempre, que por mucho documento de requisitos, mucha reunión de prospección de negocio, mucha fase de análisis de requisitos, mucha ingeniería de requisitos, mucho pdf detallando, mucho PowerPoint con futuras pantallas, mucho caso de uso detallado… sabíamos que lo que hacíamos era lo que quería el cliente cuando… lo veía funcionando.

Mucho «management» no empezó a creerse eso que ya sabíamos desde hace años hasta que Steve Jobs soltó su «muchas veces la gente no sabe lo que quiere hasta que se lo enseñas». Gracias Steve, aunque los informáticos ya lo sabíamos.

Por ello los ciclos de vida ágiles, y sus ancestros pre aparición de la palabra ágil, recomendaban enseñar lo más pronto posible, aunque fuesen cosas pequeñas, pero enseñar y enseñar, y de ahí vino lo de MVP, pero enseñar cosas funcionando, porque, además…

De siempre supimos que las cosas están terminadas… cuándo están terminadas

Así de obvio, ¿cuándo tenemos certeza de que algo está terminado? Pues cuando está terminado, así de claro. Y terminado es en producción, listo para su uso, y si, por las circunstancias no puede estar en producción… en un estado muy similar, en pre-producción.

Todo lo que era alejarse de producción era meter interrogantes, algo en papel (UML, diseños, etc.) no era nada… a saber qué se acababa construyendo, y cuándo, y cómo, y si se podía.

Y algo desarrollado, era algo más, pero de ahí a que superara pruebas y pasase a producción podría quedar un mundo desconocido, de incertidumbre.

Y algo desarrollado y Testeado se acercaba algo más a que pudiéramos decir que estaba terminado, pero… ¿Qué camino quedaba hasta salir a producción?

Realmente sabíamos que algo estaba terminado… cuando estaba terminado, y terminado es en producción (o pre-producción, y eso que aún deja dudas).

Pero nos hicieron dudar de ello, había que terminar las cosas la final, terminar todo de golpe, muchos meses después, no estaba bien visto ir terminando cosas poco a poco y así medir nuestro avance en cosas terminadas.

En vez de ello, la gestión clásica se empeñaba en medir en avance en porcentajes misteriosos (como aquellos que se añadían a los Gantt), en hacer absurdas equivalencias entre tiempo transcurrido = a avance del trabajo.

Por ello los ciclos de vida ágiles, y sus antecesores pre aparición de la palabra ágil, aparte de recomendar el «enseña pronto», nos hablaban de «termina cosas, aun pequeñas, lo más pronto posible», y de ahí luego vino lo de medir la velocidad de las iteraciones (Sprints) en cosas (típicamente funcionalidades) que acaban en producción (o pre-producción).
.
.
Hay muchas más cosas que que los informáticos sabíamos pero que el mundo no entendía (hasta hace poco), pero el post se me ha ido de extensión, como que la única documentación fiable es el propio código, que el diseño no está en un papel aparte, está en el código, que un desarrollo «no tiene» fecha fin (como si tienen los proyectos), que el que mejor decide es el que más sabe (y por ello mejor que estime el que lo sabe desarrollar y no el comercial; y que las decisiones de funcionalidad las debe tomar alguien de negocio y no aquel que las programa, y de ahí las HU y el PO), etc., pero las dejaré para otro día, para otro posible post continuación a este.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
• Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
• HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024