ES KAsi UN blog

Blog de Unkasoft, donde hablamos de programación de juegos para móviles, advergaming, marketing móvil, la industria de los videojuegos, metodologías ágiles y todos aquellos temas que nos preocupan en nuestro día a día

30 agosto 2006

SCRUM en Unkasoft: el sprint backlog

Ya hemos hablado en un par de ocasiones del sprint backlog.
Por un lado, durante la planificación del sprint, tenemos que confeccionar el sprint backlog, y por otro lado, durante el daily scrum, hay que ir actualizando su contenido.

La teoría la sabemos, pero... ¿cómo confeccionamos y actualizamos en Unkasoft este sprint backlog?

Nosotros nos basamos en la plantilla para sprints de SCRUM que publicó hace tiempo Juan Palacio (con algún retoque nuestro).
Estuvimos evaluando otras plantillas, pero no nos han convencido por ser demasiado complejas (y porque apostamos por los productos nacionales :)

En esencia, la plantilla de sprint que usamos nos hace las funciones de tablón virtual donde vamos dejando tarjetas de las tareas a completar y las vamos moviendo de sitio cuando están terminadas.
Durante el daily scrum, actualizamos cada tarea, apuntando las horas que quedan para completarla, y la propia plantilla nos saca gráficas de esfuerzo (que los ingleses llaman burndown charts).

Basicamente, la plantilla tiene tres secciones:

Configuración:
Damos varios datos del sprint que vamos a realizar, como el número de días que dedicaremos, número de horas de trabajo al día, tipos de tareas a realizar (codificación, reunión, pruebas, documentación, etc.), estados de cada tarea, integrantes del equipo o días festivos que tendremos durante el sprint.

Datos:
Aquí apuntamos las tareas que hemos ido extrayendo durante la planificación del sprint, apuntando la estimación en horas, el tipo de tarea.
Por cada tarea, a la derecha tenemos las horas que faltan para completarse en cada uno de los días del sprint. Así, si no se avanza en una tarea, veremos como sus horas no disminuyen, lo cual es una cosa mala.
Basándonos en ese total de horas y en la velocidad de desarrollo (un factor entre 0 y 1 que hemos añadido), podemos calcular la fecha estimada de cierre, distinta para cada día del sprint, para así ver si vamos a buen ritmo o llevamos retraso.
Otra cosa que hemos añadido es una columna con las horas reales dedicadas a cada tarea, que rellenamos cuando la tarea se termina. Aunque SCRUM no habla nada del control horas estimadas-reales (sólo controla las reales), nosotros lo necesitamos por temas de presupuestos, costes, etc.

Gráficos:
Por último, basándonos en los datos de esfuerzo de cada tarea, podemos sacar el famoso gráfico de esfuerzo (burndown chart) y otros gráficos para ver la evolución de las tareas, cómo fluctúa la fecha de cierre, o la carga de trabajo asignada a cada programador.

