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.

Frases: teoría vs. práctica.

La teoría es la práctica de los impotentes.

Otra de El Juego del Angel, de Carlos Luis Zafón.

Frases: principios y prioridades.

Los que sobreviven en este oficio son los que tienen prioridades y no principios.

Leída en El Juego del Angel, de Carlos Luis Zafón, novela que empecé a leer hoy para sacarme de encima el polvo de tanto picar código y que ya puedo recomendar tranquilamente (espero que siga tan bien como empieza).

Esto viene a reforzar aquello de que quien está atento encuentra máximas en cualquier lado, que es buen alumno aquel que busca un maestro, y cosas por el estilo.

Por cierto, paciencia, paciencia que ya voy a postear algo consistente… espero.

Frases: Participación y compromiso.

¿Cuál es la diferencia entre participación y compromiso? Digamos que si el objetivo es preparar huevos con jamón la gallina participa, pero el cerdo está comprometido.

(me la recordó un reciente twit de @Yoriento)

Frases: $.noop()

“$.noop returns the sound of one hand clapping.”

“$.noop devuelve el sonido de una sola mano aplaudiendo.”

- Karl Swedberg comentando la documentación de $.noop() de jQuery.

Para los despistados: $.noop() es una función de jQuery que -como su nombre indica- no hace nada.

Combinando teoría y práctica.

La teoría es cuando crees saber algo, pero no funciona. La práctica es cuando algo funciona, pero no sabes por qué. Los programadores combinan la teoría y la práctica: Nada funciona y no saben por qué.

– Anónimo (visto en Mundo Geek).

Lo que sabemos que sabemos, lo que sabemos que no sabemos, lo que no sabemos que sabemos y lo que no sabemos que no sabemos.

Hay aquí alguien a quien nunca pensé que podría citar –seriamente- en este blog: Donald Rumsfeld. Parece que el tipo se da aires de poeta, y que encima no es tan malo:

The Unknown
As we know,
There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

—Feb. 12, 2002, Department of Defense news briefing

El poema fue mencionado en el recientemente muerto y resucitado Coding Horror (por cierto, qué vergüenza. Es brutalmente cierto aquello de “En casa de herrero cuchillo de palo” y “Haz lo que digo mas no lo que hago”).

Huerfanitos.

Permítaseme un poco de humor gris tirando a negro.

En todo emprendimiento que venga pariendo software desde algún tiempo podremos encontrar desarrollos en diferentes estadíos de su camino hacia la obsolesencia: los hay desde embrionarios hasta mantenidos con vida artificialmente, pasando por recién nacidos encantadores que prácticamente no hacen nada por sí mismos, infantes con terribles rabietas que reclaman noches en vela, adolescentes indomables pero llenos de energía y posibilidades, adultos productivos e independientes y ancianos, venerables fuentes de sabiduría o mañosos insoportables cuyos achaques reclaman constante atención.

Y los hay huerfanitos, de todas las edades. Ya sea debido a que sus progrenitores hayan pasado a mejor vida o huido en estampida cual vil Frankenstein o desentendido de su cuidado o sido asesinados (o ajusticiados merecidamente), son usualmente víctimas de la indiferencia de los miembros del equipo de desarrollo.

Proliferan –me imagino, no me van a pedir rigor científico justo ahora-, más en consultoras que en empresas dedicadas a un producto o que en software factories. Supongo que porque las segundas cuidan mucho a su único hijo (o a lo sumo a sus pocos hijos) y las últimas son padres espartanos e inmisericordes que no tienen reparos en arrojar al abismo a sus vástagos más débiles, en el mejor de los casos, o madres de alquiler que paren a pedido y si te he visto no me acuerdo.

Pero si definimos como consultora a un emprendimiento que no sólo desarrolla un producto sino que también se hace cargo de su mantenimiento correctivo y mejoras funcionales (que cobra religiosamente), nos encontramos con que en este tipo de organizaciones no es tan sencillo dejar atrás las consecuencias de viejos errores… institucionalmente hablando, claro, porque sus integrantes intentarán hacerlo a toda costa (o serán eventualmente obligados a ello), y de ahí la proliferación de estos huerfanitos.

