Lo que os voy a contar es una situación que, personalmente, me he encontrado ya en tres ocasiones sólo desde el verano. Eso sin contar las veces que alguien ha sacado el tema de este post en alguna conversación de café.
Por las razones y necesidades que todos conocemos, emprender en proyectos basados en la Web está de moda. Sintetizando mucho, detrás de este tipo de emprendimiento, y de estas startups, hay una idea de negocio, un equipo humano promotor y un desarrollo software.
Aunque estos proyectos de emprendimiento están basados en construir funcionalidad sobre tecnología, es obvio decir que no todos los emprendedores que lanzan estas startups tienen conocimientos sólidos y gran experiencia (kilómetros y cicatrices) en desarrollo software. En unas ocasiones porque no es lo suyo, y su perfil es, por ejemplo, económico, y en otras porque tienen demasiada poca experiencia en desarrollo software, guerras similares y supervivencia a naufragios.
Hay una historia negra, que aun siendo de muy triste final no es lo suficientemente conocida. Historia que ha llevado siempre de una mano al mal desarrollo software y de la otra a la mala competitividad de una empresa. Historia bien documentada, la han contado muchos, cada uno a su manera, desde Dijkstra, a Brooks y, ayer mismo, Robert C. Martin.
Pero es que, además, es raro encontrar alguien que lleve unos años dedicado a esta maravillosa profesión del desarrollo software y no haya sufrido esta historia en sus propias carnes (yo mismo os podría decenas).
La historia comienza en una empresa, con un proyecto software que empieza a tener éxito. Como al principio hay poco software desarrollado nada parece indicar que el propio software sea un riesgo, o que el Kraken se pueda llegar a despertarse.
Llegan los primeros clientes, y demandan nuevas funcionalidades, nuevas versiones, que deben estar en producción rápidamente. Y así se hace. Pero a nadie parece preocuparle la calidad con que se está desarrollando el software, y si se evitan conocidas malas prácticas. El negocio es lo primero… y lo único.
Pero el tiempo pasa rápidamente, y cada vez hay más software desarrollado sin control y más gente desarrollándolo. Así que, poco a poco, casi sin darnos cuenta, aquellas funcionalidades que antes rápidamente se desarrollaban, cada vez requieren de más tiempo. Pero cliente, negocio e inversores no están dispuestos a darnos ese tiempo.
Y comienza entonces la fase de las soluciones desesperadas. Comienza la presión, y las jornadas de trabajo nocturnas y fines de semana. Crece el estrés. La gente que no aguanta y abandona el equipo, llevándose el conocimiento de cómo se desarrollaron ciertas partes del software.
Para intentar solucionar el problema se incorporan nuevos desarrolladores. Nuevos desarrolladores que al no conocer el sistema quitan tiempo a los más veteranos. Todo esto acaba bloqueando la producción de software, la puesta en producción de nuevas funcionalidades, haciendo lenta a la joven empresa y disparando el gasto.
Lo anterior ni es nuevo, ni mucho menos es exclusivo de las startups. Un gran numero de empresas mas tradicionales que desarrollan software viven esto cada día, y desde hace muchos años. Pero la mayoría sobrevive, o mal vive, durante años porque son empresas grandes, algunas con clientes cautivos, con otras fuentes de ingresos, o que se mueven en negocios que van más lentos. Y pueden permitirse ese gran desperdicio económico.
Pero las startups no se pueden permitir ni desperdicios económicos ni frenar la velocidad en que ponen en producción nuevas funcionalidades. Y además… ¿Cómo le vas a explicar a los inversores esta historia sobre por qué el desarrollo de negocio ahora es tan lento y que intentar mal acelerarlo es peor?
Así que si eres emprendedor de base tecnológica, o inversor, yo que tu me preocuparía por lo anterior. Porque por mucho que quieras ser “lean startup” si el desarrollo software te lastra… te va a ser imposible. Y si tu idea era buena, y vas despacio, puede que otra empresa te la copie… pero la desarrolle bien y, por ello, rápidamente.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Muy acertada esta visión de este problema tantas veces como dices vivido, la última que yo recuerdo en España y que ha tenido un amplio eco ha sido el de la empresa «Buen Menú» que tuvo que echar abajo su web y el servicio prestado a decenas de miles de usuarios y miles de empresas (siempre citando la información publicada por medios en internet y el hecho de comprobar en primera persona durante varios días dicha indisponibilidad del sistema web). Según estas fuentes, este servicio entre otras cosas consistente en el pago de los famosos ticket restaurant a través de una tarjeta tipo «prepago» venía fallando y cargando en las tarjetas de algunas personas hasta 4 veces el importe que les correspondía mensualmente y evidentemente la empresa perdía dinero, sin saber por dónde se les iba. Yo he sido cliente de este servicio en algunas de las multinacionales TIC en las que he trabajado y eso supone que en la última quedaron sin servicio más de 4.000 personas en España, e intuyo que el departamento de RRHH debió de encontrarse con un problema importante con los empleados y la empresa como otras miles debió de ejercer los derechos que el contrato les permitía, y a buen seguro tras varias semanas sin servicio, se dice que más de un mes de incidencia, la perdida de clientes ha sido tremenda poniendo en riesgo la viabilidad de la empresa; siempre citando lo aparecido en prensa.
Por tanto Javier, el tema no puede ser de mayor actualidad, e importancia, pues como dices, son muchos los emprendedores que lanzan negocios basados en un sistema informático al que se le da la importancia «justilla» pero no la «justa» y la justa, es mucha, pues es el sistema de producción de muchas de ellas hoy en día, y si lo comparásemos con la industria de automoción, nadie pondría diseñar e implementar el sistema de fabricación de los coches a «uno que pasaba por ahí» como ocurre muchas veces, que ha hecho un curso de desarrollo web.
Me gustaría por último resaltar lo difícil que es conciliar la necesaria calidad y al mismo tiempo las necesidades de competitividad de la puesta en marcha de un negocio, o ya puesto en marcha, el mantenimiento de esté de forma competitiva tanto en cuánto al «Go To Market» como al coste para poder competir en mercados en los que cada vez se requiere llegar ANTES. Por tanto, diría igualmente la necesaria CALIDAD y PRODUCTIVIDAD.
Estimado Javier, es por ello que el «KIT» de la cuestión esta en Cómo conseguir Calidad y Alta Productividad al mismo tiempo para ser COMPETITIVO y dar respuesta a las demandas del negocio?
Nuestra experiencia nos lleva al uso de soluciones a aplicad a todo el ciclo de vida de las aplicaciones informáticas, ADEMÁS de unos eficientes procesos metodológicos con los que se alineen dichas soluciones, desde la Gestión de los Requerimientos, el Prototipado, el Diseño de las aplicaciones (Datos y Software) y la Codificación, Pruebas y Documentación, incluso utilizando en ello algunas soluciones de Inteligencia Artificial que aplicadas a la Ingeniería de Software, permitiéndonos justamente conseguir aunar Calidad y Alta Productividad.
Creo que el Handycap de hoy en día es cómo dar respuesta a esta cuestión, cómo ser Competitivos y estoy absolutamente de acuerdo en que uno no puede ser competitivo sin calidad, aunque cada vez menos sin productividad y en ello se ha de avanzar a través de la I+D+i existente o desarrollándola.
Un saludo
Daniel,
Muchas gracias por el interesante comentario, y contar lo de Buen Menú, bastante ilustrativo.
Para mi, hay una condición necesaria (aunque puede que no suficiente) para lograr lo que comentas de «time to market» y «calidad software»: tener gente en el equipo técnico REALMENTE buena.
Pero buena de verdad. No me refiero al tipo de entrevistas de trabajo que he visto 1000 veces en la que el que entrevistador no sabe del tema y se limita a ver si el entrevistado sabe inglés o tiene un MBA. Gente buena técnicamente, y de manera probada.
Saludos
Buenas Javier,
¿Cuál crees que son los indicadores básicos que nos pueden indicar -lo antes posible- que el software que se desarrolla empieza a perder calidad y productividad?
Creo que es un tema interesante. Desde un departamento de QA hacer ver con métricas claras que lo que se está haciendo tiene problemas y que estos problemas traerán consecuencias en el futuro.
Un saludo,
Fran
Muy buen post, a veces pienso que al vida de los desarrolladores es como esta película:
http://www.filmaffinity.com/es/film245798.html