En algunas ocasiones hemos hablado por aquí de metodologías ágiles, gestión de proyectos… temas muy relacionados con esa buena gestión del tiempo. El día tiene horas limitadas y una mala planificación puede significar no cumplir plazos, o sufrir mucho con horas extra, así como depender de factores externos que hagan que la empresa vaya un poco por los picos del teléfono… o incluso que cada día sea un nuevo pico de trabajo porque no se han organizado bien las tareas, las funciones… ¿Cómo hacer más en menos?

Planificar en base a objetivos (hitos), definir y desglosar bien cada tarea dentro de esos hitos, llevar un control por escrito de to-dos (lista de tareas) e ir tachando (según la prioridad), no distraerse con el ruido (internet, otras tareas…), tener muy claro aquella cosa concreta a realizar… han sido varias de las ideas lanzadas. También se extrapola al tiempo no laboral, pues en muchos casos consumimos por esa mala gestión más horas de trabajo, reduciendo mucho tiempo de ocio.

Algunas buenas prácticas,

• Plantear hitos, etapas o objetivos…  y dividirlos en subhitos más pequeños, con una visión temporal estimada.
• En esa división, plantear un hito semanal, planteado un lunes y revisado el lunes próximo.
• Hacer una nueva división por tareas muy concretas y definidas, planificando cada día en base a ello. (Qué vamos a hacer mañana, en qué orden según la urgencia / prioridad)
• Hacer una pequeña revisión del día, para plantear mejor el día siguiente, en función de lo que no ha dado tiempo, de lo que sí…
• Dedicar tiempo al descanso y ocio, también es importante para rendir y evitar fatigas y frustraciones.

En Undead seguimos un poco toda esa filosofía, y comparado con nuestra etapa amateur en la que todos esos procesos los dejábamos más de lado, notamos una mayor eficiencia (con diferencia), que al principio puede ser costoso de ver o parecer un trámite inútil, pero que cuando se va poniendo en práctica, se demuestra.

Un libro recomendado sobre todo esto, es “Gestiona mejor tu vida“, de Alberto Pena. Y en cuanto a juegos, muchos pueden ayudarnos a darnos cuenta de la importancia de todo esto: tiempo, estrés, prioridades… suelen ser habilidades inherentes a desarrollar en el género llamado, precisamente, gestión del tiempo.

Artículos recientes relacionados:

• Gestionando una venta
• El error positivo
• Misión, visión y valores corporativos
• Desarrollo de personas y eficacia
• Ayudas públicas y subvenciones empresariales

Perfil de usuarios

Si bien hay un porcentaje de hard-gamers que consumen juegos en iPhone, la mayoría parece decantarse por un producto casual, con el que pasar un rato agradable sin complicarse demasiado. No obstante, algo que nos llama la atención es que aún así, es un público exigente. Juegos al precio mínimo con un buen acabado, no terminan de ser bien valorados. Hay que sorprender, a nivel de jugabilidad, de gráficos… y de manejo / usabilidad. El juego tiene que entenderse a la primera, creando en el usuario una sensación positiva nada más abrirlo.

Marketing

El mercado para iPhone es realmente difícil. Hacerse un hueco requiere una inversión en marketing, o tener la suerte de impactar y reducir algo ese gasto recuriendo a la viralidad, al apoyo de apple… pero en general la competencia es dura. Hay pocas aplicaciones que venden mucho, y la mayoría que venden muy poco. El término medio parece que no es habitual, así que hay que estudiar un poco lo que hay, las tendencias… e intentar hacer algo diferente, a nivel de desarrollo independiente. Las grandes IPs no tienen tal problema, pues lo que vende es esa marca, aunque luego el juego no sea nada innovador. Otra opción, es negociar con un publisher esa parte, pero para los desarrolladores “indie” es algo complicado.

Notas de prensa, reviews… en líneas generales, obtener críticas o captar la atención de algún medio importante sin pasar por caja, suele ser laborioso. Muchos emails, muchos envíos, mucho navegar…. y tampoco hemos dado con alguna agencia (española) especializada en este tema. Muchas páginas se nutren directamente del app store, pero a pesar de estar indexadas, la visibilidad es casi nula, viendo necesario invertir dinero / tiempo en ello.

Demo / No demo

