Cómo hacer mejores estimados de tiempo y recomendaciones para reducir las fechas de entrega de proyectos

Realizar buenas estimaciones de tiempo para los proyectos es muy importante. Mantiene los objetivos, fechas y presupuesto en un buen estado. A veces decidimos tomar el camino fácil y comenzamos con estimados de tiempo poco fundamentados para los proyectos. Esto es una mala práctica; es necesario revisar la documentación, las experiencias y las personas involucradas con el fin de realizar una mejor estimación y tener una base sólida que la sustente. La mejor forma de obtener datos para apoyar nuestros estimados, es a través de proyectos anteriores y situaciones similares, Esto es fácil de lograr si mantenemos una bitácora del presupuesto que en realidad se requirió y de las fechas de entrega para todos los proyectos.

Comencemos con los pasos necesarios para tener buenas estimaciones de tiempo:

Dividir el proyecto en tareas. Éste es el primer paso que debes realizar. Cada tarea debe de tomar entre dos y cinco horas para ser completada, algunas tomarán más o menos tiempo, por ejemplo, ciertas tareas son muy importantes y necesitan estar aisladas, otra situación, puede ser que la tarea requiera completarse toda de una sola vez y no es posible dividir. Cuándo nos encontremos dividiendo tareas, debemos tratar de mantenerlas lo más aisladas posible unas de otras, ya que es más sencillo realizar estimados para pequeñas tareas en comparación con el esfuerzo requerido para estimar tareas grandes o con muchas relaciones entre ellas; esto te puede mantener enfocado y  encontrar requerimientos adicionales / documentación / personas que van a ser necesarios para completar cada tarea. Esto es de gran ayuda también cuándo buscas tareas anteriores con las cuáles quieres comparar las actuales y ayuda a entender si otras tareas deben ser realizadas por otros equipos. Por ejemplo, si deseamos obtener cuentas de prueba para un sistema, es posible que el departamento encargado de manejar las cuentas, tenga datos más relevantes para nuestras pruebas, porque ellos conocen mejor cómo funciona el sistema y que cuentas les interesa probar.

Revisar proyectos anteriores para encontrar situaciones similares. Ésta es la mejor forma para conocer cuánto tiempo tomará realizar un proyecto similar. Aquí debemos tomar en cuenta que si el nuevo proyecto es muy parecido al anterior, probablemente tomaremos menos tiempo en realizarlo, puesto que ya hemos superado la curva de aprendizaje necesaria para las tareas que requirieron investigación y la lectura de diversa documentación.

Juego de poker. Cuándo se esté calculando la cantidad requerida para una tarea, es una buena idea tener la opinión de uno o dos miembros experimentados del equipo. Ellos siempre ven algo diferente y pueden ayudar a realizar una mejor estimación visualizando algún dato que no tomamos en cuenta. Es importante mencionar que si las estimaciones difieren mucho de persona a persona, es posible que no tengamos suficiente información para determinar cuánto puede tomar realizar una tarea.

Pasos previos y pasos posteriores. Muchas tareas tienen pasos que se deben realizar antes de comenzar la tarea por ejemplo: crear un nuevo repositorio, una nueva cuenta de prueba, esperar la configuración de un ambiente de pruebas. Estos se deben tomar en cuenta como parte del estimado, asimismo, cuándo la tarea se finaliza, casi siempre hay una serie de pasos posteriores, por ejemplo: enviar un correo a los solicitantes de la tarea, crear notas para la liberación a producción, dar de baja cuentas de prueba, etc.

Factores externos. ¿El equipo de soporte está muy ocupado para configurar un ambiente de prueba?
¿El área de finanzas no puede proveer la información en las fechas de ejecución del proyecto? ¿Podemos liberar el sistema en la fecha que seleccionamos, o esto no está en la ventana de liberación para el área afectada?. Todas estas preguntas son importantes cuándo establecemos la fecha de liberación de un proyecto; de nuevo, cuándo hemos estado en situaciones similares, podemos usar la experiencia para determinar que factores externos debemos tomar en cuenta.

En resumen, hay muchas cosas que se deben tomar en consideración, pero algo que debemos tener en mente, es que debemos mantenernos lo más "optimistas" posible, no podemos estar pensando que mañana va a ocurrir un "Armageddon" para fundamentar que el proyecto no se entregará a tiempo. Se pueden dar situaciones que retrasen la entrega, pero deben de ser resueltas en el momento en el que se presentan y el proyecto debe de ser reorganizado adecuadamente.

Finalmente escribiré sobre algunas formas de entregar el proyecto en menos tiempo y con menos esfuerzo:

