eduardomillan.com

Cuántas veces nos hemos visto obligados a decir esta frase. Cuántas veces, por el contrario, tan sólo la hemos pensado. Y si la diferencia es grande…

Saber detectar errores es una tarea crucial. Al principio, eres un poco más torpe, más lento, pero con el tiempo comienzas a localizar posibles defectos de forma casi automática, observando por encima. Fijas la vista y sabes si algo va mal. Con el tiempo también, aprendes a decir “no“, a filtrar, a saber qué tienes que hacer, cómo lo tienes que hacer y cuándo lo tienes que hacer. Y aprendes a decir “esto no funciona“. Antes, tenías ese mismo pensamiento, pero no lo decías, esperabas a que algo cambiase. Dabas muchas oportunidades, confiabas en que eso que no funcionaba, comenzaría a funcionar, más temprano que tarde. Tenías fe, y retrasabas decirlo. Ahora tienes claro que si algo no funciona, tienes que cambiarlo. Analizas, valoras la situación y sabes que no merece la pena seguir invirtiendo en ello, pues intuyes que son fallos sistemáticos, de raíz. Los tienes acotados, definidos, y empiezas a esbozar soluciones. Lamentándote no consigues nada, así que pones toda tu mente a trabajar en ello, pensando cambios, modificaciones, alternativas. Y encuentras una solución. Es posible que no haya una solución perfecta, pero la irás refinando. O si te has equivocado otra vez, seguirás aprendiendo, y volverás a reemplazarla por otra mejor. Si esto no funciona, asúmelo, dilo en alto, comunícalo y busca soluciones; si esto no funciona, cámbialo.

Muchas veces he comentado la importancia de contar con un diseñador (“game designer“) en cualquier proyecto, por indie que pueda ser, como rol que tome las decisiones principales en cuanto a las mecánicas, reglas o fundamentos del juego. Siempre es muy valorable que los miembros de un equipo den su opinión, pero el diseñador tiene la última palabra, descartando aquello que no encaje, adaptando ideas… en definitiva, siendo el “jefe” en el área de diseño.

Sin embargo, en equipos muy pequeños, o incluso en proyectos llevados por una misma persona, la figura del diseñador queda algo difusa si coincide con el programador. Es decir, que diseñador y programador sean la misma persona. En este caso, se suelen “fundir” demasiado los roles y relajar los detalles. Así,

• El diseño es más fácil que cambie de forma muy constante, incluso que se comience a programar sin documento de diseño, pues lo irá adaptando el programador sobre la marcha. Y eso puede dar lugar a muchas incoherencias, aspectos que no terminen de encajar….
• La percepción es subjetiva. Cuando se tiene un diseñador dando “caña”, los errores, las mejoras… se van dectectando y puliendo de forma más clara. Si no, a pesar de que el programador sea consciente, puede considerar cosas válidas que no lo sean tanto, o dejar de lado los detalles que aporten una diferenciación con la competencia.
• Especialización. Lo de siempre: tener un especialista en cada campo o rol, aporta un valor realmente único. Y se nota mucho, tanto en el juego en sí (jugabilidad, mecánicas, interacción) como en los detalles, cuándo hay detrás un diseñador.

En el desarrollo indie, todo el mundo tiende a hacer de todo, pero es algo que en la medida de lo posible, hay que tratar de evitar. ;)

A principios de mes, comentaba en qué falló en lo nuestro que una idea no vale mucho por sí misma, contando más bien el hecho de (cómo) llevarla a cabo. En muchos foros, por comentarios de conocidos… se suele oír que se tiene una idea genial, que por lo general suele ser bastante “laboriosa” de materializar. El caso es que el inventor de esa idea cree que será un gran proyecto, que renovará lo que hay en el mercado y generará muchos ingresos que repartirá entre aquellos que colaboren en tan tremendo juegazo. Además, creará una de las mejores empresas del país, con proyección internacional y éxito asegurado.