No es mi intención ser cruel inútilmente, hablo desde la experiencia: son peligrosos, créanme. Carentes y muchas veces necesitados de atención, se nos pueden pegar como garrapatas. Es así como, a través de una inocente tarea de instalación, un pequeño fix o una mejora estética nos encontramos siendo referentes, tutores, encargados, o directamente padres sustitutos de alguna de estas criaturitas de las que conocemos poco y nada.

El entorno no propicia el despegue. Si les toca transitar esta situación verán con horror como, aliviados al ver que a otro se le ha adjudicado el trasto, sus otrora solidarios compañeros de equipos evitan el tema (“y sí, alguien tenía que hacerse cargo”) o intentan naturalizarlo (“che, vos estabas con aquello de… ¿no?”), si no es que literalmente huyen despavoridos. Y no tardarán en aparecer problemas de los cuales, obviamente, nadie sabe nada y nadie nada quiere saber, salvo que tenemos que hacernos cargo.

¿Solución? Es aquí donde con un poco de demagogia podría decir que la única definitiva es adoptarlo, encauzarlo, educarlo, corregirlo, domarlo si es necesario para resolver el problema de una buena vez por todas… pero también es una posibilidad buscar a algún desprevenido, dejarle la canastita cerca, tocarle el hombro, voltear y caminar rápidamente sin mirar atrás, silbando bajito con aires distraídos.

Metáforas sobre el desarrollo de software: el juego de ajedrez.

  La complejidad del un proceso de desarrollo de un software es exponencialmente proporcional a la complejidad del producto (digo, a ojo de buen cubero).

Las metáforas nos ayudan a manejarnos en la complejidad sin sentirnos desbordados, creo que es por esto que abundan tantas y tan variadas acerca del desarrollo de software, del trabajo en equipo o de las relaciones laborales…

En Qué quieres desarrollar hoy? me encontré con una muy original y acertada: La programación es como un juego de ajedrez. ¿Se consideran buenos jugadores? Yo creo que me defiendo, aunque algunas veces me siento como Felipe:

Lleva a tus monitos de paseo.

La semana pasada escribía sobre el paradigma que rodea cualquier actividad, sobre lo importante que resulta el conocimiento y la comprensión de éste para desarrollar con éxito un software alineado con el negocio, y lo difícil de su transmisión al equipo de desarrollo.

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.

El problema es, volviendo al primer párrafo, que el equipo de desarrollo necesita conocer el paradigma real que subyace al modelo de negocio para derivar de él lineamientos concretos con los que diseñar un software. Imaginemos por un segundo que creamos un sistema de gestión para una empresa de la industria farmacéutica partiendo de que, tal cual rezan sus documentos sobre políticas internas, “la base de nuestro negocio es proveer los medicamentos para curar todos los males de la humanidad”… Imaginemos ahora la cara de los directivos cuando mostremos nuestros reportes y panel de control de gestión conformados por indicadores tales como tasa de mortandad, calidad de vida, reducción de casos de tal y tal enfermedad… cuando midamos el éxito de un producto de acuerdo a la cantidad de pacientes que se han curado gracias a él… “¡Hey! ¿Dónde está el estado financiero? ¿Y la cotización en bolsa? ¿Dónde se muestra el ROI?”.

Entonces, para conocerlo y comprenderlo cabalmente se requiere estar ahí. Es tarea propia de analistas funcionales, representantes comerciales y demás. Pero, normalmente, los programadores no pueden estar ahí y la solución propuesta por metodologías ágiles como XP –tener al usuario dentro del equipo- no siempre rara vez es posible. Surge entonces, como siempre en el desarrollo de software, el problema de la comunicación.

