Respuesta.

Históricamente, la evaluación del esfuerzo se basaba en estimaciones de expertos o en analogías con proyectos anteriores. En condiciones de tiempo e información limitados, el analista de sistemas se ve obligado a trabajar con requisitos de alto nivel, imprecisos, encontrándose a menudo con incompletitudes y expectativas exageradas.

Problema: la incertidumbre conduce a riesgos de subestimación, conflictos con el cliente y el equipo técnico, así como a sobrecostos. La evaluación es muy complicada debido a los cambios en las entradas iniciales después de la firma del contrato.

Solución:

Utilizar técnicas de descomposición de requisitos y sorteos rápidos (planning poker, tamaño de camiseta)
Identificar y documentar todas las suposiciones y limitaciones
Mantener un registro de preguntas y áreas desconocidas
Incluir un margen para riesgos (coeficientes de incertidumbre/bufers)
Lo más importante: registrar los criterios de finalización (Done) y las condiciones límite

Características clave:

Artefactos breves: escenarios de alto nivel, historias de usuario, diagramas C4
Visualización de los principales flujos de valor
Enfoque en prototipos y wireframes para llegar a un acuerdo más rápido

Preguntas trampa.

¿Se puede hacer una estimación sin arriesgar la calidad, si los requisitos aún no están completamente definidos?

No, cualquier estimación en esta etapa deberá marcarse como preliminar con el registro de riesgos y reservas. De lo contrario, la responsabilidad por el sobrecosto recaerá en el ejecutor.

¿Se deben incluir en la evaluación solo aquellos objetos que están claramente definidos por el cliente?

No. Todo lo que no está definido se evalúa a través de un 'buffer de incertidumbre' o puntos de historia especiales para futuras aclaraciones; es importante indicar: "los demás requisitos están fuera de la evaluación".

¿Es necesario que el analista de sistemas participe en la preparación del TCO (costo total de propiedad)?

Sí, el analista formula los datos de entrada: la lista de requisitos, el conjunto de escenarios, áreas de riesgo, limitaciones, lo cual es crítico para un cálculo correcto del TCO.

Errores típicos y anti-patrones

Evaluación del proyecto "a la ligera" sin considerar áreas desconocidas
Ignorar posibles cambios después del inicio de la implementación
No documentar las suposiciones y limitaciones por escrito

Ejemplo de la vida real

Caso negativo: El analista de sistemas aceptó los requisitos del gerente "tal cual", evaluó rápidamente, sin profundizar en los detalles y sin trabajar las limitaciones y áreas ocultas.

Ventajas:

Rápido, conveniente para el cliente

Desventajas:

Sobrepaso del presupuesto, descontento del cliente y del equipo
Refactorización de soluciones y los plazos "se queman" desde el principio

Caso positivo: El analista llevó a cabo una sesión de trabajo con los principales interesados, incluso trabajó sobre requisitos generales, creó un mapa de áreas de incertidumbre, documentó las suposiciones e introdujo reservas.