El Director de Proyectos es el responsable de TODO y el dueño de NADA.

Por: David Miranda

Alolargo de mi carrera he tenido la fortuna de dirigir proyectos de tecnología y he pecado al hecho de creer que somos los dueños del servicio o producto que nacen de nuestros proyectos.

Prácticamente es nuestra creación nuestro hijo, vemos a nuestro nuevo sistema y queremos lo mejor para él, visualizamos su futuro y el éxito que tendrá, como interactúa con las personas que le pidan información y cuando sea maduro la cantidad de datos que puede ofrecer para mejorar el negocio. Por lo que necesita que pueda correr y moverse rápido y empezamos a evaluar mediante estudios de mercado la infraestructura donde estará nuestro sistema. Necesitamos al personal mejor calificado para que nos ayude a crear en cada detalle sus partes, sus componentes y platicamos con los interesados (stakeholders) para mostrar nuestro prototipo del proyecto.

Si toda sale bien, nos autorizan el proyecto y nos dan la patada de Inicio (Kick-off), ahora si hay que detallar muy bien cómo vamos a crear a nuestro sistema, nuestro nuevo hijo, debemos identificar si el ciclo de vida de nuestro proyecto será predictivo o adaptativo, puesto que el desarrollo de software es muy variable y siempre existen objetivos y alcances que cambian el proyecto tendremos que irnos por un adaptativo, que cumpla con interacciones y entregas incrementales. Vaya ya empezamos con tér- minos complicados y aún no iniciamos, pero no hay de qué preocuparnos las metodologías ágiles nos ayudan a controlar esto (espera ahora estamos hablando de metodologías). Cuando escuché el término metodología, lo utilizaba de forma incorrecta en su término, si queremos hacer un pastel, no iniciamos con hornear, primero necesitamos crear la masa, ponerla en sus moldes y después hornearlo, esto es una metodología, procesos que debemos cumplir sin omitir o saltarnos otros.

Como todo buen director de proyectos sacamos nuestra “biblia” que es la que nos ayudará y es el PMBOK (por sus siglas en inglés Project Management Body of Knowledge) excelente entonces ¿el PMBOK será nuestra metodología? Esté es el pecado mortal de escuchamos muchas veces, el PMBOK no es una metodología, contienen una guía de orientación y es un estándar internacional del PMI (Project Management Institute) que para la Dirección de Proyectos, por lo que podemos utilizar los procesos (que son buenas prácticas) que sean necesarios en nuestro proyecto.

Empezamos con nuestro cronograma de actividades y poniendo quien la realizara, cuánto costará cada tarea y su duración, esta Planificación deberá ser lo más apegado a la realidad por lo que no podemos dejar que se nos vayan detalles y riesgos, nada puede salir mal ya que creamos una estructura de desglose de trabajo (EDT) con lo necesario para tener un panorama y visión general de nuestro proyecto.

En lo personal el EDT es una maravilla, tuve la fortuna de ser director de desarrollo durante más de 15 años y les exigía a los administradores de proyecto que me entregaran el EDT y me lo explicaran, ahí podía ver si el proyecto estaba bien alineado y contaba con los componentes necesarios para su producción, así como saber si el administrador de proyectos tenía el conocimiento necesario para llevar dicho proyecto.

Ahora sí “manos a la obra” y comienza la Ejecución. Adquirimos una infraestructura robusta lista para cualquier contingencia, si existiera una interrupción eléctrica, nuestra infraestructura deberá tener su propia energía ya sea una planta de luz o un UPS (Uninterruptable Power Supply) que permita seguir alimentando de forma ininterrumpida nuestro hardware. Las venas que tendrá nuestro sistemas, nuestro hijito no pueden ser delgadas que se saturen a la primera con el flujo de datos, necesitamos lo mejor, así que la red deberá tener un ancho de banda bastante grande y rápida, por supuesto deberá ser segura que no sea intervenida para desviar nuestra información, por lo que sacrificamos un poco de velocidad e implementamos esquemas de encriptación.

Empieza a llegar los primeros hitos (milestone) y sus primeros entregable, lo que no se ve, los cimientos, es por eso que nuestro nuevo sistema deberá tener un buen “cerebro” que pueda integran dan cantidad de datos, que los procese y los analice, que se relacionen entre sí, para eso deberá estar en el mejor gestor de base de datos ya que le estarán preguntando día y noche como está procesando esa información, los contadores pedirán cada transacción realizada, los financieros necesitarán los reportes de resultados, cada área de la empresa estará detrás de él pidiendo cuentas, no faltará el que diga, yo lo hacía más rápido que lo que lo hace ese siste- ma, ese sistema lo hace mal. Por lo que implementamos un monitoreo y control constante durante la creación de nuestro nuevo sistema. Hay inconvenientes que surgen, no siempre planeamos todo, “nunca falta un prietito en el arroz”, pero estamos preparados para cualquier control de cambios que mejore el resultado y de valor a nuestro proyecto. Es momento de iniciar con pruebas de calidad, evaluar y verificar que nuestro sistema hace lo que se supone está programado y lo sometemos a diferentes pruebas desde pruebas unitarias, pruebas funcionales y pruebas de integración, lo pasamos por diferentes ambientes antes de alojarlo en su nueva casa que será producción.

Hasta ahora el sistema cumple, con algunos bugs (hallazgos) que deberán ser corregidos, no queremos que esos hallazgos se convierten en errores al momento de su liberación a producción, cuidamos que cada pieza sea acoplada en base a nuestra línea base. Todo marcha a la perfección, hemos mitigado cada riesgo ya sea positivo o negativo.

Es momento de ver cómo se está generando la documentación de nuestro nuevo sistema, nuestro hijito debe estar muy bien explicado en memorias técnicas que sirvan para un diagnóstico futuro al momento que exista alguna falla.

Como vemos el director de proyectos es el RESPONSABLE de todo lo que está pasando en el proyecto, es quien debe estar en constante comunicación con el equipo y los interesados. Las reuniones de seguimiento son necesarias para evaluar que lo planeado va en tiempo.

Estamos en las rectas finales, necesitamos asegurar que el código cumple con los estándares y buenas prácticas, ya que buscamos que esté siempre vigilado para que ningún hacker le inyecte datos erróneos y lo lleve por el mal camino, es por eso que solicitamos a las áreas de ciberseguridad y monitoreo una constante vigilancia de sus signos vitales, que le hagas sus estudios de vulnerabilidad al software para revisar que está bien.

Ahí es donde los directores de proyectos no soltamos y creemos que somos dueños del sistema, de una de sus partes y no es así, cada área es responsable de su parte que le corresponde por atribuciones y son los expertos en que esté funcionando correctamente, es por eso que el director de proyectos debe trasladar esa responsabilidad a ellos, un buen cierre donde se haga entrega de todos los componentes del sistema. Porque al final los directores de proyectos son los responsables de todo lo que sucede en el proyecto, desde su inicio hasta su fin, después de esto el director de proyectos no puede ser dueño de nada ya que todo fue entregado a los involucrados y a sus áreas correspondientes.