Pero… ¿No pueden estar ahí? ¿Nunca? ¿Ninguno? ¿Ni de visita? ¿Ni por un rato? Difícil de creer. A pocos se les da la oportunidad de conocer a los usuarios en su entorno real de trabajo. Incluso cuando esto es posible, incluso cuando es sencillo encontrar la oportunidad. Más raro aún es que esta actividad sea establecida formalmente entre las tareas de un programador durante el proceso de desarrollo.

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.

Creo que es una práctica fácil, barata y muy productiva el llevar a los programadores “de paseo” al entorno del cliente en cualquier oportunidad que se presente (oportunidad para tomarles fotos vestidos decentemente… ¡o hasta de saco y corbata!). ¿Para qué? Para que conozca a los usuarios, su nivel, su entorno, su trabajo. Por ejemplo…

¿Son usuarios avanzados en el uso de una computadora en general? Hace ya mucho tiempo (no creo que esto pueda suceder ahora) me di cuenta de que el significado de los íconos más básicos y estándar –guardar, abrir- de la barra de tareas del sistema eran completamente oscuros para el usuario de nuestro sistema, que utilizaba sólo el menú porque allí decía “Abrir”, “Guardar”, haciendo todo de una manera muy incómoda. El detalle cool (para mí) de poner íconos grandes y sin texto hacía que la barra fuese completamente inútil. El gesto –tan natural para mí- de poner el cursor encima de un ícono para ver una descripción de su funcionalidad era imposible en esta persona.

¿Son jóvenes, personas mayores? ¿Necesitan algún tipo de accesibilidad para utilizar el sistema? Allá lejos y hace tiempo tuve un compañero de trabajo, un contador –creo- que era tan corto de vista que tenía que usar la lupa… y les aseguro que el sistema se veía MUY diferente de esa manera.

¿Su trabajo les exige interacción constante con el sistemao es más bien esporádica? ¿Tienen otros sistemas abiertos? ¿Tienen que consultarlos alternativamente? ¿Llevan a cabo varias tareas al mismo tiempo? Esa transacción, que nosotros imaginamos como una rápida carga de datos y un enter final tal vez requiere de varios minutos entre ingreso e ingreso para conseguirlos. Otra de las cosas impensadas que vi fue un usuario que primero copiaba todos los datos necesarios a un archivo de texto. Lo hacía desde diferentes planillas, sistemas, desde el navegador y luego abría el sistema de presupuestos y los pegaba desde allí. ¿Por qué? Era obvio, porque temía perderlos y el sistema no le dejaba grabar el registro –aunque sea localmente o en un repositorio temporal- si no tenía los datos completos. Esta era una funcionalidad que yo había discutido tercamente por demasiado problemática en relación al beneficio –según mi propio punto de vista- que representaba para el usuario. Cuando lo vi no discutí más.

¿Están cómodos? No es lo mismo utilizar el sistema localmente que hacerlo a través de un escritorio remoto, o sentado cómodamente en un escritorio que de parado frente a un rack de servidores.

Siempre hay, en definitiva, alguna cosa rara. Se me dirá que es cuestión de hacer lo que los analistas o diseñadores nos piden y listo, que al fin y al cabo ellos han estado allí –o ha leído un documento redactado por alguien que ha hablado con alguien que estuvo allí-, pero eso nos limita a lo que ellos consideran fácil o posible.

Esto último me hizo acordar algo que había escrito en La “respuesta” a “¿Cuál es el error?”, la ambigüedad, su resolución y, finalmente, la realidad:

[…] ya lo dijimos, vivimos en un mundo imperfecto. Muchas veces (en todo proyecto real esta situación es más que frecuente) el cliente no está disponible […] o no entiende la pregunta. ¿Entonces?

[…] hay veces que hay que adivinar y seguir adelante, rellenar los huecos en las especificaciones apelando al sentido común […]

