podcast - ¿Cómo lidiar con problemas de tiempo crónico?
time-management deadlines (15)
¿Qué tipo de castigos para aprobar una fecha límite son efectivos?
Ninguna. Si lo enojas, él no hará el trabajo, o encontrará otro trabajo. Deberías ayudarlo a descubrir por qué sus estimados están apagados. Hay un libro de steve McConnell sobre hacer estimaciones. Yo comenzaría allí.
¿De qué maneras puedo coherenciar a este empleado para controlar sus acciones (estimaciones de tiempo, etc.)?
Ayudándolo a encontrar la manera correcta de hacer estimaciones.
Tengo un desarrollador en mi equipo que supera crónicamente los plazos y las estimaciones. En varios proyectos la última semana o dos todos los días escucho "Debería hacerse al final del día". Este desarrollador hace un buen trabajo.
Ya le hablé de sus problemas. Parece genuinamente frustrado y molesto sobre qué hacer para corregirlos.
Mis preguntas son:
- ¿Qué tipo de castigos para aprobar una fecha límite son efectivos?
- ¿De qué maneras puedo obligar a este empleado a vigilar sus acciones (estimaciones de tiempo, etc.)?
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 arreglar los problemas de estimación sin intervención.
- No haga los plazos a menos que haya consecuencias para la empresa (contrato perdido) por no haber sido hecho 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.
¿Qué tipo de castigos para aprobar una fecha límite son efectivos?
Usted afirmó el punto y lo perdió. El castigo obvio por aprobar una fecha límite es la muerte. Si el desarrollador todavía está vivo después de pasar un plazo, la "fecha límite" obviamente no fue una fecha límite real. ¿Crees que es divertido presionar a los desarrolladores usando lenguaje marcial?
Arregla tu fraseología
Motivación
Primero que nada: 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 debes reconsiderar todo el enfoque de la gestión frente al equipo.
Como lo veo, el papel de los gerentes primero y más importante 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 entorno seguro. Al estar constantemente bajo presión por los plazos y las amenazas de castigo, creas exactamente lo contrario de lo seguro.
Además, como gerente, necesita información precisa sobre la cual basar sus decisiones. Esto también requiere un ambiente seguro. Si existe el riesgo de ser castigado por ser honesto y franco, se garantiza que obtendrá mentiras y la ausencia de información. Una base muy peligrosa para tomar decisiones.
Estimados
Como otros señalados, las estimaciones son estimaciones. En nuestro equipo no hacemos ninguna estimación individual, hacemos cálculos en equipo. (Soy un poco reacio a llamar Scrum a lo que hacemos, pero la mayor parte trata de emular si nada menos). Creo que esta es una gran manera de hacer estimaciones: cada miembro del equipo recibe una baraja de cartas compuesta 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 cartas se ocultan hasta que todos hayan elegido una carta para evitar influir en las estimaciones) y el promedio de las cartas seleccionadas se toman como la estimación.
Observe cómo los números se vuelven progresivamente menos precisos. Esto es por diseño porque las estimaciones grandes son necesariamente menos precisas.
Para nuestro equipo, hemos optado por utilizar la unidad "días hombre ideales" para las estimaciones. Tan lejos como cualquiera de nosotros puede recordar que un día ideal no ha ocurrido todavía, pero es una buena base cuando sabes cómo traducir los días del calendario a "días ideales para el hombre".
Como prescribe Scrum, el desarrollo se lleva a cabo en sprints 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 la dividimos por los días hombre planificados para el sprint. Este factor es la base para estimar cuántos "días de hombre ideal" puede gastar el equipo 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 agarra a un compañero desarrollador y hazlo juntos para hacerlo. O descompone el elemento de trabajo en tareas más pequeñas para que se pueda distribuir mejor.
90 horas es una fecha límite común para proyectos cortos. La manera fácil es, en lugar de estimar "su tiempo", medir otro. Los programadores de computadoras no deben hacer estimaciones de tiempo para sus proyectos ya que la evidencia muestra que el cálculo de los resultados de su propio tiempo genera un error mayor que la observación de otro.
A tus preguntas:
- Si eliges castigar a las personas por no cumplir los plazos, no obtendrás buenos resultados. Se desmotivarán y se sentirán menospreciados. Si sigues presionando a las personas para que cumplan con los plazos, la calidad del trabajo sufrirá y terminarás con un montón de tiempo dedicado a solucionar errores después.
- Para mejorar sus estimaciones de tiempo, podría intentar usar la programación basada en evidencia de Joel Spolsky que tiene un buen ciclo de retroalimentación para mejorar las estimaciones resultantes.
Pero tengo algunas preguntas en las que creo que debes pensar.
¿Es él 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 más optimistas son fáciles de solucionar, simplemente multiplique todas sus cifras por un factor según la programación basada en la evidencia anterior. Si él es un trabajador lento, ¿por qué? ¿Se distrae? ¿Tiene mucho cuidado de producir un código de defecto muy bajo? ¿Está él 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 a los efectos de informar el progreso en la jerarquía de gestión? Si esto último puedes resolver esto ajustando tus estimaciones tú mismo.
De acuerdo, esto es bastante común: los desarrolladores son optimistas. El trabajo de la Administración es lidiar con eso. Si alguien debe ser castigado, es el gerente (¿usted?)
Me alegra que al menos me hayas preguntado: parece que obtuviste algunas buenas respuestas de esta lista, espero que te ayuden y encuentres la manera de implementar realmente ese trabajo.
Cuando era joven, mi primer buen gerente lo trató de esta manera:
En primer lugar, me hizo presentar una lista detallada: dividir las tareas en horas y estimar cada una con una estimación muy liberal: ningún período debería ser inferior a 4 horas, independientemente de cuán pequeña fuera 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 1/2 día, si tienes suerte, y la mitad de eso se gasta en cosas que no esperabas tener para hacer).
Luego, antes de crear su agenda, duplicó todas mis estimaciones (sin decirme).
Los convirtió de esta manera, independientemente de los requisitos de calendario 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 fui mejorando al estimar, ambos notamos y ajustamos en consecuencia.
Un trabajo de gerentes no es solo hacer un proyecto, es construir un equipo. La mayoría de las veces eso requerirá entrenamiento de algún tipo. Esta es también la razón por la cual un gerente de ingeniería que no es ingeniero es inaceptable, realmente no pueden ayudar con este tipo de cosas.
El fracaso de un proyecto o programa VIRTUALMENTE NUNCA es culpa del desarrollador (excepto en algunos casos crónicos en los que no es realmente reparable o de valor y debe ser despedido). El gerente ha tomado malas decisiones al contratar al desarrollador, confiar en él, administrarlo o dotar de personal al proyecto.
Y realmente, ¿qué es la culpa de todos modos? Supongo que si el gerente no es muy bueno para hacer que el proyecto suceda, va a necesitar que alguien señale ... Si su gerente es bueno, preguntará por qué llegó hasta aquí, qué hizo para arreglarlo. , 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.
Entonces, ¿el desarrollador hace un buen trabajo, pero es pobre para estimar la cantidad de tiempo para la entrega? Todavía no estoy seguro de que tengas una situación de castigo en tus manos.
Tal vez de aquí en adelante, haga que lo guíe a través de 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. Puede encontrarse revisando sus estimaciones simplemente haciendo el ejercicio a un ritmo casi seguro más lento.
Establezca Hitos y pruebe Agile como se sugirió @OTisler.
Hay un interesante artículo de Joel Spolsky: Programación basada en evidencia
1) Rompe ''er abajo
Cuando veo un horario 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 averiguar realmente lo que vas a hacer. Escribe la subrutina foo. Crea este cuadro de diálogo. Analizar el archivo Fizzbott. Las tareas de desarrollo individual son fáciles de estimar, porque antes ha escrito subrutinas, diálogos creados y archivos analizados.
Si eres descuidado y eliges grandes tareas de tres semanas (p. Ej., "Implementar el editor de fotografías Ajax"), entonces no has pensado qué vas a hacer. En detalle. Paso a paso. Y cuando no ha pensado en lo que va a hacer, no puede saber cuánto tiempo llevará.
Establecer un máximo de 16 horas te obliga a diseñar la maldita función. Si tiene una característica de tres semanas ondulada a mano llamada "editor de fotos Ajax" sin un diseño detallado, lamento ser quien se lo corte, pero está oficialmente condenado. Nunca pensaste en los pasos que tomará y seguramente estarás olvidando muchos de ellos.
El punto principal es que él (y usted) deberían 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 regular del código al final del día para obtener una mejor idea 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.
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 miras cuidadosamente las estimaciones de tus otros desarrolladores, encontrarás mucho relleno. A veces, el relleno no es necesario, pero la tarea se expande para llenar el tiempo disponible de todos modos.
La solución a esto es cambiar la forma en que hace las estimaciones, para todos. Los desarrolladores pueden ser malos para estimar el tiempo absoluto, pero son bastante buenos en tiempo relativo. Entonces, el lunes, en lugar de "¿cuánto tiempo se tardará en agregar un whoosiwhatsit?", Pregunte "¿qué se puede hacer en el whoosiwhatsit en menos de una semana?" Eso se convierte en su tarea para la semana.
El lunes siguiente miras cómo fue. "Bueno, compré el floogle en dos días, pero resulta que impactó al mcphee ... así que esta semana necesito desacoplar a esos tipos para que los archivos whoosiwhatsit no se sobrescriban". Ok, está su tarea para la semana.
Podrías pensar que no será de ayuda, porque aún no sabes cuándo estará listo el whoosiwhatsit. Es verdad. Tu tienes dos opciones aquí:
Si necesita una fecha límite, entonces tiene que forzar a su desarrollador errante a llenar sus estimaciones como todos los demás. No le llevará mucho tiempo entenderlo, y en poco tiempo tomará "2 semanas" para escribir algo que debería haber tomado un día.
Su otra opción es cambiar las estimaciones ficticias para obtener más visibilidad. A largo plazo, este enfoque te permite tener ingenieros más productivos y más felices.
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 "no habrá problema" para finalizar la función X antes de la fecha límite. Luego, por lo general, me siento con ellos y repaso las tareas y subtareas que creo que deben realizarse para que la función finalice y cuánto tiempo piensa el desarrollador que cada una llevará.
Después de hacer este ejercicio y sumar todas las estimaciones de tareas y subtareas, inevitablemente llevará mucho más tiempo de lo que el desarrollador cree en su estimación original. Por lo general, solo tengo que hacer este ejercicio varias veces antes de que comiencen a hacer estimaciones más precisas.
No creo que el problema sea que le faltan estos plazos.
Creo que tiene un problema real al estimar la cantidad de tiempo que tomará completar una tarea.
Pídale que empiece a llevar un diario de lo que dice que llevará una tarea y cuánto tiempo le tomó completar la tarea. Finalmente, este diario se convertirá en una especie de guía para que cree mejores estimaciones. Una vez que sea mejor para estimar, no debe sentirse tan apresurado o acosado.
Si su primera pregunta es qué tipo de castigos debe considerar , creo que está perdiendo todo el tiempo. 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 configuró, si el desarrollador en cuestión no estuvo involucrado, entonces eso puede ser parte del problema.
Estoy de acuerdo con @OTisler en que la programación de los pares y posiblemente una revisión regular de los progresos al final del día puede ayudarlo a pasar ... aunque si los plazos / estimaciones no fueron realistas, para empezar, no es allí donde reside su problema.
Un monitoreo más detallado de algunas tareas específicas debería resaltar dónde se encuentran los problemas.
pregúntese esto: ¿qué implica su trabajo?
Si solo está pasando ciegamente las estimaciones de los desarrolladores (que usted sabe que no puede proporcionar buenas estimaciones) a la línea de gestión, y no decide por sí mismo si esa estimación es factible, entonces no está haciendo su trabajo.
Trate de pensar en términos de "valor agregado" (uno de mis antiguos empleadores usó mucho ese término, y lo odié, pero probablemente funcione para usted en esta situación). ¿Qué valor estás agregando? Si solo está pasando cosas en ambas direcciones entre la alta gerencia y los desarrolladores, entonces finalmente no está ganando su dinero. Podrías ser eliminado, y nada cambiaría.
El mejor gerente que tuve fue uno que examinó una serie de requisitos que le dio otro equipo, y les dijo directamente que casi un tercio de ellos era toro, y los había eliminado, incluso antes de ver la lista. El peor que tuve me hizo escribir toda esta documentación adicional de tipo de gestión que ninguno de los otros gerentes que alguna vez me había pedido que hiciera (realmente tuve la impresión de que literalmente estaba haciendo su trabajo por él), no lo hice. incluso me dio las fechas de vencimiento del proyecto, y apenas me presenté a trabajar. Ambos estaban en la misma compañía, extrañamente.
En primer lugar, asegúrese de tener claras sus necesidades.
Odio decirlo, pero en mi experiencia, los plazos de entrega son a menudo 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 exacerbe con usted.
Además, asegúrese de que sus requisitos sean realistas, así como sus estimaciones.
Asegúrese de que sus propias expectativas no lo obliguen a hacer estimaciones poco realistas para cumplir con requisitos poco realistas.
Recuerde, usted cumple con los requisitos, pero el desarrollador SIEMPRE hace las estimaciones, y no debe ser influenciado con "¿podemos hacerlo más rápido?" A menos que también esté especificando la funcionalidad que se eliminará.
Luego, asegúrese de que esté rastreando su tiempo / tareas con precisión, para que pueda obtener una buena visión de lo que está sucediendo con el proyecto.
Este proceso mostrará la falta de un seguimiento adecuado del tiempo / tareas, que puede terminar siendo el primer paso para la mejora. Si no puede ver después del proyecto cuánto tiempo tardó un artículo en particular, esa es probablemente la causa del problema allí: no hay suficiente definición en el presupuesto, o faltan tareas de "dependencia" que se descubren a mitad del proyecto, pero nunca se estiman .
TIENES que saber cuánto tiempo pasaste haciendo qué, exactamente, antes de que puedas averiguar dónde estaba el creep o qué se puede hacer al respecto.
Luego, vea dónde fallan sus estimaciones y descubra por qué. Repase una estimación de un proyecto volado, conviértalo en un proyecto en sí mismo, un problema que debe resolverse.
Una vez que hayas determinado que sus estimaciones son de hecho la fuente del problema, repasa una estimación que se realizó con él, y quizás otro desarrollador, y averigua por qué.
Esto te ayudará a descubrir cuál es la causa del problema. Una sólida comprensión del problema probablemente será la solución real.
Por último, si llega a un punto en el que tiene que intentar el castigo o la coacción, es hora de despedirlo y comenzar de nuevo.
El castigo y la coacción son respuestas apropiadas a las malas intenciones en ciertas situaciones.
Sin embargo, si este desarrollador está tratando activamente de hacer un buen trabajo, entonces solo empeoraría la situación al generar una actitud negativa y frustración.
Si el problema no se puede resolver, y usted está seguro de que el problema está con él, y no con usted, entonces es hora de despedirlo y obtener un desarrollador que pueda cumplir con los plazos. Un gran trabajo no significa mucho cuando sus costos se disparan y las ganancias se agotan.