¿Cómo debe manejar un gerente las estimaciones de tiempo razonables, pero desfavorables?

Me gusta la respuesta de HLGEM desde la perspectiva de Cover Your Assets y para establecer expectativas razonables en proyectos futuros. Tener un depósito personal de estimaciones anteriores (tanto las suyas como las de su gerente) es extremadamente beneficioso, tanto para el trabajo productivo futuro como para un caso desafortunado en el que una persona necesita disputar una revisión de desempeño desfavorable. Además, la gestión del alcance y la guía de configuración de expectativas funcionarán bien en muchos casos, aunque creo que debe equilibrar la precaución sobre si trabaja o no con el tiempo... según algunos detalles que he puesto a continuación.

Sin embargo, lo que me llamó la atención fue esa pregunta original: ¿ qué se hace al principio cuando se inician estimaciones desfavorables para corregir el problema? - en realidad no había sido respondida. Entonces, aquí hay algunos consejos que me han funcionado:

1 - Escuchar y pedir Detalle

Un problema clásico en cualquier negociación es que ambas partes piensan que se han comunicado de manera efectiva, lo que significa que ambas partes creen que han entendido completamente lo que la otra parte estaba diciendo y que la otra parte las entiende. Muy a menudo, esta percepción es falsa. Particularmente en la brecha entre la gerencia y el trabajador técnico, la jerga y el proceso pueden causar una ruptura severa.

En el ejemplo planteado anteriormente, estaría haciendo las siguientes preguntas:

• ¿Todos definen "foo" y "bar" de la misma manera? Claramente, el empleado ve "fooing the bar" como algo que plantea los problemas A, B y C. ¿POR QUÉ el gerente no ve "fooing the bar" de la misma manera?

• ¿Estamos todos de acuerdo en la probabilidad de los problemas A, B y C? Tal vez el gerente los vea como un 5 % de posibilidades, mientras que el empleado sabe que hay un 80 % de posibilidades de que estas cosas sucedan. ¿Por qué el gerente no los ve como un problema? ¿Por qué el empleado? No es habitual que los procesos o la tecnología hayan cambiado desde la última vez que el gerente realmente hizo este tipo de trabajo (si ALGUNA VEZ hizo este tipo de trabajo...) y con razón puede pensar que estas cosas son menores, según la información que tiene. tiene disponible.

• ¿Importan los temas A, B y C? ¿Cuánto importan en relación con terminar el trabajo a tiempo? ¿Podemos llamarlo "hecho" si A, B y C siguen siendo problemas abiertos? ¿Por qué? ¿Por que no? Como gerente y como empleado, algunos de los debates más difíciles han sido estos. Como gerente, he ido en ambos sentidos: he retrasado los horarios según las explicaciones de los empleados sobre por qué el problema es catastrófico, y les he dicho a los empleados que aguanten y dejen el problema abierto en otros casos. Aquí es donde yo Me gano mi paga como jefe: sé cuándo arreglar o no arreglar algo porque entiendo el negocio y las compensaciones involucradas.

• ¿Por qué el crujido? Muy, muy pocos gerentes con los que he hablado que merezcan algún grado de respeto quemarán voluntariamente a su gente para realizar un trabajo. En los casos en los que se encuentre en el nivel de negociación de "simplemente hágalo", aún debe preguntarse "por qué". Si la respuesta se reduce a "porque todos nos quedaremos sin trabajo en los próximos 6 meses si no lo hacemos", entonces puede ser hora de considerar las horas extra y dejarlo todo. Tenga en cuenta, sin embargo, que a su jefe solo se le permite jugar la carta de la crisis una vez al año más o menos... si tiene una emergencia decisiva todos los meses, entonces debe comenzar a hacer más preguntas como "¿por qué no ¿Ves esto venir?", "¿Realmente entendemos el negocio y sus clientes?" y " ¿Qué diablos está pasando en la sala de juntas ejecutiva? ¿Están todos fumando algo?"

• una pregunta relacionada pero diferente es "¿qué pasará si arruino este cronograma?" Las estimaciones se realizan por todo tipo de razones... en un caso, incumplir un cronograma a sabiendas puede conducir a la ineficiencia, porque se podría haber tomado un enfoque diferente si se conociera el cronograma real. En otros, es simplemente un mecanismo de medición y gestión, una forma de establecer metas y expectativas. Esto influye en la gestión de proyectos, como la "ruta crítica", pero si su gerente vale algo, debería poder explicar la ruta crítica en términos que van más allá de Microfot Project 101 y hablan de los impulsores comerciales reales de su empresa.

