Un proyecto técnologico, un mundo

Llevo más de un año trabajando como Project Manager en Octo Inc., utilizando principalmente el modelo de gestión Lean Project Management. No ha sido un camino fácil, pues el mundo de gestionar y coordinar un proyecto de desarrollo de software a la medida, no lo és. Lo anterior, no se da por el hecho que implique mayores conocimientos específicos o restricciones más complejas, lo es porque hay que administrar y hacerse cargo de mucha subjetividad de parte de los usuarios finales de la aplicación web.

Este post tiene como objetivo responder a la pregunta ¿En la gestión de un proyecto tecnológico, hay un común denominador de problemas entre todos los proyectos? La cual será respondida al finalizar este escrito, pero antes de esto quisiera incursionar un poco más sobre Agile y contarles mi experiencia. Mi aprendizaje específicamente con algunos clientes, con los cuales se han utilizado en su mayoría una metodología de trabajo híbrida, es decir, gestión de proyectos tradicional y un conjunto de principios de desarrollo de software conocidos como Agile.

Las prácticas ágiles son pautas que sugieren cómo debería ocurrir el desarrollo de software para obtener los mejores resultados y para familiarizarse con dicho enfoque, les presentaré los 12 principios que son los pilares fundamentales en los cuales se sostiene.

Entrega temprana y continua	Entrega con frecuencia	Progreso de prototipos de trabajo	Bienvenida al cambio de los Requisitos
Excelencia técnica y buen diseño	Desarrollo sostenible	Desarrollar proyectos alrededor de personas motivadas	Foco en la simplicidad
Colaboración diaria	Self Organizing Team	Reflexionar sobre el comportamiento del equipo	Fomentar la interacción cara a cara

Aunque se vea muy lindo escrito, estos principios al no tenerlos presentes y si no son aplicados antes, durante y después de un proyecto tecnológico, no se tendrán los resultados esperados por el cliente y por el equipo de desarrollo. A continuación les contaré sobre la estructura ideal para llevar a cabo un proyecto tecnológico.

Cada persona en particular es un mundo, por ende, entender sus intereses, problemas, frustraciones o motivaciones es un gran desafío. Esto homologado en un proyecto tecnológico requiere que para comenzar a desarrollar se deba entender a cabalidad lo que el cliente requiere. Esto no se da durante una o dos reuniones, se da mediante la comunicación constante y sincera entre los usuarios finales y el equipo de desarrollo. Puede, y de hecho muchas veces ocurre, que ni siquiera quienes realizaron la solicitud de crear y tener disponible una aplicación web, separan bien realmente lo que desean. Por esto mismo, es crucial que la comunicación no sea solo al principio del proyecto, sino que sea constante. Lo anteriormente expuesto, resulta en que sea crucial realizar reuniones continuas y exhaustiva entre el equipo de desarrollo y los usuarios finales, esto es lo que se conoce como etapa de Diseño y Especificación.

Luego cuando ya nos encontramos construyendo la solución que el cliente requiere, se deben gestionar los riesgos. Para administrarlos, se van analizando y mitigando constantemente, los diferentes riesgos comerciales, técnicos, gerenciales, de programación o de seguridad. Esto no quiere decir que debamos escribir en una hoja todos los riesgos que hay al llevar a cabo un proyecto y no revisar nunca más ese documento, significa que debemos identificarlos y eliminar dichos riesgos. Pero ¿cuál es la mejor forma de eliminar o aminorar dichos riesgos que aparecerán inevitablemente? La mejor manera es conversar y comunicar esos riesgos a tu equipo y junto con ellos tomar las medidas para lograr aminorarlos. También se le deben comunicar estos riesgos al cliente, para hacerlo parte y partícipe, así poder aminorar o evitar que esos riesgos se conviertan en problemas reales. Lo descrito antes, corresponde a la fase de Implementación.

Posteriormente continúa la fase de Verificación y Validación. En esta etapa es donde se evalúa si el producto cumple con los requisitos. Además de evaluar si satisface las necesidades del cliente. Esta fase es crucial, cuando se prueba si las cosas funcionan bien o no, se puede realmente saber y entender el desempeño de cada trabajador, según las tareas que realiza cada uno se puede observar si cumplio con la calidad exigida, si entiende rápidamente los requerimientos, si tiene la capacidad de resolver problemas rápidamente, entre otros. Estas actividades ayudan a verificar que el producto que se ofreció haga lo que se supone que debe hacer.

Al final cuando ya está el producto de desarrollo de Software listo y probado, se debe analizar las cosas que se hicieron bien y las que se hicieron mal. Esta fase se llama Evaluación. Pero esta evaluación no sirve de nada, si no hay sinceridad por parte del equipo de desarrollo, de parte del Jefe de Producto y del cliente. Se debe cuestionar en relación a si fueron implementados realmente todos los requerimientos, si la calidad fue la comprometida, si el equipo de trabajo estuvo realmente comprometido, si se cumplieron los plazos propuestos, si los requerimientos fueron los adecuados, entre otros factores más. Estos nos ayudan a no hacer dos veces las cosas mal.

Ahora que explique, de manera muy general la estructura de trabajo con la mayoría de nuestros clientes, les quiero decir que esto no se da perfectamente con todos. Y si te preguntas ¿por qué no se aplica para todos esta misma estructura? La respuesta es porque se trabaja con Personas, y como mencione anteriormente, entender los intereses personales, problemas reales, frustraciones o motivaciones de cada persona es un desafío continuo.

Las estructuras para trabajar y llevar a cabo un proyecto deben ajustarse a las necesidades y realidades de cada cliente. Algunos clientes requieren de una solución que no incluye en la planificación a todos los usuarios finales, aunque no sea una buena práctica en el mundo de Software, se deberá seguir con el proyecto pero teniendo en consideración el inminente y gran riesgo que en un futuro próximo la solución requiera de muchos cambios, no incluidos en la planificación inicial. Por otro lado, hay clientes que son muy esquematizados y que están poco acostumbrados a los cambios continuos que supone la construcción de una solución de desarrollo de software. Lo que puede ocasionar no cumplir con los plazos establecidos desde un principio por cambios de alcance o por solicitud de nuevos requerimientos no contemplados. Esto lleva a constantes frustraciones de parte de los clientes, lo que no es una sensación agradable de sentir, pues la mayoría de las veces esa frustraciones es traspasada al equipo de desarrollo. Otro tipo de cliente es el que solo desea comunicarse con el Jefe de Proyecto o Dueño del producto, sin considerar en las reuniones de requerimiento al equipo de desarrollo, quienes serán los encargados de construir lo que necesita. Esta práctica es la que encuentro la más ineficiente de todas, pues supone un mayor desperdicio de horas en comunicar al equipo de desarrollo lo que desea el cliente. De igual forma, supone mucho riesgo de comunicar de mala manera el requerimiento, lo que traerá sólo resultados negativos. También está el caso de clientes que involucran a tantas personas en el procesos de gestión de requerimientos, que no hay posibilidad de llegar a consensos claros y simples de implementar, lo que produce indecisiones de cómo construir un requerimiento en particular. Muchas veces mucha información, perjudica la toma de decisiones.

Por lo tanto y respondiendo a la pregunta, en la gestión de un proyecto tecnológico no hay un común denominador de problemas entre todos los proyectos. Todos los proyectos son mundos aislados, pueden tener similitudes en procesos o requisitos pero nunca ser iguales.