Reglas para el buen desarrollo de un producto
1. Asegúrate de saber qué estás desarrollando. Muchos de los retrasos en los proyectos se deben a que "el cliente", el/los analista/s, los programadores, etc. (inclúyete en el pack correspondiente), no saben realmente cuál es el objetivo final del proyecto. Reconoce, añade en una actualización del post, que lo que estás desarrollando ahora mismo, cambiará casi de forma irremediable en el futuro hasta completar el proyecto, así que asegúrate de que tus procesos, clases, sistemas o subsistemas, admitirán estos cambios preparándolos para ello desde el origen.
2. Trabaja solo en los puntos necesarios para lanzar la versión 1.0
 Sin olvidar lo mencionado en el punto anterior, claro...
3. Asegúrate de mantener un prototipo siempre funcional
 Si lo vas actualizando con las últimos desarrollos, y lo mantienes accesible a los usuarios finales, podrás ir corrigiendo o debatiendo con ellos desde la interfaz a posibles malentendidos en las funcionalidades de la aplicación, con lo que podrás, entonces, anticipar estos cambios en las partes que aun no has empezado o tienes entre manos...
4. No hagas del proyecto un escaparate para mostrar lo "guay" que eres
 Aquí... no es que discrepe, pero... si tu proyecto puedes aprovecharlo como escaparate del buen desarrollo y buen hacer de tu empresa o grupo de trabajo, es posible utilizarlo como un trampolín para futuros proyectos... o a la inversa, si la picias o el cliente no queda contento... una puerta abierta menos...
5. Lo breve, si bueno, dos veces bueno... osea, mejor las cosas pequeñas
 No seas mal pensado... estamos hablando de los métodos, ficheros, procesos, funciones....
6. Si alguien no está en sintonía con el resto del grupo...
 Habla con él/ella en privado
 Reasígnalo o cambia sus tareas o funciones
 Y si eres tu mismo... recuerda lo del escaparate...
7. Diseña los módulos o clases construyendo interfaces, de forma que sea accesible facilmente por terceros módulos, reutilizable y facil de implementar cambios masivos.
 Documenta estas interfaces a la perfección, pero no los módulos o clases que usa la interface, eso sí, mantén una escrupulosidad absoluta en la facilidad de lectura y mantenimiento del código de estos módulos.
8. Cuando estés en el proceso de debug de un problema, nunca digas ¡¡¡ Pero si en mi equipo funciona !!!
 ¿Quién no lo ha dicho alguna vez?
9. Si hay algún fallo de funcionalidad o algún bug grabe en la parte ya desarrollada, no continues con partes de código nueva hasta haber resuelto estos problemas
10. Si alguna parte del código es complicada de seguir el Lunes a primera hora, antes del primer café, rediséñalo.
Después de todos estos puntos, sería casi obligado hablar de algunos temas importantes, y debatir sobre ellos:
 Tomas de especificaciones.
 Reuniones de seguimiento con los clientes/usuarios y con el equipo de desarrollo.
 Equipos multidisciplinares o equipos de especialistas
 Prototipos, maquetas, beta releases...
Y prometo ir ocupándome poco a poco de estas cositas... por supuesto, necesito de tu colaboración, opiniones, críticas, experiencias... no te cortes...

Y por lo ultimo que si no te sale o estas turncado en un codigo, lo mejor y recomendable es apagar la maquina y despejarte tu mente, cuando vuelvas a trabajar en tu proyecto ya veras que si te sale.
tomedo del la web
20 rules for delivering software products Product Musings