Cultivar el “sentido común” -al que apelan los programadores cuando tienen que inventar algo para tapar algún hueco- mostrándoles “la vida real” del proyecto para el cual trabajan ahorraría innumerables idas y vueltas entre desarrollo y producción y seguramente haría que surjan ideas y mejores posibilidades para el sistema.

Paradigmas.

Los desarrolladores somos –¿hipótesis?- ante todo humanos, luego usuarios, luego desarrolladores.

Como humanos –entre otras cosas-, tendemos a sobrevalorar la propia experiencia. Por ejemplo, si el sistema que desarrollamos nos es fácil de utilizar solemos atribuirle esta característica obviando el hecho de que hemos aprendido a utilizarlo “desde atrás” (es decir, desde el código, el diseño o los requerimientos) y no “desde adelante” (desde la pantalla, los manuales o la capacitación). Para cuando nos enfrentamos a la pantalla de inicio ya sabemos casi de memoria todo lo que sigue. Abstraerse de este conocimiento es –por más que me juren y recontrajuren- imposible, y es por eso que nuestras pruebas y experiencias personales son bastante objetables como medida de lo que sucederá en el mundo real. Esto se aplica, con variaciones, tanto a desarrolladores como a analistas, testers, líderes de proyecto y a cualquiera implicado en el desarrollo de software (excepto, claro está, al cliente y al usuario).

Además de humanos –si es que damos por válida la hipótesis-, somos usuarios de sistemas de un determinado negocio: entornos de desarrollo, clientes de bases de datos, herramientas de diseño y documentación de requisitos, entre muchos otros, conforman el software de soporte al negocio del desarrollo de software. Negocio en el que estamos inmersos y que, como todos, tiene su paradigma establecido y materializado en la forma de determinados estándares: flujos de trabajo, herramientas visuales, disposición física de los objetos en una oficina… todo lo que nos rodea se deriva de éste en alguna medida.

La importancia de estos elementos –paradigma y estándares- que sobre el papel parecen un conjunto arbitrario de caprichos funcionales -¿por qué Ctrl+U y Ctrl+Shift+U? ¿Por qué un árbol y no una serie de listas encadenadas?- radica en que condicionan toda nuestra visión de la realidad (¡vaya si estamos condicionados por los paradigmas de nuestro negocio!). Los sistemas -si pretenden ser exitosos- deberán respetar –o revolucionar, pero esto es más difícil-, sobre todo en la interacción con sus usuarios, los paradigmas del negocio para el que fueron diseñados.

Como desarrolladores que somos –de eso sí estamos seguros- nos sería imposible, si estuviésemos librados a nuestro criterio, no aplicar el paradigma y los estándares propios del negocio al que pertenecemos –el desarrollo de software- a los sistemas que desarrollamos.

El problema es que, como establecimos más arriba, otros negocios o actividades tienen estándares y paradigmas diferentes. Internalizarlos es prácticamente imposible (deberíamos ser, por ejemplo, tan usuarios de distintos sistemas de gestión como lo somos de distintos entornos de desarrollo, tanto como lo es un empleado administrativo que ha transitado por diferentes empresas y puestos). Sólo podemos pretender, a lo más, conocerlos. Y para ello se requiere de una experiencia… “presencial”. Es la experiencia que trata de transmitir el analista funcional, el área comercial o quienquiera que tenga contacto directo con el cliente.

Pero un modelo mental es algo realmente difícil de describir, los estándares que se deriven de éste serán en su gran mayoría reglas y prácticas comunes y no estarán explicitadas en ningún lado. Es, en definitiva, difícil de transmitir. Por todo esto, cuantos más intermediarios haya entre aquellos que conocen a los clientes y usuarios y los desarrolladores, más probabilidades habrá de que nos apartemos del paradigma y los estándares a los que ellos están acostumbrados.

Definir el negocio.

Encontrado un muy buen concepto en la última de las recomendaciones de artículos de Wikipedia de Pymecrunch. Es una regla muy simple y en la que no había pensado nunca: Miopía de Marketing. Transcribo ese fragmento:

[…] Es mejor definir tu negocio en términos de mercado, y no de producto.

El artículo de la wikipedia lo explica con dos ejemplos muy divertidos:

-La gente no compra taladros, compra agujeros. Si te posicionas como “vendedor de taladros”, tendrás muchos problemas cuando se popularicen los punteros láser.

-La gente no quiere viajar en tren […], lo que quiere es ir del punto A al punto B. Si dices que te dedicas al negocio de los trenes, ¿qué harás cuando subir a un avión esté al alcance de cualquiera?

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

Una relación entre innovación y estructura de la empresa.

“By me”, por supuesto. Que quede claro que ésta es una visión basada más en mi insomnio veraniego que en contenidos académicos.

La definición de la RAE nos indica que innovación es la

creación o modificación de un producto, y su introducción en un mercado.

Apoyándome en ésta definición es que quisiera someter a juicio una interpretación mía, a ver qué les parece.

En el centro de todo esto está la idea de que por definición innovar implica un rendimiento económico. Dice “producto” y “mercado”, indicando con esto un objetivo último: obtener o maximizar beneficios.

Así, Innovar = crear + producir + vender. No alcanza con crear algo nuevo, sino que hay que producirlo e introducirlo en un mercado (venderlo). Y hay que hacerlo por beneficios, no por amor al arte.

Las empresas, por definición, no intentan crear nuevos productos y servicios sino que intentan innovar (las que lo hacen, claro). La búsqueda del beneficio es lo que las define como tales y es lo que hace la diferencia. Esta búsqueda de beneficio no está presente en el término “creación” y sí lo está en “innovación”.

¿La letra dura nos dice, por ejemplo, que si estoy jugando con un nuevo lenguaje de programación no estoy innovando? Sí, creo que dice exactamente eso. Puedo estar aprendiendo o creando, pero no estoy innovando. No busco introducir un nuevo producto a un mercado para obtener un beneficio. Aún si lo estuviese intentando, innovar implica hacerlo con éxito, no intentarlo.

Entiendo que “jugar” es una parte importantísima e indispensable del proceso que nos lleva a la innovación (es la parte de creación) pero no es innovación per sé. Faltan los demás elementos. Y falta el éxito.

Se me ocurre que el fracaso en la innovación por parte de muchas empresas recae justamente en no entender ésta última ecuación.

Normalmente en la base de la pirámide los empleados no tienen incentivos para innovar (y algo más, ya llego).

Innovar implica la búsqueda de un beneficio económico derivado de la introducción al mercado del producto, y el empleado está excluido de la mayor parte de ese beneficio por definición. ¿Hay muchos empleados que se alegren sinceramente de que la empresa gana 1000k en vez de 500k? En todo caso yo creo que estamos más contentos cuando nuestro sueldo sube de 0,10 a 0,12k.

El empleado cobra un fijo que se mantiene mientras la empresa siga viva, innove o no. En todo caso, la motivación para innovar dependerá de qué tan convencido esté de que la innovación es vital para la empresa y, por tanto, para la continuidad de su trabajo.

En este nivel, por otro lado, la base del conocimientos es técnico, no de negocios. Así que la mayoría no está orientado a la innovación, por falta de visión y técnica de negocio (recordemos que innovar implica éxito por lo menos en lanzar el producto al mercado).

Incluso puesta en duda la vida de la empresa sin innovación, un empleado podría preferir irse antes que ponerse a pensar en cómo innovar. Esto implicaría ponerse a pensar en cómo obtener un beneficio económico… del que, de obtenerse, sólo le tocaría una mínima parte.

Los empleados de este nivel, en todo caso, crean. ¿Por qué? Por lo que decíamos en A great place to work y en Aprendizaje e Innovación: la creación es una actividad motivadora y representa un beneficio (el conocimiento) con el que el empleado sí se queda en su totalidad (por más que la empresa también se beneficie económicamente de ello).