Este tema es un punto de debate. Muchos desarrolladores comentan que la versión libre hizo mucho daño a las ventas… y en cambio otros relatan que ayuda bastante. En nuestra experiencia, todavía sigue siendo algo pronto para valorarlo, pero las versiones “lite” no parecen provocar un buen ratio de conversión, al menos señalable. No obstante, la estrategia está en que esa versión gratuita sea jugable, pero no demasiado, pues el usuario jugará siempre esa y no comprará la completa. Tampoco restringir mucho su jugabilidad, pues la reacción no será positiva. Llegar a un equilibrio, el objetivo.

Otros modelos de negocio

De cara a nuevos proyectos propios, estamos explorando nuevos modelos de negocio. Por ejemplo, los juegos gratuitos tienen mayor público, y pueden rentabilizarse mediante publicidad in game, o pagos por contenido (niveles o items extra…).

Y para la tercera “entrega“, dejaremos un análisis más concreto sobre el Tinted Turns.

Artículos recientes relacionados:

• La publicidad en los videojuegos
• Gamelab 2010, feria del videojuego
• Juegos españoles, desde Junio de 2009 a Junio de 2010
• Gestionando una venta
• Crystal Reversi, ya disponible en la AppStore

• Cada sesión de juego, estaría limitada a un máximo de 5 minutos.
• Frase: “Mientras nos tengamos el uno al otro, nuestros problemas no cesarán“.
• Uno de los conceptos: desarrollo, falsedad o atrapado.

A modo también de consejos sobre cómo plantear los desarrollos, vimos un vídeo de la organización, en el que en clave de humor se daban una serie de recomendaciones, como por ejemplo, ser conscientes del tiempo, ajustando las espectativas y deseos del videojuego a crear.

Con el tema sabido, nos tomamos unos minutos para pensar en ideas. Hecho esto, de forma breve explicamos al resto de participantes aquello que habíamos formado en nuestra mente y, en función de las ideas presentadas, y de los perfiles (programación, producción / diseño, arte / gráficos), formamos los grupos de trabajo. A las 19:00, los siete grupos formados, estábamos ya preparados para afrontar el reto.

Team Six

Alejo, Andrés, Trisha y yo compusimos el grupo para trabajar en la idea de Alejo, encargado de tareas de arte, diseño y producción. Las primeras horas las dedicamos a definir lo más básico del proyecto, así como para decidir las herramientas de desarrollo y ponerlas en común. Tomadas las decisiones más importantes, comenzamos a avanzaar en paralelo, en los diferentes aspectos del juego.

Metodología

Como ya hemos comentado alguna vez, una de las claves para que un proyecto salga adelante es la organización. Así, adaptamos la metodología Scrum al tiempo disponible, tomando la esencia de ella y generando el “Team Six Scrum Lite“. Una ventana detrás de nosotros nos sirvió para plasmar todos los post it, revisar los sprint, definir nuevas tareas, adaptar las existentes o desecharlas….

Cada sprint se compuso de tres pasos: definición, realización y revisión. En la definición se decidía los objetivos del sprint, las tareas a realizar por cada uno de nosotros. Etiquetando las tareas por su ámbito (gráficos, programación…) y tiempo de fin, quedaban reflejadas en la ventana, teniéndolas siempre presente. Durante la realización, nos encargamos de cumplir esas tareas en el plazo dado, poniéndolo en común en la revisión.

Para compatir todos los recursos en el equipo, nos creamos una cuenta en Dropbox, algo así como un subversion. La verdad es que el servicio me sorprendió gratamente, tiene funcionalidades básicas pero mucho tamaño (2GB) y otras características interesantes.

También destacar la importancia del diseñador, del trabajo coordinado.. y de todo el equipo.

Garden Antics

El jugador se pone en la piel de un jardinero, que debe cuidar su jardín. Para ello, dispone de semillas, que puede plantar y hacer crecer regándolas de forma apropiada: si se riegan mucho se saturan de agua y pueden llegar a moir; si se riegan poco, se secan y mueren. Pero en nuestra feliz existencia hay un pequeño (pero feo) animal, que se come nuestras plantas. Y nos cae mal, muy mal. Todo nuestro trabajo, lo echará a perder como no seamos muy rápidos. No obstante, cuando come mucho, genera abono, pudiendo utilizar ese abono con las plantas y generar nuevas semillas, con las que plantar más plantas. Si en cinco minutos no cumplimos ciertas condiciones (como tener una planta sana de nivel 3), perderemos el juego.

