You just have to put some pressure on them! Set a deadline!
After all, it works for programmers, doesn’t it?!?
Management is used to negotiate everything, so when the developers come with an estimation for the work to be done their first reaction is:
“2 weeks… That’s ok… Now what if we put pressure on them? Tell them they have a week to get the job done.”
And I can understand that… It’s the job of the development managers or directors to keep things in balance and ensure the developers get the necessary time to do quality work. If not, they WILL cut corners in quality. At 10 PM they WILL choose going home over spending some more extra hours making and running tests.
What I can’t understand are the people with a programming background that, as soon as they start climbing the company hierarchy, they start setting out-of-the-blue deadlines for the developers they now manage.
What über programming technique were they using in their programming days when they got unrealistic deadlines to get the job done in time AND with quality?!?
PS: Just to be clear, this article not is about deadlines in general – it is about deadlines set without taking into account the developers’ estimations.
I know that everyone in the programming field hates this situations.
But, what a simple programmer can do against that?
Jamás había escuchado de eso…. Aquí en México jamás pasa eso…
Yeah!!
Destroy the deadlines and say yo-ho!!
Nice post, I hate having almost impossible deadlines, makes no sense at all…
My friend had this message: "Why have one list of tasks impossible to complete before a deadline, when you can have TWO!"
I am beginning to feel that way too.
Always add FIVE to your estimation…
Hay varias formas de realizar estimaciones, convengo que siempre SE DEBEN de hacer en conjunto con el equipo de trabajo (al final del día ellos lo realizan), eso es el deber ser, hasta aquí estamos de acuerdo, pero: ¿que pasa cuando el desarrollador es flojo y no tiene sentido de responsabilidad?, ¿que pasa cuando las estimaciones del desarrollador incluyen el ir 3 veces al día al starbucks, 2 veces a la cocina a ver la tele, 2 horas en socializar entre ellos, etc.?, no tengo nada en contra de ello, yo algun día estuve en esa posición, tampoco espero que un desarrollador pueda entender la urgencia, premura y importancia de las cosas, la mayoría de ellos son cuadrados y su mundo es el codigo.
Afortunadamente hay varios métodos de estimación que ayudan a reducir el riesgo de malas estimaciones y se basan en los peores, medios y mejores escenarios del mismo, tomando métricas organizacionales e información histórica de proyectos similales de forma tal que no se puedan inflar los tiempos reales de desarrollo.
Sobre la calidad, pruebas y las metodologías para asegurarla no me gusta meterme en discusión, ya que la calidad va ligada a la calidad de la persona que la implementa y la implementación de una metodología para obtenerla por si sola no genera ningun tipo de garantía, es relativo y no aplica de la misma forma para cualquier tipo de empresa.
Saludos a todos.
@Sergio:
Me suena que el problema que tienes no son las estimaciones, la causa raiz es la falta de interés de los desarrolladores. Es posible que no están motivados para dar su mejor esfuerzo las 8 horas del día? Hay muchas maneras de atacar esto con el apoyo de RH.
Sin embargo, atacando el síntoma, imponiendo deadlines, probablemente empeoraría la situación: "Porque preocuparme si de cualquier modo esto no puede salir a tiempo y voy a tener que trabajar horas extra?!?"
@Vlad:
No estoy hablando de un problema, no estoy hablando de desmotivación, estoy aludiendo un posible escenario solamente. ¿Hay formas de atacarlo?, por supuesto:
1.- Desarrollando un plan de recusos humanos
2.- Definiendo un proceso para la adquisión, desarrollo y administración del equipo de proyecto.
Dentro de dicho plan, precisamente se prevee de forma anticipada el descontento o desmotivación que comentas.
¿Como? (lo que he visto que funciona, no tengo formación en RH):
- Evaluando regularmente el desempeño de los empleados en bases a estandares y responsabilidades específicas de sus puestos de trabajo.
- Determinando necesidades de formación en base a experiencia, puesto, responsabilidad, desarrollo futuro personal y tecnológico, planificando la cobertura de estas necesidades y llevándolas a la práctica.
- Promoción del personal
- Controles internos de aseguramiento de cambios de actividades de acuerdo a contratos de trabajo.
En ningún momento estoy diciendo que la solución sea imponer fechas compromiso, estoy de acuerdo que eso empeora la situación, en el momento en que se presenta una actitud laxa por parte de un recurso como la que aludes, esto es atribuible a falta de actitud, y conforme el tiempo se convierte en un fenómeno cancerígeno que afecta a los demás miembros del equipo y por lo tanto "se debe" confrontar el problema de raíz. (existen muchas tecnicas para realizarlo también).
¡Salu2!.
@Sergio:
Correct, you seem to have it figured out then!