Dependiendo del sector de la industria el estilo de liderazgo y gestión variará, y enfocare este ejemplo del día a día en la vida de un Project Manager de la industria de la banca y finanzas liderando proyectos de tecnología en un contexto Venezuela.

En hora buena has ingresado en un banco y estarás bajo la dirección de la PMO o GGP (Oficina de Gerencia de Proyectos o Gerencia General de Proyectos, etc), te han asignado 2 o 3 proyectos y el día a día te puede llevar elaborando una serie de actividades de gestión tales como:

• Preparando convocatorias a reuniones de levantamiento de requisitos con las distintas áreas de negocio.
• Recaudar información del alcance del producto o refinando el documento funcional o cualquier otra formato contenedor de información de lo que se va a desarrollar.
• Redactar y completar minutas de reuniones que surgen durante la gestión de los proyectos.
• Cazar¹ o perseguir a los involucrados del equipo del proyecto para las aprobaciones de minutas, actas de constitución de proyectos, aprobación de documento funcionales, cierres de proyectos, u otros documentos relacionados a la gestión.
• Convocar y organizar para ejecutar reuniones de seguimiento y control de proyectos.
• Convocar a reuniones con grupos o usuarios funcionales para gestionar los nuevos cambios al documento funcional que amerita ser desarrollados por nuevos cambios al proceso de negocio.
• En algún momento dado te conviertes en un Jalabolas² por un día con las personas que están involucradas con las tareas de ejecución para que te actualicen el plan del proyecto y así puedas determinar el % avance y retraso que puede tener el proyecto según el plan.
• Gestionar informes de resultados donde en ocasiones puedes llegar a inventar avances con números fantasiosos, por ejemplo el Proyecto X lleva un avance de 15%, ¿Y qué es el 15%? Bueno los entregables en documentos como acta de constitución firmada y aprobada por los principales líderes que representa las áreas de negocio, tecnología y procesos, un par de minutas, el Gantt al detalle con fecha fin estimado a tal día, identificación de riesgos. ¿Y el producto o parte del mismo funcionando donde se evidencia su avance de desarrollo? Eso si no te lo puedo dar en este momento hay que esperar que pase a QA más o menos en 2 meses, Oooo!!, que buena gestión de proyectos estas haciendo eres todo un seco³ en el proyecto como dirían los hermanos de Chile.
• Cuando te queda algo de tiempo buscas herramientas para mejorar tu gestión, entonces te quedas con el chip mental de que realmente tienes que garantizar el cumplimiento del alcance, costo y tiempo del proyecto porque así te miden también como líder de ese proyecto y te pones creativo diseñando reportes y gráficos para mostrarles la ruta crítica, curva S con más números fantasiosos a todos los que conforman el equipo de proyecto con la intención de marcar presión porque tienes la sensación de que esta forma logras el sentido de urgencia y la importancia de llegar a la fecha y cerrar el proyecto.
• Cuando llegan las reuniones de seguimiento y presenta retrasos porque según el plan te lo indica empiezas a usar un lenguaje inquisidor, según el plan debemos estar en 65%  y no estamos, ¿Qué paso?, ¿Y porque?, empiezas a enterarte de cosas que sucedieron y que no te tomaron en cuenta para notificarte, ¿Cómo llegamos a la fecha?, ¿Qué recurso necesitamos?, una conversación que lleva a la gente a la justificación del porque no estamos alineados al plan según planteado inicialmente, deberás ahora replanificar el proyecto, contabilizar esa replanificación, actualizar el Gantt y justificar a Stakeholders y Sponsors por qué necesitamos dilatar más tiempo para cumplir con el proyecto, y por último pasarlo por escrito porque es la forma de promover la confianza y cubrirte las espaldas.
• Llamar a proveedores para que te informen si las dependencias ya están listas para poder continuar con la secuencia de actividades de desarrollo y coordinar el esfuerzo de integración con otras áreas de la empresa.
• Gestionar la incertidumbre si el proyecto se va a dar o no porque como no existe transparencia en la información debes buscarlo bajo las piedras y pasar informes de estado cosa te puede llevar meses haciendo la misma actividad, pero ojo, no puedes cerrar el proyecto.
• Y tenerles listo el café para esas reuniones que presientes que serán un poco largas por si eres de esos PM serviciales.

Quizás seas muy bueno haciendo cada una de esas actividades y eres un crack en la gestión como líder de proyectos y logras dar con esa sensación de ilusión de control del proyecto, quizás hasta lograste cumplir con el plan y la fecha pero resulta que el producto no satisface al negocio porque se ve afectado por los constantes cambios que tuvo el entorno, ya es obsoleto al mercado, tu competencia va por la versión 3.0 apenas tú con el 1.0 o está en ambiente de QA con un monto de incidencias bloqueantes, o el entorno económico del país impacto drásticamente en el alcance del producto haciendo que se quede en un branch del servidor de versiones que nunca tendrá un deploy a producción.

Si nos detenemos a revisar la lista anterior, es una lista basada en actividades, una gestión basada en tareas, en seguir un plan que se confecciono al inicio y que se le hace tracking y comparación durante la permanencia de su gestión para revisar su salud y corregir sus desviaciones, pero, aún no hay nada que el cliente o el usuario final tenga en sus manos así sea un mínimo de funcionalidades transversales de valor que pueda usar en una primera versión experimental y pueda verificar el producto, con el propósito de validar hipótesis lo más temprano posible, mejorar la interacción, la experiencia de usuario, entre otros factores de vital importancia por si quieres mantenerte como líder en el mercado de la innovación.

