Todo lo demás.

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?

El origen de la comunicación.

La comunicación dentro del desarrollo de software es un tema recurrente en este blog (artículos sobre comunicación). La principal razón de ello es, simplemente, que desarrollar software es comunicar (Del desarrollo de software como sistema de comunicación...).

Trabajamos en un mar de mensajes orales, escritos, gestuales. En castellano o inglés, expresados en diagramas y gráficos o como lenguajes de programación, y de diferentes fuentes (humanas, mecánicas, informáticas). Las acciones y decisiones que tomamos y percibimos son también mensajes.

Participar de la comunicación hace a cada integrante del equipo. No puede calificarse como tal quien no logre entender los objetivos. No se integra un equipo con estar ahí físicamente, hay que decodificar los estímulos que se reciben en ese ambiente en un sentido similar al de los otros integrantes.

Para un líder la comunicación es todo. Donde la coerción física es bastante infrecuente (digo bastante...) la comunicación hace al líder. No lo será el más fuerte ni el más capaz ni el más viejo ni el más sabio. Será aquél que transmita mensajes que lleven a los demás a seguirlo.

Usualmente vemos un gráfico parecido a éste:

Tomemos un elemento: el mensaje es “el conjunto de señales, signos o símbolos que son objeto de una comunicación”. Pero en la vida real, ¿quién dice qué estímulos son señales, signos o símbolos, y cuándo conforman un mensaje?

A la derecha del escritorio de X está el cubículo del líder de proyecto, al que puede ver ya que está definido por una separación transparente. Está visiblemente molesto mientras conversa con el líder técnico, y cada tanto levanta la vista en dirección a X. En un momento señala directamente a X, quien entiende que están hablando de él, a cerca de un grave incidente del fue responsable, y espera lo peor.

Se ha cerrado un circuito de comunicación: el líder de proyecto envía mensajes gestuales que X interpreta. ¿No?

El líder de proyecto está molesto porque han recortado casi un cuarto de su presupuesto. Descarga su furia conversando con el líder técnico, un viejo amigo. De vez en cuando levanta la vista y queda mirando al vacío al recrear los detalles de la reunión. El recuerdo lo enfurece. Apuntando hacia donde -en su recuerdo- se encuentra el gerente general, dice: “Es un verdadero imbécil”.

¿Esta última aclaración invalida la comunicación anterior? ¿El mensaje recibido por X no fue real? ¿Cómo puede X saber eso? ¿Y si no fue real, qué fue?

La decodificación de un mensaje y su interpretación es un fenómeno que hace al receptor, lo define. Somos receptores si -y sólo si- recibimos mensajes y lo somos sólo fugazmente durante el momento en que lo hacemos.

Pero por otro lado es el receptor quien decide qué es un mensaje y qué no. También decide si va dirigido a él y cómo se decodifica. En nuestro ejemplo X decidió que el gesto del líder iba dirigido hacia él, y decidió también su sentido al decodificarlo.

Así que nos convertimos en receptores a voluntad, incluso con independencia de la existencia real de un emisor con intención de dirigirse a nosotros. Basta con tomar cualquier estímulo e interpretarlo (¿o incluso el estímulo es innecesario?).

Pero este proceso de creación del mensaje que hace de una persona un receptor no es, habitualmente, aleatorio. Si así fuese la coordinación -si no la vida misma- sería imposible. Si no interpreto la luz roja del semáforo como un mensaje dirigido a mí que indica que no cruce la calle, probablemente no dure mucho en una ciudad moderna.

A través de un proceso (de aprendizaje, enseñanza, prueba y error) que comienza con nuestro nacimiento, filtramos estímulos y creamos mensajes cada vez más ajustados a la forma en la que necesitamos reaccionar para sobrevivir. Este proceso se vuelve tan automático que ni nos percatamos de ello.

Es decir, hemos aprendido a interpretar lo que nos rodea no de acuerdo a una realidad objetiva (si es que tal cosa existe), sino de acuerdo a nuestras necesidades de supervivencia (¡esto es duro de tragar!). 

