jueves, 26 de marzo de 2015

Jugar en serio.

Desde hace un tiempo vengo jugando con la idea de “desarrollar productos”.

En mi universo de fantasía, mi cabeza bulle con innumerables ideas para SaaS (Software as a Service).

Todos los días (de mi universo de fantasía) se me ocurre una idea, y son todas geniales.

Las voy anotando. Cada tanto elijo una y la desarrollo hasta llegar al MVP (Minimum Viable Product). La implemento (así de fácil y divertido, con una sola palabra, una única acción) como servicio gratuito.

La promociono (otra acción puntual, única, instantánea) utilizando “círculos concéntricos”: empiezo con un grupo reducido de usuarios y, a través de prueba y error voy depurando, limando asperezas, agregando detalles. Una vez agotadas las correcciones (porque se agotan) paso a un círculo de promoción más amplio y vuelvo a empezar.

El desarrollo es incremental, constante, continuo. La base de usuarios se expande. Se genera el feedback suficiente para determinar funcionalidades por las que un subconjunto de ellos estaría dispuesto a pagar (subconjunto que existe y cuyo tamaño es directamente proporcional a la cantidad de funcionalidades, por supuesto). 

Cada usuario paga poco, muy poco. Digamos siempre menos de “10” (dólares, pesos, yenes… no sé, no importa), pero por mes. La cosa “pega” y alcanza un cierto nivel de tráfico, y complemento ingresos con publicidad.

Y ya es hora de dejar este producto estable, tomar otra idea y volver a empezar. La mayoría de los proyectos no llegarán a tanto, pero algunos pegarán, aunque sea mínimamente. Entre todos van dejando un nivel de ingreso que se vuelve razonable en un futuro a mediano plazo.

Me gusta esa sensación de vuelta a lejanas épocas en las que me sentaba en la Atari 800XL y programaba cualquier cosa que se me viniese a la cabeza por el gusto de hacerlo y nada más, plus reconocimiento social (¡los usuarios me adoran!) y monetario.

Eventualmente la pego con algo y vendo algún desarrollo por 7 u 8 cifras. Hago donaciones a proyectos filantrópicos y con el resto me dedico a recorrer el mundo en mi avión privado (con barra). Están invitados.

… y después suena el despertador y tengo que levantarme a trabajar.

Y mientras trabajo pienso que no parece tan fantástico. Parece realizable, incluso fácil.

Por suerte soy bastante escéptico, sobre todo con mis propias fantasías. Otro thread (el pesimista) levanta una interrupción y dice que si fuese tan fácil y divertido todo el mundo lo estaría haciendo (y con éxito). Muchos lo hacen y les va bien (se despierta el primer thread –el optimista-). Son el emergente (responde el pesimista), la punta de un iceberg de proyectos hundidos por los pocos recursos (tiempo, dinero), las malas ideas, las malas ejecuciones, la mala suerte… la puta vida de mierda (y siguen discutiendo en un abrazo mortal).

¿Una fantasía irrealizable o un modelo sustentable? Sólo hay una forma de saber.

Así que me decidí a jugar en serio. Agarré la idea menos prometedora y más divertida y me comprometí a llevarla a través de todo el recorrido, desde el MVP hasta la primera versión hasta la base de usuarios y de ahí hasta donde se pueda.

¿Por qué “la menos”? Para bajar expectativas. Para no desilusionarme ante la falta de éxito inmediato. Y para cometer todos los errores posibles con una idea que ni es original ni vale tanto ni es taaan difícil de implementar, porque (en la vida real) ideas no me sobran y cuando tenga otra (en realidad… no tenía ninguna otra), espero que mejor, no quiero quemarla en un proceso de aprendizaje desde 0.

No es el proyecto en sí lo que importa sino el camino recorrido, los errores cometidos, la experiencia de hacer por uno mismo todo aquello que antes hacían otros miembros de un equipo u organización: la definición, las pruebas, la promoción, el seguimiento, el jiu jitsu comercial y otro montón de cosas que ni siquiera sé que hay que hacer.