Ahora, bien, ¿Esto es bueno o es malo?, depende, aquí hay variables en juego como el estilo de gestión, tecnología, negocio, cultura de trabajo, contexto y organización que hacen el entorno de gestión sea ejecutado de esa manera y te conviertas en un gestor de papeleo porque la metodología implementada en ese trabajo te lleva a ejecutar de esa manera.

¿A donde quiero llegar con esto?, imagínate que en donde tu trabajas esa empresa se ha visto amenazada por el entorno, un Time to Market deficiente, una capacidad de innovación nula, tu vecino o competidor más cercano tiene lanzamientos de productos más rápido al mercado, que esta evolucionando la forma de interactuar con sus clientes, con un aumento progresivo de transacciones por nuevos canales digitales que habilito el banco, o haciendo más simple el proceso de apertura de cuenta desde la comodidad de tu hogar interactuando con un app desde tu teléfono inteligente y en 3 minutos tienes una cuenta corrienta aperturada. Seguramente ese vecino o competidor decidió cambiar su enfoque de entrega de proyectos por productos y eso implica aceptar una mentalidad distinta de gestión y liderazgo por parte del área de negocios.

2 mentalidades de gestión en juego.

EL Gerente de Proyecto tiene mentalidad de Proyecto

Si comparemos ambas mentalidades tener una mentalidad de proyecto en un contexto volátil, cambiante o donde la gestión es más centrado en el cliente puede complicarte en llevar la gestión adecuada porque es de afuera las métricas o las evidencias que tienes que tomar en cuenta para medir el éxito o fracaso del producto en desarrollo y en el menor tiempo posible.

Un gerente de proyecto es alguien experto en la gestión de tareas y recursos, pero no necesariamente con conocimientos sobre el producto o servicio que se desarrollará, el éxito lo mide apegándose al plan inicial alcance, tiempo, presupuesto.

Y como mide el éxito desde adentro hacia fuera se enfoca en obtener información y dar con métricas tales como por ejemplo:

• En dar información en % de avances y desviaciones del proyecto que te brinda el gantt.
• Logros de hitos y que fases han cerrado durante el proyecto
• Informes o reportes de Curva S
• Fechas ( lo planificado vs real) y sus replanificaciones
• Estatus, si está en iniciación, planificación, ejecución y cierre
• Que documentación y entregables durante el desarrollo del proyecto ha sido completado y cuales faltan.
• Riesgos que han sido eliminados, mitigados o descubiertos
• Reporte de incidencias durante las pruebas
• Otros, estas invitado que en los comentarios nos brindes otros ejemplos de métricas o items de este estilo.

EL Gerente de Producto tiene mentalidad de Producto

Si usted o su empresa donde trabaja siguen pensando en términos de proyectos y menos en términos de productos puede ir en detrimento con la velocidad que hoy vivimos por la transformación digital, estar en el ámbito de la industria del software implica generar productos.

En este enfoque se gestiona métricas externas (evidencia real de uso del producto) para guiar activamente el desarrollo del producto maximizar el valor como el factor éxito, es la única forma de medir el impacto al negocio en la gestión del producto, por citar algunas métricas estas pueden ser:

• Satisfacción del cliente
• Uso del cliente
• Ingresos
• ROI
• Lead time
• Capacidad de innovación

Hay otras pero para eso te invito a revisar la guía gratuita de gestión basada por evidencia (Evidence Based Management)⁴ un marco con un acercamiento empírico diseñado por Scrum.org donde las organizaciones pueden usar para ayudarse a medir, administrar y aumentar el valor que obtienen de la entrega de sus productos. EBM se centra en mejorar los resultados, reducir los riesgos y optimizar las inversiones.

Entonces, empieza a dejar de un lado el patrón mental de gestión de proyectos y lánzate al pensamiento del producto. Conviértete en un facilitador de la innovación inspira al equipo con su idea de producto, involucra parte del equipo de desarrollo en el génesis del producto y todo su ciclo natural de gestión. Involucrando al equipo de trabajo en etapas tempranas de estrategia del producto hacen que tomen conciencia del impacto al negocio que ellos habilitarán al liberar lo más pronto posible incrementos terminados de software potencialmente usable.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. Principio del manifiesto Ágil Clic para tuitear

¿Entonces que mentalidad vas a mantener ahora?

No quiero decir que la mentalidad de proyectos es mala, nociva, pasado de moda, sino que su enfoque lineal, predictivo, en base a secuencia de tareas estilo cascada llevarlo a cabo en el contexto de la industria digital y la innovación no es tan simple y mecánico. La industria del software es compleja, desafiante, muy cambiante y debes moverte a su velocidad y desarrollar la capacidad de adaptación con una mentalidad ágil para ayudar la sostenibilidad del negocio como su evolución.

Espero que este post te haya despertado el interés en seguir profundizando sobre la mentalidad de Producto, si quieres obtener más información acerca de la mentalidad de Producto te invito a leer un libro recomendado sobre el pensamiento en Producto en vez de Proyecto en lecturas recomendadas, igualmente en CeaSoft como aliado y partner de Scrum.org ofrece capacitación y consultoría sobre este tema y que esta relacionado al Rol de Product Owner en Scrum porque el Product Owner es un Agile Product Manager.

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Más información

1. Cazar, verbo transitivo (COLOQUIAL) Conseguir algo con habilidad, especialmente una cosa buena o difícil.
2. Jalabola, diccionario venezolano
3. Seco, Diccionario chileno
4. EMB, Evidence Based Management – Scrum.org

Lecturas recomendadas