Existen 3 niveles de documentación de un proyecto.

1) La documentación del proyecto es una herramienta para hacer el proyecto
Una herramienta útil que te ayuda a conseguir tu fin. Algo que haces ANTES de tirar una línea de código para tener claro que hacer. Y, sobretodo, documentos que te ayudan realmente. Si no tienes claro para que vale un documento, no lo usas hasta entenderlo o necesitarlo. Nada de hacer documentación por hacer.
Conforme vas haciendo más proyectos vas viendo que documentos son más necesarios y de cuales puedes prescindir.

2) La documentación del proyecto NO es una herramienta útil.
La documentación es algo que te exige alguien (jefe de proyecto, cliente, auditoría interna, ISO) que hagas. No entiendes muy bien para que vale, no entiendes muy bien para sirve. Primero haces el programa y luego si eso, si tienes tiempo documentas (normalmente suele acabar en un no-tengo-tiempo-para-documentar, o-documento-o-programo).
Sueles acabar reutilizando documentos antiguos cambiando el texto y realmente tienes un problema grave en tus conocimientos. El resultado es Caos.

3) No documentas el proyecto
O bien porque no tuviste tiempo o bien no sabes como documentar el proyecto. El resultado es el mismo: Caos.

El documento más importante es la especificación de requisitos, muchas veces inexistente. Aunque hay que reconocer que a veces es difícil de conseguir.

A todos nos ha tocado alguna vez realizar un presupuesto, esos grandes enemigos de todo creador de software.
A lo largo de los años he ido evolucionando en la manera de enfrentarme a ellos y creo haber descubierto 4 etapas por las que uno pasa en su vida de presupuestador de software.
Me estoy refiriendo por supuesto a esos proyectos de corta duración en la que nadie te da tiempo para hacer una preproducción en condiciones, de esos que tienen que estar acabados en menos de 3 meses (o 3 semanas) y que al final duran el doble.
Las etapas que he identificado son:

1 - Novato responsable
Son los primeros proyectos en los que se te pide hacer un presupuesto porque se supone que tu eres el que sabe de programación y por ende se te presupone habilidad para calcularlos. Te sientes aplastado por tamaña responsabilidad y temes las consecuencias que tendría equivocarte. Tratas de imaginar cuales son las tareas que habrá que realizar y preguntas al equipo que tardará en hacer cada cosa, incluso de aquellas tareas que no son de tu competencia, como el grafismo, diseño o música, pero lo haces con cierta vergüenza porque piensas que deberías saberlo.

2 - Reality check
Te das cuenta al cabo de un año de que por mucho que te esfuerces, jamas acertarás con un presupuesto y que la verdad es que las consecuencias de equivocarte no son tan graves. Ademas observas como constantemente cuando tu das una cifra los de ventas te dicen que es demasiado alta y te hacen revisar el presupuesto para que se ajuste a un tope máximo que el cliente está dispuesto a pagar por el trabajo o que es demasiado poco y te hacen revisar el presupuesto para que se expanda hasta lo máximo que el cliente está dispuesto a pagar por el trabajo.

3 - Imaginación al poder, presupuestación inversa
Como ves que esto siempre funciona igual y que nunca pasa nada si te equivocas, al final acabas por preguntar en primer lugar cuanto está dispuesto a pagar el cliente y a partir de eso calculas la gente que puedes meter en el proyecto para el tiempo que te han dado para hacerlo. Si en ventas son reacios a darte esa cifra inicial (aunque luego la usarán finalmente para decirte que hay que ajustar el presupuesto), simplemente inventas una cifra que sale de multiplicar el tiempo que hay para hacerlo por el numero de personas que piensas que van a participar por el coste de cada persona. Da igual lo que digas, siempre te lo van a corregir.

4 - Que se lo invente otro
Como cada presupuesto que haces, al final es retocado y corregido, y como al fin y al cabo te lo inventas y para invertarse cosas no es necesario ninguna carrera universitaria ni años de experiencia, comienzas a intentar cargarle el mochuelo a otro, a ser posible un programador novato, para que el ciclo comience de nuevo.

En mi curro nos estamos teniendo que enfrentar a un proyecto bastante ambicioso: Crear un departamento de Release Management para un proyecto de desarrollo que tiene diversas lineas de desarrollo distribuidas geograficamente y que van a estar generando mucho codigo muy rapido y con interdependencias entre si.

Por mi experiencia profesional en los sitios que he estado, por lo que he hablado con la gente y por lo que he investigado por internet me da en la nariz que el Release management es algo que en cada sitio lo hacen a su manera y que no hay una forma estandard de hacerlo.

Se me ha ocurrido, ya que en las KPM ultimamente salia este tema, y que hay otra gente con el mismo problema, que podiamos ayudarnos mutuamente y crear un “Release Management HOWTO” con licencia GNU.

He instalado un wiki y tal, pero el interfaz de usuario me parece muy malo comparado con google docs, asi que he creado un documento de google docs que podeis ver aqui
Si quereis participar el el proyecto tengo que añadiros como editores del documento, para ello escribidme a rogemadrid(arroba)gmail.com y os doy permisos. Esta oferta está abierta a cualquiera que lea esto, ya sea miembro de soygeek, o un visitante Si queda un documento guapo que pueda resultar util lo colgaré de soygeek en forma de pagina o algo asi.