Comentaba irónicamente Alan Davis como la comunidad de ingenieros software en ocasiones le recordaba a los “lemmings”: alguien crea un concepto que sin apenas justificación es apoyado y aplicado por muchos… aunque en ocasiones todos acaben perdidos. Los ejemplos, múltiples, algunos de ellos:
- Las ahora denominadas metodologías pesadas, que en muchos lugares se usaron (y usan) en exceso, sin criterio, lentificando el desarrollo.
- Las ahora denominadas metodologías ágiles, que en el sentido contrario se usaron muchas veces de manera radical, haciendo reaparecer los problemas por los que se crearon las metodologías y el estilo “codifica y prueba”.
- Elementos como los patrones de diseño, que supusieron una moda, se llegaron a aplicar sin control, en exceso, hasta el punto de disminuir alarmantemente la productividad debido a la complejidad que tomaban los diseños (ver).
Ejemplos que aún en la actualidad siguen repitiéndose en numerosos centros de desarrollo y fábricas software, y no sólo con prácticas que se ha comprobado que son erróneas, también por la mala aplicación de las supuestas buenas prácticas.
No es sólo cuestión de conocer las “buenas prácticas” en ingeniería del software. Podemos llegar a conocerlas, disponer de informes de estas en otras empresas, etc., pero en un caso concreto… ¿qué hace más, o menos, idónea a una práctica? ¿en que medida? ¿la organización estará mejor si se implantan?
De manera simplificada una empresa pretende alcanzar un fin económico determinado. Y las organizaciones de desarrollo software, fábricas, etc., son empresas, con un fin económico.
La ingeniería del software en una fábrica o centro de desarrollo es la disciplina que guía el proceso productivo (cadena de valor). Y si la ingeniería del software se aplica a la empresa… esta debe considerar de manera notable los objetivos económicos.
Desgraciadamente los ingenieros de software suelen mostrar poco interés por los aspectos económicos de los proyectos, prácticas y su impacto; la propia disciplina es poco madura en este aspecto (sólo en los últimos años están apareciendo áreas de especialización como la ingeniería software basada en valor). Si bien en la empresa, a ciertos niveles, los términos económicos son el lenguaje que comparten las diferentes disciplinas que conviven en ella (marketing, recursos humanos, finanzas, etc.)
En una empresa dedicada al desarrollo – mantenimiento las prácticas en ingeniería del software son un elemento determinante en los resultados económicos, ya que afectan:
Por lo que se deja de ganar:
- Poca calidad -> problemas en el software -> deteriora la imagen -> y hace, por ejemplo, que el cliente confíe más en la competencia.
- Poca calidad -> retrasos -> desarrollaré menos y facturaré menos.
Por los desarrollos que no pueden ser facturados:
- Horas que sobrepasan la estimación dada al cliente, estas están fuera de la oferta y no se facturan.
Por los sobre costes:
- Principalmente por más esfuerzo, recursos humanos, debido a procesos poco óptimos.
- Costes derivados, por ejemplo, poca calidad del producto, bajo rendimiento y la necesidad de más hardware para ejecutarse.
A lo largo de la historia de la ingeniería del software se han desarrollado soluciones que mejoran la calidad del software, pero rara vez se ha estudiado el valor que aportan en términos económicos. Esto ha agrandado las ya amplias diferencias entre estado del arte y estado de la práctica. Que no se pueda justificar su aplicación en la empresa, su ROI, viabilidad económica, justificar en niveles altos y en términos financieros, etc. El impacto (retorno) económico en la empresa es el elemento que debe guiar la introducción, y medida, de una práctica de ingeniería.
Claro que para muchas empresas el mejorar los objetivos económicos no siempre pasa por introducir prácticas de ingeniería (elevar la productividad, reducir costes, aumentar la calidad, etc). Un error, no sólo en nuestra opinión.
Cuentan Kaplan y Norton como en los años 70 Xerox tenía el monopolio de las fotocopiadoras. Si bien los clientes sufrían la imposición de altos costes, numerosas averías y mal funcionamiento. Pero en lugar de mejorar las máquinas Xerox estableció un servicio técnico de reparación, que se convirtió en la principal aportación a los beneficios; incluso, debido a la lentitud de este, los clientes compraban máquinas adicionales, y los beneficios crecieron aún más. Todos los indicadores financieros marcaban una estrategia de mucho éxito.
Pero los clientes querían unas máquinas fiables, y no un proveedor con éxito financiero. Y cuando los competidores japoneses fueron capaces de ofrecer buenas máquinas, a un precio menor, fueron recibidos con los brazos abiertos. Xerox, una de las empresas de más éxito entre 1955 y 1975, quedó casi en la quiebra.
De manera exclusiva las finanzas son inadecuadas para guiar y evaluar la trayectoria de la organización, el valor que ha sido creado o destruido por los directivos. Desgraciadamente conocemos muchos y cercanos ejemplos. Fábricas que se basan única y exclusivamente en las ventas, y aún siendo su cadena de valor el desarrollo software olvidan la calidad, olvidan la productividad, olvidan la ingeniería. Y se basan exclusivamente en las ventas.
No queremos extendernos más, dejamos este artículo sobre ingeniería basada en valor. Sin duda el tema dará para muchos otros post, y que ampliaremos con algunos trabajos sobre la valoración de económica de las re-ingenierías de productos software.
- 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