En eso estuve estos meses. Algunos de “ustedes” (supongo que somos más o menos  los mismos lectores de siempre) saben de qué la va. La mayoría no y por ahora vamos a dejarlo así, porque estamos en la etapa de los “pequeños círculos concéntricos”.

“Sabía” que la construcción de un sistema es apenas una parte de la cosa. Ahora sé que lo que “sabía” y lo que “sé” va entre comillas.

Una cosa es saber que hay que definir un MVP y que eso es “difícil”, a tratar de hacerlo y darse cuenta de que es MUY difícil.

Una cosa es saber que un proyecto compite con otros y con la necesidad de ingresos, y otra la tentación constante de dejarlo “hasta acá, total para prueba ya está bien” y volver a terreno seguro.

Una cosa es saber que es difícil atraer usuarios y otra estar sentado delante de la pantalla, con el sistema “a disposición de la humanidad toda” y… “¿y ahora qué?” La humanidad está ocupada en sus propias cosas.

Una cosa es saber que hay que hacer networking y otra no tener nada importante para escribir o no tener ganas de sentarse y escribirlo o tomarse el esfuerzo y que no suceda nada (que por otro lado es lo más probable) y juntar los pedazos para probar otra vez.

Y en cada paso hay errores y torpezas y un millón de piedras puntiagudas para pisar.

Termino con lo que quería empezar (se suponía que iba a escribir un solo párrafo de introducción a esto que sigue, pero bueno…): un punteo de lo nuevo que, más que aprender, “sentí en carne propia” durante estos meses.

  • “No sabes nada, Jon Snow”.
  • Uno define un producto en documentos y palabras y bocetos de pantallas y eso está más o menos bien… pero hasta cierto punto. Los documentos iniciales quedan rápidamente en el olvido. No vale la pena dedicarles mucho tiempo ni bajar mucho al detalle: el objetivo principal de la aplicación, un boceto así nomás de “la pantalla importante” y listo. El objetivo no es elaborar el documento sino la idea.
  • Personalmente, no funciono muy bien con el micromanagement del tiempo. Me entusiasmo por momentos, me desinflo por momentos. Es mejor respetar eso, pero manteniendo un balance: Hay que hacer algo todas las semanas, aunque sea forzado, y no dejar nada colgado mucho tiempo. 
  • Sí me funciona bien el establecer una meta a corto plazo: “lo próximo que hay que hacer es…”
  • Un dashboard es imprescindible. No puedo dejar de recomendar Trello.
  • Medir las horas es imprescindible. No puedo dejar de recomendar Toggl.
  • Definir y respetar hasta dónde llega el desarrollo para la primera implementación. A rajatabla. Y cumplirlo. A medida que voy armando la pantalla se me ocurren 10.000 formas mejores de hacerlo, sólo por contraposición con los problemas que veo en el armado actual… Pero esas otras formas también van a tener problemas y llevar a otras soluciones y… así no terminamos más. Se define la primera implementación, se hace y después vemos.
  • Después de un par de meses de desarrollo, la idea original puede parecer una mala idea. ¿No debería empezar de nuevo? No. Así como hay que probar que es una buena idea, también hay que probar que es una mala idea antes de dejarla por el camino. Y para eso hay que implementarla.
  • Otra vez (y van tres): respetar el MVP a rajatabla. Escribir en el backlog es muy terapéutico para descargar tensiones. 
  • Pero ojo, el backlog puede convertirse en una bolsa de gatos muy rápidamente. Hay que mantener el orden, priorizar, jerarquizar, descartar, agrupar, dedicarle un poco de tiempo cada vez, pero constantemente. Es un embole, sí.
  • Con el primer usuario cambia absolutamente todo. Lo que parecía usable es obvio que no, las buenas ideas resultaron malas y la sensación general es, otra vez, la de que esto no va a ningún lado (un pensamiento recurrente). Hay que perseverar, corregir y mejorar sin torcer el rumbo, resistir la tentación de “barajar y dar de vuelta”.
  • Después de la primera implementación se acabaron las ideas, hay que seguir a los usuarios: se arregla o mejora lo que se usa, se implementa lo que nos reclaman. Primero hay que hacer que funcione, pero después todo se trata de que se entienda y se use, y eso es mucho más difícil.
  • Y si nadie lo usa y nadie reclama… insistir con el autobombo y la promoción.
  • Y si nadie lo usa y nadie reclama (después de un tiempo)… bueno, ahí quedó.
  • … pero meter un feature que nadie quiere de vez en cuando sólo porque es divertido mantiene el entusiasmo.
  • En resumen: POCO de todo para la primera versión: pocos documentos, poca funcionalidad, poco código, poca complejidad, poco riesgo, poco tiempo perdido.
  • Salvo paciencia. MUCHA paciencia.


