Así es. A mí me ha costado años tenerlo claro y asumirlo. Ya te lo he contado más de una vez, en mi vida profesional habré pasado por más de 80 organizaciones y mucha veces me llevaban (llevan) los demonios cuando veía una organización con un desarrollo software tan pobre (ni pruebas, ni control de versiones, etc.) y a la gerencia pasar absolutamente de ello, ni venir a las reuniones sobre el tema… ¿por qué? ¿pero es que no se daban cuenta del dinero y motivación que estaban perdiendo?
Al principio no encontraba respuestas… ¿será cuestión de tiempo? ¿será que me he auto creído yo que hacer bien las cosas es bueno y necesario? Al final, pasaban los años, seguían haciendo mal software y la vida sigue, la empresa sigue, el mudo sigue, siguen vendiendo, etc.
Sí, los buenos desarrolladores se van, los cliente se quejan, pero “no pasa nada”.
Después de apreciar en un número considerable de organizaciones este patrón (no en todas, obviamente), he querido compartir contigo algunas reflexiones, intentar racionalizar esto, más que nada con el objetivo de encontrar respuesta a algo aparentemente sin sentido, por qué hay empresas que no hacen buen software…
1) Porque hacer software con calidad no les supone ninguna ventaja (desventaja) competitiva.
Es decir, que no están ni mejor ni peor posicionados frente a sus competidores por hacer software bien o malamente. Eso pasa por alguno de los siguientes:
a) No tienen competencia.
Normalmente pasa en empresas que tienen clientes cautivos, es decir, que sus clientes no pueden elegir otro proveedor (recuerda lo de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad).
Por ejemplo, pasa cuando esa empresa le lleva desde hace tantos años el desarrollo al cliente que hay ahí tal montada que ya no hay otro que se atreva a meterse ahí.
En cierto modo, y aunque no sean muy conscientes, hasta seguir haciendo software mal es una barrera de entrada a otros competidores. Les afianza para mantener ese cliente cautivo.
Pasa también cuando la empresa de desarrollo es propiedad del cliente, es participada por el cliente, es un departamento del propio cliente, etc.
Como no hay competencia… hacer las cosas bien supone un gasto y una molestia, así que… no me compliques la vida y déjalo como está.
b) Todos los competidores lo hacen igual de mal (o de bien)
Hay sectores en los que todas las empresas que desarrollan lo hacen igual de mal. La teoría dice que si uno de ellos invirtiera e hiciese software de calidad, y con calidad, ello supondría una ventaja competitiva: podría ofrecer funcionalidad a sus clientes más rápido, reduciría costes, aumentaría productividad y obtendría mejor imagen y satisfacción de sus clientes.
Si eso pasase, el resto de empresas verían esto una amenaza a su cuota de mercado y se pondrían “las pilas”.
Pero nadie da el paso. Así que… la cosa sigue como está. Y que nadie de el paso, puede venir de alguna de las siguientes razones:
2) Desconocimiento total del tema por parte de quien toma decisiones
Normalmente, este tema, hacer software bien, es sensible, lógicamente, a aquellos que lo sufren directamente y, además, saben de qué estamos hablando: los desarrolladores.
Pero aquellos que toman decisiones no son desarrolladores, no leerán este post, esto les suena a chino (integración continua, refactorizar, iterar, etc.) y aprender que va esto es un problema. Y apostar (dinero) por algo que ni entiendes es cuestión de tener mucha fe.
Quizás con las generaciones venideras esto cambie, pero por ahora es lo que hay.
Aunque literalmente cada año una empresa pueda perder muchos de euros por mal software… nunca nadie achacará perdidas a una “cosa” que no entiende y que no sabe que existe.
3) Miedo e Inmovilismo
Si que hay un grupo que puede llegar a entender de que va esto ysus implicaciones. Pero muchas veces piensa… si funciona no lo toques. Si ya la empresa vende… ¿para que me voy a meter en este fregado y justificar una inversión de riesgo y cuestionar mi puesto? ¿y si sale mal?
Así que por miedo, e inmovilismo, la cosa se queda como está.
4 ) No hay casos conocidos y cercanos de empresas que han quebrado por mal software
Si hay casos de empresas cercanas, “vecinas”, que han quebrado por mal software… esos casos no son conocidos. Y los casos conocidos suenan muy lejanos (¿el Ariane? ¿Toyota? ¿el healthcare de Obama?) como para que alguien los vea cercanos a su entorno.
Si que hay empresas cercanas que han perdido la partida con su competencia, por no saber desarrollar software bien, pero aquellos que han perdido no creo que ni hoy sepan que aquello fue por hacer mal el software, aun estarán echándole la culpa al destino y la mala suerte.
Concluyendo
¿Entonces no hay empresas haciendo software bien o intentando mejorar? Si claro que las hay, hay muchas. Aquellas que han saltado los pasos anteriores. Y que normalmente suelen estar dirigidas por alguien que conoce algo la importancia de este tema, empresas que compiten en un sector muy basado en la tecnología y con competencia global (ahí no les queda otra) o aquellos que ya se han llevado un susto y han vivido para contarlo.
¿Qué te parece? ¿me he dejado algo?
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Buen post, yo agregaría que en muchas empresas no se hace buen software por que se obliga el uso de productos y/o herramientas software que no se acoplan a las necesidades del proyecto, y todo esto por alguien que se enmarca en el punto dos del post.
Gracias por el post. Ahora comprende mucho mejor el porqué se despilfarran millones y millones de € en las administraciones!
He sufrido esto muchas veces, y … en fin … Enhorabuena por el artículo!
Me ha encantado porque resumen muy bien el hecho de que haya empresas en el mercado del desarrollo del software gestionando tan mal sus recursos. De hecho, el caso b-2 creo que es el desgraciado caso típico de las pequeñas empeñas de desarrollo de software web: Un comercial con dinero que contrata a un par de programadores para hacer páginas web, que consigue un producto con el que crear clientes cautivos y que no tiene ni idea de lo que se le habla cuando se dice refactorizar (lo entiende «perder el tiempo programando sin ver cosas nuevas»). Como le va bien vendiendo y los clientes tampoco tienen mucho conocimiento de lo que hacen ¿para qué mejorar? Tal como dices en el artículo, para ellos son ganas de perder el tiempo y el dinero en algo que no saben para lo que vale, por mucho que les digas que un código limpio es mucho más fácil de mantener y ampliar (a esto te suelen responder que por qué no lo programas limpio y perfecto desde el principio, en fin…) y que es necesario hacer TDD y tener beta testers (¿tests? ¿beta testers? ¿pero tu no lo testeas mientras programas?). Claro, luego gran parte del tiempo se va apagando fuegos en espaguetis, enfados con el cliente, retrasos, etc, etc, casos típicos que ya comentas en otros posts, pero bueno, supongo que será un mal endémico del empresario español y del cliente, que normalmente tampoco entiende nada de software, y al que cuando les pides una aclaración de unas especificaciones vagas te responden con un «está clarísimo, pareces tontito» en vez de especificar claramente lo pedido. Así nos va…
Sí, te has dejado el de los clientes a dedo, y la incapacidad de la administración pública de valorar la calidad cuando ofertan un proyecto.
Hola!
Creo que es cierto mucho de lo que dices, tengo mis diferencias respecto al cliente cautivo. Creo qur no esta cautivo solo que sigue eligiendo porque no le representa ningun daño y se acostumbro a la dinamica. El cliente no esta cautivo, el cliente elige.
Me parece que tampoco estas exponiendo la complicidad de los desarrolladores en estas empresas. Yo como desarrollador lamentablemente tambien forme parte de este tipo de empresas, sin embargo siempre «evangelice» por decirlo de alguna forma sobre los beneficios de desarrollar software de calidad, y tratar de enrrolar mas compañeros sobre esta corriente de pensamiento aunque no siempre con exito. Los que creemos en el desarrollo de software de calidad, las buenas practicas y el agilismo tenemos una responsabilidad de agentes del cambio, de Starters del cambio en las organizaciones. Las organizaciones son, tambien hay que mirar a los que las conforman y si poseemos conocimientos compartirlos, enrolar, y difundir.
Un saludo!
Cuánta razón!
No soy experta en desarrollo todavía(ya me gustaría), pero acabo de huir de una empresa que sirve de ejemplo perfecto para lo que hablas.
Si ahora que estoy formándome empiezo con malas costumbres… no se como acabará la cosa. Empiezo el mes próximo en otro sitio, a ver si tengo más suerte y me encuentro con gente más profesional, que no es fácil.
Un saludo y sigue escribiendo 🙂
Creo que una de las principales causas del por qué hay empresas que no hacen buen software es por la falta de unificacion de criterios en cuanto a lo que las empresas realmente necesitan y lo que las empresas de software «creen» que el cliente necesita. Pero este mal proceder nace desde las universidades mismas que forman a los programadores, pues ellos tampoco unifican criterios acorde a las exigencias del mercado y los presupuestos son mayores para las empresas que se encuentran con que necesitan capacitar mas a su personal o que no pueden proveer soluciones eficaces a sus problematicas de manejo de informacion. Es tiempo que las universidades realmente formen profesionales para un mercado real y no basados en congeturas, suposiciones, hipotesis sobre como funciona las empresas.
Ni que decir, realidad global. acá en Chile no es muy lejana la similitud. También ya con años de experiencia y pasando por muchos proyectos y empresas es cierto que hay un dejo de laxitud en darle la prioridad a las buenas prácticas, en lo personal comparto la posición del comercial que vende algo que no entiende a un cliente que entiende menos y ve el desarrollo como algo alienígena. Trato de evangelizar en buenas prácticas, a veces con éxito otras no, he podido disfrutar de ciclos productivos bien armados y en estos momentos educando a comerciales sobre el simple hecho de que el esfuerzo tiene un coste y que no se le debe ocultar al cliente que esto es así y que la calidad de software debería primar con el objeto de mejorar y no parchar lo que se empezó mal
Yo te lanzo una pregunta: crees que cuando clientes como el BBVA y Santander contratan su «transformación digital» a empresas de fuera en vez de darle el trabajo a equipos de expertos nacionales (que aguantan el chaparrón y no emigran) pueden las empresas querer desarrollar bien?
Y otra: crees que los que han crecido profesionalmente dentro de esa forma de trabajo (ya sea dedicados a la empresa o reciclados en la enseñanza) van a poder realizar ese cambio de mentalidad? (yo he llegado a escuchar «es que siempre se ha hecho así» y al responder «que siempre se haya hecho así no implica que así esté bien hecho» … uf, apaga)
De verdad, me gustaría conocer tu opinión. La mía es que me ha resultado bastante esquizofrénico tanto conflicto de interés y perspectiva y empecé a cogerle bastante miedo al verbo «delegar» y ya ni te cuento al término «equipo».
Pero como la esperanza es lo último que se pierde y tu opinión no sólo es de las buenas sino que además es cercana, espero tus respuestas. Gracias.