Los desarrolladores abordan un problema complejo descomponiéndolo en otros más pequeños y resolviéndolos por separado.
En un mundo ideal , resolver un problema sería un problema complejo A y podría, en un momento dado, descomponerlo en una breve lista de pequeños problemas A 1 a A n , para cada evaluación el tiempo es sencillo, dado que el tiempo requerido para resolver el problema complejo inicial sería:
siendo D el proceso de descomposición en sí.
En el mundo real , el único problema es que t ( D ) en realidad sería mayor que el tiempo que pasa resolviendo los pequeños problemas. En otras palabras, para llegar a este nivel de descomposición del problema, prácticamente necesita resolver el problema en sí.
Todavia puedes:
Separe la tarea dada (resolver el problema) en trozos más pequeños, cada trozo sigue siendo un problema complejo,
Evalúe el tiempo esperado para cada porción y el riesgo correspondiente.
Por ejemplo, la tarea 1 requiere aprox. 5 horas, pero el riesgo de ser bloqueado al hacerlo es alto, así que dele 12 horas como espera al cliente.
Evaluar las dependencias y cómo afectan el tiempo.
Por ejemplo, la tarea 19 requiere 2 horas, y el riesgo es tan bajo que puede decirse que son 2 horas con seguridad. No 1. No 3. Pero la tarea 19 se basa en la tarea 24: la tarea 24 puede afectar la tarea 19 de una manera que requeriría reescribir completamente el código de la tarea 19 usando un enfoque diferente.
Dé todos esos detalles a su cliente. No des la suma.
El último punto es importante. Si da la suma, digamos 192 horas, el cliente cree que es una métrica muy precisa, y el tiempo que pasará es de, por ejemplo, 189 a 195 horas.
Si, en cambio, das los detalles,
El cliente que se preocupe comprenderá que no son 192 horas. Son 192 horas si todo sale mal dado el riesgo determinado durante la evaluación. También son 238 horas si todo va aún peor. También son 85 horas si todo está bien.
En cuanto al cliente que no le importa, no leerá su respuesta en todos los casos. Todo lo que quiere es un número, para poder culparte más tarde. Al dar una respuesta muy detallada que nunca leerá, sabes que no puede preguntarte por el tiempo que tomará nuevamente: ya respondiste eso. Tampoco puede culparte más tarde, ya que no leyó la respuesta para calcular la suma.