project-management project-planning estimation

project management - ¿Cómo crear una estimación de hora exacta?



project-management project-planning (8)

  • ¿Cuáles son sus experiencias con respecto a la planificación de proyectos y la creación de estimaciones de horas para nuevos proyectos?

  • ¿Cuál es el enfoque que está utilizando y por qué tiene o no ha funcionado para usted?

  • ¿Hay alguna mejor práctica para tener en cuenta?

Tareas de estimación

Los principios que trato de usar (no siempre tengo la oportunidad) son:

  • Refinamiento por etapas
  • 3 puntos estimados
  • Análisis de riesgo

Refinamiento por etapas

Al estimar, es importante estimar en la granularidad correcta y dividir continuamente y agregar tareas hasta que tenga confianza en las estimaciones. A menudo, la estimación destaca una tarea larga y crítica que puede necesitar más refinamiento y análisis de riesgo.

Análisis de riesgo

Tratar de averiguar dónde se encuentran los riesgos en cada tarea (¿hay tiempos de espera para algo? ¿Hay falta de conocimiento ?, ¿podría un competidor vencerlo? Etc. etc.) ayuda a determinar su confianza en las estimaciones, lo que le permite para determinar cómo tratar esas estimaciones. El análisis de riesgos también ayuda a determinar si se requiere un refinamiento paso a paso adicional.

Estimaciones de 3 puntos

Especificar los mejores, probables y peores cálculos para cada tarea (incluido el diseño, desarrollo, prueba y corrección de fallas) ayuda con el análisis y la planificación de riesgos. Las estimaciones se pueden usar para calcular la duración más probable para alcanzar un porcentaje de éxito particular de esa tarea. Junto con la información sobre otras tareas relacionadas, y el análisis de riesgos, un gerente de proyecto puede factorizar el riesgo y otros elementos conocidos, como las pruebas del sistema en las estimaciones, para obtener una estimación más confiable.

Por supuesto, la granularidad de las estimaciones también es importante. No tiene sentido calcular en horas para la mayoría de las tareas. En software, los días suelen ser los mejores, pero a veces pueden ser semanas o meses (por ejemplo, si está subcontratando bloques de trabajo). Elija una granularidad de tiempo que tenga sentido para todas las tareas de un proyecto (generalmente utilizo los días para las fases de captura de requisitos y de especificación funcional, y medio día después, a medida que aprendo más sobre las tareas y sus subtareas).

Conclusión

Los tres elementos se alimentan entre sí, por lo que con frecuencia debe refinar cada paso varias veces. Por ejemplo, puede tener una puñalada en la etapa de requirments, luego otra vez durante la especificación funcional, y nuevamente durante la especificación de diseño.

La estimación es una habilidad aprendida; cuanto más haces, mejor obtienes. El análisis de riesgos mejora a medida que aprende más sobre lo que no sabe, las estimaciones de 3 puntos mejoran a medida que aprende más sobre lo que sabe, y el refinamiento progresivo mejora a medida que avanza en cada paso de un proceso de diseño.

Si tiene tiempo, revise sus estimaciones originales después de completar una tarea y vea cómo se compara el tiempo real con sus estimaciones de 3 puntos y su plan de proyecto. Si difiere, vea dónde se perdió o ganó el tiempo e intente aprender qué puede sacar de eso para proyectos futuros.

La estimación no debe ser una tarea desalentadora: siempre siento que sé más sobre mi trabajo después de la estimación que antes.

Hay información excelente acerca de esto en The Pragmatic Programmer . Aconsejan que use unidades de tiempo apropiadas en lugar de estimar 130 días estiman 6 meses. También aconsejan concentrar las tareas que son más cruciales. Y evite hacer estimaciones basadas en subestimaciones.

Personalmente, creo que es útil dividir la tarea en fragmentos comprensibles para estimarlos adecuadamente. Si la tarea es grande, hay demasiados rincones y grietas que pueden ocultar problemas no previstos. Al concentrarse en los detalles de trozos más pequeños, puede evaluar los problemas potenciales con más éxito.

Práctica práctica práctica. Para estar seguro, sobreestime a medida que refina sus habilidades de estimación. Por supuesto, si usted es un consultor, esto puede costarle negocios. Si tiene miedo de perder un negocio, sin preestimarlo, pero tenga en cuenta que estará recuperando las horas adicionales de su tiempo libre / línea de fondo.

Registre el tiempo invertido en sus proyectos reales y eso lo ayudará a planear para el próximo, PSP / TSP ofrece una manera de hacerlo

Su pregunta es un problema de NP-Complete :) Hay muchos algoritmos utilizados para llegar a una estimación, pero siempre son solo conjeturas, nunca son precisos y muchos tardan mucho tiempo en ejecutarse. Olvídese de las estimaciones de horas, use scrum o algún otro marco ágil. Hacer estimaciones para un proyecto en horas al principio es simplemente mentirle a la gente.

No haga estimaciones basadas en horas hasta justo antes de construir la característica y actualice esas estimaciones continuamente a medida que avance en la función.

No se olvide de incluir el tiempo de prueba en sus estimaciones.

RE: Si tiene miedo de perder un negocio, por debajo de lo estimado, pero tenga en cuenta que estará recuperando las horas adicionales de su tiempo libre / línea de fondo.

es mejor que reduzcas tu tarifa por hora en lugar de jugar con las horas que presentas al cliente. al menos de esta manera, presenta la apariencia de valor agregado a su cliente.

LM