Así que algunos crean porque la creación (no la innovación) y el aprendizaje los motiva. A otros no, y entonces simplemente hacen su trabajo por dinero. Es decir, simplemente producen. He aquí los dos motivadores de los que hablamos siempre: un buen entorno laboral (en todo sentido, incluyendo posibilidades de aprendizaje) y una buena paga.

Así que en esta visión, muy de empresa de sistemas, la base de la pirámide aporta la creación y la producción.

Faltan los negocios. Es en el medio de la pirámide donde el innovar se convierte en un objetivo laboral: un ejecutivo debe tomar la creación, seleccionarla y encauzarla con un sentido económico y dirigirla hacia los que producen para construir un producto concreto y rentable.

El ejecutivo medio es un empleado que es evaluado por su éxito en los negocios. No por la creación de un producto distinto a todos los demás sino por el éxito de ese producto en el mercado, por la innovación que produce medida en términos de ese objetivo que la caracteriza: el beneficio económico. Los productos exitosos no son los innovadores. Los productos exitosos son los que dan un buen beneficio. En el mundo de sistemas de hoy, ese beneficio se debe gran parte a la innovación. Pero no todo, que aplicaciones de nómina hay muchas.

La motivación de los empleados de nivel medio -los ejecutivos- para innovar es que su continuidad laboral depende de ello si el mercado lo exige, ya que a través de ello se lo evalúa. Usualmente aparece un extra a través de la participación (mayor que en la base pero de todas maneras mínima en cuanto al global) en los beneficios.

Si el mercado no lo exige no estarán motivados a innovar, para frustración de los “creativos” de la base, que se encontrarán estancados, y alegría de los “productores”, que en un ambiente estable estarán más tranquilos.

Volvamos a los empleados de la base. ¿Y aquellos que sí tengan una orientación de negocios?  Lo que sucede con ellos es muy común: ascienden para ocupar cargos ejecutivos. Si conjugan las dos orientaciones (visión técnica + de negocios) pueden innovar por ellos mismos, así que se van para trabajar en forma independiente. Esto aumenta la tendencia hacia lo puramente técnico del sector.

¿Y al tope de todo, en el ápice de la pirámide? Allí tampoco hay innovación, si es que pensamos en una junta de accionistas, por ejemplo. Allí sólo hay búsqueda de beneficio, inversión. No hay suficiente conocimiento técnico, hay una gran comprensión del negocio en su estado más abstracto y puro: el dinero, el capital, el interés, el plazo, el retorno de la inversión, el rendimiento.

Las personas: el activo de las empresas... no.

Un poco a cuento de las cuestiones laborales sobre las que venía reflexionando, dos perlitas:

1) Yoriento referencia una frase vista en el blog de Escolar, atribuída a "Eusebi Cima, vicepresidente de Fomento del Trabajo (la patronal catalana) y presidente de la patronal Fepime, sobre las ayudas de 1.500 euros para los empresarios que contraten a parados con cargas familares":

"Desgraciadamente, lo que necesitamos son ayudas para despedir a la gente. Hay un ajuste de mercado, una crisis muy grave, se está generando desocupación y no puestos de trabajo. Ahora no es el momento de crear este tipo de ayudas."

2) Un extracto (muy iluminado, a mi entender) del blog de Javier Llinares (no tiene relación directa con el punto 1):

Yo no estoy de acuerdo en que las personas sean el mejor activo que tienen las empresas, ni siquiera estoy de acuerdo en que las personas sean un activo de las empresas, ya que si fuesen algo que poner en el balance, en lugar de en la cuenta de resultados, creo que lo que serían es un renting.

Las personas son un activo para ellas mismas, nunca para las empresas, ya que para que algo sea considerado un activo, tiene que existir cierto nivel de posesión, y naturalmente las personas solo se pertenecen a ellas mismas.

El resaltado es mío. Les recomiendo el artículo completo.

Qué significa NINJA en "Crisis NINJA".

