| Re: Estimacion de proyectos.
A ver... tienes los requerimientos, ¿no? Sabes hacer un diagrama de Gantt, ¿no?
Bueno, pues si no te gusta la plantilla esa, lo que tienes que hacer es no usarla, crearte el diagrama tú mismo.
O mejor aún, no saltes a hacer un diagrama de Gantt. En la Universidad, hiciste un proyecto fin de carrera, ¿no? Y supongo que también una asignatura de proyectos, ¿no? Bueno, pues, por dónde empezaste?
Analizar los requerimientos, extraer las tareas necesarias para cumplirlos, desglosar esas tareas en tareas menores hasta que puedas valorar el esfuerzo que requiere cada una. Asignas esos esfuerzos, defines las dependencias de unas tareas con otras y a partir de ahí realizas los diagramas que consideres oportuno (pert, gantt...).
Luego evalúas los recursos de que dispones y los distribuyes sobre el proyecto. Según eso, calculas el tiempo, las personas que necesitas dedicar. Calculas su valor según lo que te cuesta. A eso le añades costes de otros recursos que sean necesarios, aplicas un margen de seguridad y de beneficio que quieras obtener y sacas una cifra.
Al cliente le presentas:
- Las cifras (precio y tiempo), convenientemente redondeadas. (i.e. no le digas que 2.327,54€ y un mes y 3 días)
- El plan de proyecto: Tiempo en el que te comprometes a entregar, personas que vas a dedicar, hitos del desarrollo, puntos de control, mecanismos y plan de seguimiento, cosas que están incluídas y cosas que no, etc, etc.
Ten en cuenta:
- Para poder estimar el esfuerzo de una tarea necesitas experiencia. Si no la tienes, puedes buscar información, y tratar de aproximarlo, pero eso no va a sustituir a la experiencia. Una fuente de información es preguntarle a quien lo va a desarrollar (si tiene experiencia, claro).
- Aunque tengas experiencia, seguramente tu estimación no será buena. No te preocupes, le pasa a todos, pero tengo en cuenta para aplicar algún margen de seguridad y poner alguna provisión en el contrato sobre retrasos, imprevistos y demás. Aún así no creas que la experiencia no sirve. Nunca jamás estimes a ojo sin pensarlo bien. Básate siempre en algún dato o experiencia previa. (Así luego podrás ver dónde te equivocaste y tenerlo en cuenta en el siguiente proyecto)
- Aunque creas que tienes los requisitos, no los tienes. Dentro de un mes, cambiarán. Es más, en cuanto el cliente empiece a ver algo, cambiará de idea. Empezará a decir que no era eso lo que quería, que sería mejor de otra forma... Cuenta con esto como algo inevitable. Así, no pretendas tener todos los requisitos al empezar y no sigas un proceso rígido. Procura ir avanzando de forma modular, ir enseñando al cliente lo que tienes de forma frecuente para que los cambios que pida afecten lo menos posible. Establece esto en el plan de seguimiento y ponlo en el contrato a efecto de poder establecer límites a los cambios que pueden ocurrir. Ojo, no se trata de decirle que no puede cambiar ningún requisito, sino de establecer que si los requisitos cambian, habrá que modificar el presupuesto.
- Acepta que tus primeros proyectos tendrán estimaciones bastante malas. Pero utilizalos bien para fijarte en lo que estimaste y lo que luego ocurrió en la realidad.
- Puedes dividir las tareas de muchas formas. Trata de llegar a un nivel lo más detallado posible. No hace falta llegar a "1. poner un campo de nombre. 2. poner un campo de apellidos. 3. poner un campo de edad..." pero sí es bueno llegar a un nivel de detalle que puedas evaluar con algo de confianza. Evalúa tipos y luego clasifica las cosas según esos tipos:
Por ejemplo, si vas a tener muchas pantallas, haz 3 pantallas tipo que vaya a tener la aplicación (simple, normal, compleja), evalúa cada una lo mejor que puedas y luego clasifica tus pantallas así.
O por ejemplo, analiza los componentes gráficos que vas a hacer, clasifícalos según la complejidad y haz lo mismo. O con otras funcionalidades, según sea tu aplicación.
Si no, siempre puedes volver a la Universidad y preguntar. |