2 - Hablar a la audiencia

Una de las cosas más riesgosas de un ex gerente técnico que piensa que sabe cómo hacer su trabajo es que probablemente sabe más que suficiente para ser peligroso. Los términos de tecnología tienden a sonar similares de una década a otra, mientras que la actividad real puede cambiar notablemente.

Esta es un área delicada, ya que no querrás preguntarle al jefe si realmente sabe lo que realmente significan todas las palabras en tu oración. En cambio, debe buscar señales de que las palabras que está lanzando muestran una marcada desconexión de la realidad tal como la conoce. Entonces necesitas hacer una copia de seguridad y redefinirlos con él. A menudo, esto se puede hacer suavemente con frases de conexión como "así es como defino lo que acabas de decir..." o "déjame llevar esto a un nivel más profundo de detalle para estar seguro de que realmente nos entendemos..." Cosas como esto le permite hacer un poco de educación gerencial en el camino.

3 - En general

Encuentro que la comunicación técnica sobre la incertidumbre siempre es complicada: es el caso en el que todos tienen que asumir más de lo que les corresponde en la comunicación.

Otro truco es ingresar un "¿podemos arreglar esto?" conversación que no está cargada con la necesidad de comunicar sobre una tarea real y una estimación. Encontrar un momento de bajo estrés entre las tareas y la reserva en algún momento con su gerente le permitirá decir "hey, parece que tenemos este mal ciclo en el que le doy una estimación, no me cree, no puedo cambiar su mente, y no puedo cumplir con la fecha límite, así que estamos todos jodidos... ¿cómo arreglamos esto?". Dar un paso adelante y comprometerse le mostrará al jefe que realmente te importa, que no lo estás rechazando solo por diversión... y les da a ambos algo de espacio para pensar en el horrible patrón sin el problema inminente de la siguiente tarea.

Además, asumo alegremente que todos en su oficina tienen el mismo problema, o que no hay ningún compañero suyo que tenga un conjunto similar de circunstancias. Las respuestas anteriores son pautas generales para tratar de descifrar a otras personas... el kilometraje en cualquier truco en particular varía notablemente de un gerente a otro. Las personas tienen diferentes tipos de estilos y barreras para la comunicación y, a veces, el orden de las operaciones en una comunicación u otros factores que suenan menos sensibles entrarán en juego en términos de ser efectivos. Si tienes un compañero de trabajo que tiene necesidades similares de negociar tareas con el jefe, y tiene mejor suerte, pide ayuda. Es probable que tenga algunos trucos para manejar esto... y si realmente estás atascado,

Está cometiendo un error fundamental y, al hacerlo, le está perjudicando a usted y a su empresa: las estimaciones no son negociables. Las estimaciones de tiempo representan su mejor CONVIVENCIA sobre cuánto tiempo llevará algo, según su experiencia.

Puede desglosarlo, pero es imposible de justificar: es su opinión y experiencia.

Trabajar horas extras no acorta el proyecto, en el mejor de los casos significa que se utilizan menos días calendario, pero la cantidad de horas (que es la unidad en la que debe dar sus estimaciones) seguirá siendo la misma y, de hecho, puede aumentar.

Su conversación de muestra debería ser así:

Gerente : ¿Cuánto tiempo tomará terminar la Tarea X?
Trabajador : YY horas.
Gerente : ¡Eso es N semanas! Eso debería ser fácil, solo debería tomar Z días. Solo tienes que ir al bar, pan comido.
Trabajador : En mi opinión, me llevará YY horas.

Solo cambie su estimación en respuesta a un cambio en el alcance o un cambio real en su estimación (ya sea hacia arriba o hacia abajo). Negociar tu opinión es solo una frase elegante para mentir...

Tenga en cuenta que esto no significa que el gerente esté equivocado acerca de cuánto tiempo tomará, o que no debería presupuestarlo como le parezca mejor; eso es un asunto completamente diferente. Pero el trabajador al que se le pide que proporcione una estimación debe proporcionar una estimación, no repetir lo que diga el gerente.

