Estimación de tiempo de una investigación de error compleja (no una directa) [duplicado]

Esto no es prácticamente útil para usted, pero no me hundiría en el nivel de explicarle a los colaboradores no técnicos por qué ciertas tareas técnicas son más difíciles que otras. El punto de contratar especialistas para tareas de programación que sean mejores en aspectos técnicos y peores en asuntos de negocios o administración que sus empleadores es que sus son mejores en ellos . En gran parte, entender por qué surge un defecto equivale a ser capaz de solucionarlo y, en menor grado, a evitar errores similares en el futuro.

En forma breve y brutal, si sus superiores pudieran entender por qué algunas tareas de depuración son tan difíciles, podrían realizarlas por sí mismas, lo cual no es así, ya que lo contrataron. Es difícil para alguien aceptar que hay distinciones que no pueden apreciar, por lo que tiene poco sentido explicar a un gerente que tiene dificultades que no puede explicarle. Lo mejor que puedes hacer es subir a su nivel de vista y decirle: "Mira, sé que esto suena mal, pero no te puedo decir muy bien cuánto tiempo tomará sin importar el incentivo" . Una vez que hayas dicho esto en los casos en que es cierto, y han visto que es realmente cierto (porque tu esfuerzo sí varió de manera impredecible), quizás empezarán a creerte cuando digas que no sabes algo. Pero no aguantaría la respiración. Decir "no sé" a algo en un entorno competitivo es muy difícil de hacer, y muchos profesionales evitan hacerlo a toda costa; y por eso tienden a creer que tampoco es verdad cuando alguien más lo está diciendo. Extraño, pero (en mi experiencia anterior) todo muy cierto.

Dependiendo de la gravedad del problema y la urgencia de solucionarlo, verifique si están de acuerdo con un esfuerzo "de tiempo limitado". Digamos, dos días investigando / intentando recrear el problema. Si no lo tiene para entonces, informará sobre lo que eliminó como problema y verá si quieren que continúe investigando.

Para problemas menores, es probable que acepten un período de tiempo corto siempre que el trabajo continúe en otros problemas o características. Para los principales, especialmente aquellos con mayor visibilidad, el cuadro de tiempo les permitirá obtener informes periódicos sobre su esfuerzo.

Combine dos enfoques: la "estimación de tiempo fijo" y el enfoque "No sé" sin decir literalmente que no sé. Seamos realistas, si supieras exactamente lo que está causando el error, no lo habrías escrito de esa manera (sí, sé que no siempre arreglamos nuestro propio código, pero no estamos limpiando el desorden de otra persona). incluso peor?).

Adquiera el hábito de responder a las solicitudes de cotización de errores de tiempo con "Voy a echarle un vistazo y le haré saber cuánto tardará". La gente quiere saber que te importa lo suficiente demostrando que estás tomando medidas para resolver el problema y que estás priorizando su tarea de manera adecuada. Hacer promesas (y son promesas en su mente) que no puede cumplir va a disminuir su nivel de confianza en usted.

No te olvides de reorganizar tus otros compromisos. En términos simples, no puedo corregir tu nuevo error encontrado y ofrecer una nueva función al mismo tiempo. ¿Cuál quieres que haga primero? Con suerte, eliminarán el error, pero nunca se sabe.

No quieren una explicación técnica. Cuando un usuario no técnico pregunta: "¿Por qué va a llevar esto tanto tiempo?" No necesariamente quieren una respuesta técnica y realmente no quieren detalles. Al tomarse el tiempo para investigar el error y luego dar una estimación del tiempo, también puede resumir la solución. Puede haber varias áreas de la aplicación que deban modificarse (la deuda técnica ya ha vencido), parchando otra tecnología, etc.

Sugiero dar un rango como estimación.

Por ejemplo, para problemas fáciles puede ser "entre 15 minutos y tres horas", para problemas difíciles puede ser "entre dos horas y una semana".

Esto debería transmitir su punto. Si le preguntan a por qué su mejor y más estimado cálculo de caso difiere tanto, puede comenzar a explicar las cosas que mencionó en su pregunta (proceso cíclico, etc.) e incluso dar ejemplos para el mejor y el peor de los casos.

Buscar una solución a un problema puede ser muy parecido a buscar cualquier otra cosa que falte. Tomemos las llaves del coche por ejemplo. Si los míos no están en el estante al que pertenecen, verifico el otro lado del estante y amp; Un par de bolsillos de abrigo y generalmente los encuentras en minutos.

Cuando mi esposa perdió sus llaves hace un tiempo, tuvimos que esperar a que la nieve se derritiera primero. Eso llevó un par de meses.

Creo que lo has clavado con "fácil", "confuso" y "duro". Es fácil encontrar un error cuando puede reducir rápidamente su espacio de búsqueda a algo razonable. Es difícil cuando no puedes.

Lo que realmente deben saber todos tus superiores es que esto es una prioridad, estás trabajando metódicamente / tienes un plan de búsqueda y todavía no te has quedado sin ideas.

La estimación del tiempo para completar tareas en el desarrollo de software es un arte oscuro. Creo que tus argumentos son buenos, pero olvidaste uno crítico:

Por mucho tiempo que creas que va a tomar, multiplica eso por dos.

He encontrado que esto funciona bastante bien. Las cosas siempre tardarán más de lo que cree, especialmente en el desarrollo de software.