Son cosas bastante obvias, pero supongo que la gente tiende a olvidarlos en medio del desarrollo y la cosa puede alargarse sobremanera.
Tu mejor idea no debería ser la primera que intentas llevar a cabo
El primer proyecto que realices incluirá el proceso de aprendizaje de las técnicas, tecnología y herramientas relacionadas con el producto/plataforma que estés realizando. Al terminarlo, si echamos la vista atrás se verán muchas cosas que podían haberse mejorado o hecho de otra manera. En general saldrá un producto bastante mejorable en todos los aspectos. Es algo normal, y es por eso que recomiendo realizar un proyecto de aprendizaje antes de dedicarte a tu mejor idea, para que el producto realizado tenga una mayor calidad.
Empieza pequeño
También existe el factor de la motivación. Es muy positivo ver los avances del proyecto, y sobre todo ver que el final se acerca poco a poco. Esto en proyectos grandes es más difícil de visualizar, los avances diarios pueden no influir apenas en la distancia que queda para terminar y eso puede ser un duro golpe para nuestra motivación.
Plasma la idea en papel
Escribe el concepto de la idea en texto, en una descripción corta, que incluya todo lo que se pretende añadir al producto. Incluye las secciones que se pretenden añadir, los controles, las pantallas, unos números aproximados, etc. Con esto se descubrirán incongruencias y se taparán huecos antes de que escribamos una sóla línea de código, además de que puede servir de base para presentar la idea a otras personas y que la visión del producto que tiene cada uno sea más parecida.
Haz un prototipo
Aunque sobre tu cabeza todas las piezas encajen y veas un producto de mucha calidad, existe la posibilidad de que en la práctica no sea así, y en realidad no sea posible lo que pides, o sea más complejo de lo que parecía en un primer momento.
Como regla, yo diría que si en una semana o dos no se es capaz de tener un prototipo mínimamente funcional, el proyecto es probablemente demasiado grande para que se pueda llevar a cabo correctamente.
Aquí hay que determinar bien si se considera al prototipo una prueba rápida "para tirar", o una primera evolución de lo que será el producto final. El primer caso probablemente sea más rápido de hacer, pero hay que tener en cuenta que después debería ser eliminado y volver a empezar de cero (o si no habrá demasiadas chapuzas metidas en el esqueleto del proyecto). El segundo se tardará un poco más en desarrollar, con la ventaja de que se puede seguir trabajando sobre él.
No me inclino por ninguna de las dos versiones, probablemente dependa de cada uno. Una ventaja de hacer el prototipo para tirar es que se pueden aprender de los errores que se hayan cometido hasta ese punto, y evitarlos en la versión final.
Organízate
Incluso aunque seas una sola persona, existe la necesidad de determinar qué tareas han de llevarse a cabo, e idealmente con qué prioridad. Aquí cada uno tiene su manera de gestionarlas, algunos son capaces de acordarse de todo, pero en cualquier caso recomiendo apuntarlas porque eso permite "liberar" a la mente de la responsabilidad de acordarse y concentrarse mejor en el trabajo.
Además, eso permite tener una aproximación del progreso que se lleva del proyecto, así como del ritmo que llevamos (número de tareas realizadas por semana, etc.). Cuanto más pequeña sea la lista, más cerca estará el final del proyecto :).
En nuestro caso usamos Pivotal Tracker , herramienta que recomiendo a equipos pequeños, pero vamos, que al principio usaba un bloc de notas y también servía.
No pierdas de vista el objetivo
Recuerda que el objetivo principal es completar el proyecto. Existe la posibilidad de dedicar más tiempo a un aspecto concreto porque nos gusta más, o de dejar de lado algo que aunque no consideremos importante, para el exito del producto es crítico (por ejemplo, el icono de la aplicación, el box art o las capturas de pantalla).
También existe la posibilidad (de hecho, la certeza) de que se nos ocurran muchas ideas que "mejoren" el producto final, hasta el punto de que si las hiciésemos todas el proyecto nunca acabaría (el temido "feature frenzy"). No digo de no añadir nada, pero tener muy claro que son extras sobre la idea original y sopesar bien el valor real de cada una de ellas antes de implementarla.
No hace falta alcanzar la perfección
No todo tiene que quedar perfecto. Muchas de las partes del proyecto bastará con que queden "suficientemente bien". Siempre pueden ser mejoradas más adelante. Esto es importante sobre todo en las cosas que tampoco van a verse tan a menudo o que son bastante secundarias. Es preferible dedicar más tiempo a mejorar lo que se va a ver constantemente.
No dejes lo peor para el final
Porque nunca querrás hacerlo y "encontrarás" nuevas cosas que hacer mejor que esas tareas que a nadie le gusta hacer. A estas tareas es mejor dedicarles un esfuerzo constante, intercalando tareas más gratificantes o sencillas, para que no se reduzca la motivación.
Además, "lo peor" suele ser importante para el producto final, o si no no se añadiría y punto :).
Enfócate en lo que mejor sabes hacer
Entre otras cosas porque lo harás más rápido y mejor. Por ejemplo, yo puedo hacer cosas aceptables (tampoco mucho) en gráficos, pero dedicándole unas seis veces más tiempo de lo que tardaría un dibujante de verdad, y con un resultado mucho peor.
A veces no queda más remedio, ya sea por no disponer de nadie que lo haga mejor, o porque éste tiene demasiada carga de trabajo, pero si es posible es mejor que cada uno se dedique a su rama. También es algo a tener en cuenta a la hora de plantear la idea, ya que no tiene sentido pensar en una idea para la que nuestro equipo no está cualificado, o con un desequilibrio importante entre los tipos de tarea a realizar y los roles disponibles.
Usa un control de versiones
Poco puedo decir sobre este punto. Tanto si se trabaja en equipo como si no, un repositorio de código es muy útil para poder disponer de versiones anteriores, para poder trabajar desde distintos sitios sin problema, y para poder probar chapuzas en cualquier momento sin miedo a romper nada en la versión final.
Aprende a "dar un paso atrás"
Durante el desarrollo del proyecto, es muy habitual que uno se centre en las tareas concretas que tiene asignadas, y que tan sólo realice las pruebas para comprobar que la funcionalidad que le tocaba añadir sea añadida, y poco más. También es bastante común que lleguemos a "acostumbrarnos" a algunos bugs o errores, hasta el punto de olvidarnos de su existencia y asimilarlos.
Por último, existe la posibilidad de que se nos haya pasado algo por alto y falte una pieza importante de la que no seamos conscientes al desarrollar el producto (Por ejemplo, con los efectos de sonido es bastante habitual olvidarte de ellos si programas escuchando tu propia música)
Es por ello que es importante hacer sesiones de betatest en las que nos consideremos un usuario final, alejándonos del entorno de desarrollo y fijándonos sólamente en el producto final. En el caso de los juegos de consola, esto se facilita porque basta con ponerse a jugar en la consola y punto, en otros casos puede requerir un poco más de concentración.
Lo importante es cambiar el chip y tener algo a mano para anotar los bugs y cosas a mejorar encontradas, y anotarlo todo. Después ya se comprobará qué cosas se cambian realmente y qué cosas no, pero al menos que se sepa de su existencia.
Piensa en el futuro
Durante el desarrollo de los proyectos, surgirá la necesidad de crear nuevas utilidades, o funcionalidades no disponibles aún. En este momento habría que plantearse si dicha funcionalidad va a ser usada a menudo en futuros proyectos (o futuros puntos del mismo). Si es así, probablemente será buena idea dedicarle un poco más de tiempo para que la funcionalidad facilite posteriores usos, integrándola en el motor, etc.
Hay que distinguir la necesidad real de usarla en el futuro con la mera posibilidad. Si no existe la certeza, yo no le dedicaría más tiempo, siempre se puede generalizar dicha funcionalidad más adelante.
Esto mismo sirve para elementos dentro del propio producto. En mi caso suelo aplicar la regla de preparar una funcionalidad para futuros usos sólo si ésta se sabe que se va a usar en más de dos casos distintos. Si no, tirar con algo que funcione y copiar-pegar la segunda vez que se use, y refactorizar la tercera.
Aprende de tus errores
Por último, una vez finalizado el proyecto y para los que vengan detrás, es muy útil redactar un pequeño postmortem que exponga los puntos que se considera que han quedado bien, y los puntos que se considera quedaron mal o podrían haber sido mejorados, para tenerlos cuenta en el siguiente proyecto y no cometer el mismo error.
Si no va a hacerse público, bastaría con una lista de puntos sin mucha explicación y debería ser sencillo. Hacerlo público requiere más esfuerzo porque hay que extenderse un poco más.
Lo ideal es darle un poco de tiempo al proyecto para poder conocer la opinión del público al respecto del proyecto, y así saber qué cosas gustan y qué cosas no.
Conclusiones
Después de este ladrillo, creo que he plasmado gran parte de mis teorías y experiencias respecto al desarrollo de los proyectos en los que me he visto involucrado. En el tintero me he dejado cosas como la organización del equipo del proyecto y temas de marketing, ya que en esos campos tengo menos experiencia y tampoco tengo realmente ningún consejo útil que dar. Espero que alguna cosa le sirva de ayuda a alguien.