Para sobrevivir necesitamos reaccionar especialmente a lo que un emisor intenta transmitirnos deliberadamente, y por ello somos muy buenos en detectar eso.

Pero de vez en cuando se produce un equívoco. El efecto de encontrarse con un malentendido (por ejemplo cuando X se entere de que no estaban hablando de él) es parecido al que nos provocan las ilusiones ópticas: nos revelan que nos movemos en un entorno que nosotros mismos estamos creando a partir de los estímulos que recibimos, y que nos podemos equivocar.

Pero volvamos a lo laboral. Lo anterior supone un problema, y uno grande. Desde el punto de vista de un líder, por ejemplo, es imprescindible asegurarse de que lo que dice se interprete en determinado sentido.

El lenguaje, los estudios y la experiencia compartida ayudan pero no aseguran. Si hay que transmitir la definición de un sistema administrativo un cursograma aportará un lenguaje preciso… dependiendo del grado de conocimiento de éste que tenga el receptor.

La única forma es el feedback (lo que puede pasar en su ausencia: Pedrito (el líder de proyecto) y el lobo: la importancia del feedback): el receptor devuelve el mensaje al emisor y éste lo confirma.

A mayor experiencia (más tiempo, conocimientos y vivencias compartidas) menor necesidad habrá de este tipo de “feedback de confirmación”.

Notemos que esto no soluciona nuestro ejemplo. ¿Cómo confirmar un mensaje que no se ha enviado? Si el emisor (el líder de proyecto) no es consciente de la interpretación de la que han sido objeto sus señales (por parte de X) no tiene forma de corregirla.

Este último caso es insalvable. Y todos lo sabemos. X tiene “cola de paja”. En la oficina está el paranoico que cree que lo van a echar. Y el que no sabe que está en la cuerda floja. Y el que se siente galán de la oficina. Y el jefe que se cree respetado y obedecido. Y el que cree que son todos haraganes. Todos “nos creemos” porque, finalmente, hemos construido nuestro mundo interpretando a nuestro antojo los estímulos que… ¿recibimos?

Def: Sistema

Imperdonable no haber comenzado las definiciones con la más básica de todas.

Sistema: Conjunto de partes o elementos organizadas y relacionadas que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida) información, energía o materia.

Extracto de la entrada para sistema del diccionario de Alegsa. Les recomiendo darle una leída a la entrada completa.

El desarrollo de software como sistema, y nosotros adentro.

Un emprendimiento de desarrollo de sistemas puede encuadrarse en infinidad de teorías, modelos, directivas, recetas. La teoría de sistemas ofrece la gran ventaja de ser conocida por la mayoría de los involucrados (o por lo menos debería serlo). Al fin y al cabo, en un emprendimiento de desarrollo de sistemas estamos desarrollando exactamente eso. El emprendimiento es un sistema (administrativo) que desarrolla sistemas (de computadora).

Ok. Este sistema es una secuencia E-P-S-R: Entrada-Proceso-Salida-Retroalimentación. ¿Les suena? En informática describimos casi todo de esta manera: algoritmos, software, hardware, negocios. ¿Por qué no describir así el proceso de desarrollo? ¿No es acaso un "negocio" como cualquier otro?

Utilizamos entonces la misma secuencia de que utilizaríamos para analizar cualquier requerimiento: establecer la salida (qué es lo que el sistema debe hacer), la entrada (qué necesita para hacerlo), y luego abrir esa caja negra llamada proceso (cómo lo hace).

