Todos los proyectos son lo mismo: una tarea que se puede dividir en subtareas con fechas limite y responsables distintos que pueden dedicar su tiempo completo o simplemente realiza una aportacuon puntual.

Y eso es todo, parece que la cosa no tiene mucho misterio pero la verdad, al final es casi un arte ajustarse al presupuesto y a la fecha de entrega.

Una de laa cosas que cada vez tengo mas clara es que ni de te ocurra empezar nada hasta tener un analisis de que vas a hacer, como lo vas a hacer y como mediras los resultados. Este analisis ha de ser publico para dirección por si quieren cambiar algo, que aprovechen la ocasión. Con la versión final del análisis monta la división de tareas, con objetivos claros, un solo responsable y una fecha final de entrega. Comunicalo a los implicados y negocia los cambios, actualiza el proyecto y mas que menos ya estás preparado para empezar.

En todo proceso, sobretodo si es largo, hay que tener medidas de como avanza y en caso de que se haya estancado, buscar alternativas para cumplir la fecha de entrega con la calidad exigida.

Otro de los puntos interesantes es si el proyecto es interno o externo. A priori ambos dos tienen ventajas e inconvenientes, pero mi experiencia personal me indica que cuando las cosas se tuercen, es mucho peor cuando el proyecto es interno. Asi que hay que hacer analisis y toda la parafernalia y tenerla por escrito por si acaso.

Una vez finalizado el proyecto tocaría realizar las pruebas. Ver si todo funciona correctamente, reportar comportamientos extraños, etc… El proceso de prueba, sobretodo en software, es casi un proyecto nuevo per se. La variabilidad es tan grande que todo es posible. Por eso es importante tener un buen sistema de reporting y tracking.

Haciendo todo lo anterior es posible que el proyecto falle o no se cumplan las fechas de entrega, pero sino lo haces seguro que pasara.

No hay post relacionados.