sábado, 21 de marzo de 2015

The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

hughMcLeodCompanyHierarchy compLifeCycle

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

sábado, 7 de febrero de 2015

8192

Si se preguntaban (no creo que se estuviesen preguntando, es pura retórica) por qué se actualiza tan poco este blog últimamente…

8192

… ya van a haber otras novedades (aparte del 16384). Paciencia…

sábado, 30 de agosto de 2014

Mi aplicación

Casi todos (los programadores, obvio) tenemos “mi aplicación”. Ésa que, cuando haya tiempo, vamos a hacer “como se debe”.

El “como se debe” varía con cada uno, pero me arriesgo a generalizar: no es una afirmación positiva sobre ciertas herramientas y prácticas, es más bien una negación de aquellas que venimos utilizando, utilizamos o nos obligaron a utilizar, o de las que escuchamos hablar mal por ahí o… un largo etcétera.

En criollo: “mi aplicación” no va a ser como éste proyecto-huérfano-engendro-mutante del que me contaron, caí o armé (“por culpa de…”, seguro).

¿Cómo es “mi aplicación”? La mía de mi propiedad, al día de hoy, es:

-Una aplicación web hosteada en google.

-Server side: en java, pero va a devolver exclusivamente JSON. Pura data. Lo juro.

-Con alguna base de datos no relacional, porque son re-cool.

-Bootstrap.

-Pero no pienso escribir una sola regla de css. Lo juro.

-Ni tampoco mucha imagen ni iconito. Si puedo quedarme sólo con lo de bootstrap, mejor.

-Ni meterle 10.000 plugins (aunque ya empecé… pero lo voy a deshacer, y cuando lo deshaga lo juro).

-Jquery

-Jquery validation, si hace falta (imagino que sí).

-Knockout.

-Require.

-Y visjs, porque necesito algo así.

-Y NADA más.

El problema es… el de más arriba: que es cuasi-simétricamente-opuesto a todo lo que alguna vez hice: no soy diseñador ni mucho menos (estoy aprendiendo que entre “seguir la onda”, y “diseñar” hay un abismo insondable). Nunca programé en java (profesionalmente, proyectitos de prueba hicimos todos). Nunca usé bootrstrap. De íconos y gráfica o imágenes… sólo sé buscar en google, y al photoshop no me lo presentaron (ni siquiera sé usar bien el paint.Net). Visjs es genial, pero todavía estoy leyendo la documentación. Los únicos viejos conocidos son Knockout, require, jquery y compañía. Pero son herramientas, no una forma de trabajar con la que uno viene acostumbrado, y en la que “el camino para hacer tal cosa” aparece casi naturalmente.

Como todo primer intento, es… bueno, como se imaginan que es. Pero hay que seguir haciendo y rehaciendo hasta que salga. Mentalmente, claro, porque en la real realidad, uno va dedicándole horas a cuentagotas entre proyectos más rentables, con la esperanza de que en algún momento éste también lo sea.

