Hoy, vamos a analizar un aspecto a menudo pasado por alto del ciclo de vida del desarrollo de software (SDL) conocido como revisión posterior al proyecto. Comenzaremos definiendo qué es exactamente una revisión posterior al proyecto y pasaremos a cubrir los elementos de una buena revisión del proyecto.
¿Qué es una Revisión Posterior al Proyecto?
Una de las características de un proyecto es que tiene un comienzo y un final definidos. A veces, el comienzo y el final pueden no estar muy claramente definidos (!) pero por lo general se puede tener una idea aproximada de cuándo comenzó un proyecto y cuándo terminó. Algo que no tiene este tipo de vida finita no es realmente un proyecto. Sin embargo, es posible dividir cualquier actividad, como el mantenimiento y soporte continuos de software, en una serie de proyectos claros, por lo general finalizando un proyecto cuando se pone en producción una versión de software y comenzando un nuevo proyecto para la siguiente versión o actualización.
Una revisión posterior al proyecto es una forma muy útil y poderosa de agregar un mecanismo de mejora continua. La mayoría de las actividades se pueden dividir en un conjunto de proyectos separados como se mencionó anteriormente. Este mecanismo de mejora continua ayuda a que cada proyecto exitoso sea más exitoso (y con frecuencia menos estresante para todos los participantes). Las revisiones posteriores al proyecto generalmente implican que el equipo del proyecto y las principales partes interesadas se reúnan y revisen lo que salió bien y lo que salió mal durante el proyecto. Esta información puede ayudar a los participantes a tomar las decisiones y los planes correctos para que el próximo proyecto funcione mejor. También puede ayudar a aclarar malentendidos y otros problemas.
Leído: ¿Qué es el Software de Gestión de Proyectos para Desarrolladores?
Por ejemplo, en una revisión posterior al proyecto que una vez realicé, el equipo de Control de Calidad (QA) se molestó al sentir que los cambios en los requisitos se habían aprobado y realizado sin su aporte durante el proyecto. En base a estos comentarios, esto se corrigió en proyectos posteriores, asegurando que un representante del equipo de control de calidad estuviera siempre presente cuando se debieran realizar las discusiones sobre los requisitos. Esto los puso al tanto y les dio la oportunidad de mencionar los posibles impactos en los plazos de garantía de calidad. Es importante asegurarse de que todos los participantes en la revisión posterior al proyecto comprendan que no es el momento de asignar culpas o realizar ataques personales. La idea es elogiarse mutuamente por los trabajos bien hechos, así como encontrar formas de hacer las cosas aún mejor. Uno debe tener cuidado de que una revisión posterior al proyecto no degenere en un ejercicio de señalar con el dedo o una pelea a gritos.
Los Elementos de una Buena Revisión Posterior al Proyecto
Como se mencionó anteriormente, el propósito principal de una revisión posterior al proyecto no es asignar culpas, sino identificar áreas para mejoras y formas de mejorarlas. Antes de planificar una revisión posterior al proyecto, identifique sus objetivos principales y lo que desea quitar.
- Identifique los elementos que se hicieron bien: Por ejemplo, tal vez las estimaciones de tiempo fueron muy buenas, los desarrolladores y los equipos de control de calidad trabajaron bien juntos, etc.
- Identificar elementos que podrían mejorar: Tal vez la documentación del sistema no estaba lista a tiempo; los desarrolladores tuvieron disputas con los analistas, etc. Básicamente, estos son elementos que necesitan alguna mejora que se puede lograr de manera realista con cierto grado de esfuerzo.
- Identificar los elementos que están rotos: Estos son bastante graves y pueden requerir un replanteamiento completo de cómo se hacen. Es posible que algunos procesos necesiten ser eliminados o cambiados. Tal vez los requisitos que cambian continuamente requieran que el equipo cambie a una metodología de desarrollo más ágil. Es posible que sea necesario reasignar a dos personas que se ponen nerviosas la una a la otra para que no tengan que trabajar juntas.
- Decidir planes de acción: Obtener entrada & acuerdo sobre planes de acción para mejorar los elementos que necesitan mejoras y formas de arreglar los elementos que están rotos. Esto hará que sea mucho más fácil implementar cambios a largo plazo, así como ayudar a construir un fuerte sentido de compromiso y espíritu de equipo en el equipo.
Intente reunir a la mayor cantidad de partes interesadas y miembros del equipo para la reunión. Si bien puede parecer una receta para el caos (!), si se planifica bien, puede ser una gran experiencia para todos. Asegúrese de que todos entiendan el plan de acción y los objetivos. Es probable que las partes interesadas y los miembros del equipo se entusiasmen si lo ven como una oportunidad de trabajar para resolver los problemas. En mi experiencia, la primera vez que se hacen estas revisiones generalmente son las más difíciles, ya que la gente no está segura de lo que está permitido y lo que no. Algunos diputados también pueden tomar mal las críticas. Puede tener sentido tener una idea de los problemas potencialmente explosivos y cómo desactivarlos antes de ir a la reunión. Reunirse en privado con los participantes afectados antes de la reunión para asegurarse de que se entienden las reglas básicas y obtener el compromiso de que se seguirán puede ser muy útil.
Una buena técnica que he encontrado para ayudar a identificar los problemas principales es hacer algo como votar. Cada participante coloca elementos que pueden caer en una de las categorías bien hechas, algunos ajustes necesarios y debe arreglarse. Esto hace que todos sientan que sus opiniones se cuentan. Además, puede ayudar a proporcionar una visión completa de muchos problemas. Con frecuencia uno encontrará un patrón en muchos temas. Elogie los artículos que la gente sienta que están bien hechos. Las cuestiones mencionadas con más frecuencia son las que requieren atención. En este punto, puede ayudar que las personas proporcionen ideas sobre cómo mejorar los artículos que necesitan mejoras y cómo reparar los artículos que están rotos. Incluso puede tener una votación informal sobre qué ideas parecen las mejores.
Una vez finalizada la reunión, recoja toda la información y anótela. Asegúrese de detallar lo que va bien, lo que necesita mejoras y lo que debe arreglarse. Identificar las técnicas que todos acordaron trabajar para hacer la mejora y solucionar los problemas. Es una buena idea presentar esto a la alta dirección, especialmente si algunas correcciones necesitan aprobación o recursos. Estos informes les proporcionan una forma de revisar al equipo y les ayudarán a confiar en que el equipo está tratando de atacar y solucionar problemas por su cuenta. Es mucho mejor encontrar maneras de solucionar los problemas usted mismo en lugar de que la alta gerencia se involucre en encontrar las soluciones. Por lo general, las personas resienten las órdenes ejecutivas, pero trabajarán voluntariamente en los cambios que ellos mismos propusieron.
Leer: Las Mejores Herramientas de Gestión de Proyectos para Desarrolladores.
Conclusión
Las revisiones posteriores al proyecto son una forma valiosa para que los equipos mejoren su rendimiento y habilidades. Ofrecen un mecanismo para ayudar a impulsar la mejora continua, así como mejorar la moral del equipo. Es importante que el mayor número posible de partes interesadas participen en la revisión, ya que ayuda a revisar todas las partes del proyecto y proporciona un mecanismo para aclarar malentendidos y otros problemas. Una buena planificación y seguimiento posterior a la reunión es crucial para que estas revisiones sean un éxito.