Nuestro juego tomó el concepto de desarrollo, tanto por el objetivo del juego de ir creando un jardín, como por el desarrollo de la relación con el bicho. Al principio, le odiaremos mucho, pero poco a poco le iremos cogiendo cariño, pues si somos habilidosos, nos proporcionará un sentimiento de simpatía, sin que siga siendo una fuente de problemas para con nuestras plantas y flores.

Anécdotas

Muchas risas, tensión (buena), nervios… un fin de semana de lo más intenso. Seguro que en todos los grupos hubo mucho que contar… en el nuestro, contamos algunas cosillas…

• Hubo dos momentos muy críticos. Andrés y yo creímos haber perdido todo el código de dos sprints al integrar cada parte de nuestro código. Al final pudimos recuperarlo y todo quedó en un (gran) susto…
• En la integración final, no parecía funcionar la release. Así, tuvimos que recompilar el proyecto (VS 2005) en Code::Blocks. No tenía muchas esperanzas de que funcionara, pero no dio problemas y pudimos entregarlo a tiempo.
• Bugs, bugs, bugs… en 40 horas no da mucho tiempo a depurar bugs. Eso unido a malas prácticas en el código para ahorrar tiempo… lo que sí conseguimos es que tales bugs no se notaran en exceso…

El resto de grupos

Sólo el hecho de participar ya dice mucho de la gente. La experiencia en desarrollo de videojuegos de cada uno era muy diferente, pero todos se merecieron ganar, por una cosa o por otra. Aunque el premio mayor, sin duda, es el trato, las relaciones, el compañerismo… y lo vivido en tres días. ¡Geniales todos ellos!

Los trabajos se pueden ver, descargar y votar en la página del Global Game Jam. Por nuestra parte, a ver si esta semana depuramos alguna coseja y lo resubimos por aquí.

Premios

En el salón de actos de la Facultad de Informática, se entregaron los premios, previa exposición de los trabajos ante los compañeros y organización y previa muestra y estudio del jurado de la industria. (Fueron grupo por grupo evaluando nuestro trabajo, en la zona de desarrollo).

Tras unas palabras del jurado explicando su fallo, los ganadores subimos a la entrega. El premio al mejor videojuego fue para Eclipse, un juego 2D plenamente jugable y divertido. En cuanto al premio de mejor arte, compartimos el premio con Ginos Pizza, que contaba con un buen trabajo de modelado y arte 3D.

El tercer premio lo decidíamos los participantes, votando los dos juegos que más nos habían gustado. Una elección difícil, sin duda. Incluso hubo un empate en primera instancia. Finalmente, Garden Antics quedó en primer lugar. Así, nuevamente agradecer a todos los compañeros el voto, es una gran satisfacción hacer cosas que gusten.

Repercusión

Durante el fin de semana hubo cámaras capturando fotos y vídeos, haciendo entrevistas… Además del streaming directo y de los reportajes relacionados con la universidad, rtve y público han difundido el evento.

Organización

El lugar elegido fue muy apropiado: dos plantas, una para descanso y manutención, y otra para trabajo. Además nos dejaron adaptar el espacio y juntar mesas, haciendo un espacio más compacto y utilitario. Siempre hubo gente de la organización a mano, incluso de madrugada, pendiente de que no faltara comida, bebida o cualquier otra cosa vital. Quizás el área donde dormimos (muy pocas horas, eso sí) estaba demasiado cerca de ruidos, siendo valorable para próximas ediciones buscar un modo de aislar más a los que necesiten dormir.

Camiseta, llavero, diploma, impresos varios, encuesta de satisfacción…. detalles valorables, en una organización muy cercana y familiar. El año que viene, seguirán mejorando.. no hay ninguna duda.

Artículos recientes relacionados:

• La publicidad en los videojuegos
• Gamelab 2010, feria del videojuego
• Velada Open ArsGames – Mondopixel
• Juegos españoles, desde Junio de 2009 a Junio de 2010
• El primer iPad Mad Camp