Sobre cómo interpretar estos gráficos, hay mucho que hablar. Aquí cuenta mucho la experiencia y la intuición (como en todo gráfico que se precie), aunque os recomiendo que leáis este post sobre los cinco signos de problemas durante una iteración. Nosotros creo que ya los hemos sufrido todos (:
También existen gráficos más complejos para gestionar de forma correcta las tareas introducidas a mitad del sprint.

Bien, esto poco a poco va llegando a su fin.
El próximo día hablaremos un poco sobre cómo combinamos eXtreme Programming con SCRUM.

Etiquetas: ,


22 agosto 2006

SCRUM en Unkasoft: el daily meeting

El otro día estuvimos hablando de cómo podemos organizar los sprints de SCRUM, dejando en el aire el tema de las reuniones diarias (llamadas daily meeting)

Antes de entrar en harina, tenemos que presentar a la figura del Scrum Master.
SCRUM propone los roles de "product owner", "equipo de desarrollo" y "Scrum Master".
El Scrum Master es la persona que conoce la filosofía y el modo de aplicar SCRUM en una empresa. No se trata del clásico "jefe de proyecto", sino que es uno más del equipo, al mismo nivel que los demás, aunque con tareas distintas.
Como ya hemos dicho, en los proyectos típicos de SCRUM se trata de una persona que compagina esta actividad con otras (puede ser habitual que el Scrum Master sea también el "product owner", o un programador más), aunque en proyectos grandes quizá pueda haber un Scrum Master a tiempo completo.
Es importante que el Scrum Master sea una persona con cierta capacidad de decisión en la empresa, más que nada porque quizá tenga que tomar algunas decisiones difíciles para que el proyecto llegue a buen puerto.

Bien, hechas las presentaciones, podemos decir que el corazón de SCRUM es la reunión diaria, (también llamada "scrum" en referencia al movimiento típico de rugby). La reunión es un momento en que todo el equipo de desarrollo pone en común sus avances, sus dudas, pide ayuda, etc. Con una reunión diaria nos evitamos las desagradables sorpresas a punto de cerrar la versión, ya que se va viendo el avance (o el "no-avance") día a día.

En varios equipos de desarrollo que conozco desde dentro, el jefe de proyecto va mesa por mesa preguntando el típico "¿cómo vas?", o el programador avisa al jefe cuando ha terminado una tarea.
Recordemos que en SCRUM, no existe ese concepto de "el jefe revisa", sino que, como estamos hablando de equipos autogestionados, es el equipo al completo (programadores como tú y como yo) los que van revisando el trabajo de los demás.
Además es importante que el equipo vaya viendo los avances del proyecto al completo, y no sólo de su parte. Esto crea un sentimiento de pertenencia e identificación, y este sentimiento podemos decir que es la gasolina de la metodología SCRUM. Sin sentirse identificado, el proyecto SCRUM al final se parará igual que un coche se para sin gasolina.
Todo esto me lleva a recordaros una vez más la regla de oro: no intentes aplicar SCRUM en cualquier empresa y en cualquier equipo. Elige muy bien la gente y el ambiente de trabajo.

La reunión diaria no debe durar más de 10-15 minutos, para evitar las típicas reuniones interminables, donde nunca se saca nada en claro. En nuestro caso la reunión es muy informal y dura 2 minutos (: ya que sólo estamos dos programadores en el proyecto.
Así que no hay excusas del estilo: "no tengo tiempo para reunirme", porque seguro que estás perdiendo más tiempo leyendo esta página.

SCRUM define un modus-operandi más o menos establecido. Durante la reunión, cada integrante tiene que contestar tres cuestiones:
  1. ¿Que hiciste ayer?
  2. ¿Que vas a hacer hoy?
  3. ¿Que necesitas para seguir?
En el blog del Jeff Sutherland (uno de los creadores de SCRUM), explica con detalle el porqué de estas preguntas:

¿Qué hiciste ayer?
Con esta pregunta se pretenden dos cosas:
  1. Que todo el mundo este trabajando en las tareas que él mismo se asignó. Como ya hemos dicho, SCRUM no funciona del modo tradicional en que el jefe de proyecto dice: "Fulanito, para la semana que viene tienes que tener terminada la tarea X", sino que cada desarrollador se asigna las tareas que cree que puede hacer mejor. Es posible que alguien "se invente" lo que ha estado haciendo. Sinceramente: es su problema. Cuando llegue el fin del sprint quedará en evidencia al verse que sus tareas no están terminadas y se verá que ha estado mitiendo durante todas las reuniones.
  2. Que todo el equipo vea como avanza el proyecto. Siempre viene bien para la moral ver como tus compañeros avanzan a buen ritmo en sus tareas, y el equipo se mueve a un ritmo constante hacia un objetivo común. Esto ayuda a que los rezagados se den más prisa y que los desmotivados se auto-motiven. Ojo, hay que distinguir cuando un programador está por debajo de su capacidad, tiene algún tipo de problema personal o cuando no le apetece trabajar más. Cada caso requiere de acciones distintas del Scrum Master.
    Hay veces en que los retrasos se deben a que el programador no es consciente de las consecuencias que acarrea un retraso en su código, y por eso se toma las cosas con más calma. Es natural y no suele ser culpa del programador: nadie se lo ha explicado y él no tiene porqué saberlo (típico en empresas con poca o nula comunicación). Con esta reunión se elimina este problema: todo el mundo es muy consciente cuando hay que correr porque se está esperando a que termine, o cuando las cosas se pueden tomar de una forma más relajada.
En este momento el programador actualiza el "sprint backlog" para reflejar el tiempo que queda para terminar la tarea con la que estaba (más adelante explicaremos cómo está organizado y cómo trabajar con el sprint backlog).

¿Que vas a hacer hoy?
En esta pregunta, cada integrante se asigna las tareas que más le gusten, dentro del sprint backlog. Ni el equipo, ni el Scrum Master deben obligar a nadie a hacer una tarea, sino que tiene que ser el propio programador el que elija la que quiere hacer. ¿Por qué? pues sencillamente porque nadie sabrá mejor que el programador las tareas que puede hacer mejor y más rápido. Por lógica, todo el mundo elegirá las tareas que le vayan mejor a sus habilidades y conocimientos, así que poco a poco las tareas se irán asignando de la forma más óptima sin intervención externa (teoría del caos en estado puro :)
Según avanza el sprint, van quedando pendientes las tareas que nadie ha elegido. En ese punto el Scrum Master pude sugerir, pero no obligar.
Hay metodologías que sugieren que las tareas con mayor riesgo deben hacerse antes que las de menor riesgo. Eso tiene su lógica, así que en caso de duda, deberíamos elegir siempre las tareas con mayor riesgo.

¿Que necesitas para avanzar?
Muchas veces, en las empresas tradicionales, las personas que están en puestos de responsabilidad olvidan su principal función: organizar y gestionar el entorno para que sus subordinados pueden trabajar en las mejores condiciones posibles (al fin y al cabo, se trata de maximizar el rendimiento del sueldo que se les paga). Sin embargo, muchos los jefes se quedan con la parte bonita, "organizar y gestionar", olvidándose de para qué se les ha dado ese "poder".

En esta pregunta, el programador lanza un aviso al equipo (y especialmente sobre los que más responsabilidad tienen en el equipo) sobre qué aspectos le tienen bloqueado o deben ser mejorados. El Scrum Master debe hacer lo posible por solucionar esos puntos críticos, aunque si algún otro programador tiene la solución al alcance de la mano, debería decirlo (siempre que haya un buen clima lo hará, pero si hay problemas entre miembros del equipo, no cuentes con que la ayuda surja espontáneamente).

Algunos problemas típicos son:
Algunos problemas puede que se resuelvan facilmente (por ejemplo, añadiendo nuevas tareas al sprint backlog), sin embargo, a veces las cosas se complican.

Si el proyecto está en apuros, lo habitual es que la lista de problemas sea cuando menos generosa. En ese momento, el Scrum Master debe ir recopilando esa lista en un "impediments backlog", o la "pila de problemas". A partir de ese momento, la prioridad del equipo no es avanzar en el "sprint backlog", sino hacer que ese "impediments backlog" desaparezca lo antes posible. Para ello se asignarán los distintos impedimentos a personas del equipo de desarrollo, o incluso a personas fuera del equipo (el administrador de red, el responsable de compras, etc.). Al día siguiente, se revisará tanto el "sprint backlog" como el "impediments backlog", eliminando aquellos impedimentos que se han solucionado, y pudiendose retomar las tareas del sprint que estaban bloqueadas.

Bien, y para terminar, pondremos un ejemplo más o menos gráfico de lo que sería una típica reunión diaria:

- Toñete: Bueno, que sepáis que ya he terminado con la refactorización de los renderizadores.
- Juancito: Perfecto, al final has tardado menos de que esperabas ¿no?
- Toñete: Sí, estaba inspirado y me ha salido de un tirón (:
- Perico (el Scrum Master): Genial, guardaremos esas horas sobrantes para el final del sprint, que nos harán falta.
- Toñete: Hoy voy a empezar a aplicar la aceleración por hardware, aunque la verdad es que no sé ni por donde cogerlo
- Juancito: Yo recuerdo haber leído algo en internet sobre el tema... dame un rato y esta tarde te envío algún código de ejemplo de la clase VolatileImage.
- Toñete: vale tío, muchas gracias. Cuando tenga tu código espero avanzar sin problemas.
- Juancito: Pues yo estoy atascado con el deshacer/rehacer. Está afectando a un montón de módulos y la verdad es que estoy un poco perdido entre tanta clase, herencia y métodos.
- Toñete: quizá te ayudaría usar alguna herramienta de modelado UML, más que nada para que veas las dependencias entre clases y cómo afectará tu cambio.
- Juancito: Sí, quizá sea buena idea... pero no sé cual usar ¿Rational Rose? ¿Together?
- Perico: Creo que en el otro departamento ya están usando alguna. Voy a preguntarles, y si vemos que nos viene bien, gestiono la compra de la licencia para nuestro departamento.
- Juancito: vale... pues entonces mientras consigues eso voy a intentar automatizar las pruebas en los teléfonos móviles.
- Perico: de acuerdo, voy a conseguirte unos cuantos teléfonos para que lo puedas probar en distintas marcas y modelos.
- Juancito: ok, entonces mañana os cuento a ver cómo me ha ido.

El próximo día trataremos el uso de la hoja de cálculo para gestionar el sprint backlog

Etiquetas: ,


19 agosto 2006

SCRUM en Unkasoft: el sprint

Continuemos con nuestra serie sobre SCRUM… tratando el tema de los sprints.

Para ponernos en situación, diremos que el sprint de SCRUM es más o menos lo mismo que la iteración en XP, aunque salvando ciertas distancias.

Podemos definir al sprint como el periodo de tiempo que tiene el equipo de desarrollo para implementar, documentar y probar un conjunto de nuevas funcionalidades (a este conjunto se le suele llamar “incremento”). Al finalizar el sprint, debemos tener una versión lista, empaquetada y con un bonito lazo rojo para entregar a cualquier cliente.

El sprint se divide en tres fases más o menos típicas:

1. - Planificación: una reunión del product owner junto con el equipo de desarrollo para:
2.- Implementación: una vez que tenemos el “sprint backlog” completado, podemos empezar el desarrollo. Se acuerda por ambas partes (product owner y equipo) que hasta que no se termine este sprint no se podrán “colar” nuevas funcionalidades. Si surge una nueva necesidad, se apuntará en el product backlog y en la planificación del próximo sprint se tendrá en cuenta.
Todos los días del sprint se hará una reunión (llamada “daily meeting”) del equipo para ir revisando cómo va el trabajo y actualizar el sprint backlog. El próximo día trataremos este tema.

3.- Revisión: una vez terminado el sprint, se reúnen el product owner, el equipo y cualquier persona interesada (por ejemplo gente de marketing, clientes, etc.) y se hace una demo informal de la nueva funcionalidad (llamada “incremento”). En esta revisión pueden surgir nuevas funcionalidades que serán apuntadas en el product backlog.

Por otro lado, se reúne el equipo de desarrollo consigo mismo, y saca dos conclusiones:
  1. ¿Que nos ha ido bien y debemos repetir?
  2. ¿Qué nos ha ido fatal y debemos mejorar?
Por ejemplo:
- Toñete: me da la sensación que en este sprint la hemos cagao con el tema de las pruebas de los nuevos renderizadores
- Juanín: sí, ha sido un infierno, pensé que no se acababa nunca.
- Toñete: en cuanto podamos deberíamos investigar cómo automatizarlo. Habrá cosas que no se puedan, pero seguro que hay alguna forma de automatizar aunque sólo sea una parte.
- Juanín: sí, lo apunto para colarlo en el próximo sprint.
- Toñete: por cierto, lo que sí que ha ido muy bien es el prototipo para probar lo de deshacer/rehacer
- Juanín: sí, menos mal que lo hicimos, porque yo no tenía ni idea como combinar los patrones Command y Memento. Una vez que tuve el prototipo, no fue más que aplicarlo al resto de casos.
- Toñete: pues para la próxima ya sabemos…

Bien, el próximo día hablaremos sobre cómo es el día a día de la implementación de un sprint y el "daily meeting".

Etiquetas: ,


16 agosto 2006

SCRUM en Unkasoft: el product owner

Ayer hablamos del product backlog, o en castellano: pila de producto. Bien, la persona encargada de llevar a buen puerto este documento es el que SCRUM llama product owner, o para nosotros el propietario del producto. En realidad no se trata de una persona tal cual, sino que estamos hablando de un rol, que en nuestro caso lo adoptamos dos personas a tiempo parcial (Jaime y yo mismo), aunque podría ser una persona a tiempo parcial (lo más habitual) o en proyectos muy grandes, una o varias personas a tiempo completo (ojo, SCRUM no encaja en proyectos grandes, así que si estás en este caso piénsatelo dos veces antes de empezar).

Bueno, pues el(los) propietario(s) del producto deben tener una visión clara del producto a construir (Jaime la tiene, y yo lo intento :), debe(n) saber bien qué se debe implementar, y sobre todo lo que NO se debe implementar.
Por cierto, suele ser más difícil de distinguir lo que NO se debe implementar, ya que parece ser que el 45% de las funcionalidades implementadas nunca llega a usarse. Por otro lado está la teoría del 80/20, donde dice más o menos (traducción libre de las mías):
A muchos desarrolladores les seduce la idea de la teoría del 80/20. Parece que tiene mucho sentido: el 80% de la gente usa el 20% de la funcionalidad. Así que te convences a ti mismo de que sólo necesitas implementar ese 20% de funcionalidad para seguir vendiendo el 80% de las copias. Por desgracia, no siempre es el mismo 20%. Cada usuario usa un conjunto de funcionalidades distinto. [...]
Pero esto es otra historia y debe ser contada en otra ocasión...

Bien, como decíamos, el product owner debe tener una idea clara de la dirección del proyecto, manteniéndo al día y priorizada la pila del producto. No se trata de pasarse meses analizando las necesidades reales y sacar la cojo-pila (también llamdo mega-análisis o super-especificación), sino trabajar unos días para sacar la cantidad de funcionalidad suficiente para cubrir la primera versión (algo que pueda funcionar), y a partir de ahí, añadir cosas.
Lo de siempre: el movimiento se demuestra andando.

Esta figura se parece más o menos al "cliente" que pregonaba eXtreme Programming, donde era la persona que colaboraba con el equipo en redactar las famosas historias de usuario, y que decidía lo que se iba a implementar en cada iteración de desarrollo.

Una vez que la versión está implementada, el propietario de producto la revisará para ver si ha cumplido con las expectativas que él tenía sobre ella... es decir: ver si las funcionalidades que él propuso como útiles y necesarias, realmente lo son (que a veces no lo son).

Cuando el propietario del producto tiene su pila más o menos preparada, colaborará con el equipo de desarrollo para definir la pila del sprint... así que ya tenemos carrete para el próximo día, donde hablaremos de los sprints (:

Etiquetas: ,


14 agosto 2006

SCRUM en Unkasoft: el product backlog

Bien, una vez hecha la introducción, vamos a tratar los distintos aspectos de SCRUM, siempre explicando cómo los hemos abordado en Unkasoft y qué problemas hemos tenido (y seguimos teniendo) a la hora de usarlos.

El primer elemento que tratamos de implantar fue el Product Backlog, o pila de producto: se trata de una lista de funcionalidades que debe llegar a tener el producto que estamos desarrollando. En teoría, cuando implementemos todas esas funcionalidades, el producto estará acabado (ya, a ver cuando llega eso, porque yo no lo tengo claro).

Este paso a sido fácil para nosotros, porque hace tiempo que usábamos un documento (que llamábamos "problemas a resolver") donde íbamos apuntando todas las cosas que nos gustaría que tuviera Battlewizard. Este documento lo íbamos ampliando con nuestra propia experiencia, peticiones del departamento de QA, o de empresas que están usando Battlewizard (como nuestros early adopters GPM-e y Karonte).
Adaptarnos a SCRUM a sido tan sencillo como convertir el documento en una hola de cálculo, incluyendo los títulos de las nuevas funcionalidades y con una explicación breve en forma de comentarios. En la propia hoja de cálculo hemos organizando las características en cuatro categorías conforme a la urgencia de implementarlas: muy alta, alta, media y baja.

¿Y para qué nos está sirviendo esto? Pues sencillamente para no olvidarnos de nada y para tener un sitio de consulta cuando queramos saber qué hay que hacer y qué es más urgente. Además, este documento es el punto de partida a la hora de planificar una versión.
Una vez que hemos implementado una característica, la borramos de la pila de producto, y así poco a poco va decreciendo (bueno, en realidad no ha parado de crecer desde que la hemos creado, añadimos más funcionalidades de las que nos da tiempo a implementar, pero con el tiempo y una caña... :)

La persona encargada de mantener este documento es el llamado "propietario del producto" ("product owner") y su función es... bueno, creo que ya está bien por hoy, así que el próximo día hablaremos del propietario del producto...

Etiquetas: ,


11 agosto 2006

SCRUM llega a Unkasoft!

Este verano está siendo movidito.
Estamos restructurando el equipo (alguno ya han llegado, y otros están por venir), salida a la calle de dos juegos más (todavía no podemos decir nada sobre ellos pero pronto publicaremos algo aquí sobre ellos) y probar una nueva metodología de gestión de proyectos: SCRUM.

Hace ya tiempo veníamos usando eXtreme Programming como metodología de desarrollo, sobre todo en el equipo de Battlewizard, pero la parte de planificación, gestión y seguimiento de los proyectos la teníamos un poco descuidada. Así que con la ayuda de Juan Palacio nos hemos puesto en marcha y ya vamos por nuestro sexto sprint (:

¿En qué consisten SCRUM? Pues es una metodología de autogestión de equipos, es decir: no hay un jefe que ordene y los demás obedezcan, sino que el propio equipo es el que tiene que auto organizarse.
Bueno, esto de promulgar la autogestión está muy bien, pero tienes sus problemas. No intentes aplicar esta metodología en cualquier sitio, porque yo conozco algunas empresas y algunas personas con las que esto sería un fracaso asegurado.

Justo hace un par de días Joel Spolsky ha publicado unos artículos sobre gestión de equipos, y en ellos cataloga los tipos de gestión típicos las empresas en tres: (como siempre, te recomiendo que lo leas porque no tiene desperdicio):
Así que el primer consejo: no intentes aplicar SCRUM en cualquier sitio. Primero haz que se respire un clima adecuado y cuando tengas el caldo de cultivo, todo será más fácil.

A continuación tenéis nuestra experiencia sobre algunos elementos de SCRUM que estamos usando en nuestro trabajo diario:

Etiquetas: ,


10 agosto 2006

¿Quién gana la partida en los juegos móviles?

Durante los años 70 y 80, las compañías definieron sus estrategias con base en ideas de grandes “gurús” como Kaplan y Norton, quienes marcaron objetivos exponenciales de crecimiento basados en economías de escala. Todos estamos de acuerdo que el mercado de los videojuegos es muy goloso, pero ¿quién se llevará al final el pastel?

Me he tomado la osadía de crear un mapa estratégico –inspirado por toda la info de América-, que indique gráficamente los siguientes comentarios. La principal idea es compartirlo, que sea útil a todos los que quieren participar –para los escépticos de estratégica distinta a la pura competición leed el siguiente post sobre 'Strategy of the Dolphin' -
Todo esto lleva a una visión, ser un referente en la producción de juegos móviles y diferenciarse no por coste. Aunque suene cliché, lo que importa no es la cantidad sino la calidad. Al final con todo ello lograremos crear valor a los que confiaron e invirtieron en nosotros.

Etiquetas:


01 agosto 2006

La diferencia entre el fracaso o el éxito con los videojuegos móviles

Hablando con varios desarrolladores de videojuegos para móviles siempre terminamos haciéndonos la misma pregunta: ¿Cuál es la diferencia entre el fracaso y el éxito con los videojuegos para móviles? Finalmente, el mercado y las limitaciones técnicas responden a esa pregunta con bastante frialdad.
Hoy en día el éxito pasa por lograr destacar con alguno de los videojuegos desarrollados, donde destacar debe definirse como un éxito de ventas que sobresalga respecto al coste de producción.
Si seguimos al mercado, debemos buscar los éxitos de ventas entre las marcas conocidas y de moda, y lógicamente el ahorro de costes de producción se basa sobre todo, dentro de este mercado, en la deslocalización de los recursos humanos encargados de portar cada juego a cada tipo de teléfono móvil. El éxito consistiría entonces en tener una marca conocida y de moda, desarrollar un videojuego sobre dicha marca y tener un coste de producción bajo. El fracaso entonces debería considerarse como la falta de marca y una imposibilidad de portar los juegos a muchos móviles de manera asequible.
Como mensaje del mercado y de las limitaciones técnicas es una respuesta asumible y lógica, pero no es suficiente para nosotros. Vamos a cambiar el concepto de éxito introduciendo nuevas variables. Ahora creemos que el éxito, pasa por automatizar el proceso de portar los videojuegos entre los teléfonos móviles, un coste casi nulo, y el disponer de juegos divertidos, simples y fáciles de manejar. Buscamos la comodidad del desarrollador, del distribuidor, del agregador, del operador y en definitiva la diversión del jugador. Si somos capaces de hacer y empaquetar un juego divertido en dos semanas con un coste de producción de unos 2.000 €, y luego tenemos ingresos en unos quince países por un valor total de unos 10.000 €, entonces habremos logrado un éxito, porque habremos obtenido una alta rentabilidad.
No hace falta abocarnos a la marca de éxito, sino adaptarnos a la capacidad del mercado para pequeñas empresas como nosotros; debemos automatizar procesos y crear en paralelo los videojuegos. 10 Juegos casuales al mes para un catálogo de empresa, obteniendo unos 10.000 € como objetivo por videojuego y teniendo unos gastos medios de 2.000 € por juego, harán del pequeño desarrollador una empresa de éxito.
Esto no quita disponer de personal creativo que sea capaz de hacer juegos llamativos y divertidos. Si no tenemos presupuesto para publicidad, dejémoslo a los distribuidores y agregadores, por poco que distribuyan y se muevan, algunas descargas obtendremos y podremos rentabilizar el trabajo.
Seguimos apoyando los juegos de calidad, de marcas conocidas haciendo calidad, pero mientras una pequeña empresa es capaz de hacerse con un juego de calidad y con marcas conocidas y de moda, ha de generar catálogo y generar ingresos. Automatizad los procesos o pedid ayuda a los que los estamos automatizando, es parte del camino para avanzar en este mercado.
El éxito total, será sacar videojuegos de marca con un coste asequible de producción.

Etiquetas:


This page is powered by Blogger. Isn't yours?