Cuando se le pide que estime las fechas de finalización, ¿hay alguna manera especialmente educada o inteligente de decir que es “Hecho cuando esté hecho”?
¿Es la única manera de decir, “No puedo decirlo ahora mismo, compruébelo conmigo a [hora determinada]”?
He sido gerente en el extremo receptor de “se hará cuando se haga”, y se trata de la respuesta menos útil que se puede dar+. Decir eso y nada más te pone en grave peligro de ser considerado poco colaborador. Es absolutamente necesario dar más información.
Para explicar un poco más sobre el “por qué” de eso, en un proyecto de software a menudo hay acciones que sólo se pueden hacer cuando se ha terminado, pero que tienen que ser planificadas y programadas con antelación. Si no puedes decir algo acerca de cuándo estarás terminado, el proyecto termina siendo aún más tarde y a menudo cuesta más dinero.
Dicho esto, “¿Cuándo estarás terminado?” no siempre significa “Date prisa”. A menudo la persona que pregunta quiere saber para poder planear. Es mejor asumirlo a menos que tenga una razón para pensar de otra manera.
Aquí hay algunas posibles circunstancias en las que podría estar:
A veces, por supuesto, te das cuenta de repente durante algún trabajo que va a llevar mucho más tiempo del que piensas. Si el momento en que trabajas es importante, normalmente es mejor sentarse e intentar averiguar cuánto tiempo va a llevar realmente, en lugar de limitarse a arar. A veces (o en realidad siempre, debido a la ley de Murphy) se te pedirá una estimación mientras aún estás trabajando en ello. En ese caso está perfectamente bien decir “Tendré una mejor estimación para ti en [algún tiempo]”
Por cierto, todas las respuestas anteriores asumen que eres un trabajador de “nivel superior” responsable de su propia programación. Si no, o en caso de duda, involucre a su jefe.
+_No es técnicamente la respuesta menos útil. Una mentira descarada, o una cita que no tiene intención de cumplir sería peor. Pero “estará hecho cuando esté hecho” es sólo un paso adelante de esos.
Cuando te piden que estimes las fechas de vencimiento, ¿hay alguna forma especialmente cortés o inteligente de decir que es “Hecho cuando esté hecho”?
Siempre me ha gustado “una vez que la gente deja de interrumpirme”, pero no soy especialmente cortés.
Es la única forma de decir, “No puedo decir ahora mismo, compruébalo conmigo a [hora determinada]”
Ciertamente no. Hay empresas/culturas donde “Cuando esté hecho” es una respuesta aceptable Blizzard por ejemplo , al menos externamente), y te animaría a trabajar y cambiar tu cultura hacia eso.
“No estoy seguro, depende de Alice y Bob y… ”“ es una respuesta bastante pasiva-agresiva que puede ser usada en algunas áreas para desviar a la persona que hace la pregunta y si se hace bien puede convertir a esa persona en un activo que te ayuda a eliminar los obstáculos.
"No estoy seguro, ¿cuándo me vas a conseguir X? ” es una respuesta más claramente agresiva donde alguien se está entrometiendo en tu negocio pero no cuidando del suyo. Puede ser útil señalar que tus estimaciones no van a ser mejores que las de ellos, y mantenerte en un nivel más alto es una tontería. No es recomendable.
“No estoy seguro, necesito comprobarlo con mi equipo ” puede ser una respuesta sólida que te da tiempo para considerarlo, así como retratarte como alguien que se somete a un conocimiento experto. También ayuda si lo compruebas con tu equipo, ya que normalmente pueden proporcionar una buena información, así como ser comprados en la fecha límite a la que esencialmente los estás comprometiendo. Sin embargo, ten cuidado, ya que esta respuesta puede ser mal utilizada y presentarte como alguien que no hace nada más que ser un intermediario.
“Eso depende, ¿qué tiene que hacer? ” Otra respuesta sólida que puede ser pasivo-agresiva, pero a veces puede llevar a una bonita sesión improvisada de recopilación de requisitos. También funciona para mantener un negocio honesto. Si te comprometes a trabajar, entonces ellos necesitan comprometerse con el alcance (y los recursos).
“Eso depende, ¿qué tan bien necesita funcionar? ” Similar a la última pregunta, ayuda a refinar el alcance y cumple con el tercer lado del triángulo .
“No lo sé. Este sprint es XYZ. ” Una respuesta limitada para la gente que usa sprints (a menudo ingenieros de software). Lo bueno aquí es que la compañía probablemente se ha comprometido a hacer Agile con Sprints, así que tienes ese respaldo. En un ambiente ideal, las únicas cosas planeadas son para las ~2 semanas de tu actual sprint. Todo lo demás no está planeado a propósito para que puedas estar bien… …con lo que tiene prioridad. En un mundo no ideal, las cosas son probablemente planeadas al enésimo grado, y luego divididas en trozos de dos semanas, pero la pregunta proporciona una buena oportunidad para que comentes con sarcasmo sobre ese absurdo.
Así que en resumen, hay muchas malas maneras de esquivar la pregunta. Probablemente es mejor dar algún número del peor de los casos y luego volver a hacer el trabajo real.
Me gusta “no hay una estimación para eso todavía”.
Da la respuesta que quieres, es bastante objetiva y neutral en su tono, y sugiere que se podría hacer una estimación en algún momento, pero ciertamente no en este momento aquí en la máquina de café sin una imagen clara de lo que realmente significaría hacer lo que está preguntando.
Necesitas estar preparado para la pregunta “qué necesitarías para hacer una estimación”, ya que eso debe ser tomado en serio.
Cuando se te pide que estimes las fechas de vencimiento, ¿hay alguna forma especialmente educada o inteligente de decir que está “Hecho cuando esté hecho”?
Normalmente no puedes salirte con la tuya siendo inteligente y diciendo “Estará hecho cuando esté hecho” sin importar cómo lo enmarques. Cuando se le pide que estime las fechas en que está hecho, eso no es lo que el preguntón quiere oír.
En cambio, puedes transmitir tu estimación, y dar un grado de exactitud a tu estimación.
Algo así como “Basado en mi comprensión actual del proyecto, mi estimación es de 3 meses. Pero, como los requisitos no están escritos todavía, podré proporcionar una estimación más precisa una vez que los lea”. (Extraoficialmente, los llamo “guesstimates”.)
Si tu entorno de trabajo requiere algo más formal que este tipo de estimación hablada o enviada por correo electrónico, asegúrate de incluir todos tus supuestos en tu estimación formal, junto con tu evaluación de la precisión con la que eres capaz de estimar en ese momento.
Puedes hacerlo mejor, si se te permite más tiempo con el que preparar tu estimación, y se te dan más datos en los que puedas basar tu estimación. Pero siempre se puede estimar en cualquier período de tiempo - siempre y cuando no se espere que la estimación sea particularmente precisa.
Una vez que proporcione sus estimaciones (sin importar cómo se deriven), mantenga a sus interesados al tanto si ocurre algo que cambie su estimación - particularmente cuando se avecinan los plazos.
Asumo que usted es la persona responsable del proyecto o tarea sobre la que se pregunta. En ese caso, ¿por qué no puede decirlo?
Todas estas son razones legítimas para no tener una buena estimación, pero también son problemas que tienes que plantear proactivamente a tu responsable (o en el primer caso, podrías conseguir que te reconociera que la tarea puede deslizarse para permitir cosas de mayor prioridad). “Hecho cuando está hecho” simplemente dará la impresión de que no sabes y no estás haciendo nada para averiguarlo. Como tal, esto impide que su gerente planifique el panorama general.
De sus respuestas a los comentarios y respuestas, sospecho que su pregunta debería ser realmente:
Mi trabajo consiste en muchas pequeñas tareas, que puedo recibir en cualquier orden, y que tienen diferentes prioridades. Tengo una cola constante de tareas de menor prioridad que sólo puedo hacer cuando no hay tareas de mayor prioridad por completar.
A menudo me piden que dé estimaciones sobre cuándo se completarán las tareas de menor prioridad. Mi respuesta actual, “Se hará cuando esté hecho” no está siendo bien recibida.
¿Qué debo hacer?
Desde esta perspectiva, la respuesta es obvia - necesitas hacer un mejor seguimiento y gestión de las tareas. Esto no implicará un cambio en su proceso/cola/priorización - sólo un poco de trabajo extra en el seguimiento del tiempo de cada tarea.
Número 2 va a requerir un poco más de trabajo cada semana. Si ya llevas un registro de las tareas y el tiempo no debería ser difícil, pero incluso si no llevas un cuaderno de notas, y cada vez que terminas una tarea escribe el nivel de prioridad y cuántas horas le dedicaste. Al final de la semana puedes sumar el tiempo de cada prioridad, y una vez que hayas estado haciéndolo durante unas semanas deberías tener una media de funcionamiento decente.
Cuando alguien te pida una fecha de finalización, suma todas las horas de su tarea y las tareas que tiene por delante en un determinado nivel de prioridad, para el tiempo mínimo y máximo, y luego divide por el número medio de horas disponibles para ese nivel de prioridad por semana. No les digas cuántas horas has asignado por tarea, o cuántas horas has asignado por semana, sólo necesitan saber el día que no ocurrirá antes, y el día en que debe hacerse. Hay 3 tareas previas a esa, y parece que el mejor caso es el próximo viernes, y el peor caso es el miércoles siguiente. Consúltenme en unos días y tendré una mejor estimación.“_
Si hay tareas que necesitan hacerse que nunca se hacen, pueden considerar implementar un aumento de nivel de prioridad basado en el tiempo. Las tareas de baja prioridad, si no se hacen en N semanas, pasan al siguiente nivel de prioridad.
De esta manera puede proporcionar estimaciones que manejarán las expectativas de sus compañeros de trabajo y superiores.
No hay información, "Se hará cuando esté hecho” es peor que la información no deseada, _“Las tareas de mayor prioridad nos están inundando. Pasarán 8 semanas antes de que esto reciba una actualización automática de prioridad, y luego tomará una semana o dos en esa cola hasta que esté terminado.”
Eso es algo que nunca deberías decir. Todo lo que hará es irritar a su gerente y hacerle parecer incompetente.
Dígale lo que cree que tomará (si no puede definir los pasos y más o menos lo que tomarán, entonces probablemente necesite que alguien haga un mejor trabajo sobre los requisitos, así que dígale que los requisitos no están claros y por lo tanto no puede determinar lo que tomará), qué retrasos tiene generalmente debido a un trabajo de mayor prioridad y luego dele una fecha. Los clientes no aceptarán siempre como fecha de vencimiento y por lo tanto no debes dársela. Cuando ocurran cosas que cambien la prioridad y otras cosas se adelanten, envía un correo electrónico al gerente y fija una nueva fecha basada en el retraso. A menudo cuando señalas el cambio de la fecha de vencimiento, esas cosas de mayor prioridad se desplazan hacia abajo. Cuando ocurran cosas que hagan que el rwork tome más tiempo del que estimaste, asegúrate de que el gerente sea inmediatamente consciente del impacto que eso tiene en la fecha de vencimiento.
Cualquier dev debería ser capaz de proporcionar estimaciones de tiempo. Es parte de lo que te pagan, así que deja de lidiar con el “cuando sea”. Si no eres bueno en esto, entonces mejora manteniendo registros de lo que estimaste y cuál fue el tiempo real. Incluya en su estimación el tiempo de demora y el tiempo de las reuniones, la comunicación por correo electrónico, los requisitos de refinación, las pruebas de unidad, las pruebas de apoyo a la calidad, etc., para obtener un mejor número. Si se le pide una fecha directa, asuma no más de 6 horas productivas al día cuando convierta las horas que cree que tomará en días y ponga un par de días para los inevitables retrasos.
Basándose en los comentarios de otras respuestas, parece que su problema no es la estimación del tiempo sino la comunicación de los retrasos basados en el cambio de prioridades. Lo que necesitas es ser más, no menos comunicativo cuando esto ocurre. Necesitas hacer saber a la gente cuando su tarea ha caído en la lista de prioridades (y a qué) y se retrasará y cuánto tiempo esperas que pase antes de que vuelvas a ella. Deje que vayan a pelear las prioridades con los gerentes. Dígales que pueden hablar con el gerente si no están de acuerdo con las prioridades actuales.
Pero es su obligación absoluta hacerles saber cuando las cosas cambien y que usted estará trabajando en algo antes de su proyecto. Esto no debe esperar hasta que tengan que preguntarte por qué no se ha hecho todavía. En cualquier caso, “cuando sea” no es una respuesta aceptable. Pretender que estás demasiado ocupado para responder tampoco es aceptable.
Necesitas entender que los informes de progreso, las estimaciones de tiempo, etc. son todo tu trabajo y son tan importantes o más importantes que las partes del desarrollo real. Esto no es una interrupción innecesaria, es parte de su trabajo. Estas personas están pagando tu salario con sus proyectos. Empieza a tratarlos con respeto y respetando sus necesidades. Una vez que sepan que pueden confiar en ti para que les digas cuándo se retrasarán las cosas, te molestarán menos.
Deberías responder con una distribución, no con un solo número: algo como, “Podría hacerse la semana que viene, si tenemos suerte”. Si no tenemos suerte, dentro de seis semanas. La mejor estimación es de unas dos semanas". Esa respuesta a menudo tendrá una mala reacción. Si lo hace, puedes señalar cualquier número de tratados de estimación de costos de software que muestren que tal incertidumbre es común y realista.
He trabajado en un proyecto similar a este. Una tarea que pensé que tomaría dos semanas terminó tomando un mes y medio.
Afortunadamente sabía que no tenía una comprensión adecuada del tiempo requerido para entrar. Así que cuando mi jefe me preguntaba en el standup (trabajamos con desarrollo ágil) le daba mi mejor estimación y le explicaba por qué pensaba eso. Aunque mis estimaciones resultaron ser inexactas, le di lo que pensaba que se necesitaría por cada petición pero me aseguré de que supiera que estaba sujeto a cambios.
En general, la honestidad es lo mejor, sea sincero al respecto y manténgalo informado. Hay veces que no hay una respuesta clara y todo lo que podemos hacer es mantener a nuestros jefes tan informados como sea posible.