• Bonita. Desarrollado en Java, software libre, orientado de un modo especial a conceptos de la ingeniería de software.
• DotProject. Un sistema bastante completo, actualmente el que usamos en nuestra intranet. La organización de tareas, calendario, proyectos.. está bastante pulido… pero en temas de permisos, grupos de usuarios… aún potente, queda algo flojo, entre otras cosas porque resulta algo complicado de manejar. Tiene detalles importantes, pero también alguna que otra lagunilla. Aún así, una buena elección.
• PHProjekt. Un proyecto de los más extendidos. Foros, tareas, perfiles y skins o temas, pero nada del otro mundo.
• Trac. Una opción muy interesante, a pesar de tener una interfaz algo simple. Trae un cliente de subversion, sistema de tickets, wiki, tareas y milestones…
• ProyectPier. Manejo de tareas, proyectos, grupos y ficheros. Simple, pero eficaz y amigable.
• EGroupware. Otra aplicación que integra muy bien diferentes funcionalidades: gestor de tareas, archivos y tracker, wiki, contactos…
• OpenACS. Una herramienta completa: gestión de proyectos, sistema de tracking, tareas, CMS, foros, calendario… Corre bajo bases de datos Oracle / PostgreSQL, es open source y está enfocado a sitios con mucha información y tráfico.
• Acollab. Sencilla aplicación que incorpora chat, foros, gestor de archivos, grupos y miembros, además de contar con un espacio para editar documentación de forma colaborativa.

Y otros dos proyectos comerciales, que también nos parecen curiosos…

• Project.net. Gestor de proyectos comercial, de código abierto. Parece también muy completo
• Assembla. Se trata de un servicio online, que ofrece muchas posibilidades de gestión. Espacio gratuito para proyectos públicos / libres (con opción de pago que amplía características, como privatizar el entorno), subversion, tracs, wiki…. todas las herramientas básicas.
• BaseCamp. Del estilo de Assembla, quizás más pulido, pero de mayor coste, tiene varios planes para adaptarse a la necesidad del usuario.
• MetoCube. Aunque se trata de un sistema de documentación de procesos, puede servir como gestor de proyectos, pues está bastante depurado, pudiendo probar una demo online.

En la página Open Source CMS, en la sección de groupware, se relacionan estos y varios gestores más, para seguir teniendo donde elegir. Y tú, ¿cuál recomiendas?

Artículos recientes relacionados:

• Developer Hub, Windows Phone 7
• Primeros talleres del meetapp
• Gestión del tiempo
• Vender juegos para iPhone
• Desarrollar juegos para iPhone

Idea. ¿Qué queremos hacer? En este proceso se trata un poco de definir los aspectos básicos que deseamos tenga nuestro juego: género, temática, mecánica de juego, ambientación base…

Documento de diseño. El paso inmediato después de la tormenta de ideas, es definir, cuánto más exacto mejor, todo lo que ha llovido en ella. Aquí también se irán planteando las opciones de desarrollo concretas, como la plataforma, el lenguaje, el tipo de gráficos… En este enlace puedes ver una buena guía de todo aquello que debe tener un buen documento de diseño. (Aunque en realidad, hay muchos puntos de vista sobre el contenido que debe estar presente y la forma en la que debe desarrollarse).

Estudio de mercado. Si existe una visión comercial para el juego, es vital cumplir con este paso. ¿Qué aporta mi juego al resto de juegos que hay en el mercado? ¿Cuáles son mis competidores? ¿Cómo puedo quitarles jugadores? ¿Qué mejoraría de sus productos? ¿Tengo posibilidades reales de hacerme un hueco en la competencia? Muchas preguntas que requieren un análisis del mercado, de estudiar todo aquello que influirá en las ventas. Y, por supuesto, tampoco hay que dejar de lado el modelo de negocio, la forma de distribución…

Concreta tareas. Metidos ya en el desarrollo, se observa que un grupo produce más si se está pendiente de él, si el lead (el líder del que hablábamos en un post anterior) reparte trabajo de forma concreta. Cambiar un “que cada uno haga lo que vea” por “tú, desarrolla esto, esto y esto, de tal forma que se cumpla que….” Si hay algo que retrasa mucho, es no saber por dónde tirar o no saber qué hacer. Para eso también sirve el documento de diseño, para que se sepa de forma clara por dónde se ha de tirar. El reparto de tareas, se ha de realizar de forma concreta, tendiendo a dividirlas en partes pequeñas, siguiendo su progreso y finalización. Esto no quiere decir que se necesite una dictadura, sino que haya una distribución de trabajo concreta y organizada.

Plazos y milestones. Para dar más caña al equipo, puede ser buena práctica fijar plazos para las tareas, teniendo reuniones periódicas y compartiendo informes o reportes de aquello que se ha finalizado. Como siempre, es probable que haya retrasos, pero el equipo sentirá que debe ponerse las pilas si se han de cumplir entregas, además de dar más seriedad o oficialidad al grupo. También puede servir como autoevaluación, para ver la progresión del trabajo…

Metodologías. En relación a los dos puntos anteriores, puede ser interesante seguir una metodología definida. Sobre gestión de proyectos y metodologías de desarrollo, se ha escrito mucho… una nueva tendencia (que parece muy efectiva y aplicada, por ejemplo, por los chicos de Zed) es la metodología Scrum. La programación extrema o XP también es muy utilizada.

Si este listado pretende ser una serie de consejos a seguir, para otro artículo dejamos el listado de pautas a saltarse en el desarrollo de software y, especialmente, en el desarrollo de videojuegos.

Artículos recientes relacionados:

• Gestión del tiempo
• Vender juegos para iPhone
• GameJam, una compo internacional
• Gestores de proyectos
• La figura del diseñador y la importancia de planificar

¿Qué hace un diseñador? Si el programador programa, el grafista realiza los gráficos, el músico compone las melodías y ritmos…. ¿quién se encarga de diseñar el juego? Si en un proyecto no existe tal figura, será difícil que llegue a buen puerto. Imagina que todo el equipo se pone manos a la obra, haciendo grandes progresos. A las pocas semanas, el grupo no sabe por donde tirar: el programador se encuentra con unos gráficos que no le sirven, que no están adecuados a la nueva forma que ha pensado de implementación o que la herramienta con la que comenzó ya no es la indicada; el grafista se da cuenta de que necesita un nuevo set de gráficos, tirando por la borda todo el trabajo realizado en ese tiempo…. ¡caos! Que se hubiera evitado si se hubiese comenzado la casa por los cimientos…

El diseñador es el encargado de decidir y planificar todo lo relativo al concepto de la aplicación, el que cambia un “a ver que va saliendo” por un proyecto bien definido y concretado. Temática, mecánica y tipo de juego, ambientación, fases y niveles, estructuración… cada detalle del que constará el juego… plasmando todo esto por escrito, en aquello que se conoce como documento de diseño, algo así como una biblia del juego. Más adelante, por diversos motivos, puede actualizarse, pero siempre se tendrá una referencia clara del rumbo a seguir. Por ello es muy importante no comenzar a trabajar hasta que no se haya elaborado ese documento, pues será como lanzarse a la mar sin brújula ni carta de navegación. Y rodeado de agua, se oirá algo como “y ahora, ¿qué?“.

Por otro lado, la persona que asuma el rol de diseñador, deberá ser consciente de las limitaciones y recursos disponibles, tanto técnicos como humanos. Diseñar un MMORPG nos gustaría a todos pero… para la gran mayoría, no es algo viable. Entonces, el diseñador tendrá que ir definiendo el proyecto en función de aquello con lo que se cuente:

• Presupuesto: ¿será necesario invertir o disponer de dinero? ¿de cuánto?
• Nivel técnico del equipo: ¿se puede llevar a cabo por las personas del equipo? ¿nos quedará grande?
• Herramientas: ¿se puede realizar con tal herramienta? ¿hay que pensar en otra?
• Tiempo: ¿cuánto tiempo nos llevará? ¿podemos permitirnos ese tiempo?
• Objetivos: ¿están definidos? ¿el diseño va acorde con ellos? ¿se conseguirán con este diseño?

En otras palabras, planificar. El diseño no debe ser algo aleatorio, sino algo estructurado, pensado, concreto.

Artículos recientes relacionados:

• Gestión del tiempo
• Vender juegos para iPhone
• GameJam, una compo internacional
• Gestores de proyectos
• Gestión de proyectos: videojuegos

Posiblemente, el mayor problema al que se enfrentan los grupos amateur sea la coordinación, aplicada a todos los ámbitos, como la motivación de cada uno de los componentes o el empeño puesto en sus obligaciones. Varias claves para el progreso de equipo podrían ser:

• Un líder. La figura de un líder, un coordinador, es algo vital. Aunque dentro haya democracia y se valoren todas las opiniones de los miembros, alguien debe ser capaz de llevar las riendas en la toma de decisiones, de repartir el trabajo, de organizar las tareas, teniendo la última palabra, aún a riesgo de equivocarse. Además, en muchas ocasiones se requiere una respuesta temprana, en la que debe decidir por su cuenta para el bien del grupo. De los errores se aprende, pero no se puede aprender de errores si estos no se comenten, porque el grupo tardó semanas en ponerse de acuerdo en la decisión a tomar…
• Jerarquía y funciones. Contar con un líder es una necesidad, pero para satisfacerla no sólo basta con tener a la persona, sino que el resto del equipo acepte su condición de jefe, asumiendo la jerarquía. Para potenciar la participación de todo el grupo, se pueden repartir funciones, de tal manera que no sea el líder quién cargue con todo. Marketing, relaciones públicas, publicidad, tecnología interna, administración de recursos… siendo también imprescindible que se cuente con la aceptación de todos.
• Tomárselo en serio. A pesar de la condición amateur o independiente que pueda tener el equipo, otra condición para el éxito es que cada uno de los integrantes esté dispuesto a tomárselo en serio. Hablando el otro día con otros desarrolladores, se decía “pero no cobran, así que tampoco puedes exigir mucho“. Visto así, bien es cierto, pero el pertenecer a un grupo es algo voluntario, debiendo estar de acuerdo con los objetivos definidos por el grupo. Y, al fin y al cabo, no deja de ser otro hobbie… si compites jugando al fútbol, tampoco cobras, y tu entrenador te pedirá que muestres interés o dejes el equipo. Por tanto no consideramos mala opción descartar a los condicionales y apostar por los incondicionales. Recuerda que tu grupo marchará si todos sus miembros marchan…
• Tareas. Otro punto importante en la organización es que cada uno sepa las tareas que tiene que hacer, y las tareas que tiene que hacer el resto. En otras palabras, coordinación. Para ello es útil manejar algún gestor de proyectos, con el que repartir y administrar las tareas de cada desarrollo (o generales a la vida del grupo), dejando referencia escrita de todo aquello que está por hacer o ya ha sido realizado.
• Actividad. En relación a lo anterior, que el equipo sea una entidad viva. Hay que moverse, estar alerta, atentos a oportunidades y dedicarle un tiempo definido y constante. Si se pierde la constancia… se pierde la actividad… y con ello el grupo (y sus proyectos) muere.
• Objetivos. Ya hemos hablado de ello en varias ocasiones: definir objetivos generales del grupo y objetivos para cada proyecto, por escrito, haciendo balances temporales, valorando su consecución, planificando en el tiempo…

Como decíamos al principio, de todo esto y más charlaremos en un evento que estamos organizando, del que queda poco para fijar una fecha concreta y ponernos manos a la obra con la elaboración oficial del programa. Así pues… atento al blog…

Artículos recientes relacionados:

• Gestión del tiempo
• Vender juegos para iPhone
• GameJam, una compo internacional
• Gestores de proyectos
• Gestión de proyectos: videojuegos

En varios artículos hemos comentado la importancia de contar con una máquina que soporte todo el tema logístico del equipo: intranet, subversion, wiki, documentos… Una opción algo inviable (al menos como servidor primario) es montar un equipo casero. El ancho de banda reducido, posibles ataques, un porcentaje alto de caídas… al final termina por ser un descontrol. Otra opción es contratar un servicio de hosting… pero… ¿dónde?

En Google se pueden encontrar infinitos resultados acerca de empresas que ofrecen servicios de hosting, housing… ubicadas en prácticamente cualquier país y con unos rangos de precios / opciones muy diferentes. Y, por supuesto, con una calidad de servicio también muy dispar. ¿Cómo elegir entonces? Aunque nada puede asegurar que el servicio vaya estar acorde con lo contratado… algunos consejos podrían ser:

