Cómo responder "¿Cuándo se hará?"

Todos lo tenemos, problemas que resultan difíciles de solucionar y resolver una solución a través de un código oscuro y una extraña funcionalidad inesperada. Lentamente, trabaje lógicamente para encontrar patrones, errores, errores. Este proceso lleva tiempo y el cliente a menudo no comprende fácilmente los problemas.

¿Cómo responde uno cuando se le hace la pregunta "¿Cuándo se hará?", Especialmente cuando el cliente puede no comprender las complejidades inherentes del desarrollo de software?

Respondes la pregunta honestamente.

Usted les dice que es un problema difícil, que la solución no es obvia y que no está seguro de cuánto tiempo llevará resolverlo. Promete actualizarlos en tu progreso cada [período de tiempo], para que sepan que estás trabajando en ello y, por supuesto, en realidad les envíes las actualizaciones.

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 ₁ 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.

Independientemente de lo que calcule, no olvide incluir la ley de Hofstadter : siempre lleva más tiempo de lo esperado, incluso si tiene en cuenta la ley de Hofstadter.

Por lo general, uso una fórmula modificada de CPM / PERT. Es algo como esto:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(No estoy seguro de cómo hacer todo el formato matemático elegante; si alguien quiere editar esto para eso, entonces siéntase libre).

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Destacaría que podría variar significativamente, dependiendo de cómo vaya el proyecto. Si reevalúa su proyecto cada pocos días, incluso podría proporcionar una actualización semanal. Recorre un largo camino para satisfacer a los clientes irritables :)

Explicar plazos vagos a usuarios no técnicos es difícil. Esto es cierto tanto en las fases creativas de un proyecto como al rastrear un error molesto. En ambos casos, el tradicional "descomponer el trabajo en piezas más pequeñas" no funciona tan bien.

La tarea original se centra en el último caso, así que hablemos de eso. Si no puede dar una línea de tiempo, dígale al usuario qué intentará y cuándo volverá a ellos. Cuando llegue a la mitad de la línea de tiempo autoimpuesta, envíe una breve y honesta actualización por correo electrónico. Al menos una hora antes de la fecha límite, dé su respuesta formal. Ahora tienes credibilidad. Si el problema no se resuelve, al menos estás iluminando un poco. Puede parecer una pérdida de tiempo, pero no lo es.

Dado que no puede dar cuenta de los obstáculos desconocidos y las sorpresas imprevistas, puede ser difícil estimar con confianza. Ideas:

• Pruebe con un rango: "Estoy seguro de que tomará al menos N días (por ejemplo, 3), pero podría tomar hasta 4N".
• Busque el apoyo de más ingenieros superiores en la estimación y defensa de estimaciones.
• Trabaje en iteraciones más cortas (estilo Agile / Scrum) para producir un código mínimo que agregue valor comercial (ganando confianza), luego repita.
• Aprenda habilidades de negociación de un libro como el clásico Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).

Para nuevos desarrollos, especialmente desarrollo ágil:

"La perfección se logra, no cuando no hay nada más que agregar, sino cuando no hay nada más que quitar". - Antoine de Saint-Exuper

Si está estimando el esfuerzo y el tiempo para corregir algunos errores casi imposibles de reproducir en un sistema terriblemente complejo con muy pocos o ningún desarrollador con un dominio íntimo del sistema, entonces la única respuesta correcta es "Cuando se solucione".

Por lo general, les diría la verdad. Les diría que no lo sé en este momento, y podría tener una mejor visión en una semana. Luego les entregaría un parque de pelota con tantos garabatos delante de él como caben en el papel para indicar que es una suposición basada en la intuición. Si comienzan a molestarte, simplemente comienza cada oración con "Es posible ..." Por lo general, cualquier persona por la que haga algo está contento con el "Verificación en una semana más o menos, pero ahora todo lo que puedo decir son unos 2 meses" o algo así.

El proceso de software personal (PSP) se centra en mejorar las estimaciones. Esto se logra mediante el registro disciplinado de las tareas. Esto, en esencia, "acelera" un poco la parte de la "experiencia" de la estimación, ya que tendrá datos reales sobre tareas típicas. Por supuesto, esta profesión aún requiere soluciones únicas para muchos problemas, pero en mi experiencia, las estimaciones son mejores después de usar PSP.