Estimación de tareas para PM que no son desarrolladores

Si es posible, no lo hacen.

Piden a los desarrolladores que lo estimen.

Las estimaciones siempre deben ser realizadas por las personas que realizarán el trabajo que se estima. Si esto no se hace, entonces corre los siguientes dos riesgos:

1. La estimación es inexacta, ya que la persona que la estimó no tenía conocimiento del trabajo que debía realizarse.
2. Las personas que hacen el trabajo no tienen ningún compromiso con esa estimación y, por lo tanto, es menos probable que también tengan compromiso con cualquier objetivo o fecha límite para ese mismo trabajo.

Haga que los ejecutores de tareas proporcionen estimaciones

En marcos ágiles (e incluso en marcos sensibles no ágiles), los gerentes de proyecto nunca deben estimar los elementos de trabajo por sí mismos. ¡En cambio, las personas que realmente harán el trabajo ("ejecutantes de la tarea") hacen la estimación!

Para obtener las estimaciones más realistas, haga que los ejecutantes de la tarea calculen el tiempo y la complejidad del trabajo que realizarán. Desea que calculen en función de sus propias habilidades, conocimientos y recursos, porque en realidad no importa cuánto tiempo le tomaría a otra persona hacer el trabajo. Todo lo que importa en un sentido pragmático es cuánto tiempo les tomará a las personas asignadas al proyecto realizar una tarea con los recursos que tienen disponibles.

Si debe confiar en estimaciones de terceros por algún motivo (por ejemplo, tener un experto en la materia en lugar de los ejecutores de la tarea que proporcione una estimación de planificación aproximada), entonces querrá capturar las suposiciones de esa persona y luego aplicar intervalos de confianza apropiados y fudge. factores a las estimaciones que producen.

Expresar estimaciones como un rango

El producto final de cualquier estimación debe ser un rango, no un valor único. Muchos profesionales apuntan a un intervalo de confianza del 80 %, pero también incluyen objetivos pesimistas y optimistas. Por ejemplo, puede usar 60-95% como su margen inicial, con una expectativa inicial de 80%. ¡Solo asegúrese de comunicar de manera efectiva a las partes interesadas que cualquier estimación es un pronóstico y no una garantía de devolución de dinero!

Es muy raro que esto sea posible. Pero puede pasar, así que veámoslo:

Cualquier estimación se basa en evidencia estadística de experiencias pasadas haciendo un trabajo similar. Si el trabajo que estamos haciendo es notablemente similar y tenemos un gran conjunto de datos para trabajar, podemos hacer estimaciones en gran parte a partir de la categorización de la tarea. Por ejemplo, yo trabajaba en un centro de datos y creamos muchos servidores. A partir de los datos estadísticos, cualquiera (incluido un PM) podría decirle cuánto tiempo tardaría en aprovisionar un servidor de Windows en una pieza de hardware en particular. También podrían mirar la cola para ver cuál sería el tiempo de cola probable para el trabajo.

Entonces, ese es el tipo de situación en la que es posible. La razón por la que obtuviste las otras respuestas (con las que estoy completamente de acuerdo) sobre cómo debes dejar que las personas que hacen el trabajo lo estimen, es porque casi ningún trabajo de conocimiento cae en esta categoría, especialmente el desarrollo de software. Incluso si dos funciones o aplicaciones parecen similares en la superficie, por lo general son muy diferentes detrás de la pantalla. Por lo tanto, desde el punto de vista del PM, no encontrarán tareas similares, no lo suficiente para hacer una predicción, o probablemente no tengan la profundidad de conocimiento necesaria para identificar realmente si una tarea es realmente similar.

Aquí, se lo pasamos al equipo. Tampoco tienen tareas similares con las que compararlo, pero lo analizan mucho más profundamente hasta que llegan a tareas similares. Por ejemplo, han ejecutado consultas en bases de datos antes. Han formateado los datos en la pantalla. Han manejado la validación de entrada. Aún así, probablemente sería mucho más preciso llamar a estas conjeturas que estimaciones, pero al menos son conjeturas informadas basadas en experiencias pasadas.

Como ex desarrollador y administrador de proyectos ágil, aquí está mi 2p.

Algunas tareas son fáciles de estimar ya que son una cantidad conocida y se han realizado muchas veces antes. Una fábrica de salchichas sabe exactamente cuánto tiempo se tarda en hacer una salchicha más.

Algunas tareas son imposibles de estimar. Una empresa de biotecnología no sabe si alguna vez encontrará una cura para la enfermedad x [inserte alguna enfermedad actualmente incurable aquí], solo puede buscar vías prometedoras de manera organizada.

La mayoría de las tareas de desarrollo se encuentran en algún lugar entre estos dos extremos, y un desarrollador generalmente tendrá una buena idea de dónde se encuentra cada tarea en este rango.

Como gerente de proyecto, puede ayudar en este proceso pidiéndoles a los desarrolladores que identifiquen aquellas tareas que son más riesgosas/desconocidas, y separando estas tareas en una etapa separada donde el resultado es un prototipo de producto. El prototipo no tendrá la ingeniería o la solidez del producto final, pero habrá puesto todas las cosas más riesgosas al frente del proyecto cuando se haya comprometido la menor cantidad de recursos. Si alguna característica resulta ser inviable, entonces lo ha descubierto lo antes posible y puede cambiar el curso a un costo mínimo.

Una vez que tiene un prototipo funcional, es mucho más fácil para los desarrolladores planificar y estimar la ingeniería requerida para convertir el prototipo en un producto de proyecto entregable.

Una última cosa, no subestimes la diferencia entre un prototipo y un producto entregable. Si bien es más predecible, esta diferencia representará entre el 75 % y el 90 % del esfuerzo total del proyecto.