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.