En una ocasión me encargaron un proyecto, no muy grande. Era un equipo de dos programadores más el jefe, pero como este no tenia conocimientos de tecnología Java entre yo como especialista.
Así que monté el proyecto con una visión más a largo plazo de lo que se suele hacer.
Sabía que íbamos a tener que entregar el diagrama lógico y físico de la base de datos, así que en vez de hacer las modificaciones de las tablas directamente en la base de datos y al final del proyecto documentar utilizamos una herramienta de modelado de datos para hacer los cambios, generar el script y rehacer la base de datos con ese script. Cuando tuvimos que hacer la instalación en el cliente ya teníamos el script hecho y perfectamente validado. Cuando tuvimos que entregar la documentación de la base de datos, también ya la teníamos y perfectamente actualizada.
Para la gestión de las tareas en vez del típico excel o emails utilizamos un gestor de tickets, que nos permitió tener muy controlado todo el trabajo que se iba realizando y el pendiente de realizar.
La lección que sacamos de esa experiencia es que si dedicas un poco de tiempo al principio del proyecto a construir unos pilares sólidos al final del proyecto te dan sus beneficios. El proyecto no se desvió por esos motivos, si por otros.
Fueron medidas sencillas de aplicar con un muy buen resultado. El problema es que a veces la gente se obsesiona con el «si hacemos esto mejoraríamos a largo plazo» y acaba cayendo en la sobreingeniería. Que es tan mala o incluso peor que el hacer las cosas chapuceramente.