• Involucra a todos los departamentos interesados en el proyecto. Los proyectos de desarrollo de software también deben incluir a miembros de los departamentos interesados o afectados por el proyecto. Se les debe asignar tareas como: búsqueda de cuentas de prueba, análisis de resultados, etc. Esto tendrá como resultado, la revisión a tiempo de los requerimientos de los departamentos y la planeación de los siguientes pasos; por otro lado, los departamentos podrán conocer cómo va el proyecto, qué expectaciones tener, dar retroalimentación a tiempo y entregar información relevante para las pruebas.
• Sistemas prefabricados. Muchos proyectos contienen un objetivo similar al de algún software existente en el mercado. Si puedes comprar un sistema que tenga una buena relación costo/beneficio/calidad, debes considerar comprarlo y apropiarlo a las necesidades del proyecto. Debes comprar un sistema confiable que haya sido usado por varios usados, esto garantiza que tengas una cantidad importante de pruebas que validen su funcionamiento y reducirá drásticamente el tiempo del proyecto que estás ejecutando.
• Contratar compañías expertas. Si el software que vas a desarrollar es muy genérico, es posible que exista una empresa dedicada a realizar el sistema que necesitas en una cantidad menor de tiempo y que probablemente te sorprenda con un buen precio. Esto te permitirá enfocarte en otros proyectos que sí requieren la atención explícita de tu equipo y realizarás más cosas en menos tiempo.

Esto es una guía básica que espero encuentren útil al momento de realizar estimaciones para proyectos. Ésta es la versión original. Estaré traduciendo varias entradas, con la finalidad de llegar a más usuarios. 

¡Espero hayan disfrutado la entrada!

Making good estimates and ways to reduce delivery dates

Making good estimates is very important because it keeps the project goals, dates and budget in a healthy state. Sometimes we take the easy path and just throw numbers for the budget and the time that it takes to deliver the project, but that's a bad practice, we must review documentation, experiences and the people involved in order to give a good estimate and support our numbers. The best way to obtain support data is through old projects and similar situations, this information should be easy to obtain if we keep track of what was the real budget and the real dates of delivery of all the projects.

First I will talk about the required steps to have good time estimates:

• Divide the project in tasks. This is the first thing you need to do. Each task should take around two through five hours to complete, some tasks might take more time or less time, for example, certain tasks are very important and they need to be isolated, or it could also happen that they need to be completed all at once. Something else to take into account when dividing tasks, is to keep them as self independent as possible, meaning that there's no dependency on another tasks. It's always easy to estimate the time required for small items than the one required for big items, this can keep you focused and find additional requirements/documentation/people that you will need to complete each task. This also helps when you're looking for similar situations in the past, it's easier to find a matching similar situation when tasks are divided properly. Another good thing about this is that it helps in understanding if some tasks should be made by another team, for example, in some cases, testing accounts can be provided by another department because they know better what are the things that they want to test.

• Review old projects and find similar situations. This is the best way to know how much will it take to create a similar project. Take into account that if the new project is really similar, we may end up finishing it sooner than expected. This is because in most projects, there's a learning curve for items that needs discovery and reading documentation.

• Poker game. When deciding the amount of time required for a task, it's a good idea to have the opinion of one or two experimented members of the team, they always see something that is missing for the other individuals, and that could be key to set the estimate for the task. Keep in mind that if the estimates provided are very different, is a smell of insufficient data to set the required time for completing a task.

• Pre-steps, Post-steps. It's important to know if there are another things needed to start and to finish the task and add it to the estimate. For example, you might need to create a branch for working on the task, set up a new account for a system, wait for a testing environment, etc. Those are the pre-steps, but when you finish the action items of the task, there might also be another post-steps, like creating release notes, sending out an email to the business owners, deleting testing accounts, etc.

• External factors. Network team is too busy to set up a testing environment? Working with the financial area in a time that they cannot provide information fast? Can you release the software project in the date you selected?. This and many other questions are important when creating an estimate and deciding on dates of delivery, if you have been in a similar situation before, it could be easy to know when some external factor will be affecting the date of delivery.

There are many things to take into consideration! but something to keep in mind is that you should stay as "optimistic" as possible, meaning that you cannot put as a support to your estimate, the fact that there could be an "Armageddon" tomorrow, and your project might not be completed on time.

There will be situations that can delay the delivery date of the project, but they should be addressed at the moment that they happen, and the project should be reorganized accordingly. Another thing that I would like to talk about is ways to deliver the project in less time, and with less effort:

• Get all the team interested in the project involved. Software projects are not completely developed by the software team. If there are going to be changes to the some department systems, it's a good idea to have them involved as much as possible, and even assign some tasks to them (like finding testing accounts, providing data analysis, etc). The outcome of this will be early checking the requirements of the departments and based on that, planning the next steps, on the other hand, the departments can know how's the project going, what are the expectations, provide early feedback about features, and give relevant data for testing.

• Buying systems. Many projects are similar to current systems in the market. If you can buy a system that has a decent trade-off between cost/value/quality, think about buying it and customizing according to your needs. You should buy a very known system in order to trust that it has been deeply tested and that can reduce the time required for delivery.

• Request help from another company. If you have the budget, it can be useful to have another company help you, specially if they're experts on the system you want to develop, this can be cheaper than expected, because they have passed the learning curve and can save you a lot of time, and allow you to focus on another projects that can only be developed by your team.

That's it for now. I hope you enjoyed this entry. Let me know if you have any questions or if you would like me to talk about another topic. Many thanks readers!