Me han encantado dos entradas de Versión Cero: Mi historia en Meta4 y Vista y el efecto segunda versión de donde he sacado una cita del mismísimo Stroustrup:

Esto es un consejo que creo haberle leído por primera vez a Bjarne Stroustrup en The Design and Evolution of C++ : “Un sistema grande y complejo que no ha evolucionado a partir de otro pequeño y simple no funciona y, además, es imposible arreglarlo para que funcione”.

Al parecer el efecto segundo sistema ya lo señaló Frederick P. Brooks en el mítico The Mythical Man-Month. Y es que yo lo sé, que hay que volver a los clásicos, que todo estaba ya allí.

Nunca lo había pensado de esta forma pero es verdad ¿No os a pasado? Hacer algo bien y al intentar mejorarlo pasarnos de frenada con infinidad de requerimientos, últimas tecnologías para dejar a la competencia a años luz, miles de horas de I+D para al final tener que tirarlo y volver a empezar en modo pragmático.

Y como podemos ver en esa «visión» de la historia de Meta4, es muy fácil en nuestro sector perder el foco de lo que nuestro producto hace para los clientes y construir «sólo» tecnología. Olvidar lo que los clientes necesitan y hacer lo que nosotros queremos que necesiten. Desatendiendo lo que les movió inicialmente a confiar en nosotros.

Es muy típico el dicho de «crecer o morir» y más en nuestro mundillo donde o estás a la última o eres «viejo», pero aún siendo esto cierto, el dejar de avanzar solo nos acabará hundiendo, el intentar dar un salto «cuántico» (en el sentido literal) es aún más dañino en la mayoría de las ocasiones.

En teoría un proyecto bien llevado nunca debería fracasar, si en el proyecto se tiene una clara lista de requerimientos, de objetivos a lograr. Si estos son adecuadamente valorados y puestos en el plan. Si ponemos adecuadamente los puntos de control y las salvaguardas. Si evaluamos adecuadamente los riesgos ¿Por qué habría de fallar?

Pues en general porque esos proyectos «versión 2» no se construyen como proyecto al uso. Aparecen como un «proyecto» de I+D, se gestan típicamente con una fase inicial «indefinida» de evaluación de tecnologías, o lineas de desarrollo o pruebas de concepto que acaban nutriendo una lista de must-have’s interminable. Siendo además la mayorías de ellas sólo el resultado de dos o tres pruebas «Hola Mundo» con la tecnología X o el lenguaje de programación R.

Habría que separar claramente los procesos I+D, que son necesarios desde luego, de los proyectos de construcción de versiones clave de nuestros productos. Pero resulta que eso de I+D la mitad (por ser géneros) de las veces no existen si no es en el marco de ese proyecto. Es decir que se hace tarde y mal. Aprisa para probar todo eso que los técnicos han oído hablar y que les suena que estaría bien usar, pero sin darle el tiempo para realmente valorar si merece la pena su uso.

Es un problema de la empresa, estratégico, si no introduces en tu día a día adecuadamente el I+D, esto no funcionará luego bajo presión. Un proyectos, salvo contadas ocasiones, nunca debería construirse sobre tecnologías nuevas no probadas exhaustivamente por un equipo senior (o al menos mixto) de I+D de la compañía, y que esto haya ocurrido «fuera» del marco físico y temporal del proyecto.

Vale, me he pasado de idealista, y además las tecnologías van tan rápido que no hay tiempo de probar tan bien las cosas. Pero todo esto no puede ser motivo de irse al otro extremo y armar un proyecto no ya plagado sin o con 2 o 3 elementos no testados o dominados por el equipo. Eso es un seguro para el fracaso.

Seamos razonables y planifiquemos con tiempo.