El suicidio de un nuevo negocio: Tener que volver a escribir el código.

Original publicado el 25 de enero de 2011, por Steve Blank.

Traducido por Alberto Peralta.

Las ventajas del Desarrollo de Clientes, del desarrollo ágil y del producto mínimo viable (o conjunto mínimo de características) son continuos comentarios de los clientes, rápida iteración y mínimo código desperdiciado. Pero con el tiempo si los desarrolladores no tienen cuidado el código escrito para encontrar a los primeros clientes puede llegar a ser difícil de manejar, de mantener o puede incluso limitar el crecimiento. Irónicamente se convierte en la antítesis de la agilidad. Y la magnitud del problema aumenta de forma exponencial con el éxito de la empresa. ¿La solución lógica? “Rehacer la arquitectura y escribir de nuevo el código” del producto. Para una empresa en un mercado que evoluciona rápidamente esto suele representar el principio del fin.

Parece lógico.

Acabo de comer (en mi restaurante griego favorito en Palo Alto olvidando lo que parecía una reunión con inversores) con un amigo que era socio fundador técnico de su empresa y que ahora es su presidente. Contrató a un ejecutivo de operaciones como CEO hace unos años. Hablamos de cómo iba la empresa (“muy bien, gracias, después de 5 años la empresa factura unos 50 millones de dólares anuales”) pero realmente quería hablar de un problema que tenía en mente. “A medida que hemos crecido nos hemos vuelto más y más insensibles a los cambios del mercado y las necesidades del cliente. Nuestra facturación va bien pero podemos quedarnos fuera del mercado en 2 años si no podemos seguir el ritmo de cambios de plataforma de nuestros clientes. Nuestro CEO no tiene experiencia en tecnología, pero está frustrado porque no puede tener las nuevas características y plataformas que quiere (Facebook, iPhone y Android, etc.). En la última reunión del Consejo el VP de Tecnología explicó que la raíz de nuestros problemas era que “nuestro código ha acumulado una gran cantidad de deuda técnica, el código es muy feo y no es como se habría hecho hoy”. Explicó al Consejo que la única manera de conseguir esas características era volver a escribir el código del producto. Mi amigo añadió: “Parece lógico que el CEO esté a punto de aprobar el proyecto”.

Para pegarse un tiro.

“¿Y el Consejo no le dijo 3 cosas al oír sus argumentos?”, le pregunté. “No” respondió mi amigo, moviendo tristemente la cabeza, “el resto del Consejo dijo que parecía una buena idea.”

Tras unas cuantas preguntas más supe que el código base, que ahora era enorme, todavía tenía restos del código original que se utilizó al principio, cuando la empresa se ​​encontraba en la fase de Descubrimiento del Desarrollo de Clientes. Los diseños que se hicieron entonces con el objetivo de averiguar qué producto era válido no eran adecuados para incorporar las nuevas plataformas que quería la empresa.

Recordé a mi amigo que yo no he sido responsable de producto por lo que cualquier consejo que pudiera darle era sólo de alguien que había visto esa película antes.

Los cantos de sirena a los CEOs que no son técnicos.

Un CEO se encuentra con el problema de “volver a escribir el código” por lo menos una vez durante su mandato. Si se trata de un ejecutivo de operaciones contratado para reemplazar a un CEO técnico que además era fundador, entonces parece que la decisión es fácil  (basta con escuchar al VP de Tecnología comparar lo que se tardaría en volver a escribir el código, poco tiempo, y lo que se tardaría en adaptar el código antiguo para poder disponer de las nuevas características, mucho tiempo). En realidad, esta es la opción de los tontos. El equipo de ingeniería puede conocer las dificultades y problemas de adaptación del código antiguo, pero no tiene ni idea de las dificultades y problemas a los que se enfrentará al escribir un nuevo código base.

