El lo quiero todo y el porqué los proyectos Software fracasan
Esta entrada no es una entrada de metodologías, ni de gestión de proyectos, ni de cómo abordar la toma que requisitos, sino de sentido común, el cuál muchas veces no es el más común de los sentidos.
Todos los proyectos Software empiezan con una idea, incluidos los que corresponden a migraciones de un producto, que desarrollado en un lenguaje de programación (llamémosle obsoleto), debe por razones que no voy a analizar ni enumerar ahora, ser migrado a una tecnología más moderna.
Es sobre este último tipo de proyectos, los que desean ser migrados, donde deseo detenerme para abordarlo en esta entrada.
Y es basándome en mi experiencia en cuanto a migraciones de proyectos se refiere, concretamente sobre Visual FoxPro y VB6 a .NET, que cuando tenemos delante de nosotros un reto como es la migración de la aplicación a una tecnología más moderna, debemos detenernos a pensar no cómo abordarlo, que es algo que debe ser tratado más adelante, sino el qué.
Decidir el qué es la primera pieza del puzzle, y es tan vital como el respirar para un ser vivo.
Parece una paradoja porque todos sabemos que la toma de requisitos es vital y debe ser el primer paso a abordar. También sabemos que todos los requisitos deben estar claramente identificados. Ahora bien, un requisito no implica realmente abordarlo sí o sí en la primera versión de una migración. Pero voy a explicarlo mejor.
En una migración no sólo tenemos la oportunidad de hacer mejor nuestro producto en una tecnología más moderna, sino que incluso podemos mejorar el producto reestructurando las partes que lo forman y añadir nuevas características que aporten al producto un valor añadido. Ahora bien, la pregunta entonces sería… ¿dónde poner el límite o donde cortar esos requisitos?. ¿Los incluimos todos?.
En mi experiencia he visto un poco de todo, y lo que más me ha sorprendido siempre son las ansias por abarcar demasiado sin poner límite, algo que creo puede resultar en muchos proyectos un fracaso. Como dice el refrán, el que mucho abarca poco aprieta, y si hiciéramos caso al sabio refranero español, nos evitaríamos muchos problemas.
Si lo que queremos es incluir absolutamente todo, correremos el riesgo de fracasar en nuestro intento, y de que lo que iba a ser una migración plácida y satisfactoria, se convierta en un quebradero de cabeza, una pérdida de dinero, y por lo tanto un estrepitoso fracaso.
Es por ello, que desde mi personal experiencia y dependiendo lógicamente de la complejidad y extensión del proyecto, sugiero delimitar claramente los bloques que van a formar parte de lo que será la versión 1.0 del producto migrado, para posteriormente y a partir de esta primera versión que verá la luz en el mercado y saciará las ansias y demandas de nuestros clientes, preparar una versión 1.1 ó incluso 2.0.
¿Ejemplos sonados de esto?. Pues tenemos varios, pero me quedo con dos a modo de prueba de concepto.
Uno de ellos es Visual Studio 2002, es decir… .NET Framework 1.0.
¿A alguien le suena Visual Studio 2003?. ¿Sí verdad?. Pues con esta versión se incluyó .NET Framework 1.1.
Es decir, Microsoft decidió sacar a la luz la versión 1.0 de su producto sabedor que el mercado la esperaba.
Mientras tanto, los equipos de Microsoft tenían ya preparadas mejoras para esta primera versión, pero no llegarían a la salida de esa versión, así que decidieron esperar unos meses e incluyeron esas mejoras en lo que denominaron como versión 1.1.
El mercado se quedó saciado inicialmente con la versión 1.0, y lo más importante, se puso en el mercado esa primera versión del producto que era el objetivo fundamental de lo que hoy es .NET. Si no se hubiera tomado esa decisión, quién sabe lo que habría ocurrido.
¿Otro ejemplo?.
Uno más reciente. Windows Phone 7.
Sobre este producto, comentar que Google y Apple han golpeado bastante fuerte, y Microsoft con su Windows Mobile 6.5 apenas podía reaccionar o ni tan siquiera hacer algo meritorio. Llegaron bien al mercado pero los años habían pasado y su producto apenas tenía innovación y estaba en vía muerta. De ser una tecnología dominante, pasaron a ser dominados por la competencia.
Microsoft necesitaba dar un golpe de efecto, así que rediseñaron su sistema operativo Mobile y lo hicieron de cero.
El mercado demandaba una reacción acorde a los tiempos por parte de Microsoft. El mercado sabía que llegaban tarde a esta fiesta, pero ¿para qué esperar a sacar una versión que cumpliera con todos los requisitos que tenían?.
Mejor sacar Windows Phone 7, sacar posteriormente un Service Pack 1 que incluya mejoras (por poner un ejemplo, Copiar y Pegar), y en el futuro próximo sacar una nueva versión (¿Windows Phone 8?).
Como vemos, todos queremos todo, eso es evidente, pero a veces por querer incluir todo, podemos no llegar a la meta y fracasar en nuestros proyectos.
También es cierto que podemos fracasar por no llegar a implementar los requisitos fundamentales, pero por eso es necesario realizar un buen estudio previo que será abordado después de tomar todos los requisitos del proyecto y delimitarlos claramente, así como marcarse un roadmap claro y abordarlo con decisión y sin dudarlo.
Esta forma de trabajar, sí que puede ayudarnos a cumplir con los propósitos del mercado y de los clientes, y lo más importante, evitar que nuestros proyectos Software fracasen.
9 Responsesso far
Muy acertado el post con respecto a los tiempos y a lo q con mucho abarca…..
Esto me lleva en parte a lo que ya discutíamos antes sobre migraciones de VB6, que algunas si que se pueden migrar directamente (para luego mantener) con herramientas como las de Artinsoft, pero otras…. si que implican recodificar, y ahí entra el análisis que indicas.
Concretamente conozco una aplicación que ha crecido inyectandosele pantallas y procesos que no recomiendo migrar directamente sino tan solo rehacer y reconstruir, pero ahí el trabajo fundamental sera ver que funcionalidades dejaron de ser usadas, cuales se usan una vez al año y cuales cada día, para de esta manera hacer el plan de releases. Siendo que a efectos de no parar la producción sea necesario hacer releases nuevos de la aplicación antigua para ir deshabilitando las funcionalidades que ya se han ido migrando.
Suerte que ya no estoy en ese proyecto, aunque mucho me temo que esa migración la seguirán pateando hacia adelante hasta que Windows 8 los obligue a ello…
Hola Ernesto.
Como siempre, muchas gracias por aportar tu personal granito de arena.
Tan sólo puedo decir que estoy totalmente de acuerdo con lo que comentas. Va en la línea de lo que comento en mi entrada, pero es que además coincide 100% con lo que he vivido yo en varias empresas diferentes.
Un saludo. 🙂
Aunque solo sea por la simple razón de que los entornos de programación obsoletos dejan de recibir mantenimiento por parte de sus editores responsables, no nos queda mas remedio que saltar al último.
Gracias por comentar Miguel.
A veces no sólo es por lo que dices (que también) sino por que la nueva tecnología lleva implícitos ciertas mejoras que nos obliga de cierta forma a migrar el Software sí o sí, para entre otras cosas, ser competitivo con respecto a los avances del mercado, y obviamente con respecto a la competencia.
En muchas ocasiones, los «soldados» no entienden muy bien las estrategias de los «generales», y siempre opino que no está de más que las estrategias globales se pongan en conocimiento de todos para saber bien en qué dirección remar y porqué, pero en esas ocasiones se toman decisiones estratégicas que a veces salen bien y otras no.
Un saludo.
Gracias por el ejemplo de Windows Phone 7, me lo apunto para convencer a jefes y clientes.
Comparto la idea de migraciones progresivas como mejor solución, pero quiero añadir que pueden requerir un sobrecoste por la necesidad de sincronizar antiguas y nuevas bases de datos, en el caso de que aprovechemos también para actualizar su estructura, como suele ser conveniente. Aunque los módulos sean bastante independientes, suelen existir conexiones (lógicas entre los distintos departamentos de la empresa) que habrá que realizar de forma provisional con pasarelas que después se descartarán.
Pero pese a este sobrecoste, coincido contigo en que tu propuesta de no abarcar todo el proyecto de golpe es la mejor.
Un saludo 🙂
Hola Jorge
Esta es la forma en la que algunos administradores o contratistas de proyectos deberian enfocar al momento de empezar el suyo propio, muchos creen que contratando 20 ddesarrolladores y/o QAs podran entregar TODO el proyecto, equivocados mis queridos amigos. 🙂
Estoy totalmente de acuerdo contigo Jorge y no es otra cosa que aplicar YAGNI y KISS 🙂
Un abrazo
@Pablo, muchas gracias por opinar. 🙂
Tienes razón con lo que comentas pero en determinadas circunstancias. Date cuenta que el hacer un proyecto de migración parcial requiere en primer lugar identificar las características y delimitarlas, en segundo lugar presentar qué características irán en esa primera versión e incluso preparar un roadmap del producto, y en tercer lugar, que varios departamentos tengan claro y estén de acuerdo con lo que se va a hacer.
A partir de esto, se puede entregar un producto bastante grande como para satisfacer las necesidades más importantes que demandan los clientes para abordar esos pequeños detalles (no menos importante) en otra fase.
Lamentablemente he conocido proyectos de migración que han fracasado, que llevan 5 años intentándolo y fracasando por querer todo a la primera, incluso por ejemplo queriendo pasar de VB6 a SOA (no WCF, hablo de SOA) directamente como si lo de hacer servicios fuera coser y cantar.
Por supuesto que es un sobrecoste, pero es lo que he puesto en otras entradas acerca de la inversión y del ROI. Es una forma de tener un primer retorno de inversión y justificar los costes de alguna manera. Lo demás, son fracasos absolutos normalmente.
@Enrique, no tengo más que añadir a lo que has dicho. 🙂
Muy bueno el post, Jorge.
Yo estoy en una situación similar en mi empresa.
Tratando de abarcar mucho, al final todavía no hay nada de nada.
Se oye Silverlight, luego que si nube y así continuamente. Al final nada de nada y el tiempo pasa.
@laser,esas cosas nunca terminan bien, pero ¡mucho ánimo!.
Al final, cuando las empresas se ponen así, la culpa es siempre de los remeros, a los que les echan por incopetentes.
Aquí va la historia (cualquier parecido con la realidad es pura coincidencia): http://www.hermanotemblon.com/?p=562
Un saludo y gracias por comentar. 🙂