Editar en respuesta al comentario: se ha sugerido que el empleado debe realizar un seguimiento de su estimación, la estimación de los gerentes y el tiempo real. Y el quid de la cuestión es que él debería estar haciéndolo, al igual que el gerente. Deberían estar haciéndolo, para que ambos puedan hacer un mejor trabajo al estimar el tiempo para el próximo proyecto, con más confianza y experiencia.

Documéntalo todo. Mantenga una hoja de cálculo de su estimación inicial, la estimación reducida y lo que realmente tomó. Eso debería mejorar la capacidad de estimación de los desarrolladores y mostrarle al gerente qué tareas similares requerían en el pasado. Si el gerente es razonable, el simple hecho de poder mostrar la historia pasada puede ayudarlo. También le da algo que mostrarle a la alta gerencia cuando el gerente de línea intenta tirarlo debajo del autobús por no cumplir con la fecha límite que le dijo que no era razonable. Y siempre objete la fecha límite irrazonable por escrito, indicando por qué no es razonable y qué es posible que tenga que recortar para cumplir con la fecha límite. Y asegúrese de que todas las partes interesadas en su empresa estén copiadas en ese correo electrónico.

Al hacer estimaciones, hágalas en detalle. No olvide incluir tiempo para reuniones y comunicaciones por correo electrónico, tiempo para escribir/ejecutar pruebas unitarias, tiempo de depuración (puede incluir eso en el tiempo de desarrollo si lo prefiere, solo asegúrese de incluir el tiempo). Incluya tiempo para respaldar las pruebas de QA y UAT (responder preguntas, solucionar problemas encontrados, etc.) y tiempo para hacer la documentación requerida. Tenemos una plantilla que usamos que incluye todo esto, por lo que nunca lo olvidamos al estimar. Cuantos más detalles tenga, más difícil será descartar su estimación como inexacta. Y más fácil es probar después que usted tenía razón y el gerente estaba equivocado.

Próximo paso. No trabaje por la noche ni los fines de semana para cumplir con un mal plazo. Esto solo los alienta a establecer plazos insatisfactorios porque los cumplirá incluso si se pasa de las horas asignadas, incluso si eso lo mata. Pero hace que sea más difícil pedir lo que necesita cada vez después de eso. Bueno, terminaste XYZ en una semana y esto es más fácil. Sí, pero no quiero trabajar 120 horas cada semana.

Finalmente, no acepte ningún cambio en el requisito sin un cambio correspondiente en las horas y la fecha límite. Esto es especialmente cierto si el problema proviene del cliente o de las partes interesadas internas, no de su gerente inmediato. Obtenemos un cambio en el requisito, les decimos cuánto tiempo más tomará y cuánto adelantará la fecha límite. Es asombroso cuántos de esos plazos inamovibles se vuelven móviles. Y es sorprendente cuánta funcionalidad absolutamente necesaria deja de ser necesaria hasta la próxima versión cuando haces esto.

Aclaremos dos cosas por adelantado: - ¿Cuáles son las cosas que pueden impedir que una persona haga las cosas a tiempo? - qué innovación (ya sea pequeña o grande) podría ayudar a una persona a terminar una tarea antes de lo esperado.

Si yo fuera el empleado o el empleador, comenzaría con esos dos puntos.

Echemos un vistazo más de cerca a ellos:

• cosas que pueden impedir que una persona haga las cosas a tiempo

tecnicismos: - falta de equipo adecuado, lugar de trabajo inconveniente, mucho tiempo perdido en los desplazamientos, distracciones, etc.

comunicación: - probablemente la mayor pérdida de tiempo. Mientras que las estimaciones son más o menos conjeturas, reducirlas a componentes específicos disminuye el nivel general de incertidumbre. Casi cualquier tarea, en cualquier campo, consiste en trabajo en la tarea misma, comunicación, distracciones, descanso, revisiones, control final. La comunicación tiende a tomar la mayor parte del tiempo y, sorprendentemente, para los empleadores, la mayoría de las veces son ellos los que causan que se consuma una cantidad extraordinaria de tiempo en esto. Mi consejo es establecer un límite de tiempo inicial (cuota) en la comunicación.

recursos humanos: - no tener a alguien disponible para guiarlo/ayudarlo cuando se atasca/hacer una revisión rápida/etc. puede ser un serio inconveniente en algunos casos. No sabe si es posible que necesite ayuda externa y cuándo, pero cuando la necesita y no está disponible de inmediato, se desperdician cantidades pecaminosas de tiempo para nada.