Si bien “construir éste sistema lo antes posible” es la madre de todas las cag…, también es la madre de todas las cosas que están ahí afuera en este preciso momento, satisfaciendo necesidades de éste preciso momento, probablemente tan efímeras como la combinación de herramientas que (ahora) “me gusta”.

“Como a mí me gusta” va variando a medida que avanzamos. A veces más, a veces menos, pero siempre, con cada paso hacia adelante, surge el imperioso impulso de pasarle la guadaña a (casi) todo lo que se deja atrás… y uno va y lo hace. Porque ésta es “como a mí me gusta”. Es inevitable: la motivación parte de “armar un proyecto como a mí me gusta”, y no “construir éste sistema lo antes posible”.

Pero bueno, juntar dos o veinte librerías, copypastear un poco de código y salir con algo rápido a ver si pega es, probablemente, eficaz. O por lo menos un fracaso rápido y a otra cosa… pero no es lo que tengo ganas de hacer ahora.

Tengo ganas de seguir jugando.

Y a todo esto… ¿qué hace, exactamente, “mi aplicación”?

Por ahora, nada.

¿Qué debería hacer?

No está muy claro, ya veremos. Lo importante es que “esté como a mí me gusta”.

¿Verá la luz del sol?

lunes, 2 de junio de 2014

4096

A small victory.

4096

buscando en google veo unos screenshots que llegan hasta 65536… ¿fakes? Si sigo así, en un par de meses les confirmo.

jueves, 15 de mayo de 2014

Jetas*

En mis tiempos, cuando se quería hacer alguna gráfica (folleto, página web, calcomanía, papel higiénico, mouse pads servilleta o lo que sea) se tiraban un par de print screens de las pantallas más “bonitas” (o se inventaba alguna si es que no había), un poco de bla bla bla “mejorará su vida” y listo.

Ahora la onda es poner la jeta* de algún CEO presentable (pocos consiguen), o  empleado, o modelito o pobre flaco que iba corriendo una maratón con cara de langa (no, no vi que lo hayan usado, pero podría ser) y nada más. De qué hace el sistema, ni una palabra (o bien abajo), no sea cosa que alguien reclame la letra chica. Si es mujer, morocho, latino, indio, oriental o miembro de alguna “minoría con onda en USA”, mejor, y si es de varias al mismo tiempo (una mujer negra de ojos rasgados vestida de Pancho Villa), mejor que mejor.

O gente laburando en unas oficinas con toda la onda, limpias y llenas de luz, muy prolijamente desordenadas, súper informal. Vaya uno a saber ande se trabaja así, tal vez en algún lugar (hay uno de casi todo), pero me juego que no es la regla (al menos no para los que tocan el teclado).

O un tipo más o menos joven haciendo garabatos en un pizarrón, y todos alrededor con cara de “estoy aportando ideas”… y siempre alguna mina hay, por eso de las minorías que mencionaba antes. A veces hasta eligen uno o dos medio feos (medio al fondo, a un costado o fuera de foco), para darle realismo. Pero todos tienen los dientes blanquísimos, eso sí (debe ser por los tubos de luz), y nadie con los ojos rojos ni las ojeras negras ni la barba crecida ni la mandíbula colgando en un bostezo interminable.

Debe ser para mostrarle al mundo que el desarrollo de software, especialmente el de line-of-business, es producto del trabajo de personas comunes y silvestres y extremadamente cool (a este ventiañero lo vendemos por genio). Trabajo en equipo (lo vendemos diez veces) que demanda un ambiente acorde (total lo encadenamos al teclado hasta que le salga algo), re-creativo (con una play se queda contento), pero de mucha responsabilidad (y si no es la play están los palos, y de última de acá no te vas) y, sobre todo, esfuerzo (te va a costar un ojo de la cara), un gran esfuerzo sostenido en el tiempo (lo vas a tener para el día en que te mueras)… un trabajo casi artístico (así que si sale cualquiera no es culpa nuestra, el arte es así… indomable).

