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 guió 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… ¿que 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.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

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

  1. Anda que no nos lo has contado veces… y sigue haciéndolo por favor 🙂
    Que en algunos entornos como el de las administraciones públicas (seguro que no es el único), en cuanto te despistas volvemos una y otra vez a caer en lo mismo: Que si cómo no voy a pasar estas funcionalidades al usuario (documento de requisitos); que si cómo no voy a cerrarlas antes de empezar; que si dile a la empresa que te envie un cronograma en el que me digas que vas a cumplir el contrato a 30 de Abril de 2019; que si a 30 de Abril es cuando está terminado y es cuando lo pongo en producción todo de golpe… Esto de los contratos cerrados con las AAPP seguro que te daría para unos cuantos post.
    Enhorabuena por seguir con el blog y por este tipo de labores de concienciación.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *