¿Cómo lidiar con problemas crónicos de tiempo?

https://stackoverflow.com/questions/612892

03-07-2019
|

Pregunta

Tengo un desarrollador en mi personal que sobrepasa crónicamente los plazos y las estimaciones. En varios proyectos, la última semana o dos todos los días escucho "debe hacerse antes del final del día". Este desarrollador hace un buen trabajo.

Ya le he hablado de sus problemas. Parece realmente frustrado y molesto por lo que debe hacer para corregirlos.

Mis preguntas son:

¿Qué tipos de castigos por pasar una fecha límite son efectivos?
¿De qué manera puedo obligar a este empleado a controlar sus acciones (estimaciones de tiempo, etc.) a sí mismo?

ACTUALIZACIÓN : Basado en las respuestas; Esto es lo que he descubierto.

El castigo es una mala idea.
Es natural que un empleado no pueda solucionar los problemas de estimación sin intervención.
No establezca fechas límite a menos que haya consecuencias de la empresa (contrato perdido) por no haberse realizado para entonces.
Utilice los métodos disponibles (Agile, la lista de verificación de Joel) para ayudar al desarrollador a estimar mejor.

Gracias por los enlaces y la información. También gracias por actualizar mi pensamiento.

Solución

No creo que el problema sea que faltan estos plazos.

Creo que tiene un problema real al estimar la cantidad de tiempo que tomará completar una tarea.

Haga que comience a llevar un diario de lo que dice que tomará una tarea y cuánto tiempo le llevó realmente completar la tarea. Eventualmente, esta revista se convertirá en una especie de guía para él para crear mejores estimaciones. Una vez que se vuelve mejor en la estimación, no debe sentirse apresurado o agobiado.

Otros consejos

Hay un artículo interesante de Joel Spolsky: Programación basada en la evidencia

1) Divide ’er down

Cuando veo un cronograma medido en días, o incluso semanas, sé que no va a funcionar. Tienes que dividir tu agenda en tareas muy pequeñas que se pueden medir en horas. Nada más de 16 horas.

Esto te obliga a entender realmente lo que vas a hacer. Escribe subrutina foo. Crear este cuadro de diálogo. Analizar el archivo Fizzbott. Las tareas de desarrollo individual son fáciles de estimar, ya que ha escrito subrutinas, cuadros de diálogo creados y archivos analizados anteriormente.

Si es descuidado y elige tareas grandes de tres semanas (por ejemplo, "Implementar el editor de fotos Ajax"), entonces no ha pensado en lo que va a hacer. En detalle. Paso a paso. Y cuando no has pensado en lo que vas a hacer, no puedes saber cuánto tiempo tomará.

Establecer un máximo de 16 horas te obliga a diseñar la característica maldita. Si tienes una función de tres semanas llamada "Editor de fotos Ajax" sin un diseño detallado, lamento ser el que te lo explique, pero estás oficialmente condenado. Nunca pensó en los pasos que va a tomar y está seguro de estar olvidando muchos de ellos.

El punto principal es que él (y usted) deben aprender de sus errores y tenerlos en cuenta en la próxima estimación.

Además, si usted es un desarrollador, haría una revisión periódica del código al final del día para obtener una mejor perspectiva de su proceso de desarrollo.

Y, por supuesto, iteraciones más pequeñas y más granularidad con las tareas. Establezca la duración máxima de la tarea en 1 día. Esa es la regla que tenemos.

Si tu primera pregunta es qué tipo de castigos se deben tener en cuenta Creo que estás en un perdedor de inmediato. Si crees que hace un buen trabajo, es posible que tengas que mirar los plazos / estimaciones y ver si eran realistas en primer lugar. Quién los estableció, si el desarrollador en cuestión no estuvo involucrado, entonces eso podría ser parte del problema.

Estoy de acuerdo con @OTisler en que la programación en pareja y posiblemente una revisión regular del progreso del final del día con usted mismo pueden ayudarlo ... aunque si los plazos / estimaciones no eran realistas para comenzar, no es allí donde reside su problema.

Una supervisión más estrecha en algunas tareas específicas debe resaltar dónde se encuentran los problemas.

¿Qué tipo de castigos por pasar? ¿Una fecha límite es efectiva?

Ninguna. Si lo enojas, él no hará el trabajo, o encontrará otro trabajo. Deberías ayudarlo a averiguar por qué sus estimaciones están mal. Hay un libro de steve McConnell sobre cómo hacer estimaciones. Yo empezaría allí.

¿En qué formas puedo coherencia esto empleado para vigilar sus acciones (tiempo estimaciones, etc.,) ¿mismo?

Al ayudarlo a encontrar la manera correcta de hacer estimaciones.

Primero, asegúrate de que tienes todos los requisitos claros.

Odio decirlo, pero según mi experiencia, las fechas límite son una cuestión de requisitos poco claros o especificaciones débiles por parte de un supervisor. Lo primero que debe hacer es asegurarse de que el problema no se origine ni se agrave con usted.

También, asegúrese de que sus requisitos sean realistas, así como sus estimaciones.

Asegúrese de que sus propias expectativas no lo impulsen a realizar estimaciones poco realistas para cumplir con requisitos no realistas.

Recuerde, usted cumple con los requisitos, pero el desarrollador SIEMPRE hace las estimaciones, y no debe dejarse llevar por " ¿podemos hacerlo más rápido " a menos que también esté especificando la funcionalidad que se eliminará.

Luego, asegúrate de que esté realizando un seguimiento de su tiempo / tareas con precisión, para que puedas obtener una buena visión de lo que está sucediendo con el proyecto.

Este proceso mostrará cualquier falta de seguimiento adecuado de tiempo / tarea, lo que puede terminar siendo el primer paso para mejorar. Si no puede ver después del proyecto cuánto tiempo tomó un elemento en particular, esa es probablemente la causa del problema allí mismo: no hay suficiente definición en la estimación, o falta la dependencia " " Tareas que se descubren a mitad de proyecto, pero nunca se estiman.

TIENE QUE saber cuánto tiempo se dedicó a hacer qué, con precisión, antes de poder averiguar dónde estaba la amenaza o qué se puede hacer al respecto.

Luego, vea dónde están fallando sus estimaciones y descubra por qué. Revise una estimación de un proyecto fallido, conviértalo en un proyecto en sí mismo, un problema por resolver.

Una vez que haya determinado que sus estimaciones son de hecho la fuente del problema, repase una estimación que haya analizado con él, y quizás otro desarrollador, y averigüe por qué.

Esto te ayudará a descubrir cuál es la causa del problema. Una comprensión sólida del problema probablemente será la solución real.

Por último, si realmente alcanzas un punto en el que tienes que intentar un castigo o coacción, es hora de despedirlo y comenzar de nuevo.

El castigo y la coerción son respuestas adecuadas a los delitos intencionados en ciertas situaciones.

Sin embargo, si este desarrollador está intentando activamente hacer un buen trabajo, solo empeorarías la situación generando una actitud negativa y frustración.

Si el problema no se puede resolver, y está seguro de que el problema está en él, y no en usted, entonces es hora de despedirlo y conseguir un desarrollador que pueda cumplir con los plazos. Un gran trabajo no significa mucho cuando sus costos aumentan y las ganancias salen por la ventana.

Bueno, esto es bastante común: los desarrolladores son optimistas. Es el trabajo de la gerencia tratar con eso. Si alguien debe ser castigado, es el gerente (¿usted?)

Me alegro de que al menos lo hayas preguntado. Parece que obtuviste algunas buenas respuestas de esta lista, espero que te ayuden y encuentres la manera de implementar algunas que funcionen.

Cuando era joven, mi primer buen gerente lo manejó de esta manera:

En primer lugar, me hizo llegar a una lista detallada, dividiendo las tareas en horas y estimando cada una con una estimación muy liberal. Ningún período debe ser inferior a 4 horas, independientemente de cuán pequeña sea la tarea. .

Luego los miró y me dijo que duplicara todas mis estimaciones. (Los desarrolladores, especialmente los desarrolladores más jóvenes, no piensan en el hecho de que solo eres productivo durante aproximadamente la mitad del día, si tienes suerte, y la mitad de eso se gasta en cosas que no esperabas. hacer).

Luego, antes de crear su calendario, duplicó todas mis estimaciones (sin decírmelo).

Los convirtió de esta manera, independientemente de los requisitos de programación de arriba. Un buen gerente debe darse cuenta de que decir que debe hacerse en 2 días, no lo hace posible.

A medida que mejoré en la estimación, ambos nos dimos cuenta y nos ajustamos en consecuencia.

El trabajo de los gerentes no es solo hacer un proyecto, es construir un equipo. Más a menudo que no va a requerir entrenamiento de algún tipo. Esta es también la razón por la que un gerente de ingeniería que no es un ingeniero es inaceptable, realmente no pueden ayudar con este tipo de cosas.

El fracaso de un proyecto o programa es VIRTUALMENTE NUNCA es culpa del desarrollador (excepto en algunos casos crónicos en los que no es realmente reparable o de algún valor y debe ser despedido). El gerente ha tomado malas decisiones ya sea al contratar al desarrollador, confiar en él, gestionarlo o dotar de personal al proyecto.

Y realmente, ¿qué es culpa de todos modos? Supongo que si el gerente no es muy bueno para hacer que el proyecto se lleve a cabo, necesitará que alguien le señale ... Si su gerente es bueno, preguntará por qué llegó tan lejos, qué hizo para solucionarlo. , etc.

Contratar a un gerente es contratar a alguien para resolver los problemas. Para que los desarrolladores sean productivos. Si no puede hacerlos productivos, no es la persona adecuada.

A tus preguntas:

Si elige castigar a las personas por no cumplir con los plazos, no obtendrá buenos resultados. Serán desmotivados y se sentirán menospreciados. Si sigues presionando a la gente para que cumpla con los plazos, la calidad del trabajo se verá afectada y acabarás teniendo mucho tiempo dedicado a la corrección de errores posteriormente.
Para mejorar sus estimaciones de tiempo, puede intentar usar programación basada en evidencia de Joel Spolsky que tiene un buen circuito de retroalimentación para mejorar las estimaciones resultantes.

Pero tengo algunas preguntas sobre las que creo que debes pensar.

¿Es más tarde que todos los demás? Si es así, ¿por qué es porque es un estimador demasiado optimista o un trabajador lento? Las estimaciones sobre optimistas son fáciles de solucionar: simplemente multiplique todos sus números por un factor, según la programación basada en la evidencia que aparece arriba. Si él es un trabajador lento ¿por qué? ¿Se distrae? ¿Es muy cuidadoso para producir un código de defecto muy bajo? ¿Está sobre soluciones de ingeniería? ¿No está reutilizando el código de manera efectiva?

¿Importan los plazos, o son solo fechas arbitrarias basadas en las estimaciones con el fin de informar el progreso hacia arriba en la jerarquía de gestión? Si esto último puedes resolverlo, modifica sus estimaciones tú mismo.

¿Qué tipo de castigos por pasar? ¿Una fecha límite es efectiva?

Declaraste el punto y lo perdiste. El castigo obvio para pasar un plazo es la muerte. Si el desarrollador aún está vivo después de pasar una fecha límite, la " fecha límite " Obviamente no era un plazo real. ¿Crees que es divertido presionar a los desarrolladores utilizando el lenguaje marcial?

Arregla tu redacción.

Motivación

En primer lugar: lea Peopleware

Siguiente. ¿Por qué crees que el castigo será una forma efectiva de manejar a las personas que se supone que son creativas? Creo que hay que repensar todo el enfoque de la gestión frente al equipo.

Como lo veo, el primer y más importante rol de los gerentes es asegurarse de que los desarrolladores puedan ser creativos y productivos. No es que sean productivos. Hay una gran diferencia en esas pequeñas palabras. Para ser creativo necesitas un ambiente seguro. Al estar constantemente bajo la presión de los plazos y las amenazas de castigo, creas exactamente lo contrario de seguro.

Además, como gerente, necesita información precisa en la que basar las decisiones. Esto también requiere un ambiente seguro. Si existe el riesgo de ser castigado por ser honesto y franco, tiene la garantía de mentiras y falta de información. Una base muy peligrosa para tomar decisiones.

Estimaciones

Como se ha señalado, las estimaciones son estimaciones. En nuestro equipo no hacemos estimaciones individuales, hacemos estimaciones como equipo. (Estoy un poco renuente a llamar Scrum a lo que hacemos, pero la mayoría trata de emular, por lo menos, no.) Creo que esta es una excelente manera de hacer estimaciones: a cada miembro del equipo se le da una baraja de cartas que consta de números 0 , 1 / 2,1,3,5,8,13,20,40,60,100 y al estimar una tarea, cada desarrollador elige una tarjeta (las tarjetas se ocultan hasta que todos hayan elegido una tarjeta para evitar influir en las estimaciones) y el promedio de las cartas seleccionadas se toman como estimación.

Observe cómo los números se vuelven progresivamente menos precisos. Esto es así por diseño porque las estimaciones grandes son necesariamente menos precisas.

Para nuestro equipo, hemos optado por utilizar la unidad " ideal man days " para estimaciones. Hasta el momento cualquiera de nosotros puede recordar que un día ideal no ha ocurrido todavía, pero es una buena base cuando se sabe cómo traducir los días de calendario a "días de hombre ideal".

Como prescribe Scrum, el desarrollo se realiza en intervalos de dos semanas, después de lo cual la nueva versión se implementa en el entorno de producción. Después de cada sprint, tomamos la suma de las estimaciones de las tareas completadas y las dividimos por los días planificados para el sprint. Este factor es entonces la base para estimar cuántos " días ideales para el hombre " El equipo puede gastar en un período de dos semanas.

Los elementos de trabajo reales realizados por un desarrollador individual no necesitan una estimación. La primera aproximación es siempre 1/2 - 1 día para completar. Si esta estimación resulta ser falsa, simplemente toma a otro desarrollador y hazlo juntos para hacerlo. O puede desglosar el elemento de trabajo en tareas más pequeñas para poder distribuirlo mejor.

Establezca Hitos e intente Agile como sugirió @OTisler.

No creo que debas castigarlo. Solo haz que entienda cómo hacer estimaciones precisas.

Como líder del equipo, los miembros de mi equipo me han dicho que será " no hay problema " para terminar la función de X en el plazo. Luego, por lo general, me siento con ellos y repaso las tareas y sub-tareas que creo que deben realizarse para que la función se complete y el tiempo que el desarrollador cree que tomará cada una.

Después de hacer este ejercicio, y sumar todas las estimaciones de tareas y sub-tareas, inevitablemente tomará mucho más tiempo de lo que el desarrollador piensa en su estimación original. Por lo general, solo tengo que hacer este ejercicio con ellos unas cuantas veces antes de que comiencen a realizar estimaciones más precisas.

Lo que me sorprende es que solo tienes uno de estos tipos.

Los ingenieros son horribles al estimar cuánto tiempo tomará algo. Apuesto a que si observa detenidamente las estimaciones de sus otros desarrolladores, encontrará mucho relleno. A veces, el relleno no es necesario, pero la tarea se expande para completar el tiempo disponible de todos modos.

La solución a esto es cambiar la forma de hacer estimaciones, para todos. Los desarrolladores pueden ser malos para estimar el tiempo absoluto, pero son bastante buenos en el tiempo relativo. Entonces, el lunes, en lugar de " ¿cuánto tiempo tomará agregar un whoosiwhatsit?, & Quot; pregunte " ¿qué puede hacer en el whoosiwhatsit en menos de una semana? " Eso se convierte en su tarea para la semana.

El lunes siguiente te fijas en cómo fue. "Bueno, tengo el floogle instalado en dos días, pero resulta que impactó el mcphee ... así que esta semana necesito disociar a esos tipos para que los archivos whoosiwhatsit no se sobrescriban". Ok, hay una tarea para la semana.

Puede que pienses que no servirá de nada, porque aún no sabes cuándo estará listo el whoosi que es eso. Es verdad. Tienes dos opciones aquí:

Si necesita una fecha límite, entonces tiene que forzar a su desarrollador errante a completar sus estimaciones como todos los demás. No le llevará mucho tiempo entenderlo, y en poco tiempo estará tomando " 2 semanas " Para escribir algo que debió haber tomado un día.

Su otra opción es intercambiar las estimaciones ficticias por más visibilidad. A la larga, este enfoque hace que los ingenieros sean más productivos y mucho más felices.

¿Entonces el desarrollador hace un buen trabajo, pero es pobre en estimar la cantidad de tiempo para la entrega? No estoy seguro de que tengas todavía una situación de castigo en tus manos.

Tal vez siga adelante por un tiempo, pídale que lo guíe por su proceso para estimar un punto de entrega. Esta puede ser una oportunidad para preguntarle por qué los pasos X, Y y Z toman cierta cantidad de tiempo. Es posible que se encuentre revisando sus estimaciones simplemente haciendo el ejercicio a lo que seguramente es un ritmo más lento.

pregúntate esto: ¿Qué implica tu trabajo?

Si solo está pasando ciegamente las estimaciones de los desarrolladores (que usted sabe que no pueden dar buenas estimaciones) en la línea de administración, y no está decidiendo si esa estimación es alcanzable, entonces no está haciendo su trabajo.

Intente pensar en términos de " valor-agregado " (Uno de mis viejos empleadores usó mucho ese término, y lo odié, pero probablemente le funcione a usted en esta situación). ¿Qué valor estás agregando? Si solo estás pasando cosas en ambas direcciones entre la gerencia superior y los desarrolladores, en última instancia no estás ganando tu dinero. Podrías ser eliminado y nada cambiaría.

El mejor gerente que he tenido fue uno que revisó un conjunto de requisitos que le dio otro equipo, y les dijo directamente que casi un tercio de ellos era toro, y que me los quitaron, incluso antes de que viera el lista. La peor que nunca me había hecho escribir toda esta documentación adicional de tipo de gestión que ninguno de los otros gerentes que me había pedido hacer (realmente me dio la impresión de que literalmente estaba haciendo su trabajo para él), no Incluso me dan las fechas de vencimiento del proyecto, y apenas se presentan para trabajar. Ambos estaban en la misma compañía, extrañamente.

90 horas es una fecha límite corta común del proyecto. La forma más sencilla es que en lugar de estimar "su tiempo", mida otro. Los programadores de computadoras no deben hacer estimaciones de tiempo para sus proyectos, ya que la evidencia muestra que calcular el tiempo propio da como resultado un error más grande que observar otro.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow