Veamos… una cosa es hablar de metodologías, y para desarrollo de software tenemos muchas, desde la tradicional "Que metodología…?", hasta "Extreme-Programing", pasando por otras como "Agile" por ejemplo.

Pero otra cosa muy distinta es, como administramos un proyecto informático?, en particular, como administramos un proyecto informático de desarrollo de software? (y me refiero a una grandecito, tipo 12 meses). Aquí el tema se vuelve muy espinudo, y voy a gráficar con un ejemplo extremo y de antología el tema, solo discutiré en este articulo la relación con el cliente, no entrare en detalles del equipo interno por razones obvias pero tal vez en otro post toque el tema.

Nuestro Cliente X por supuesto, es primera vez que enfrenta un proyecto de desarrollo con una empresa seria (donde yo trabajo), ésta cuenta con metodologías varias incluyendo una para la administración general del proyecto y su gestión al cliente. El nivel de conocimiento técnico del cliente es bastante pobre, y me refiero a la contraparte, ya que estamos hablando de una empresa que esta recién tomando en serio la tecnología como algo mas que un departamento dentro de su empresa.

Escena Numero 1: Pues bien, parten las reuniones, se explica la metodología de administración del proyecto, se muestran y explican los artefactos, desde los templates de minutas de reuniones, hasta los documentos y procedimientos para escalar los problemas diversos incluyendo los temas financieros (costos, pagos, facturación de hitos), hasta la entrega de definiciones por parte del cliente y los plazos y formas para ello, así como otras explicaciones referentes al proyecto en si.

Cuento corto: Me voy a saltar innumerables episodios de este proyecto con el Cliente X para no aburrirlos, pero no esta de mas decir que se notaba un proyecto riesgoso en cuanto a la indefinición del cliente, la cual en todo caso fue lentamente entregándose a nosotros para la construcción del sistema Z. El cual por cierto se diseño con todos los artefactos para ello, incluyendo StoryBoard (screenshot de pantallas de manera que el cliente viera como interactuaria la solución), los modelos de negocio, incluso la parte estética y otros temas menores se definieron en papel mucho antes de la construcción de la primera línea de código. Con el beneplácito de la contraparte técnica de todos estos puntos el proyecto se inicio.

Bien, el cuento no esta muy corto hasta ahora, pero para ir terminando el post les comento que terminado el desarrollo y mostrado al cliente la solución final, escuche una de las frases mas memorables de mi historia como profesional de la informática. Y la cual por cierto me inspiro a escribir este articulo. Debo mencionar que este proyecto y estos eventos pasaron hace ya mas de 1 año. Por lo que la retrospectiva del tiempo me a dado suficientes meses para entenderlo y explicar mejor lo sucedido.

Escena numero 2: El cliente dice…. MMMMmmm si, sabes que Javier, veo que lo han construido bien (performance, gráficas, flujos,etc) y efectivamente esta todo en las minutas en relación a que es lo que pedimos, pero sabes que?…. No me gusta…

Yo digo: Ok, pero es lo que pidieron y podemos ajustar algo, pero es lo que fue definido incluso en la forma, y eso que discutimos varios puntos y finalmente acordamos hacerlo como ustedes querían. El Cliente dice: Si, efectivamente es como dices tu, pero sabes que……(Aquí viene la frase para el bronce)….. NO NOS DEBISTE HABER HECHO CASO!…… (Cric… Cric…. Cric…. Silencio en la sala). El Cliente dice: Ustedes eran los expertos así que aunque nosotros especificamos las funcionalidades y esta todo por escrito no es lo que queremos (Cric…..Cric…. Cric se escucha un grillo a lo lejos…. silencio total).

Estos hechos por cierto no son ciencia ficción (lo recalco). No les voy a contar como termino todo, solo decirles que ese cliente hoy en día es uno de nuestros mejores clientes, y de los mas contentos por cierto. En otra ocasión les contare como se hizo el milagro. Pero en ésta solo quiero comentarles lo siguiente:

Una buena metodología de administración de proyectos de software, bien aplicada, no es certificación de éxito en un proyecto!, no crean y por favor no crean que con llevar todos los artefactos y tener relativamente contento al cliente les asegurara el éxito en su proyecto. Como después de hablar con mucha gente, mi sabio amigo Alvaro me lo explico. "Las metodologías de administración de proyectos no te aseguran el éxito de un proyecto desde el punto de vista de gestión del mismo, solo te aseguran que hiciste correctamente todos los pasos que se deben dar ". Y entonces que fallo?, bueno los dejare en el suspenso, solo comentarles que tanto el cliente como yo aportaron al problema (en mi caso mas inexperiencia que otra cosa), por suerte yo también aporte mucho mas para la solución. Y créame que las minutas y toda la metodología de PM no fueron la razón final del éxito.

Metodologías de administración de proyectos:

"Imprescindibles para el éxito de su proyecto!".

"Si su proyecto tiene Metodología de PM y es aplicada correctamente,

no concluya que el éxito esta asegurado.

(Por favor entienda!…el concepto es asimétrico!)"

PM, Humildemente muy recomendado

Link relacionados al tema PM:

http://www.pmi.org

Javier Urrutia