En nuestro caso la salida (del sistema de desarrollo de software) es un sistema compuesto por piezas de software, hardware y documentos orientados a una tarea específica. En la entrada del sistema tenemos los requerimientos del usuario, palabra santa. Y en el proceso tenemos todos los subsistemas necesarios para transformar una lista de requerimientos en software, hardware y documentación: analistas, programadores, líderes de equipo, líderes de proyecto, testers, expertos en base de datos, expertos en infraestructura... Pero también, y esto es algo que en general no se tiene muy en cuenta: personal de ventas, de atención al cliente, de facturación, de recursos humanos. Tenemos computadoras, redes, software de desarrollo de todo tipo (para el análisis, entornos de programación, compiladores, versionado), software de administración de base de datos... Pero también tenemos software de administración de todo tipo (ventas, facturación, atención al cliente, pago de sueldos), un lugar físico, escritorios, cafeteras (espero), plantas (donde yo trabajo no), baños (sí, eso sí tenemos, pero...), personal de limpieza... la lista es interminable, pero la idea final ya tiene que haberse entendido: tenemos una empresa, grande o chica, miles de empleados o dos amigos programadores con un cliente ocasional, con todo lo que ello representa.

Para la descripción del proceso de desarrollo se han escrito selvas enteras de papeles, y llenado varios gigas de información. Las teorías y procesos tradicionales pueden resumirse en una secuencia de: análisis, diseño, construcción y pruebas (todo en uno), implementación. Con sus variantes, por supuesto. Luego tenemos una infinidad de variantes iterativas: en esperial, escalonadas en tirabuzón o calesita, todas ellas repiten de alguna manera la secuencia arrojando porciones del producto final en cada iteración.

Pero falta algo... dijimos entrada, proceso, salida... retroalimentación. ¿Dónde está la realimentación en un sistema de desarrollo de sistemas? Empezemos por el principio: ¿Qué es la retroalimentación en este contexto? Voy a tratar de atrapar la idea: una vez que un proceso de desarrollo alcanza cierta madurez, puedo examinar el resultado con el ánimo de mejorar el proceso. Retroalimentación implica que la salida de un sistema lo modifica. En todo desarrollo se examina el resultado (el software, por ejemplo, o los documentos) y se habla de control de calidad, excelencia, 0 defectos... pero no es esto de lo que hablamos aquí. Podemos tener un producto excelente en tiempo y forma y clientes satisfechos, pero al mirar hacia atrás nos damos cuenta de que hemos atravesado un infierno para llegar a ello: requerimientos contradictorios, problemas con los equipos, tiempos muertos, personal inexperto... ¿Qué importa, si al fin y al cabo el producto es bueno y el cliente está contento? Dirección por resultados, que le dicen.

Ok. Los resultados son indispensables. Sin resultados no hay desarrollo... pensemos un poco en esto. Si no hay desarrollo sin resultados entonces no hay empresa de desarrollo sin resultados... entonces... Todas las empresas y emprendimientos existentes brindan resultados. Algunas brindan mejores con mayor frecuencia. Pero si no lo hicieran no sobrevivirían. Es la lógica darwiniana de cualquier mercado. Así que tenemos que mejorar el proceso para competir.

Pero lo más importante: nosotros como personas somos parte del proceso, estamos dentro de él. Digo, nuestro trabajo (analista, programador, administrador de base de datos, el que sea) ocupa buena parte de nuestro tiempo, y no es sostenible sólo por los resultados. Puedo ganar buen dinero y estar contento con las felicitaciones de mi cliente... mientras me repongo de mi pico de estrés, de mi ataque cardíaco, o simplemente mientras duermo las 72 horas que tengo atrasadas o trato de recordar el nombre de alguien de mi familia, etc.

Muchas veces, cuando al final "todo" sale bien tendemos a creer que hicimos bien las cosas, y puede estar pasando una de dos: los problemas están por venir (muy probable) o en algún momento alguien lo hará mejor. Pero incluso si eso no se da y todo sigue bien... podríamos hacerlo con menos esfuerzo que y dedicarlo a cualquier cosa que nos guste (no necesariamente trabajar).

Conclusión: como profesionales, como personas, nuestro interés está en la retroalimentación positiva a partir no sólo de los resultados sino de examinar cómo hemos atravesado el proceso. El buen producto mejorará más o menos la vida del cliente, pero la retroalimentación mejorará la nuestra.