• Mira opiniones. Las opiniones pueden darte una idea acerca del producto. Clientes contentos o hartos, experiencias, recomendaciones de webmasters y otros emprendedores…
• Analiza la página. No tiene por qué ir en relación, pero si su sitio web está desatendido, anticuado, con información caduca… no es una buena señal de que se preocupen mucho de sus cosas…
• Prueba. Muchas compañías ofrecen periodo de prueba y/o garantía, de tal modo que si no te convence, te habrá salido gratis.
• Periodos medios. Lo ideal sería renovar el contrato del servidor cada mes, siendo libre de marcharte si la cosa va mal. Pero, por lo general, contratar mes a mes es más caro (tarifas más altas y/o cuotas de instalación), saliendo más rentable firmar por más tiempo. Pero tampoco hay que pasarse, o quedarás comprometido (aka pérdida de dinero) aunque el host no te sirva….

Además debes tener en cuenta o estimar el uso que vas a dar al servidor. Es decir, transferencia que vas a consumir, tamaño en disco, servicios como ftp, ssh, cuentas de email, dominios permitidos… en función de eso, estará el precio y las condiciones.

Contratar hosting en España, tiende a salir bastante caro, en comparación con Estados Unidos. Por contra, alojarlo allí te costará tener que dominar el inglés (para el soporte técnico, dudas, ampliación de contrato…) y quizás algo de lag. Según nuestra opinión, compensa, a menos que tengas recursos económicos de sobra. Al principio, puedes contratar un plan mínimo e ir aumentando según progresen tus proyectos o ambiciones.

Como otra opción más, existen servicios gratuitos que ofrecen o bien hosting (sobre todo promociones, nuevas empresas, patrocinios o partners) o bien un entorno a modo de intranet, como assembla. Hace no mucho nos creamos una cuenta para probarlo y está interesantillo, sobre todo para grupos que comienzan a dar sus primeros pasos o para quién desea tener un espacio funcional sin más complicaciones.

Pendiente nos queda la segunda parte de este post, en el que comentaremos nuestra experiencia con las empresas en las que nos hemos alojado, para que pueda servir como una pequeña referencia…

Artículos recientes relacionados:

• Gestión del tiempo
• Vender juegos para iPhone
• GameJam, una compo internacional
• Gestores de proyectos
• Gestión de proyectos: videojuegos

¿Por qué una wiki? Muchas de las labores más administrativas y de documentación que ahora controlamos mediante la wiki corporativa, antes eran elaboradas mediante posts del foro interno y/o de ficheros en excel / word. Con el aumento de trabajo, vimos que organizarnos así era tedioso y poco productivo. Por ejemplo, a la hora de actualizar, había que bajar el fichero del servidor, editar avisando de que estábamos modificando el archivo y volver a subirlo… además del tiempo, había que sumar un cierto grado de descoordinación o caos y estar pendiente de usar las mismas versiones para evitar incompatibilidades. Además, en ocasiones necesitábamos acceder a los archivos desde otros equipos, en los que no teníamos el software apropiado para su edición / visionado… restando todavía más puntos organizativos.

Con la instalación de la wiki, esos problemas desaparecieron. La documentación está siempre online, en un directorio protegido, ordenada por categorías y subcategorías, en artículos y capítulos…. accesible de forma cómoda e intuitiva, en la que se puede buscar información concreta…. y editarla con nuestro usuario… siendo conscientes de los cambios y modificaciones realizadas.

En cuanto al gasto, es muy reducido. De hecho, el software que lo gestiona, es libre, existiendo múltiples scripts open source, como MediaWiki o TikiWiki. En el artículo de la wikipedia (basado en el primero) puedes ver una definición ampliada del concepto.

¿Para qué una wiki? Los usos que se pueden dar a una wiki corporativa son muy extensos, tantos como llegue la imaginación o, mejor dicho, la capacidad o necesidad organizativa. En Undead Code, usamos nuestra wiki para:

• Documentación Técnica. En lugar de realizar ficheros en html, word… con la documentación técnica de nuestros proyectos, la redactamos y actualizamos sobre la wiki. Así, en tiempo real y con cada cambio, tenemos una idea clara de las nuevas versiones implementadas, de las nuevas funcionalidades, de cómo actúa una parte del juego en concreto…
• Documentación Corporativa. Textos y resoluciones relativas al grupo, como actas / orden del día de reuniones, enlaces a documentos oficiales internos…
• Documentación Logística. Ubicación de servidores, direcciones de correo, de ftp, estado del subversion…
• Documentación Externa. Enlaces a páginas de recursos, iniciativas, concursos, páginas de tutoriales, listados interesantes de gráficos, de scripts, frameworks… toda la información que encontramos en la red y que alguna vez puede sernos útil.
• Cultura técnica. Cuando realizamos algo complicado, lo apuntamos en la wiki como fuente de conocimiento. Así, cuando alguien se encuentre con el mismo problema, sabrá cómo solucionarlo.

Gracias a ella, somos más ágiles a la hora de afrontar temas organizativos, sobre todo en la parte de información estática. Para documentación que no varía constantemente, como fuente de conocimiento interno y externo, es mucho más útil (y cómodo) tener referenciados los textos en la wiki que tener que estar buscando el tema concreto del foro o revisar los archivos de forma offline, algo que sin lugar a dudas , según nuestra experiencia, influye mucho en la productividad.

Y, como conclusión, resumida en tan sólo una frase, diremos que instalar una wiki en tu servidor es una excelente vía de sacarle partido.

Artículos recientes relacionados:

• Gestión del tiempo
• Vender juegos para iPhone
• GameJam, una compo internacional
• Gestores de proyectos
• Gestión de proyectos: videojuegos

“Tener un dream team es más importante cuanto menores son los recursos con los que se cuenta“. En las charlas sobre emprendedores y start ups de CP Labs, durante la Campus Party, fue una de las grandes frases que tuvimos el privilegio de escuchar. Cuando nos lanzamos a emprender, cuando comenzamos a montar un grupo de desarrollo… lo más probable es que apenas contemos con un par de amigos y muchas ideas en la cabeza. Por esa falta de recursos, es vital que las personas que formen el proyecto se sientan identificadas con él, tengan mucho más que una motivación puntual, se entiendan y tengan los mismos objetivos / puntos de vista… Por ponerlo de forma un poco más descriptiva y a modo de esquema o listado,

• Más gente… un error. Este es un tema muy tratado en foros strateros. La verdad es que nuestra experiencia también lo confirma. Dice un dicho que “mejor pocos y bien avenidos, que muchos y con rencillas“. Cuando el núcleo que emprende aumenta, el porcentaje de “acciones” o de control disminuye de forma drástica. Es decir, más socios implican más trabas a la hora de tomar decisiones. En determinados proyectos, habrá necesidad de ser más gente… siendo conveniente definir cada “peso” de la persona dentro del grupo en las primeras reuniones de constitución.
• Subcontrata. En relación al punto anterior, ser más gente o tener a muchas personas al cargo es la mayoría de veces una desventaja, en el sentido de que habrá más escaqueos, será más difícil la coordinación, dirigir los matices de los proyectos…. contando con que sigan al pie del cañón y no abandonen a la mínima, dejando al grupo colgado. Una opción es derivar el trabajo que no podamos atender (porque no haya en nuestro equipo el perfil necesario, porque estemos saturados…), contratando a profesionales freelance o atrayendo a colaboradores que les guste el proyecto. En el segundo caso, si la calidad del mismo es buena, no debería haber muchos problemas para encontrarlos… aunque involucrar a alguien en tu proyecto es algo que siempre tiende a costar, sobre todo cuando no está montado y se tiene que confiar en la idea…
• Buen rollo! Tener un grado de amistad o apego especial con tus socios, puede llegar a ser un punto fundamental. Muchas horas, muchos quebraderos de cabeza, muchos líos…. todo se llevará mejor si hay ese feeling entre los compañeros y se trabaja en un clima sin tensiones ni disputas personales. No es mejor socio quién tiene más dinero, sino quién sabes que no te va a traicionar ni a dar problemas.
• Dream Team. En una empresa grande, no importará demasiado que haya alguna parte de ella que no funcione. En un equipo independiente, para ir progresando, que cada uno funcione engranándose en la rueda es también un aspecto vital. Por funcionar entendemos que el trabajo salga, que haya talento e ideas, disposición, ganas….

Después de todo esto, llegamos a una conclusión: no es fácil formar el equipo perfecto. Es muy posible que nos equivoquemos al elegir a nuestros socios, a nuestros colaboradores… en las decisiones a tomar respecto a ellos….. Sólo queda ir aprendiendo de los fallos y tenerlos en cuenta en el futuro. Y es que otro dicho dice que “la experiencia, es un grado“…

Artículos recientes relacionados:

• Gestión del tiempo
• El error positivo
• Ayudas públicas y subvenciones empresariales
• Vender juegos para iPhone
• Encuentro de emprendedores tras el FICOD 09