Todavía le falta algo (dos “cositas”, en realidad) para llegar al “MVP corregido” (el “minimum viable product” redefinido después de haber subido lo que yo creía que era el minimum). Nadie me hizo llegar nada al respecto. El uso es la intersección entre la promoción y la necesidad, y uno sólo puede controlar el primer término. Sin necesidad, la gente juega un poco y listo. Si gusta se agenda el link para después. Está muy bien, pero no es “uso”.
¿Qué hubo entre esos dos MVP’s, además de esas “dos cosas”? ¿En qué cosas ni siquiera había pensado?
Le pongo Analytics y listo.
… no. Analytics está muy bien tal cual sale de la caja, pero se queda muy corto. Permite ver el impacto de un post, de facebook, de tweeter, del mail, pero nada más. ¿Y el uso? ¿Se usa el upload de esquemas? ¿El login con google? ¿El preview de datos? ¿La ayuda?
El event tracking no es difícil de implementar. Lo difícil es determinar qué trackear (qué acciones) cuando uno ya tiene todo desarrollado. Lo que no se trackea no se ve. Trackear un par de eventos y dejar por error dos o tres afuera implica tener una visión muy sesgada del uso. Si lo hubiese pensado desde el principio, agregándolo a medida que se desarrolla la funcionalidad, afinándolo desde el momento 0…
No, no es “demasiado para un MVP”. Saber hacia dónde dirigir el segundo paso es tan importante como dar el primero. Pero hay un argumento determinante por el cual no se puede dejar para después: recolectar un volumen de datos relevante lleva –con suerte- semanas.
Try-catch-mail alcanza, y por las dudas logueo todo.
Me mando un mail con la excepción y ya está bien para empezar, con eso ya sé dónde buscar en el log. No, tampoco. Cortísimo.
Ok, hubo un error. ¿Quién? ¿Haciendo qué? ¿Qué datos de entrada? ¿Qué valores de salida? Los errores que pueden corregirse mirando un stack trace se agotan rápidamente. Después… las cosas se vuelven más complicadas. El “log viewer” de la consola de GAE es por lo menos “rústico”. Excederse por más y generar 1Gb de log por día está bien cuando podemos comprimir, descargar el archivo y procesarlo tranquilamente, pero no es el caso. Una posibilidad es recolectar parámetros de entrada y valores de salida de todas las funciones pero loguearlos sólo cuando hay un error. O afinar el log para cada operación, o guardar los errores aparte, en la base… Lo que sea, pero no es tan simple como un try-catch-all.
Cada error es un usuario–casi-perdido, y usuarios no sobran.
Malditos celulares.
¿Para qué miércoles quiero dar soporte a celulares en un data generation tool? Si, que se pueda ver… pero no importa si no es usable, no es una aplicación que tenga sentido en un smartphone. Y en la primera versión ni eso, que se vea como se ve. Total foundation ya ayuda bastante sin que hagamos nada.
Error. La aplicación no se usa en un smartphone… pero el 50% (50% medido, no es un decir) de los usuarios entra por primera vez desde uno. ¿Por qué? Y… si promociono por twitter y facebook… ¿qué esperaba? No esperaba nada - señal de que estoy viejo.
No tiene que ser usable, pero es indispensable que sea “probable”, “jugable” o al menos “agendable”. Como mínimo –muy mínimo- que puedan decir “ok, avisáme después.
Lo ideal sería que se pueda jugar un poco, abrir una cuenta y grabar. Bueno… más trabajo (y esto no está incluido en “las dos cosas”).
Consola de administración.
Paráaaaa… ¿un backoffice para un data generation tool? Si.
Estoy usando objectify. Muy lindo, muy rápido el desarrollo de todo, pero… el acceso a datos desde la consola es incluso más rústico que el log. Lo que objectify graba ya es bastante difícil de leer… Si un error “rompe” la cuenta de un usuario (se graba algo y luego le da error cada vez que entra) estamos al horno: corregir esa especie de “assembler de datos” es demasiado peligroso o directamente imposible (ni lo intenté).
Guste o no hay que hacer una página de administración donde podamos ver la data en forma prolija y modificarla si es necesario. Y no podemos empezar a hacerla sobre el hecho de que ya hay alguien que no puede entrar a su cuenta. Y también va a tener sus errores.
Y todo lo demás.
Y, finalmente, las “dos cosas” de las que hablaba al principio. Esas son las únicas dos funcionalidades propias de la aplicación de toda esta lista. Pero no voy a decir cuáles son. Talvez ni hagan falta.
Una buena
Son cosas simples (aunque no “tan simples”) si se las tiene en cuenta desde el principio. Bueno, para esto era, ¿no?
La eterna batalla, la eterna duda: ¿Debería ser una aplicación desktop o un servicio web? Para mí no hay dudas: allí donde una conexión entre cliente y servidor esté disponible, web, y no se hable más. Pero es sólo una opinión de programador fundada exclusivamente en mis gustos y preferencias a la hora de construir el software. 
Silencio de radio estos días, ¿lo notaron? Tal vez sí –eso espero-, ya que corté un período de extrema verborragia que abarcó las últimas semanas, aunque –reconozco- con más relleno que ideas.
No son todos 
Rara vez es explicitado en manera alguna –decía- y cuando lo es –cuando pretende serlo- se materializa en forma de frases de compromiso que rara vez tienen que ver con la cosa real que dicen reflejar. Es un poco como la visión a la que tanta importancia le dan las normas de calidad: pocos saben qué es y de poco sirve saberlo -salvo para certificarse en algo- pero no se puede tener éxito sin ella. Análogamente, los negocios exitosos no son los que saben qué es un paradigma sino los que tienen un paradigma exitoso. Siempre es bueno racionalizar, poder poner en palabras, explicitar, pero lo indispensable es tener qué explicitar.
Para los que han tenido esta experiencia -como parte de una visita formal o no- ha sido casi reveladora. Día a día, inevitablemente y de forma intuitiva, encerrados tras una muralla de código, los programadores derivan, imaginan, se forman una imagen del negocio para el cual programan. Lo hacen a partir de los requerimientos, del diseño propuesto para las pantallas, de las funcionalidades. Pero es muy difícil que esta imagen, condicionada por su experiencia y sus propios paradigmas, coincida con la realidad.
