Las estimaciones imprecisas son uno de los retos más populares de la gestión de proyectos. Cuando se inicia un nuevo proyecto informático, se quieren saber dos cosas: cuánto tiempo va a llevar y cuánto va a costar. Para responder a estas preguntas, debe estimar los proyectos que va a ejecutar. No existe una regla mágica que diga que el proyecto X tarda 12 semanas y cuesta $150.000. O que un sitio web tipo Y tarda 10 semanas en desarrollarse y cuesta $100.000.
Lo que aprenderá de este artículo:
- ¿Cómo se preparan los gestores de proyectos para la estimación de costes en la gestión de proyectos?
- ¿Qué técnicas de estimación son útiles para la estimación de proyectos?
- ¿Cómo se prepara la planificación para estimar costes con fórmulas?
No se puede evaluar el plazo o el coste de un proyecto sin una estimación exhaustiva, incluso si el alcance del proyecto es muy similar a lo que se ha hecho antes. Y lo que es peor: la estimación nunca le dará una respuesta 100% exacta a estas preguntas. Entonces, ¿por qué hacemos estimaciones? Porque es la única manera de hacer suposiciones sobre el calendario y el presupuesto del proyecto, la carga de trabajo y los recursos necesarios para llevarlo a cabo.
Estimando el proyecto, también podrá programar a los empleados con la experiencia y las competencias adecuadas. Lo que puedes hacer al respecto es utilizar metodologías y técnicas que te permitan estimar con la máxima precisión posible. A continuación te explicamos cómo utilizar la metodología Agile y la técnica Planning Poker para crear estimaciones significativas de tu proyecto.
James Grenning desarrolló en 2002 la sesión de póquer de planificación conocida por su estrategia denominada Scrum póquer. A principios de los años 50, su método de estimación, Wide band Delphi, requería demasiado tiempo y tenía otras limitaciones. En el caso de Grenning, el plan de póquer consistía originalmente en abordar un problema en el que los jugadores estaban demasiado entusiasmados y demasiado concentrados para ganar. Mike Cohn, fundador de Agile alliances y Scrum alliances, utilizó posteriormente esta técnica para un artículo titulado Agile Estimation and Planning.
El éxito de un proyecto depende sobre todo de lo bien que se entienda de qué se trata. Eso incluye:
- Comprender las expectativas del cliente
- Comprender los objetivos del proyecto y su meta principal
- Crear una lista de características necesarias
Una vez que haya leído las instrucciones del cliente y disponga de toda la información posible sobre los requisitos del proyecto, podrá enumerar todas las características y transmitírselas a su equipo.
Para ello, cree un backlog del producto que incluya todas las funciones pendientes. A continuación, podrá priorizarlas, evaluar su complejidad y calcular el tiempo que tardará en completarlas. Un backlog de producto adecuado debe constar de:
- Historias de usuario: describen las acciones que los usuarios pueden realizar en cada paso del uso del producto.
- Criterios de aceptación: enumera los elementos necesarios para que una historia esté completa.
- Puntos de la historia: estimación de la cantidad de trabajo, los riesgos y la complejidad en valor relativo en puntos.
- Tareas para las historias de usuario: enumere las tareas necesarias para realizar una historia de usuario.
Es crucial implicar al equipo de desarrollo en la creación y priorización del backlog del producto para garantizar evaluaciones precisas y realistas.
Con la lista de características lista, asigne prioridad a cada una de ellas. Puedes utilizar el método de análisis MoSCoW para ordenarlas como:
- Debe tener
- Debería haber
- Podría haber
- No tendrá
Al desarrollar un proyecto, céntrate en las cosas que tienes que entregar en primer lugar. Construir un MVP te da la posibilidad de probar hipótesis sobre tu idea antes de completar todo el proyecto, mostrarlo a las partes interesadas o a los usuarios beta, y recoger comentarios importantes para el desarrollo posterior del resto de características.
Asignar prioridades también puede ayudarte a estimar el proyecto. Al centrarse en las funciones principales y en las que hay que hacer primero, puede hacer suposiciones más precisas sobre su finalización estimada. En el caso de las funciones que "podrían ser necesarias", puedes empezar con una estimación aproximada, ya que se encuentran en una fase más avanzada del proceso de desarrollo y pueden cambiar muchas cosas para cuando el equipo llegue a ellas (y si el equipo llega a ellas, ya que después de recoger opiniones sobre el MVP puedes cambiar de rumbo y no incluir todas las funciones previstas inicialmente).
Sin embargo, es importante estimar todas las características, independientemente de su prioridad (excepto las que "no se tendrán", claro), ya que se quiere tener una visión general de todo el proyecto a la vez. Y, a medida que se avanza en el proyecto, se puede reevaluar el alcance del trabajo para asegurarse de que las estimaciones siguen siendo exactas.
Una vez completado el backlog del producto, es hora de estimar cada uno de sus elementos. Para ello, utilizamos puntos de historia. Son unidades que los equipos ágiles utilizan para evaluar el trabajo necesario para completar cada elemento del backlog. Los puntos de historia ayudan a asignar un valor relativo a los elementos del backlog del producto. No están relacionados con el tiempo y pueden tener distintos valores para distintos equipos, por lo que no tienen valor emocional. Por lo tanto, lo más probable es que los miembros del equipo no rellenen las estimaciones sólo para estar seguros. Planning Poker ayuda a los equipos de software a planificar los flujos de trabajo y mejorar el ritmo de entrega de los proyectos.
Utilizando puntos de historia, un equipo puede estimar:
La Sesión de Planificación es una de las técnicas de estimación a nivel bruto, que utiliza una versión modificada de la secuencia de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100. Para estimar los elementos del backlog del producto, los miembros del equipo reciben los mismos juegos de cartas de póquer de planificación con números. A continuación, tras una breve presentación del elemento del backlog del producto por parte del Propietario del Producto (que no vota) y el debate, eligen en privado la carta con el número de puntos de historia que consideran relevantes para la cantidad de trabajo necesaria para completar este elemento y las revelan al mismo tiempo.
Si las cifras difieren, los miembros del equipo discuten por qué han elegido tal cantidad de puntos de historia y vuelven a votar. Esto forma parte del proceso de póquer de planificación, un método de estimación basado en el consenso que se utiliza en Agile para estimar el esfuerzo de las historias de usuario. Lo hacen hasta llegar a un consenso y luego pasan al siguiente elemento del backlog del producto. Y si el número acordado es alto, digamos 20, 40 o más, significa que una historia puede requerir demasiado trabajo para un sprint y puede ser necesario dividirla en tareas más pequeñas. Lo ideal es que la presentación del tema, el debate y la votación duren unos dos minutos, lo que permite estimar todo el backlog en poco tiempo. Pero como de lo que se trata aquí es de estimar todo el backlog de una vez, tómese su tiempo y no se preocupe si algunas historias tardan un poco más en evaluarse.
La velocidad del equipo muestra el ritmo de desarrollo del proyecto. Ayuda a comprender dos cosas:
- La cantidad de trabajo que su equipo es capaz de hacer en un sprint
- ¿Cuál es la fecha prevista de finalización de todo el ámbito de aplicación, suponiendo que esté fijado
La velocidad es diferente para cada equipo. Puede evaluarla después de las iteraciones iniciales, cuando el equipo ya haya trabajado en algunas características. Por ejemplo, si ha incluido cuatro elementos del backlog del producto en la primera iteración para un número total de 20 puntos de historia, y el equipo ha terminado tres de ellos, lo que equivale a 15 puntos de historia, esta es la velocidad actual de su equipo. Recuerde que sólo cuentan los elementos completados. Aunque hayan conseguido empezar el cuarto elemento pero no lo hayan terminado, no cuenta.
El scrum master desempeña un papel crucial a la hora de facilitar el proceso de estimación y garantizar evaluaciones precisas durante estas sesiones.
Tras negociar los puntos de historia y evaluar la velocidad del equipo, podrá determinar el calendario del proyecto. Para ello, sume la velocidad del equipo de las tres últimas iteraciones y divídala por tres. Por ejemplo, si la velocidad de esas iteraciones fue de 20, 23 y 17, la velocidad media equivaldría aproximadamente a 20 puntos. Si la cantidad total de trabajo se había estimado en 100 puntos de historia, entonces, con la velocidad media de 20 puntos, se necesitarían 5 iteraciones para completar el proyecto. Suponiendo que una iteración dure dos semanas, el proyecto debería entregarse en 10 semanas.
Para determinar el presupuesto de su proyecto, puede utilizar esta fórmula básica: (total de puntos de historia / velocidad * horas de equipo por sprint) + costes no laborales = presupuesto estimado. Con el número total de puntos de historia dividido por la velocidad media, multiplica el número de sprints por 40 horas semanales por miembro del equipo para obtener el coste laboral. A continuación, añada los costes no laborales, como los costes de capital, los costes de equipo, los costes de mantenimiento, los costes de formación, etc. Por ejemplo, tenemos un proyecto estimado en 100 puntos de historia y la velocidad media de nuestro equipo es de 20 puntos. Asignando un equipo de 5 personas al proyecto con tarifas horarias de $50, las horas de equipo por sprint valen $20.000 y $100.000 para 5 sprints. Con un coste hipotético no laboral de $50.000, el presupuesto estimado para nuestro proyecto sería de $150.000. Teniendo en cuenta los intervalos de confianza sobre los niveles ejemplares de 80-120%, el rango informado de nuestro presupuesto es ahora de $120.000 a $180.000.
Recuerde que ninguna estimación es 100% exacta. Lo mejor es reestimar el proyecto cada pocas iteraciones, ya que hay cosas, como la disponibilidad de recursos, la velocidad del equipo o el alcance del proyecto, que pueden cambiar con el tiempo. Reestimando, te aseguras de que tu estimación está actualizada. El uso de software de seguimiento del tiempo y programación de recursos también te ayudará a gestionar la disponibilidad de tu equipo y a reasignarlos si es necesario. Con las técnicas y herramientas adecuadas, puede hacer que sus estimaciones sean más fiables y planificar mejor su próximo proyecto.
Una estimación precisa del proyecto es crucial para el éxito de la gestión del mismo. Comprendiendo las expectativas y los objetivos, creando un detallado backlog del producto, priorizando las características y utilizando técnicas como story points y Planning Poker, puede mejorar la precisión de sus estimaciones. La reestimación periódica y el uso de herramientas para el seguimiento del tiempo y la gestión de recursos mejoran aún más la fiabilidad de los plazos y presupuestos del proyecto. Siguiendo estas prácticas, puede superar los retos que plantean las estimaciones imprecisas y garantizar mejores resultados del proyecto.
Utilice con facilidad la técnica de estimación Planning Poker
Compruebe por qué nuestro software de gestión de recursos es el elegido por los jefes de proyecto de Hill-Knowlton o Stormind Games
La planificación eficaz de los recursos es un objetivo crucial para empresas de todos los tamaños, ya operen en línea o en sectores tradicionales. Dada la gran variedad de empresas que requieren una planificación de recursos, es difícil ofrecer una recomendación única...
Las empresas suelen esforzarse mucho en la asignación de recursos. Quieren mantener a todo el mundo ocupado y asegurarse de que sus tareas son valiosas (lo que a menudo significa facturables) para la empresa. La cosa se complica cuando el equipo...
Equipos de todo el mundo se enfrentan a retos similares cuando se trata de planificar el calendario de su equipo. Crear un plan de proyecto es difícil de por sí, y mantenerlo al día y reaccionar ante los cambios es más...