Voy a deschavar (con alguna vergüenza) mi desconexión absoluta de la actualidad en estos días (que no de la realidad, que es bien diferente) y de paso hacer un favor a quienes no se atrevían a preguntar.

Acabo de leer en el blog de Javier Llinares Salas, por primera vez, el significado de NINJA, término que ha estado dando muchas vueltas estos meses:

NINJA = No income, no job, no assets, es decir que un ninja es una persona que no tiene ingresos, no tiene trabajo y no tiene propiedades.

Un rayo de luz al interior de mi zócalo...

Panqueque System III: El infierno de las preferencias.

Es difícil que un desarrollador que haya trabajado en algún sistema de gestión no se haya enfrentado con esta situación.

Circuitos administrativos hay para todos los gustos. Tenemos los clásicos compras, producción, ventas, facturación, atención al cliente, liquidación de sueldos. También tenemos algunos más infrecuentes, pero de todas maneras muy comunes: presupuestos, importación, exportación, marketing...

Todos ellos han sido descritos, caracterizados y estandarizados extensivamente por la bibliografía de la administración de empresas. Algunos de ellos, por estar atravesados por restricciones legales, son muy parecidos en todos lados.

Pero el problema de las sutilezas existe siempre. Cada empresa tiene las suyas, a veces justificadas, a veces no. Y el momento de comprar un software que gestione el circuito será el de la dura negociación para determinar quién se adapta a quién (la empresa al software o viceversa) y en qué grado.

En Panqueque System II: Un caso de dependencia del cliente apuntaba al caso en el que el cliente requiere customizaciones de tal especificidad que termina quebrando al desarrollo en dos versiones (por lo menos). El problema es casi comercial: se cobran customizaciones pero el cliente domina hábilmente la negociación y termina con un software a medida.

Este caso es sutilmente diferente. Más que de un error comercial, estamos hablando de un vicio funcional.

Los analistas funcionales, en su contacto cotidiano con diferentes clientes, son caldo de cultivo para esas pequeñas variaciones orientadas a demostrarle a cada cliente que el software se adapta perfectamente a sus necesidades.

Tomadas individualmente cada una de estas variaciones parece inofensiva, fácil de implementar y con una relación costo-beneficio ampliamente favorable. El cliente siente que el producto le calza como un guante. Cada vez que durante la demostración él apunta a cuestiones como "ah, nosotros requerimos que el gerente apruebe el pago para los mayores a..." podemos responderle "eso es configurable aquí".

Finalmente, todo termina siendo configurable allí (en esa pantalla infernal con 200 opciones que se activan y desactivan unas a otras). Que si tal funcionalidad está desactivada tal pantalla no tendría que verse, que si el módulo tal no está activo los datos tendrían que mostrarse de tal manera o de tal otra... Que los vendedores a veces pueden y a veces no pueden, que los descuentos a veces son fijos o pueden ser variables o...

Cada una de estas variaciones aporta su granito de arena para hacer de la gestión de configuración un absoluto desastre.

Lo divertido es -esto le he visto ya en varias ocasiones- cuando la combinatoria de estas opciones a veces sutilmente incompatibles unas con otras, resulta en comportamientos completamente insospechados. O cuando para activar ésta se necesita activar aquélla y para activar aquélla necesito esta otra que requiere la primera... una especie de abrazo mortal.

Y ni hablar de cuando se pretende incorporar nueva funcionalidad. El desarrollador que esté a cargo del nuevo módulo o pantalla puede verse involucrado en uno de dos infiernos: o se encuentra con una larga lista de opciones y variaciones pre-existentes que está comprometido a implementar, o (esto es tal vez peor), no hay documentación clara sobre alguna o ninguna de ellas o de la relaciones entre todas y se va enterando sobre la marcha o durante el testing.