Será para hacer el software más humano, digo yo.

* jeta = cara, rostro (soy re-internacional).

martes, 13 de mayo de 2014

Prefiero el picado fino.

Creo (comienzo que permite divagar sin molestarse en verificar ni pensar dos veces) que esta preferencia es impronta de los últimos años de trabajo “Senior” (comillas obligatorias) en equipos más o menos medianos, más o menos “rotativos”. Picaba funcionalidad, sí, pero la mayor parte del tiempo tenía que buscar bugs en, verificar o consultar código de otros, en funcionalidad de la que no tenía más que una (valga la redundancia) vaga idea funcional. Entiéndase “no tenía mucha idea de cómo estaba programada o siquiera pensada”.

Entonces abría una carpeta (y a veces otra y otra y otra) y por los nombres me iba dando cuenta de cómo venía la mano. Me es cómodo encontrar una lista de archivos con nombres de clase más o menos coherentes, sintiéndome seguro de que no hay más que eso, simplemente porque “un namespace por carpeta, una clase por archivo”.

Ése es el picado fino. ¿Se entiende? Si no, querido lector, mejor siga su camino por otros callejones de la web, que acá ya no se le explica nada a nadie.

A veces hay un archivo con un enum y nada más. A veces una clase enorme con otras privadas y públicas y enums e interfaces y demás, adentro unas de otras, como muñecas rusas… pero en definitiva siempre una y sólo una clase en el archivo (amén). Se supone, al fin y al cabo, que cualquier otra cosa interna hace al detalle de lo que la contenedora dice (en su nombre) que hace.

A otros no. A otros les gusta el picado grueso. Un par de carpetas, las mínimas necesarias para leer el contenido con comodidad, arregladas en una jerarquía más bien plana y a otra cosa mariposa. Los nombres de los archivos se refieren no a clases sino más bien a… bueno, nunca encontré/entendí si había una regla, supongo que obedecen al (o son la medida del) sentido común de quien los crea.

Éstos otros, los del picado grueso, suelen argumentar con cierta razón que codificar una funcionalidad, tocando al mismo tiempo 5 o 10 archivos por separado, es un mareo. Uno trabaja en MVC, por ejemplo, saltando entre vista, controlador, modelo (principal y varios secundarios), un par de helpers, algo más aquí, algo más allá… y son como 10 archivos o más, si la cosa es compleja.  Y sí, puede ser… a mí no me molesta tanto, y, a la inversa, me es un mareo ver todo junto. “Así es MVC”, o “Así son las reglas de estilo en .Net”, contraataco (por no decir “así me gusta y punto”).

Normalmente, de encontrar código “picado grueso” en en una solución compilada de .Net, puteo (a veces para adentro, a veces para afuera)… pero en javascript, por ejemplo… “y bueh, así es la we’ ¿vio?”. Después empecé a usar require.js y… ¡picado fino en javascript! Y pienso (a futuro cercano, lo veo verde todavía) empezar con TypeScript y ahí los del picado grueso me van a odiar en serio, porque ya no hay excusa (salvo el gusto personal, argumento tan fuerte como el que lo utiliza –débil en mi caso-).

Pero no está mal el picado grueso, no. Es un tema de preferencias, nada más, de idiosincrasia, costumbre, organización mental de cada uno… andá a saber. Alguno dirá “hay que encontrar el punto justo”… y suena bien, pero (en este punto) prefiero seguir un (y sólo un) criterio, aunque se vaya al extremo. Habrá que ponerse de acuerdo y decidir con qué se prefiere lidiar cuando toque: ¿un archivo de 1000 líneas o una jerarquía de 5 carpetas de profundidad con 20 archivos de 30-50 líneas en cada una? Pero a veces una cosa y a veces otra (y a veces ninguna) sí que es un enjambre.

Es, en todo caso, una buen tema para animar la conversación alrededor del fuego de algún proyecto incendiado. Basta, me voá trabajar.