motivación: - si pudiéramos hacer esto bien, podríamos hacer todo bien... Un tema amplio, pero vale la pena pensarlo o leer algo al respecto, en cada tarea que asignamos o nos asignan. Una pregunta provocativa aquí: ¿podría el simple hecho de pensar en una fecha límite existente desmotivar a uno de hacer las cosas a tiempo? Incluso cuando los plazos funcionan como motivadores, ¿no son demasiado estresantes? ¿No hay una mejor manera?

• qué innovación (no importa si es pequeña o grande) podría ayudar a una persona a terminar una tarea antes de lo esperado

En lugar de preocuparnos por las estimaciones, ¿no podríamos intentar mejorar los flujos de trabajo de las tareas con cada nueva tarea? Esto es lo que predica Kaizen/mejora continua. Optimicemos la estructura del flujo de trabajo y hagámoslo lo más independiente posible del ser humano particular involucrado. Entonces no existiría el problema de discutir sobre las estimaciones.

lo que el gerente realmente quiere es una buena barra de progreso sobre cómo va el trabajo. En mi libro, cualquier cosa estimada en más de una semana es algo que necesita un desglose funcional y una especificación adecuados. Entonces, comenzaría a producir la lista de compras de tareas que deben realizarse hasta que estén en el intervalo de 1 a 2 días: debería poder producir al menos 5 de estas, probablemente más. La lista de compras será como "definir api" "paquete de refactorización" este tipo de cosas. Luego, cuando el gerente quiere actualizar, solo muestra lo que está marcado en la lista de compras. Estarán más felices porque se sentirán más conectados con el trabajo y tú estarás más feliz porque habrá menos ambigüedad. Si el gerente no está interesado en la lista de compras, entonces su cronograma agresivo es simplemente bravuconería al estilo de los locos.

Este problema se resolvió hace años, se llama estimación de punto de historia .

Puedes leer sobre esto en línea, pero básicamente:

Evita que la gerencia intente manipular a los desarrolladores para que hagan estimaciones de tiempo poco realistas al no tener ninguna estimación de tiempo .

En su lugar, cada pieza de trabajo se divide en tareas pequeñas, y cada desarrollador (no el administrador) estima el tamaño/complejidad de la tarea como un valor en puntos (1, 2, 3, 5, 8, 13... los números de Fibonacci funcionan mejor). La puntuación de la mayoría/promedio se convierte en la "estimación" de la tarea.

Después de algunas semanas, el equipo se vuelve consistente con lo que consideran un triple, lo que es un triple, etc. (es diferente para cada equipo).

También se ponen al ritmo de cuántos puntos de tareas se completan por semana.

El gerente nunca puede decir cuántos puntos es un trabajo, por supuesto. Y ahora es culpa de ellos si esperan que el equipo haga 100 puntos de trabajo en una semana cuando siempre hacen alrededor de 50.

Muchas tareas no se pueden estimar con precisión, eso es solo un hecho de trabajo muy complejo (como el desarrollo de software). Pero si las tareas son lo suficientemente pequeñas, y el equipo de desarrollo está a cargo de la estimación, y se basa en la complejidad en lugar del tiempo, un gerente puede planificar lanzamientos y administrar las expectativas del cliente.

Mi experiencia con esto fue la siguiente: me pidieron que creara una línea de tiempo de Microsoft Project para una migración de software que involucraba una pantalla verde a GUI a mediados de la década de 1990. Calculé dos años y medio. La persona que me pidió programar el proyecto dijo 'haz que encaje en un año'. No iba a ser el desarrollador, pero sabía que la estimación de un año era inútil, y se lo dejé claro a la persona que me pidió que lo hiciera.

Básicamente, moví todo para que encajara en el marco de tiempo de un año. El empleador se comprometió, yo seguí adelante, y como hice un seguimiento con las personas que hicieron el trabajo, resultó que tomó alrededor de tres años. Esta fue una migración de proyecto militar y no había duda de que el nuevo sistema era necesario, por lo que no hacerlo no era realmente una opción. El contratista le dijo al comprador militar todo lo que quería escuchar, facturó el tiempo y los materiales, y lo hizo. Si el cronograma está impulsado por preocupaciones políticas en primer lugar, el estimador simplemente debe decirle a la gente lo que quiera escuchar, advertirles que la estimación es optimista y dejar que los segundos adivinen vivir con los resultados.