Validación en un proyecto

Validación en un proyecto

foco en el tiempo, seguramente te suenen estas situaciones. Es habitual a lo largo de un proyecto tener hitos en los que entregar documentos o prototipos que necesitan ser validados y recibir feedback. Recibir feedback significa que debes evolucionar tu producto o servicio, no que necesites ese hito para poder construir algo ya definido (como en el caso de una pieza concreta de un producto en una línea de montaje). Estos hitos suelen ser puntos críticos en los que se necesita una respuesta rápida para poder proseguir. Desde mi punto de vista, dos aspectos clave para para conseguir una respuesta rápida sobre un entregable son:

  • Que el cliente haya sido involucrado desde el principio en aquello que tiene que validar, siendo partícipe en la mayor medida posible, de la elaboración.
  • Que no pase un periodo largo de tiempo sin que el cliente haya visto la evolución.
En este tipo de escenarios, hace tiempo que he desistido a realizar documentos entregables con el objetivo de ser validados.
Nunca me he encontrado con un documento que sea validado sin feedback.
Está claro que después del feedback, puedes darlo por bueno y cerrarlo (validación implícita). Pero seguramente ese escenario tiene consecuencias en el devenir del proyecto.

¿Qué me permite el documento de trabajo?

Creo que lo más importante del enfoque es la implicación con aquellas personas que lo están desarrollando y por tanto, con el cliente. No es un grupo de trabajo y un validador, es un grupo de trabajo que ‘pivota’ de forma continua. Por tanto, el documento siempre está abierto a modificaciones o mejoras. Todo aquello en que se está de acuerdo, ya está validado. Conseguimos alinear de forma temprana y compromiso sobre su elaboración.

¿Cómo debe ser un buen documento de trabajo?

  1. Simple, que no sencillo 😉 Debe contener todo aquello que sea esencial, pero sin rodeos. Como este post 🙂
  2. Comprensible. Debe ser intuitivo y seguir un hilo lógico y coherente desde el punto de vista de la persona que lo debe entender.
  3. Muy visual. De esta forma, el interés por él aumenta y facilita su lectura (o uso).
Si no consigues estos tres aspectos puede que mejor lo dividas hasta poder conseguirlo.

¿Y cómo cierro el alcance?

Para cerrar el alcance hay que acordar la metodología con el cliente. Si usas documentos de trabajo (que pueden ser perfectamente prototipos en el mundo del software), hay que acordar el número de revisiones y el esfuerzo a dedicar. A partir de ese esfuerzo se irá evolucionando el producto hasta llegar al producto requerido.
Es de suma importancia en este escenario que el cliente tenga en todo momento constancia de los recursos y esfuerzo dedicado, para así poder acordar de forma periódica hasta dónde se llega.
Mi recomendación es que reserves el tiempo y recursos necesarios para poder dedicar a las revisiones y gestión del feedback dentro dl proyecto. Son de aquellos costes ocultos que, si tienes en cuenta al principio, te ahorran disgustos y hacen que el proyecto se desarrolle mejor. Y por tanto, vivas un poco más feliz :)]]>

Leave A Reply

Tu dirección de correo electrónico no será publicada.

*