Un CEO que hubiese vivido el desastre de volver a escribir el código, o que entendiera la complejidad del código, sabría que al no existir ya el equipo de ingeniería inicial las probabilidades de volver a cometer los viejos errores son altas. Es muy posible que además se produzcan nuevos errores que no se habían producido la primera vez (la ley de Murphy dice que el optimismo desenfrenado probablemente hará que un proyecto para volver a escribir código de 1 año se transforme en un proyecto de varios años).

Mi comentario fue que el CEO y el VP de ingeniería estaban confundiendo causa y efecto. Los clientes no estaban pidiendo un código nuevo. Pedían, ya, nuevas características y plataformas. A los clientes no les importa si se les hacen llegar a través de código espagueti, de una nave extraterrestre o de un producto totalmente nuevo. Y mientras se vuelve a escribir el código aquellos competidores que no estén enamorados de la pureza arquitectónica aumentarán las características, las plataformas, los clientes y su cuota de mercado. La diferencia entre añadirlas ahora, el año que viene, o el siguiente podría ser la misma que se da entre crecer y cerrar.

¿Quién quiere trabajar en el antiguo producto?

Quizás el efecto secundario más peligroso de embarcarse en volver a escribir un código es que la decisión condena al código antiguo antes de que exista una alternativa viable. ¿Quién va a querer trabajar en el código antiguo con todos sus problemas cuando el VP de Tecnología y el CEO han declarado que el nuevo código será el futuro de la empresa? El código anterior es como si estuviera muerto desde el mismo momento en el que los ejecutivos hablan de “volver a escribir”. Otra consecuencia es que el CEO no tiene vuelta atrás. Si el calendario que plantea el VP de Tecnología termina alargándose 4 años en lugar de 1 año no hay manera de hacer progresos adicionales en las nuevas funciones durante ese tiempo.

Lo que realmente pasa es que falta imaginación.

Se me ocurrió que la situación reflejaba poca imaginación del VP de Tecnología, agravada por la falta de experiencia de un CEO que nunca había vivido una situación en la que hubiera que volver a escribir el código y por un Consejo que tampoco entendía la propuesta y que no había exigido a ninguno de los dos una solución creativa.

¿Qué consejo dí a mi amigo? Dado el dinamismo y la competencia en ese mercado, una iniciativa así es una asesina de empresas. La lógica debería ser: No volver a escribir código base en aquellas empresas en las que el tiempo de comercialización (de llegada al mercado) sea crítico y las necesidades del cliente cambien rápidamente”. Volver a escribir el código puede tener sentido en mercados donde el tiempo de vida de los productos es largo.

Lo que le sugerí fue que se tumbara en las vías delante del tren en la siguiente reunión del Consejo. Que forzara al CEO a articular qué características y plataformas necesitaba y para cuándo, y que indicara qué medidas había previsto para gestionar el riesgo de un posible retraso. Y que averiguara si era posible un planteamiento de ingeniería completamente diferente (¿retocar sólo los módulos correspondientes a las funciones que se necesitaban?, ¿volver a escribir las nuevas plataformas en un código base distinto?, ¿crear un equipo de especialistas para las nuevas plataformas?, etc.).

Lecciones aprendidas.

  • No siempre que se debe volver a escribir el código el resultado es el mismo. Cuando el mercado es estable y los cambios son poco frecuentes es posible que haya tiempo para volver a escribirlo.
  • Cuando los mercados / clientes / competidores cambian rápidamente no da tiempo a pedir un “tiempo muerto” porque el código sea feo.
  • En este momento es cuando se necesita entender 1) qué problema hay que resolver (una pista: No es el código) y 2) cómo solucionar ese problema de forma creativa.
  • Tomar la decisión incorrecta puede hundir la empresa.
  • La situación bien vale un enfrentamiento en la reunión del Consejo.
Publicado en Customer development, Desarrollo de clientes, Inversores, Technology, Tecnología, Venture capital

Deja un comentario

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

*