Supongamos que estamos iniciando un proyecto, pero no tenemos experiencia previa en la presupuestación de un proyecto de software.
¿Qué deben hacer los muchachos que trabajarán en ese proyecto para hacer una planificación presupuestaria decente?
¿Todos los movimientos deben ser considerados en este proceso? Me refiero a la codificación de la estructura y el acceso a los datos, la creación de servicios tranquilos, la creación de la estructura y la arquitectura de la base de datos, y así sucesivamente con cada movimiento.
¿Cómo debe continuar el proceso de planificación del tiempo?
Para definir el presupuesto y el cronograma de un proyecto, lo primero que debe saber es el alcance del proyecto. Lo que significa: necesitas saber lo que no está en el proyecto.
Comenzando con el alcance, puede desglosar aproximadamente el proyecto en tareas principales y obtener una primera estimación de la planificación y el presupuesto del proyecto.
Solo tenga en cuenta (y recuérdeles a las partes interesadas) que es tosco y necesita ser refinado. ¡No permita que una estimación tan aproximada se escriba en un contrato!
Para estimar, lo primero es obtener una estimación de tiempo, que es más bien una cuestión de experiencia, en mi opinión. Dada una cantidad de trabajo y conociendo la complejidad de la tarea, un PM debe poder estimar el tiempo necesario para realizar la tarea.
Después de eso, el costo es bastante fácil de calcular. El costo depende de los recursos consumidos: el costo del equipo es obviamente el costo principal. Y luego las herramientas que usarán (computadoras, software, etc.), los servicios que consumirán (energía, acceso a Internet, teléfono, etc.). Tal vez necesite trabajar con contratistas, proveedores. Y así...
El costo es, por supuesto, la suma de todos los costos durante el tiempo del proyecto.
La respuesta que probablemente esté buscando es dar grandes rangos de estimaciones (más o menos 50-100% o más) y decir: esto es lo que pensamos. Porque no lo sabes.
La planificación probablemente se haga mejor de arriba hacia abajo, comenzando con elementos vagos (p. ej., la función X) y desglosándolos en elementos más pequeños.
Si no conoce bien sus requisitos, o si pueden cambiar, y si no está creando algo estático como un compilador, le sugiero que proporcione agile/scrum/xp/etc. un torbellino Le permite estimar el tiempo restante para trabajar dado el desempeño real del equipo anterior, y solo necesita esperar un sprint (~ 2 semanas) para obtener datos reales sobre cómo lo está haciendo.
PMI sugiere muchas técnicas de estimación excelentes que probablemente pueda utilizar:
Un presupuesto es más difícil de estimar. No tengo mucha experiencia con eso, así que voy a evadir esa parte. El valor ganado es generalmente terrible (desde mi perspectiva del desarrollo de software), aunque el seguimiento de los costos esperados frente a los reales hasta la fecha es muy útil.
Lo primero que debe hacer es crear la estructura de descomposición del trabajo (WBS) hasta el nivel del paquete de trabajo. La EDT describe el producto final que debe entregar, así como los procesos necesarios para entregarlo. Esto requerirá una serie de iteraciones en las discusiones con las partes interesadas para asegurarse de que se incluya todo lo que se requiere. Necesitas una idea bastante buena de cómo se ve hecho.
El resultado final debe desglosarse con suficiente detalle en los componentes funcionales que se sumarán a la capacidad que el producto necesita para soportar. Cada uno será un paquete de trabajo.
A continuación, se debe estimar cada paquete de trabajo. Ashes ha proporcionado algunos métodos típicos para obtener una estimación válida. Como la estimación parece ser un problema, recomendaría desarrollar cada paquete de trabajo (o elemento WBS de nivel más bajo) en todas las tareas requeridas para completar el entregable (= definición de tarea ). Luego, cada tarea se estima por separado en horas o días de trabajo ideales. Lo que significa que si alguien trabajara ininterrumpidamente en esta tarea, le llevaría x horas. Una vez más, la estimación la realizan expertos en la materia y/o las personas que las realizarán.
No use estimaciones de un solo punto, sino un rango (lo más probable es lo peor).
Esto significa que, en lugar de estimar que una tarea tomará 10 horas, detalle la estimación en el esfuerzo más probable de 8 horas y, en el peor de los casos, digamos 14 horas porque no conocemos muy bien la tecnología XYZ y puede ser una pieza. de torta, pero cuando el factor X no coincide con Y, entonces tenemos que reconfigurar Z, de ahí las 14 horas.
La cantidad de esfuerzo o el tiempo que realmente lleva una tarea no es determinista (10 horas), sino que sigue una distribución de probabilidad que debe tener en cuenta. Piense en su viaje diario al trabajo: ¿toma exactamente la misma cantidad de tiempo cada día? Teniendo en cuenta el peor de los casos, puedes calcular un margen, pero te las arreglas contra el más probable (porque Murphy no siempre visita y para prevenir el síndrome del estudiante (tomar todo el tiempo asignado)).
Tenga en cuenta que, si aún no está seguro de qué tecnología usar, tendrá que hacer suposiciones o (mejor) hacer una estimación para cada posibilidad.
La estimación se realiza mejor con un grupo de personas, en lugar de individualmente.
La suma de todas estas estimaciones le dará el presupuesto requerido en horas o días para cada paquete de trabajo y, en última instancia, para todo el proyecto y las posibles alternativas de ejecución.
A continuación haz tu red de todos los paquetes de trabajo (este es el plan que vas a seguir) y programa las tareas y asigna personas o perfiles a cada una de ellas, así también sabes el costo estimado y el tiempo de entrega .
Realice la identificación de riesgos (¡utilice la WBS!) y agregue tareas específicas de mitigación de riesgos cuando sea necesario.
Consulte cada elemento de la WBS para detectar posibles riesgos y cree un plan de respuesta/mitigación de riesgos: estas 'acciones' de su plan de respuesta a riesgos deben agregarse en algún lugar, ya sea en un paquete de trabajo propio o en los paquetes de trabajo afectados. Estas tareas también deben ser estimadas.
Asegúrese de que estos elementos de costos estén identificados para que conozca su presupuesto de contingencia y cómo se aplica.
El cronograma final se basa en las estimaciones más probables o en cualquier otra forma de calcularlo (por ejemplo, PERT), pero asegúrese de calcular también algún margen , tanto en tiempo como en dinero. Como estimar parece ser un problema, es mejor argumentar para tomar la diferencia entre el más probable (o promedio, o PERT o lo que sea) y el peor de los casos. Dado que te las arreglarás contra el primero, eso debería estar bien.
No olvides añadir los costes de material, licencias,... para completar tu presupuesto.
Espero que esto tenga sentido.
Una palabra final: ¡tiempo de seguimiento! Para que pueda usarlo para el proyecto después de este. No solo para poder comparar con paquetes de trabajo o tareas realizados anteriormente (si realiza un seguimiento del tiempo en este detalle), sino también para realizar un seguimiento de lo bien que está haciendo las estimaciones. Si nota que subestima en un cierto %, puede usar esa 'evidencia' la próxima vez como un margen separado o incluso para ajustar las estimaciones más probables.
Esteban
remolcador