Pero el punto “conflictivo” viene cuando observas que tiene poca experiencia (o incluso ninguna) en el sector, que va a dedicar sólo el tiempo libre (a lo sumo), que no cuenta con más recursos que un hosting (en algunos casos, gratuito), que tiene algún programador también a tiempo más que parcial…. En otras palabras, cuando ves que sólo es una efímera ilusión. No obstante, el “emprendedor” consigue los primeros colaboradores y se comienzan a hacer cosillas. Pero el proyecto necesita muchas horas, mucha planificación, muchas personas, mucho sacrificio… y no parece ser cosa de dos días como se había pensando en un principio. Y el tiempo pasa, los avances cada vez son menores.. y tras varios meses el equipo se da cuenta de que el proyecto no marcha, que aparte de las magias, está todo por hacer. ¡Con lo bien que pintaba! Una lástima, pero el juego se cancela… y queda en el olvido… con poco más que unos bocetos.

En el caso del mmorpg es especialmente llamativo, pero no hace falta que el proyecto sea un juego, ni tan siquiera que sea un mega proyecto. Soñar está bien, pensar en grande, también; pero hay que tener los pies en el suelo, analizar los recursos (materiales, temporales, personales…) que se tienen, estudiar lo que implica, lo que estamos dispuestos a aportar (de verdad) y hacer algo en coherencia. Idear un proyecto revolucionario no sirve de nada si no se puede llevar a cabo, por el motivo que sea. Y cuanto más pasan los años (y los proyectos), más cuenta me doy de ello.

El otro día escuchaba un programa de radio titulado “qué falló en lo nuestro” (o cómo conducir de noche), y me pareció un buen título para este post.  El 2009 fue sin duda un año de aprendizaje sin descanso, de muchas lecciones nuevas y, también otras, de recordatorio.

• Lo bien atado, mejor atado está. Las palabras se las lleva el viento, la buena voluntad puede terminarse de un día para otro. Acuerdos, colaboraciones, tratos… e incluso pactos entre socios, por escrito y definiendo pauta por pauta. Si alguien no hace su trabajo, si alguien no cumple lo pactado… tendrás más seguridad y podrás “tirar de contrato”, si está todo bien definido. Confiar demasiado en la buena voluntad… es mucho lujo.
• La gente, el mejor tesoro. Dar responsabilidad a personas no adecuadas puede ser una fuente de problemas inagotable. Y ese “no adecuado” puede ser falta de talento, de constancia, de ganas, de visión…  si quieres hacer algo, asegúrate que la gente en la que te vas a apoyar es de fiar, en todos los sentidos. Si no, sigue buscando y busca colaboradores (y trátalos bien) para temas que no comprometan en exceso a la empresa.
• Saber adaptarse es vital, pero no tener planes significa la muerte. Una empresa o cualquier proyecto emprendedor serio (del que se pretenda vivir), no es un hobbie o un “a ver qué pasa”. Planifica, estima, valora, plantea… y sé realista. Evita el “de aquí a 3 meses, ya veremos”, “vamos viendo sobre la marcha”, “según vayamos viendo”… o no tendrás nunca un rumbo estable, aumentando las posibilidades de fracaso.
• Analiza y evita impulsos. Una puerta a medio abrir es muy tentadora, pero piensa si realmente puede abrirse del todo. Quizás por poner mucho empeño en ella dejes otras cerradas, pero de apertura más fácil, o otras abiertas en las que no te habías fijado por ese deslumbramiento inicial. En mi caso, por ejemplo, me centré mucho en un proyecto que resultó ser un fracaso (entre otras cosas por no analizar bien los recursos disponibles), y dejé de lado otras cosas que hubieran resultado más productivas.
• Un proyecto no va a comerse el mundo por ciencia infusa, por bueno que sea. Cada vez que se oye “tengo una idea demoledora, que va a arrasar”, se huele un fracaso.  Sobre todo, porque esa idea hay que llevarla a cabo. Muchas ideas que he oído y otras en las que de algún modo he participado, han quedado en eso, en ideas difusas que el aire se llevó.  Y nadie apostará por ti (compañeros, socios, inversores…) si no ve un proyecto sólido detrás. En videojuegos, es lo que se  conoce como “el misterioso caso del mmorpg” (hablaré de él algún día :P).

