1. Presentaciones de la puesta en marcha de proyectos
A veces, la planificación y ejecución de un espectáculo de perros y ponis en el momento del despliegue ayudará a garantizar que la conexión sea segura entre el equipo de proyecto, la solución final y la comunidad de usuarios finales. Es de esperar que cualquier problema y discordancia que pueda haber con los requerimientos del proyecto respecto a la funcionalidad que se espera de la solución final queden resueltos durante las Pruebas de Aceptación del Usuario o User Acceptance Testing (UAT), pero no no hay garantías de que eso ocurra.
Incluso aunque la UAT haya sido aprobada, no hay garantía alguna de que el cliente sepa exactamente qué es lo que quiere, de que se haya hecho todo “a la perfección” y de que funcione al 100% como estaba planeado.
Una presentación de la solución final a una comunidad más amplia de usuarios finales en el momento de la implantación del sistema, o justo antes, garantizará aún más que el cliente reciba lo que necesita. Por ello, si se detectan desajustes, es en estas presentaciones donde se expondrán y se realizarán solicitudes de cambio. Además, añadir funcionalidades en las fases finales del proyecto puede ayudar a conseguir la satisfacción total del cliente y que el proyecto encaje con la estrategia y los objetivos de la organización.
2. Grupos de discusión y encuestas a usuarios finales
Si prestamos atención a la comunidad de usuarios finales, podremos entender mejor si estamos satisfaciendo sus necesidades permitiéndoles utilizar la solución y ponerla a prueba. ¿Tiene el funcionamiento deseado?
A veces, éste grupo de personas, que son clave para medir el éxito de los proyectos, son pasadas por alto o no son involucradas de la manera correcta durante la fase de definición de los requisitos del proyecto. Al permitirles usar la solución, hacerles encuestas o realizando indagaciones para saber si aun quedan discordancias por resolver, podremos responder de manera proactiva a las necesidades del cliente.
Ten en cuenta que si descubrimos estas deficiencias al final del proyecto, solucionarlas no será ni fácil ni barato. Será nuestra culpa como equipo de proyecto. ¿Y en caso de que haya sido el cliente el que no ha cumplido con los requerimientos del proyecto? Eso sería determinante en cualquier decisión que se tome en forma de solicitud de cambio, ya que sin duda tendría un efecto sobre donde recaiga la responsabilidad financiera. Y en el caso de que se trate de una funcionalidad crítica, habrá que resolverlo rápidamente.
3. Retrospectiva de las lecciones aprendidas
Organizar sesiones de retrospectiva para analizar las lecciones aprendidas durante el proyecto o al final de los mismos es una buena manera de entender cómo se siente el cliente respecto al desarrollo del proyecto, la solución a entregar y el equipo de proyecto. Cualquier problema o inquietud debe ponerse sobre la mesa en estas sesiones.
Yo recomiendo que estas sesiones de retrospectiva se realicen durante el proyecto, en las fases claves de su desarrollo, en vez de al final del mismo. Y es que, de hacerse al final del mismo, sería más difícil reunir a los miembros del equipo que ya estén trabajando en otros proyectos y al cliente, que seguramente esté entonces ocupado probando la nueva solución o con otras responsabilidades.
Si se realizan estas sesiones de retrospectiva en varios puntos del ciclo de vida del proyecto, se obtendrá información valiosa que ayudará a mantener una alta satisfacción del cliente, y permitirán al equipo de proyecto saque provecho de ese feedback para las fases restantes del proyecto actual, así como para futuros proyectos.