Además te voy a decir el truco de verdad para solucionar tus problemas rápido. 
Quieres saber cuál es la única manera que se ha inventado de lograr rápidamente y sin dolor resolver tus problemas con el desarrollo software: dejar de desarrollar software.
Si te han contado, vendido, leído en un blog o ppt, que implantando la nueva metodología “scrUP v 7.2”, o el nuevo ciclo de vida “iterascada v 9.0”, rápida y maravillosamente, en poco tiempo, se resolverán de manera instantánea tus problemas de desarrollo software… probablemente te han engañado.
Nadie ha mejorado significativamente su desarrollo software (es decir, ha obtenido mejoras sustanciales económicas, de productividad o calidad) sin disponer primero de un buen equipo técnico – humano (es decir, el más adecuado a su desarrollo – negocio, te recomiendo el post de lo más determinante para el éxito son las personas) y una cultura en la empresa que permita la mejora. Si ese tú caso, si ya dispones de los anteriores, entonces sí, empieza a estudiar la mejor metodología para tus circunstancias, a formarte, y a mejorar tú metodología, lo que también te llevará muchos meses. Si no, mejor prepara los cimientos, mejora el equipo y crea una cultura de mejora. Siento ser tan directo, pero creo que así queda más claro.
Sí no hay buen equipo y cultura de mejora olvídate, ahorra dinero en cursos, y ahórrate decepciones. Hay miles de organizaciones que jamás consiguen mejorar de verdad su metodología, ni logran mejoras económicas, de productividad o calidad sustanciales. Hacen algún cursito, contratan a algún consultor, etc. Pero luego (como no hay ni cultura, ni equipo) todo queda en nada, se olvidan, y siguen teniendo enormes sobre costes y grandes problemas de calidad en sus productos, pero… sobreviven. Es otra estrategia, mientras que te lo permita el mercado y tus clientes.
Y esto os lo cuento por experiencia, por la mía propia y por la que otros documentaron hace años. Déjame que te resuma algunas experiencias:
Dos experiencias mías (de entre muchas similares)
Te podría contar muchas, pero por no extenderme te resumo dos historias reales.
Historia 1. Empresa en la que trabajé hace unos años, 100% de desarrollo software. Equipo técnico genial, muy bueno. Todos con enormes ganas de hacer las cosas bien, y con conocimiento para ello. Pero para la dirección, que era principalmente comercial, con cero conocimientos técnicos, esto invertir en palabras metodológicas raras, eso de estimar en vez de que el comercial dijese por teléfono al cliente cuanto se tardaba en hacer un desarrollo, eso de que las planificaciones debían contemplar tiempo para gestión de la configuración, etc., le parecía tirar el dinero. Resultado, fracaso. Tiempo desperdiciado por el equipo técnico, que al final se fue.
Historia 2. Empresa en la que trabajé algunos años después, 100% de desarrollo software. Equipo técnico con mínimos conocimientos técnicos. Las decisiones técnicas y del día a día las decidían gente con conocimiento funcional en temas económicos y financieros. Una parte de la dirección muy motivada por mejorar, y conocimientos de cómo hacerlo. La cultura de la empresa muy de “déjame como estoy que así estoy muy bien”. El software que se hacía era bastante malo, gran cantidad de incidencias y con enormes sobrecostes… pero el cliente pagaba por él. Resultado, fracaso (para quienes querían mejorar). Tiempo desperdiciado por el directivo técnico, que al final se fue.
Experiencias, documentadas por otros
Entre otros muchos, ya lo dijo Brooks en el 75 (te recomiendo este post), que muchas veces, nos ofrecen, o buscamos nosotros, tentadoras “balas de plata” (el “iterascada v 9.0”) que rápido, con apenas esfuerzo, nos solucionen los problemas (bastaría pasar por algunos foros y conferencias para ver muchas “balas de plata”), que de manera inmediata prometen acabar con el monstruo en el que en ocasiones se convierte un proyecto software. Pero, según Brooks: “que sepamos, hasta la fecha apenas se han descubierto unas pocas balas de plata, y ya hace tiempo de ello”.
Y también lo dijo en su día Parnas (te recomiendo aquí este post), cuando comentó aquello de que no andes buscando nuevas soluciones mágicas para tus problemas de desarrollo, que la mayoría de las soluciones ya se inventaron, lo que toca es la dura tarea de aplicarlas.
Y si lees los problemas que tenían el desarrollo software hace 40 años, verás que son los mismos de hoy.
Alguna conclusión
Cuando alguien está desesperado, tiene problemas en su empresa, su cliente está a punto de romper con ellos por la baja calidad de su software, etc., es candidato a caer en las sectas, pseudociencias metodológicas o en gastarse el dinero pensando que su problema se solucionará rápido.
Pero piensa que hace no tantos años lo mismo se prometía con el diseño estructurado, y los problemas se minimizaron pero no todos, ni sin esfuerzo por el equipo. Y lo mismo pasó con UML, con la OO, con CMMI o pasará con Scrum.
¿Han sido buenas aportaciones las anteriores? Buenas no… buenísimas. Pero han sido buenísimas mejoras, no soluciones mágicas. Y aquellos que más supieron sacarles partido fue porque antes contaban con un buen equipo técnico – humano y una cultura en la empresa que permita la mejora. Los anteriores, más la incorporación de la nueva metodología, fue lo que les hizo mejorar sustancialmente.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- 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
Typo: exfuerzo
Gracias por el artículo.
Un saludo.
Pingback: Bitacoras.com
😉
Muy bueno el artículo.
Ingenioso título e interesante reflexión, enhorabuena.