Por el blog de Undead, publicamos algunas experiencias con herramientas clasificadas como “gestores de proyectos“, y de hecho llevo ya varios años haciendo uso de este tipo de software. He probado muchas aplicaciones, principalmente en entorno web, tanto a nivel de SaaS como soluciones open source descargables e instalables en un servidor web. Algunas me han llegado a parecer muy productivas, usándolas durante cierto tiempo, pero por unas cosas o por otras, al final siempre he tenido la sensación de que se quedaba pequeño, o no terminaba de convencerme.

¿Qué tendría que tener el gestor de proyectos perfecto? En mi opinión,

• Usuarios, roles y permisos. La mayoría implementa todo esto, pero en muchas ocasiones de forma un tanto rara. Los usuarios tendrían que poder englobarse en grupos (dirección, equipo, freelancers, colaboradores…) y en base a ello, que tuviesen ciertos permisos, para acceder a unos módulos u otros.
• Agenda. Disponer de una agenda de contactos, puede llegar a ser muy útil, para no recurrir al archivador de tarjetas, al correo…
• Wiki. Una wiki que resulte útil, pues algunos la incorporan en modo demasiado simple, o con un diseño que apenas permite encontrar algo o documentar a gusto. Además, que sea definible por proyectos, de tal manera que una persona que estuviese en el proyecto A, no puede acceder a la documentación del proyecto B.
• Proyectos. En un proyecto pueden participar usuarios de diferentes grupos, cada uno con una serie de permisos. La flexibilidad ideal sería, por ejemplo, que al subir un archivo, pudieses elegir qué grupo podría verlo o editarlo. Y disponer de otras funcionalidades como calendario, diagramas de Gantt…
• Tareas. Siguiendo el punto anterior, un buen gestor de tareas. Milestone o hitos, listas de tareas, tareas sin estar dentro de una lista, asignaciones a personas y en tiempo… De un vistazo, tener el control de lo que se está haciendo, de lo que queda por hacer, de quién está con ello…
• Ficheros. Gestión de ficheros, divididos por categorías, tags… e integración con subversion.
• Foros. Organizados por proyectos, también con un sistema de permisos / grupos / usuarios, y con alertas. Al nuevo mensaje, correo! Una moderación avanzada, también se agradecería. Borrar mensajes, editarlos, trasladarlos…
• Usabilidad / Manejo. En general, todos los gestores suelen pecar de ser algo “duros” a la vista. Los temas visuales no están nada cuidados, y la usabilidad a la hora de manejo y configuración muy pobre. Muy “1.0“. Permitir un diseño personalizable, pero con uno potente por defecto, tener los módulos bien organizados, búsquedas…
• Open Source. Para ser perfecto, tendría que ser Open Source, sencillo de instalar (sin mil instalaciones previas por consola), de configurar (GUI), y realizado bajo PHP / MySQL.

La principal limitación viene al a hora de controlar temas como manejar información para diferentes equipos / personas, de tal manera que en un mismo proyecto, puedas decidir qué documentos compartes con quién (o con qué grupo), qué mensajes son para todos o sólo para algunos… o temas como asignar tareas muy puntuales a una persona que no está dentro de un proyecto, sino en otro, pero que de forma temporal necesita acceder a algo presente en otro proyecto… Son cosas no habituales, pero cuando el equipo es muy limitado y dependes de muchos freelance o colaboradores, facilitan la organización.

Los proyectos que he ido usando /probado: dotProject, ProjectPier, Egroupware, Trac, PHPProjekt, Tikiwiki, Assembla, Clocking IT, TeamBox. Y seguro que alguno más me dejo por ahí… ;) alguna sugerencia? :P