Por qué la definición de requisitos no es una pérdida de tiempo
Una buena definición de requisitos acorta la duración de la implementación y reduce los cambios durante el desarrollo. Crea una base común para el equipo del proyecto, los departamentos y la dirección: qué se construye, por qué y quién es responsable de ello.
Los entregables esenciales
Un Discovery bien ejecutado produce al menos los siguientes entregables:
- Mapeo de procesos As-Is y To-Be con decisiones claras.
- Modelo de datos inicial: objetos, campos clave, relaciones.
- Modelo conceptual de permisos: perfiles, roles, uso compartido.
- Lista de integraciones requeridas con la dirección del flujo.
- Backlog documentado con priorización para la primera versión frente a fases posteriores.
- Métricas de éxito concretas para el período posterior al Go Live.
Las preguntas correctas para los propietarios de los procesos
Un buen Discovery no pregunta 'qué quieren en el sistema', sino que intenta comprender cómo se trabaja realmente:
- ¿Qué sucede cuando llega una nueva consulta o lead? ¿Quién lo gestiona, quién lo aprueba, qué se guarda?
- ¿Qué decisiones se toman fuera del sistema (correo electrónico, Excel, WhatsApp)?
- ¿Qué informes son realmente necesarios para la dirección y los jefes de equipo?
- ¿Qué reglas de calidad de datos son críticas para el trabajo?
- ¿Qué sucede cuando un empleado se va o es reemplazado?
Qué estropea los procesos de definición de requisitos
- Una definición de requisitos gestionada solo con TI y no con los propietarios de los procesos reales.
- Un documento enorme que nadie lee ni aprueba.
- Decisiones pospuestas a la "fase de desarrollo", creando una dependencia interminable.
- Evitar decir 'no' a solicitudes que no tienen cabida en la primera versión.
Preguntas frecuentes
Una definición de requisitos enfocada para una primera versión suele durar entre dos y ocho semanas, dependiendo de la complejidad de los procesos y la disponibilidad de las partes interesadas.