La gestión de proyectos en el rubro tecnológico es un elemento clave para el éxito de la operación, ya que sienta las bases y estructura general del proyecto a realizar, ya que sobre esta estructura se construyen los otros elementos, como el diseño de la interfaz, la experiencia del usuario, validación de concepto, pruebas de calidad, entre otros.
Para que estos proyectos avancen, primero debemos entender la finalidad de estos, así como las necesidades actuales, futuras, explícitas e implícitas de nuestros clientes, sus usuarios finales y los respectivos grupos de interés. Posteriormente, y entendiendo el alcance de la solución, dividimos el proyecto en fases que nos permitan la realizarlo de una forma ágil y eficiente.
Es aquí donde se viene lo difícil, ya que debemos asignar de forma estratégica cada actividad a realizar, entendiendo que debemos completar una para continuar con la siguiente, sin embargo, constantemente surge la duda: ¿esta tarea/actividad está “hecha”? ¿no está relacionada con otra tarea futura que podrá afectar su estatus?
Estas y otras interrogantes son las más comunes de lo pensado, siendo el principal debate que deberían tener tanto el cliente (Product Owner) como los líderes de proyecto de parte de las compañías de desarrollo de software.
Definir el significado de “Hecho”
La Definición de “Hecho” (o como se estila decir en inglés DoD por Definition of Done) es cuando todas las condiciones, o criterios de aceptación, que un producto de software debe satisfacer son cumplidas, de manera que cumple funcionalmente con los requisitos de un usuario, cliente, equipo, o está disponible para ser utilizado por otro sistema, cumpliendo con los parámetros de calidad establecidos. Esto evita que alguna característica/funcionalidad incompleta sea puesta en productivo, generando errores y retrabajo al tener que regresar para hacer las debidas correcciones, así como disconformidad de los clientes y/o usuarios finales.
Esta definición se determina al inicio de cada proyecto, usualmente en las reuniones que sostiene el Product Owner y los líderes de desarrollo, sin embargo, suele ocurrir que a medida que avanza el proyecto, esta definición es replanteada variadas veces, de manera de que las expectativas del mismo terminan acoplándose a la práctica, así como a los distintos parámetros de calidad, proceso de trabajo, entre otros.
Teniendo claro cuándo una característica/funcionalidad esta “hecha”, entonces se puede tener una mejor idea de en qué parte del proyecto nos encontramos, permitiendo tomar decisiones más certeras y claras acerca de cuanto falta para terminarlo y cuándo deben ser incluidos los respectivos recursos en el proyecto.
Un elemento clave, que nos ayudará enormemente en esta definición consta en las llamadas User stories (historias de usuario), estas podrían definirse como el trayecto que siguen los usuarios dentro de nuestro desarrollo para realizar las tareas deseadas.
Uno de los mayores riesgos que puede ocurrir al no contar con una clara definición y entendimiento de las partes ocurre justamente al presentar todos los requerimientos completados durante el proyecto, precisamente al final de cada iteración, donde al momento hacer las debidas revisiones nos daremos cuenta de que dichos requerimientos no están del todo finalizados, generando los debates sobre el avance real.
La importancia de acordar términos
Cuando una historia de usuario o un incremento (conjunto de historias) está “Hecho”, todos en el equipo deben dar por entendido lo mismo: que esta funcionalidad/incremento ya puede salir a producción. Si bien este entendimiento es resultado de transparencia y confianza entre las partes, la parte más evidente es cuando se suele avanzar a la siguiente fase del proyecto, ejemplo: cuando el equipo Scrum finaliza un sprint.
Otro aspecto importante es definir qué tan completa debe estar una característica, funcionalidad, historia o incremento para pasar a la siguiente etapa. Si esta es de vital importancia para todo el proyecto, entonces debe ser considerado como un criterio de mínima. De lo contrario, volverán a ocurrir malentendidos de parte y parte.
Sin embargo, la Definición de “Hecho” puede evolucionar. Cuando la relación entre el Product Owner y el equipo Scrum madura y se desarrolla positivamente, puede ocurrir que la definición de “Hecho” usada previamente en los incrementos se amplíe durante las reuniones de Retrospectiva y retroalimentación, incluyendo nuevos criterios de mayor calidad, basados en parámetros más prácticos.
Relación entre “Hecho” y Criterios de Aceptación
Un elemento importante para determinar el estado de alguna característica, funcionalidad, etc. Es el llamado Criterio de Aceptación, su definición más básica es cuando esta cumple con todos los requisitos mínimos necesarias para poder ser puesta en producción, tanto a nivel técnico, como funcional, operativo, entre otros.
Los criterios de aceptación son importantes para:
- Gestionar las expectativas, tanto para el Product Owner como para el equipo Scrum.
- Definir el alcance y reducir la ambigüedad.
- Establecer criterios de prueba para el control de calidad.
- Evitar el cambio de alcance a mitad del Sprint, lo cual afecta directamente en la planificación.
Uso de la Definición de “Hecho” en las Fases de un Proyecto
Una vez entendida esta definición, así como los Criterios de Aceptación mínimo, los responsables de planificación del proyecto podrán elaborar la debida hoja/mapa de ruta del desarrollo del producto/servicio, así como la estimación global del esfuerzo a invertir con el propósito de cumplir efectivamente con las Historias de los usuarios.
A su vez, define la cantidad de trabajo a definir en cada Sprint, ya que se usará como guía para cumplir con la definición de los criterios establecidos en la reunión de planificación y en las subsecuentes reuniones de seguimiento y retrospectiva. Esto tiene como resultado una mejor evidencia en la terminación de una fase del proyecto y el inicio de la siguiente.
Impactos de la falta o mala de aplicación de la Definición de “Hecho”
Uno de los principales efectos de una incompleta o mala aplicación de la Definición de “Hecho” es la “Deuda Técnica, la cual se refiere al trabajo adicional producido por una implementación de una funcionalidad o característica que no estuvo finalizada, o que no cumplió con todos los requerimientos mínimos necesarios, como puede ser el haber realizado las debidas pruebas de calidad, o la documentación.
Como principal consecuencia encontramos que el equipo debe retrabajar en finalizar los requerimientos mínimos en las funcionales/características previamente aprobadas, lo cual genera retrasos y pérdida de recursos.
Consejos a tener en cuenta para la redacción de la Definición de “Hecho”
- Involucrar al equipo: incluir en la etapa de planificación a la mayor cantidad de miembros responsables del equipo, de esta manera todos podrán dar su punto de vista y traer a la mesa temas que solo se podrían ver más adelante del proyecto. Mejorando la visión que se tiene del proyecto y cuándo terminaría una fase y comenzaría otra.
- Realizar las historias de los usuarios: este valioso recurso nos permite identificar las necesidades de los usuarios desde su punto de vista. Mientas mejor definidas estén, más fácil será determinar cuándo un desarrollo está “Hecho”.
- Cumplir con los requerimientos técnicos: es muy importante que todas las funcionalidades y requerimientos técnicos sean alcanzados, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
- Cumplimiento de los requerimientos: es muy importante que todas las funcionalidades y requerimientos sean alcanzado a nivel técnico, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
- Ejecutar Testing funcional y no funcional: validar la calidad y que los requerimientos técnicos estén debidamente testeados es clave. Ningún desarrollo de ningún tipo debería estar considerado “Hecho” sin haber pasado por el proceso de Testing & QA.
- Contemplar las Épicas (Epics): donde “Hecho” a este nivel puede referirse a una prioridad estratégica de la organización, un objetivo del plan de negocio, o alguna un conjunto de requerimientos que satisfagan una necesidad del mercado.
Conclusión
El arte de gestionar un proyecto va más allá de dividirlo en fases y asignar recursos y fechas de entrega, siendo lo más importante el conocer a fondo tanto los requerimientos del cliente como contar con el dominio técnico necesario para saber asignar los recursos correctamente.
Los procesos de Huenei incluidos en su Propuesta de Servicios Ágil incluyen acordar con sus clientes la Definición de “Hecho” para sus servicios, permitiendo brindar transparencia en los resultados y confianza sobre el avance del trabajo.
Así mismo y como parte del compromiso en la aplicación de Nuestros Valores de Orientación al Cliente y Eficiencia, hacemos seguimiento y llevamos métricas de eficacia del desempeño de nuestros equipos al medir el nivel de retrabajo por deficiencias en la aplicación de la Definición de “Hecho” y sus criterios de aceptación.
En lo que respecta a la realización de tareas, la clave es que todo el equipo (tanto interno como de parte del cliente) estén en sintonía y entendimiento sobre qué se necesita para que un desarrollo, característica y funcionalidad está completamente finalizadas, permitiendo avanzar con el proyecto como para levantar la bandera para señalar que algo falta.