En el primer caso, se genera una sobrecarga tal que la más mínima funcionalidad agregada insume un número aparentemente desproporcionado de horas. Pero por lo menos esto puede estimarse. Es un problema, y es conocido. En el segundo caso -la falta de documentación-, el desarrollador se va enterando sobre la marcha, con la sensación de ir retrocediendo a cada paso. Si había estimado 4 horas, luego fueron 8 y luego 16 y luego...

¿Soluciones? Ninguna es categórica. Cuándo incorporar una variación que surge del circuito administrativo de un cliente en particular es siempre es una relación de costo-beneficio. Los beneficios son instantáneos y los costos a mediano y largo plazo.

¿Podemos decir que no? Dependerá de qué tan importante sea la "sutileza" para el cliente y de qué tan importante sea el cliente para la empresa. Lo que es imposible de explicar (de cara al cliente) es que de alguna manera la calidad del producto puede verse comprometida.

Desde lo técnico el nudo de la cuestión estará en crear una arquitectura en la cual se puedan establecer cambios de comportamiento en forma global, de manera tal que el programador no tenga que estar al tanto de estas variaciones al momento de codificar. Esto no siempre es posible, y si lo es, lo será sólo en cierta medida.

Y desde lo metodológico, la simplificación: no sólo implica hacer más simple el código existente, sino retirar lo que no es frecuentemente utilizado. Este punto es al que se le suele restar importancia. Un producto con algunos años y versiones sobre sus espaldas puede estar cargando con un sinfín de posibilidades que ya nadie utiliza.

De cualquier manera, lo importante no es evitar el infierno de preferencias, dado que éste infierno, si está controlado, puede ser el que incline la balanza hacia nuestro favor al momento de ganar clientes. Lo importante es que la parte comercial y funcional del proyecto o la empresa sea consciente de la forma en la que sus decisiones afectan al producto.

Varias veces el equipo de desarrollo se encuentra con que se han aprobado customizaciones u opciones sin ningún tipo de consulta previa. No es una cuestión de "querer estar en todo", pero... ¿Si no se ha consultado al área técnica, sobre qué bases se ha decidido que lo que se cobra o ingresa por la customización es mayor al costo actual y futuro de la misma?

Los artículos de la serie:

Panqueque System.

Panqueque System II: Un caso de dependencia del cliente.

Actividades informáticas vs. olímpicas.

Voy a reconocer que el post Trivia olímpica informática del blog "Mi carrera laboral..." me pareció en principio una soberana estupidez ("con la mejor onda, ¿eh?"), sobre todo porque los ejemplos no eran de lo más divertido.

Pero ahora veo que por suerte los lectores han superado a los redactores, con algunos comentarios muy buenos:

• Uf! Trabajando en seguridad informática solo puedo sentirme un referí.
• Subgerente de sistemas - 100 metros con vallas. Vive saltando obstáculos con tal de llegar a la meta.
• Gerente general == Espectador. Se entretiene viendo al resto trabajar, jaja

Y hay bastante más... a mí todavía no se me ocurre ninguno.

Fachada de negocios.

La correspondiente entrada en Wikipedia -Facade (patrón de diseño)- indica que

"El patrón de diseño facade o façade sirve para proveer de una interfaz unificada sencilla que haga de intermediaria entre un cliente y una interfaz o grupo de interfaces más complejas."

Para resumirlo un poco, la fachada de negocios es un concepto de diseño que nos hace pensar en varias "caras" (fachadas, justamente) para un sistema dependiendo del cliente que lo utiliza. Así, por ejemplo, un cajero y un gerente de banco tienen diferentes fachadas de acceso al mismo sistema.

A la inversa también funciona. Podemos tener varios sistemas independientes entre sí y presentarlos como uno sólo unificándolos en una misma fachada. Esto es común cuando se requiere la integración de sistemas tecnológicamente incompatibles.

Otro uso interesante -muy típico de Microsoft- es la renovación visual de un sistema sin cambios de fondo, que nos permite venderlo como si fuera un sistema nuevo.

Pero una imagen vale por mil palabras:

(Gracias a ud-ya-sabe-quién-es por el video)

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.