Las competencias core del Product Manager digital de éxito
31 agosto, 2018
Éxito en software: cuando el Design Thinking se alía con Agile
2 septiembre, 2018
Es un secreto a voces. Una buena parte de los proyectos de desarrollo de software no salen bien. Tan solo hace falta bucear un poco por la red para disponer de unos cuantos datos que nos sirven para refrendar esa afirmación ¿Sabían ustedes cual es la cantidad de dinero que pierde la economía europea cada año por culpa de proyectos de IT que no salen bien? 142 millones de Euros… el 5% de su PIB. Además, globalmente se estima que 1 de cada 6 proyectos de IT tiene un sobrecoste del 200% y un retraso del 70% y que incluso el 17% de los proyectos van tan mal que ponen en riesgo la existencia de la compañía. Es normal entonces que cerca del 75% de los ejecutivos de negocio (y IT) crean que los proyectos nacen condenados desde el principio
Ante estas cifras es fácil preguntarnos ¿Cuántos proyectos salen mal realmente? Para respondernos lo primero que debemos aclarar entonces que quiere decir salir mal. Una definición bastante aceptada en el mundo del software vendría a ser cuando estos proyectos cumplen alguno de estos supuestos: se entregan evidentemente tarde, por encima de presupuesto, con menos de las funciones requeridas, se cancelan antes de acabar o simple y llanamente no se usa nunca una vez entregado.
¿Cuántos proyectos de software salen mal realmente?
Lo segundo que debemos saber es que es una pregunta difícil de contestar. Para respondernos tomaremos diversos estudios realizados sobre proyectos de sistemas de atención al cliente o CRMs. La consultora AMR estima que son un 29% los proyectos de CRM que salen mal, cifra que Forrester eleva al 47% y que Gartner deja en un enigmático más del 50%. Otros como The Economist son más pesimistas aún y elevan el porcentaje hasta un preocupante 56%, cifra que la consultora Butler Group se encarga de minimizar con su alarmante estimación del 70%. A nivel global y referido a los grandes proyectos de IT, la consultora McKinsey nos acaba de convencer reflejando el dato de que el 66% de los proyectos de software van por encima de presupuesto y que el 33% además van por encima en tiempo.
Ante la constatación del hecho es lógico preguntarse ¿Cuáles son los problemas que encontramos y que nos llevan al fracaso? ¿Cuáles son los pecados que cometemos para merecernos esto? Quizás lo mejor para entenderlo es permitiéndome que les cuente una historia.
El desarrollo de un proyecto de software: una historia real
Pepe es el jefe de un Departamento importante dentro de una gran empresa. De él dependen muchas personas que le reportan diariamente quejas y mejoras Tiene una idea que quiere llevar a cabo o bien un problema que quiere solventar. Cree que el software puede ayudarle y para ello destina un dinero. Juan tiene una empresa con muchos expertos que se dedica a hacer proyectos de software. Él cree que puede ayudar a Pepe. Pepe y Juan mantienen una reunión donde Pepe explica lo que quiere y Juan levanta los requisitos de lo que debe construir.
En base a esos requisitos, Juan prepara una propuesta técnica y económica de lo que ha entendido que necesita Pepe. Después de mucho negociar sobre el alcance y los términos de la propuesta, se ponen de acuerdo. Pero, antes de comenzar a construir nada, el equipo de desarrollo de software de Juan escribe como va a ser lo que van a construir. Para conseguirlo, pasan un buen tiempo. A la finalización, Juan pide a Pepe que valide los documentos que explican como va a ser lo que va a construir. Lamentablemente Pepe no entiende los documentos redactados en un lenguaje que él no comprende por lo que se fía de Juan que le asegura que es lo que ha pedido. A partir de ese momento el equipo de Juan comienza a construir. Y pasan los meses.
Después de mucho insistir, Pepe consigue que le enseñen como va la construcción de lo que quiere. Pero, pese a que le cuesta admitirlo, no entiende bien que le enseñan y sigue confiando en que le entregaran lo que quiere por el dinero que ya ha pagado. Después de mucho tiempo y algún que otro retraso, Juan entrega a Pepe lo que ha construido. Es hora de validar juntos lo que el equipo de desarrollo ha hecho. Sorpresa. Pepe encuentra que hay bastantes cosas que no son como las había pensado y le pide a Juan que las cambie. Tras diversas reuniones de una tensión palpable en las que Pepe consigue que se cambien cuatro cosas, Juan le pide más dinero a Pepe para poder hacer lo que el pide realmente y le recuerda que el validó las especificaciones de lo que está viendo.
Después de mucho tira y afloja ambos acuerdan cerrar el desarrollo en el punto en el que está. Cuando Pepe se lo muestra a sus usuarios éstos, además de no ver reflejados sus problemas, lo ven complicado, incompleto y poco usable. Evidentemente deciden seguir con sus viejos Excel.
¿Cuál es la moraleja de la historia? Qué al final Pepe tiene algo que le ha resultado más caro de lo que creía, por lo que ha tenido que esperar un montón, que no es como el quería y que nadie va a usar. Así seguro que Pepe se lo pensará dos veces la próxima antes de confiar en desarrollos de software y pasará a ser parte del 75% de pesimistas
Ahora asumamos por un momento que en esta historia había un caso de negocio que sustentaba el proyecto, había un sponsor ejecutivo que lo apoyaba, quien desarrollaba tenía los recursos adecuados, quien desarrollaba aplicaba las metodologías adecuadas, quien desarrollaba usaba las herramientas e infraestructura adecuadas, quien desarrollaba sabía gestionar el proyecto adecuadamente y que los unicornios existen…
Entonces, si realmente se hubieran cumplido todos esos supuestos ¿Qué ha podido salir mal? Pues simplemente el tema aquí es que todos cometemos pecados.
Los pecados del software
Soberbia
Frecuentemente pensamos por los demás y creemos que tenemos la solución. No preguntamos a los usuarios reales, los que tienen los problemas y usan los programas. No validamos las propuestas con los usuarios. Eso nos lleva a que los requisitos de lo que se “tiene” que hacer no reflejan necesidades reales. Caemos así siempre en el decir QUE debemos hacer para curarnos en vez de decir que nos duele. Además, los ”expertos” de los que crean el software creen que tienen la solución para todo. Ellos tienen la razón…
Gula
También pecamos de gula. Frecuentemente abarcamos más de lo que podemos analizar, gestionar, tratar y digerir. Alargamos innecesariamente el tiempo en que disponemos de cosas tangibles y con valor. Ampliamos así el riesgo de cometer errores. Nuestra ansia de controlarlo todo nos lleva además a eternizamos en los detalles lo que aumenta exponencialmente los tiempos. Sin olvidar que muchas veces los que tienen que desarrollar el software aprovechan para aprender
Pereza
Frecuentemente no sabemos lo que queremos (ni sabemos lo que no queremos). Tengamos en cuenta que el software es algo intangible. Es difícil ponerle forma, color o tamaño… Por el contrario, los seres humanos preferimos decidir en base a la comparación y eso es imposible con el software. Preferimos que nos enseñen para decir si o no. Pero por otro lado, antes de entrar en detalle en algún tema, lo que nos consumirá mucho tiempo, preferimos dar las cosas por sentadas. Y eso pasa sobre todo en aquellos que tienen que diseñar el software. Cuando no entienden al cliente, suponen…
Envidia
Respecto a la envidia, frecuentemente queremos lo que vemos en otras partes, aunque no entendamos bien que es… Todos queremos salir perfectos en la foto y ser los más innovadores. Pero la tecnología avanza rápido y las cosas quedan obsoletas rápidamente. Por eso, muchas veces pedimos que se hagan cosas por la excitación propia de la tecnología, no por necesidades de negocio. Además la gente cuando habla de software no miente, pero tiende a no decir toda la verdad. Son los pescadores modernos… Queremos siempre lo más nuevo, lo que otros nos han vendido como perfecto
Avaricia
