Broken Culture

Los norteamericanos tienen una capacidad increíble para estandarizar cualquier realidad y encajarla en un set de historias prefabricadas, por más compleja que sea. Si, todo el mundo estandariza y encaja realidades en historias… es sólo que ellos lo hacen especialmente bien.

Mis feeds de “desarrollo” en inglés están llenos de telenovelas: los programadores somos la mucama inteligente, buena y fea; los managers, la malvada bomba sexy; la empresa (el capitalismo), el millonario que parece malo por estar atrapado sus redes pero que en el fondo es bueno. El final es cantado: la mucama inteligente se gana el corazón del millonario a fuerza de honestidad, bondad y trabajo duro, y en la última escena es la que está más buena de todas. La mala cae envuelta en sus propias telarañas y termina desenmascarada como la chupasangre inútil que es, desterrada en quién sabe dónde.

Tim Chevalier toma la decisión de abandonar la telenovela-sistemas y da sus razones. Después Michael O. Church sintetiza esas razones en una pregunta: “Can tech fix its broken culture?”, y responde “si” pero con más palabras. ¿Y cómo? Como dicta la trama: resistiendo los ataques del management-malvada-bomba-sexy y demostrando valía con honestidad, inteligencia y trabajo duro (y muy poca paga) hasta que el capitalismo-sociedad-millonario se de cuenta y expulse a los managers-malvada-bomba-sexy del juego.

La afirmación que más fuerte me suena en el post Michael no es “podemos reparar la cultura de sistemas”, sino otra mucho más desesperada y sutil: “hay una historia con un final feliz en el que los buenos que resisten son recompensados”.

En algún momento (allá lejos y hace tiempo) en el que hubiese coincidido (y hasta se podría buscar prueba de eso en este blog), un tiempo en el que lo “Agil” prometía ser la movida que desenmascararía las malvadas maquinaciones del management, demostrando de una vez y para siempre que los “techies” somos el verdadero corazón de las empresas.

Pero ahora, un par de años después, “Agil/Scrum” es más o menos lo mismo que “CMMI”. Todos los puntos de aquel manifiesto que hubiesen podido cambiar algo fueron ignorados o licuados; sólo quedaron las reuniones. ¿Y los tests y la integración continua y la nube y los frameworks y el open source…? ¿No son avances? Sí son avances… también las pantallas planas, los multi core, el wifi y los celulares… Pero el escenario es el mismo en el que se escribió The Mythical Man-Month (en 1975). Sólo cambió el decorado.

El argumento es “la mucama con esfuerzo llega al millonario”. En sistemas se dice “los techies programando van a dominar la industria”. El problema en la trama es “que la mala tiene al millonario engañado”. En sistemas, “que los managers son explotadores parásitos de la empresa”. Pero en ambos casos la industria/la empresa/el capitalismo siempre recompensa el valor generado. En última instancia verá quiénes generan el valor cuando los managers, a fuerza de incompetencia, caigan en su inevitable desgracia y se desencadene el final feliz.

En pocas palabras: hay que salir y mostrarle al mundo que los técnicos son los que generan valor. Siguiendo esa línea, si fuésemos adolescentes sobreexplotados de McDonalds deberíamos unirnos para revelarle al mundo que somos los que hacemos las hamburguesas.

Es una telenovela simplificadora que justifica lo que hacemos ante nosotros mismos mientras estamos dentro. Nos convence de quedarnos y nos explica por qué se van los que se van, separándonos de ellos para que no se nos ocurra tomarlos de ejemplo. “Cualquier parecido con la vida real”, lejos de ser casual, ha sido elaborado, refinado y corregido a lo largo de los siglos (si, siglos: Cenicienta) para identificarnos con la mucama-pobre-heroína de la trama mientras hacemos girar la rueda del molino, caminando en círculos hacia ninguna parte.

Como las telenovelas, es un discurso que no tiene ni pretende ser real ni tener sentido, sólo coherente y útil hacia dentro. Si uno rompe “la cuarta pared” y abandona el set ya no ve ni buenos ni malos ni lindos ni feos ni historia ni nada: sólo un montón de actores representando un guión más o menos delirante que no escriben ni escribieron.

Bueno, y “Can tech fix its broken culture?”

La “cultura de las empresas de tecnología” no está rota. La “cultura de las empresas” surge y prospera en tanto las hace funcionar, sobrevivir y prosperar… a las empresas, no a las personas. No está ahí para conseguir la felicidad ni el bien común de nadie… pero tampoco para impedirlos.

Personalmente creo que no hay nada que demostrar ni a quien demostrarle nada; nadie mirando, sólo nosotros mismos. No hay héroes buenos-pero-feos enfrentados a managers-malos-que-parasitan-las-empresas, ni millonarios naive a los que hay que llevar por la buena senda para bien de todos. Ni siquiera hay un “somos” ni un “son”: no hay una historia común encaminada hacia un final feliz, o hacia ningún otro lado. Lo que hay es un momento y un espacio y ciertas reglas más o menos fijas… A algunos les conviene el status quo, a otros no. Para los que no, a veces se puede y vale la pena dar la pelea por el cambio, a veces no.

De lo que estoy más seguro es de que no se toman buenas decisiones mirando telenovelas.

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.

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:

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.

Frases: Lo que sobra.

[…] como verás, arquitectura y diseño es lo que sobra... sobra porque todos somos arquitectos y diseñadores y hacemos lo que se nos da la gana, no hay directivas.

“Un amigo”, hablando sobre esas cosas lindas que tienen los sistemas.

Desafíos.

Un desafío es el deseo de alcanzar un objetivo ubicado un poco más allá (no demasiado, porque si no ya sería un sueño) de nuestras capacidades actuales. Implica mejora, autosuperación.

Para mí, lo motivador de mi trabajo es lo desafiante que puede llegar a ser. Frecuentemente se nos plantean proyectos parecidos a aquellos que enfrentamos en el pasado pero con algún matiz, algún punto oscuro, alguna particularidad especial que nunca hemos implementado. Estas particularidades representan nuevos problemas y son las que hacen al proyecto desafiante en esa medida justa que nos permite enfrentarlo con cierta confianza sin llegar al extremo de la sensación del salto al vacío.

Cuando no es así simplemente me aburro, y no tolero bien el aburrimiento. A mediados del 2009 di el salto y cambié de trabajo. En su momento actué guiado más por esos sentimientos –de aburrimiento- racionalizados que por razones objetivas. De alguna manera ese creciente aburrimiento ante los problemas y situaciones han alimentado este blog -inmejorable vía de escape- en la primera parte de este año (y a cuya ausencia se debe, en cierta medida, la poca producción bloggera de la segunda).

Finalmente el tiempo puso las cosas en perspectiva y el nuevo entorno me da un punto de comparación. Me llama la atención lo nimio, lo poco importantes que eran los problemas y situaciones que ponía como excusa del cambio. Ahora es claro que esa necesidad de cambio no estaba dada por el entorno sino que provenía de mí mismo, que su origen no era la gravedad o repetición de algún problema o situación sino el nulo desafío que éstos representaban para mí. Pareciera que “nulo desafío” implica que todo era “fácil”. Nada más lejos de lo que quiero decir, aquí vamos.

El punto central de toda esta cantinela es que uno no sólo “es parte de” sino que también construye la situación que lo rodea. Decir “no habrán nuevos desafíos” es, en realidad, una vuelta retórica por la que esquivamos la responsabilidad en la construcción de esa situación al ubicar a los desafíos en el entorno cuando en realidad están en nosotros.

Los desafíos no están allí, uno no los encuentra sino que los crea. Es decir que constantemente enfrentamos los desafíos que nos hemos creado, como Don Quijote contra los molinos de viento.

Un entorno de trabajo desafiante no es, por si queda alguna duda, algo objetivo. Lo que para unos es tierra fértil es desierto para otros, no por la dificultad o no de los problemas objetivos a resolver –finalmente el único problema objetivo lo constituyen los requerimientos de un cliente-, sino por la predisposición o no de cada uno a crear desafíos en ese entorno en un momento determinado.

Pareciera ser, entonces, que a nivel institucional hay poco que se pueda hacer para crear un entorno desafiante, dado que esta característica reside en cada persona y no en ese espacio creado grupalmente.

En alguna medida es así. No se pueden “crear” desafíos institucionalmente. Pongamos un ejemplo: se plantea “ser referencia en el uso de la tecnología X” como un “desafío en el que todos tenemos que estar comprometidos”. Esto es en realidad apenas un objetivo y una expresión de deseo que puede ser origen de un desafío motivador para algunos pero indiferente o incluso fuente de sentimientos negativos –inseguridad, presión, rechazo- para otros.

Lo que sí se puede hacer institucionalmente es ubicar a cada integrante en un puesto en donde los problemas objetivos –los requerimientos de sus clientes externos o internos- estén alineados con su predisposición a crear desafíos en torno de esos problemas y proporcionar los recursos, la libertad de acción o la guía que necesite cada uno para superarse. Esto será mucho más productivo que el vano intento de imponer desafíos a diestra y siniestra como si todos fuéramos iguales y nos interesaran las mismas cosas.

Pero esto implica un conocimiento muy personal de cada integrante del equipo por parte de la institución… mejor dicho por parte de las personas que definen los puestos en las instituciones y que –erróneamente o no- generalmente están muy alejados del resto de la empresa, si no física por lo menos profesionalmente.

La solución común, dado que a nivel institucional no puede haber un conocimiento personal profundo de cada uno, es dividir la responsabilidad entre persona e institución: la responsabilidad institucional es de abrir las puertas, proporcionar los caminos para que cada uno busque o cree ese lugar desafiante, y está en cada uno la responsabilidad y el esfuerzo de motorizar esa búsqueda. Motorizar es buscar, proponer, convencer, buscar alternativas, concretar.

Es tan común en sistemas la queja constante sobre las posibilidades de desarrollo profesional (“de encontrar nuevos desafíos”) como la inacción de quien las enuncia en cuanto a la creación o búsqueda de ese espacio fértil en desafíos profesionales.

De ser sincero el deseo, de existir esa búsqueda y de ser infructuosa, debería continuar por fuera (pero ya basta de quejarse), la posibilidad de que no haya intersección entre lo que una persona encuentre como desafiante y las necesidades de una institución en particular existe, y no hay más que hacer que seguir buscando.

Monkey Business.

Son casi humanos... somos casi monos, mejor dicho.

Visto en La Pastilla Roja

Me deja pensando, al trasladar la situación a nuestra vida laboral, en que –si bien entre otros factores- las reglas de juego tienen un peso fundamental para determinar si será la colaboración, la competición o la indiferencia la característica predominante en un entorno de trabajo.

En todo caso estoy bastante seguro de que las reglas pesan más que las características personales. Somos ante todo animales sociales –al punto en el que sólo sobrevivimos en sociedad-, mucho más influenciables por los que nos rodean que –en conjunto- ellos por nosotros.

¿Se pueden alcanzar altos niveles de calidad –esa esmeralda perdida- en el desarrollo de software sin colaboración, sin verdadero trabajo de equipo? Yo creo que sí, pero es mucho, muchísimo más difícil que en un ambiente colaborativo.

Los costos de un ambiente de “indiferencia” en el que cada uno “sólo hace lo suyo” se ven reflejados en complejas estructuras de control superpuestas que coordinan el trabajo: líderes de esto y gerentes de lo otro, supervisores de lo de más allá y más acá, capas y capas de jefes de jefes cuyo trabajo es apenas un poco más que distribuir información y controlar el correcto ensamblaje de subproductos que se construyen en la base de la pirámide aisladamente, sin visión de conjunto.

Se podría decir que parte del trabajo de esa jerarquía es, justamente, proporcionar una visión de conjunto. El problema es que, para el momento en el que el flujo de trabajo llega a ese nivel de revisión es un poco demasiado tarde para cambiar nada.

Para el momento de revisar la calidad –siguiendo las metodologías tradicionales- ésta está prácticamente determinada –sí, claro que podemos corregir desvíos funcionales… ya sabemos lo que sucede con la calidad del código durante esas correcciones-. Si el producto no cumple con las expectativas –de calidad, no sólo las de cumplimiento de requisitos funcionales- la única solución real es el retrabajo.

La solución propuesta generalmente es dividir el desarrollo en pequeñas etapas y revisar la calidad en cada una de ellas –siempre al final- con la esperanza de que la “suma de las calidades” sea provechosa –siempre al final-, y si así y todo las etapas presuponen productos demasiado amplios, las subdividimos… y luego ponemos a un responsable de cada división y de cada etapa, y ya estamos donde empezamos: jefes de jefes de jefes y poco trabajo real.

En un ambiente de colaboración las cosas son diferentes. La revisión es constante porque nadie es indiferente a lo que lo rodea. Cada corrección es mínima pero se dan constantemente. Es mucho más probable que la calidad final sea –para bien o para mal- toda la que el equipo pudo dar en un momento determinado. En esta situación el retrabajo cobra otro sentido: no es la corrección de lo que –en teoría- podría haberse hecho bien desde un principio sino la materialización del aprendizaje acumulado en el camino.

Pero son las reglas las que determinan si esa colaboración es posible. Si la ruta, -correcta o no, eso se verá al final- está predeterminada a través de un diseño milimétrico, el combustible de horas/hombre está calculado como para llegar con el tanque vacío y encima el vehículo no tiene ventanillas de poco sirve ponerse a pensar si hay o no un árbol en el camino, más vale rezar y esperar que cuando nos bajemos estemos en donde queríamos estar. ¿Parece difícil, no?

La influencia de la orientación al producto o al cliente en el desarrollo de software - II: La elección de la tecnología.

Esto viene a seguir la serie inciada en el post anterior: I: Los muertos se dejan atrás, que es recomendable leer primero.

---

La elección de la tecnología.

Durante la vida del desarrollo de un producto de software es inusual, aunque cíclico y fundamental, el momento en donde surge la necesidad de determinar la tecnología a utilizar.

Es el tipo de decisiones que hay que tomar en el momento de la reingeniería. Momento que se suele demorar hasta lo inevitable, por lo que los intervalos entre éstas se miden en años, si no en lustros o décadas.

Las razones son variadas y pueden ser tan técnicas como la degradación del código y la obsolescencia del hardware o software de base, o funcionales, como exigencias del mercado demasiado difíciles de implementar en la tecnología actual o la aparición del fantasma de imagen a “viejo y obsoleto”.

Para una empresa orientada al producto una reingeniería es una gran revolución, y suele venir acompañada de grandes cambios y resistencias en el equipo de desarrollo. Integrantes aferrados a la tecnología y metodología en retirada verán sus posiciones de poder o confort atacadas por aquellos familiarizados con las nuevas. La decisión, entonces, afectará inevitablemente a las relaciones de poder establecidas durante años y a las que se generen durante los próximos.

No es, en resumen, el momento de hacer experimentos. El proceso debería comenzar con la investigación de las tecnologías establecidas (nadie recomienda jugarse por aquellas más novedosas) y seguir con pruebas de factibilidad, y prototipos, y más pruebas y…

En una consultora, por otro lado, se inician pequeños o medianos proyectos todo el tiempo, y cada uno es propicio para la experimentación con nuevas metodologías, frameworks, herramientas, patrones… Un error implicará un proyecto tormentoso o (muy inusualmente) fracasado, a lo sumo un par de víctimas fatales, pero nada demasiado terrible.

Lo que degenera en… un paisano ´e cada pueblo. Y sí. Tengo que reconocer que la sensación de tener asignada una “pequeña” tarea sobre un proyecto X, bajarlo del control de código fuente y abrirlo es como la que producen esas escenas en las películas de terror en las que la mano se acerca al picaporte de la puerta… y se acerca… y se acerca… y lo gira… y la puerta se abre y… y entonces uno respira aliviado o grita (“my eyes!”). Hay de todo. Lindo, feo, malo y bueno, y muchas veces hay de todo en el mismo proyecto, en diferentes secciones o funcionalidades.

Pero también es cierto que profesionalmente uno se mantiene al día. Y las herramientas decantan. A la hora de los grandes proyectos (con suerte) las decisiones son más medidas y basadas en experiencia acumulada en proyectos reales (aunque más pequeños) y no sólo en meras pruebas o prototipos.

Al trabajar durante largo tiempo sobre el mismo producto y con la misma tecnología, los desarrolladores tienen la oportunidad de hacerse expertos en ella, con todas las ventajas (mejores resultados, menores tiempos de desarrollo, proyectos “tranquilos”, estimaciones precisas) y desventajas (obsolescencia, encasillamiento, monotonía, pocos desafíos) que esto puede conllevar (que no necesariamente se darán unas u otras).

En contrapunto, una consultora es caldo de cultivo de experimentadores casi compulsivos (el que mucho abarca poco aprieta, dicen), y proyectos cual criatura de Frankenstein, rejuntes de diferentes frameworks y tecnologías cosidos y emparchados de manera grosera…

…o cosidos prolijamente, pero en todo caso grandes contenedores de soluciones redundantes. Es por haber trabajado largo tiempo con un conjunto reducido de frameworks, patrones y tecnologías que conozco a fondo sus posibilidades y desconfío de las herramientas complementarias y complejas que vienen a solucionar problemas extremadamente simples.

Si el peligro al desarrollar un producto es la obsolescencia o el fracaso en la implementación de una reingeniería (y una dolorosa “vuelta atrás”, o un ciclo corto hasta la próxima), el peligro de la experimentación excesiva al trabajar en proyectos relativamente cortos es el desperdicio de experiencia (descubrir siempre nuevos problemas en vez de solucionar los conocidos) y una dispersión de tecnologías que desemboca en un stock de proyectos que nadie puede entender completamente (a menos que sea un experto en Silverlight, .Net, Servicios, jQuery, NHibernet, Active Record, MVC y la mar en coche) y que por tanto sólo pueden ser parchados una y otra vez.

Como siempre, la solución es huir del riesgo, de los extremos. El faro es la simplicidad, y nos alejamos de ella tanto cuando forzamos a una tecnología (tal vez ya obsoleta) a hacer cosas que no existían cuando fue pensada o cuando nos pasamos de rosca innovando y metemos en la misma bolsa (a nivel proyecto u organización) más herramientas de las que podemos nombrar en cinco minutos.

La influencia de la orientación al producto o al cliente en el desarrollo de software - I: Los muertos se dejan atrás.

Arbitrariamente (como toda clasificación) y a muy grandes rasgos, podemos dividir el mar de equipos de desarrollo de software en dos corrientes principales: enfocados al producto y enfocados al cliente.

Los equipos enfocados al producto son responsables del desarrollo de uno o varios sistemas, siempre orientados a un mercado específico (si bien puede ser definido en forma más o menos amplia): sistemas contables, para la gestión de hospitales, comercios minoristas, logística o para el control de determinados dispositivos. El producto (o la familia de productos, entiéndase de aquí en más) requiere mantenimiento y constantemente se prueban e implementan nuevas funcionalidades y cambios para justificar los lanzamientos y generar ventas.

Del otro lado tenemos desarrollos enfocados hacia el cliente: profesionales independientes y equipos de desarrollo en consultoras y software factories de todo tipo y color que luchan por armar, mantener y ampliar una cartera de clientes a los que usualmente intentan vender de todo, si es software mejor. Algunas están también especializadas en un mercado en particular, pero vale la clasificación en tanto no vendan el mismo producto a varios clientes.

Y después hay grises, pero creo que la clasificación abarca a una amplia mayoría.

Hasta ahora he sido desarrollador de productos (aunque más de uno fue acaparado por algún cliente importante). Tenía formada una imagen bastante pobre acerca de la calidad de los productos y del trabajo en consultoras (sobre todo en las grandes, pero es una experiencia que por ahora no tengo), y crucé la línea cargado con no pocos prejuicios y temores. Pero bueno, hay que alejarse de las zonas de confort, dicen.

Han pasado ya casi cuatro meses desde el salto, puedo decir que por lo menos una de las consultoras (por suerte) no es como me la esperaba. Realmente las cosas no son ni mejores ni peores, simplemente distintas, y a esto iba, a hacer un contrapunto.

Los muertos se dejan atrás (aunque hay zombies indestructible).

La huella de toda consultora es un reguero de cadáveres más o menos malolientes: proyectos cuya calidad interna deja mucho que desear, si bien hacia afuera suelen verse bastante bien (que al cliente hay que cuidarlo). El aprendizaje se da de proyecto en proyecto y los primeros en implementar determinadas herramientas o tecnologías son víctimas fatales de la inexperiencia.

En cambio, cuando trabajamos en versiones incrementales del mismo producto, siempre sobre la base de código de la versión anterior, poco a poco la experiencia se materializa en todo el proyecto a través de revisiones y refactorizaciones. El equipo (si no es testarudo) no tarda en darse cuenta de que si se mueven las lápidas y se dejan las tumbas los muertos se convierten en fantasmas que nos acecharán eternamente. La única forma de sacárselos de encima es buscar el cadáver y darle cristiana sepultura.

A cierta distancia de la línea de entrega de un proyecto que se presentará, aprobará (y si te he visto no me acuerdo), es inútil refactorizar y solucionar definitivamente determinadas cuestiones. Llega un momento en el que el sistema “es así” y punto, y aunque (por lo menos para mí) es difícil de aceptar, hay que dar media vuelta y seguir adelante.

Cuando se trabaja sobre un producto toda refactorización es provechosa y bienvenida. Incluso en las reingenierías el código “del sistema viejo” es referencia para determinar detalles de implementación, por lo que cuanto más legible mejor. Así que es sencillo cuándo determinar cuándo es conveniente hacer una refactorización o resolver un problema de fondo: siempre.

En una consultora determinar a ojo cuándo se ha llegado ese punto de no retorno es muy difícil, y los errores en este sentido son frecuentes. Muchas veces las inevitables horas fuera de presupuesto que insumen las correcciones entre presentación y aprobación superan aquellas que hubiesen sido necesarias para la refactorización, y otras veces se van horas de refactorización en funcionalidades con pocos errores y cuya prolija implementación nunca será vuelta a ver.

En todo caso, y en esto he confirmado mis prejuicios, aunque la consultora en sí no pueda desprenderse de algunos muertos devenidos en zombies, la realidad es que desde el punto de vista de un desarrollador en particular es poco probable que una vez abandonado el proyecto se lo vea volver en la misma dirección.

Suficiente, creo, para una primera entrega. Seguimos en la próxima.

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.

Cuando los resultados no reflejan la experiencia o el aprendizaje.

Hay veces que llama poderosamente la atención la brecha (otras veces el abismo) entre la calidad de un equipo y la del proyecto sobre el que trabaja. A veces para bien, a veces para mal.

En algunos se percibe una capacidad para la mejora que excede en mucho la capacidad técnica (inicial) de sus integrantes. La falta de experiencia hace que se reinventen muchas ruedas y se cometan muchos errores de esos que (tal vez pecando de un poco de soberbia) los desarrolladores de más experiencia catalogan de “típicos”, pero que son ampliamente compensados por la motivación a corregirlos, incluso en varias aproximaciones, intentando una y otra vez. Éste es el caso ideal en el que, en todo momento, la calidad del proyecto refleja todo el aprendizaje y la experticia del equipo.

Pero en otros se ve que el resultado, si bien funcional, no tiene la calidad que podría esperarse de acuerdo la experiencia de los participantes, o que surgen (en el peor de los momentos) problemas que derivan de errores que podrían haber sido detectados (e incluso corregidos) con relativa facilidad por los miembros de más experiencia, problemas que luego de un tiempo de incubación terminan impactando transversalmente en todo el proyecto volviéndose de difícil o imposible solución.

Mucho tiene que ver en la calidad de un proyecto la habilidad para resolver problemas de sus integrantes. Mucho más tendrá que ver la experiencia y muchísimo más la motivación.

Es la experiencia la que permite ganar tiempo aplicando soluciones ya probadas y enfocarse en aplicar la habilidad en resolver aquellos problemas que hacen único a cada producto de software. Pero es la motivación lo que lleva a utilizar la (mucha o poca) habilidad disponible y aprender (con mayor o menor velocidad) de los errores y aciertos (propios y ajenos), que es lo mismo que decir “adquirir experiencia”.

Pero una cosa es la motivación a aprender y otra la de aplicar el resultado de ese aprendizaje al proyecto en particular sobre el que se está trabajando y aprendiendo, y de ahí la brecha entre capacidades y realidades que mencionaba al principio. La mayoría aprende de los errores y ve posibilidades de mejora, pero son menos (muchos menos) los que desandan el camino para corregirlos o implementar esas mejoras en el código ya escrito. ¿Por qué?

Se me ocurren un par de factores que hacen de esa decisión (la de seguir sin mirar atrás) la más razonable:

• Si el alcance del proyecto es acotado y está próximo a entrar en una etapa de mantenimiento (¡exclusivamente!) correctivo, de poco o nada servirá mejorar lo que de todas maneras funciona (suponiendo que funciona razonablemente, ya que de no ser así no hay alternativa posible).

• Si el problema es transversal y está demasiado extendido, puede ser mejor será tratar de no cometerlo de aquí en más y corregirlo sólo en donde las modificaciones sean imprescindibles.

• En cualquier caso en el que el impacto sea menor que el esfuerzo que requiera la corrección. El problema aquí es la medición de ese impacto, para la que deberíamos considerar no sólo la situación actual sino también a futuro. Si estamos desarrollando un producto que se pretende mejorar y ampliar indefinidamente (en vez de “cerrar y entregar”) la acumulación de pequeños problemas terminarán afectando la calidad haciendo cada vez más difícil implementar nuevas funcionalidades y forzando una (mucho más riesgosa y costosa) reingeniería.

En definitiva, es cuestión de decidir en forma consciente y explícita si vale la pena el esfuerzo dada cada situación en particular. Pero hay otros factores, menos técnicos y más humanos o de organización, que bloquean las alternativas:

• Simple resistencia al cambio, el aferrarse a un estado en el que los problemas (graves o no) son conocidos.

• Una patológica actitud defensiva puede hacer que cualquier sugerencia se vea como una crítica.

• Soberbia, que impide ver los problemas y desventajas que inevitablemente están presentes en cualquier solución.

• Desinterés o el clásico “sólo hago lo que me ordenan”.

• Escaso trabajo en equipo o excesivamente compartimentado, que hace que se pasen por alto los problemas y posibles mejoras transversales.

Son estos factores son los que hay que detectar y combatir porque son los que llevan a decisiones irracionales o por defecto (aquellas que surgen de la no-decisión). El ideal es que el equipo tenga el control del proyecto, lo que implica ser consciente de los aciertos, de las cuestiones “mejorables”, de los errores que hay que corregir y de los que hay que soportar.

Trabajo remoto.

Las herramientas de comunicación han avanzado muchísimo, qué duda cabe. Es posible sentarse en el escritorio de la oficina desde casa de una forma razonablemente transparente utilizando una VPN, conversar con los demás miembros del equipo por chat, por voz o video a través de servicios que prácticamente todo el mundo utiliza de forma muy natural y cotidiana. Si pensamos en cómo este conjunto de tecnologías –de comunicación- ha impactado en la economía y las relaciones laborales veremos gran dificultad en imaginar en qué las transformará de aquí a 20 o 30 años.

En el rubro del desarrollo de software -integrado necesariamente por personas y empresas acostumbradas y abiertas a la tecnología- todos, en mayor o menor medida, utilizamos algunas herramientas de trabajo remoto. Aquellos con más experiencia recordarán con extrañeza los no tan lejanos tiempos en los que instalar, configurar, verificar un problema o arreglar una emergencia, eran todas tareas que implicaban moverse e ir a visitar al cliente.

De un tiempo a esta parte -apenas un par de años-, la “presencia virtual” se está extendiendo hacia dentro del equipo de desarrollo, al que siempre imaginamos como un montón de personas trabajando juntas en el mismo lugar. Si bien la imagen anterior sigue representando la norma, opciones de trabajo remoto comienzan a analizarse seriamente como una posibilidad por cada vez más organizaciones, y comienzan a configurarse otro tipo de equipos, a los que usualmente se nombra como equipos distribuidos.

Por otro lado, desde lo ágil siempre se ha dicho –y yo comparto- que la coordinación y comunicación es a la vez demasiado importante y demasiado compleja en el desarrollo de un producto de software, por lo que deberíamos optar, siempre que sea posible, por la forma más eficaz de coordinar y comunicar: cara a cara.

Debemos ser conscientes de que al utilizar estas nuevas tecnologías estamos, en mayor o menor medida, sub-optimizando la comunicación. Es una opción racional si -y sólo si- los beneficios superan el costo de esa sub-optimización. Es decir que si para una consultora argentina tener un cliente español no representa ninguna dificultad operativa seria, no por ello tiene sentido hacer una videoconferencia con otro cliente cuyas oficinas están a escasos 200 metros. Una software factory que alquile oficinas con espacio e infraestructura suficiente para todos sus empleados no se beneficiará de las posibilidades del trabajo remoto en tanto no reduzca el costo del alquiler o capitalice una mayor velocidad de respuesta como nuevos clientes o precios más altos en cada contrato, o en un aumento medible de la productividad.

Yendo un poco a lo personal, para los miembros de un equipo tener la posibilidad de trabajar remotamente implica libertad de horarios y –sobre todo- el aprovechamiento de esos momentos de inspiración o entusiasmo, esquivando la saturación. Si a uno se le ocurre una gran idea un domingo a la mañana y tiene ganas y tiempo de probarla lo antes posible, ¿por qué no? Si se nos hace cuesta arriba un lunes a la mañana o un viernes a la tarde y las fechas límite lo permiten, ¿no sería más productivo entrar tarde o irse temprano, descansar, distraerse, en vez de luchar por terminar algo que en otro momento de mayor motivación nos llevaría la mitad de tiempo?

Suena bien, pero tiene un límite. Recordemos los costos de los que hablábamos al principio: de poco servirá todo ese trabajo adelantado si la funcionalidad había cambiado (la cambió el analista trabajando tarde a la noche desde su casa) y el desarrollador no se enteró por no chequear el correo.

Sobrepasamos un límite cuando, más seguido que esporádicamente, unos quedan a la espera de poder comunicarse con otros y los horarios no coinciden y comienzan a aumentar los tiempos muertos. Desde lo personal, ese costo de la libertad puede pagarse en forma de constantes llamadas y comunicaciones disruptivas por temas laborales que impiden una desconexión completa.

Para complicar las cosas las personas son extremadamente diferentes en este sentido. Algunas preferirían trabajar todo el tiempo en forma remota y sin horarios y otros ir a la oficina con un horario fijo, salir y no ser molestados para nada hasta el día siguiente. ¿Entonces? Dependerá de cada equipo encontrar el punto justo en el que todos se sientan cómodos, lejos de los extremos del control estricto o de la amalgama entre vida personal y laboral.

Personalmente creo que las herramientas de trabajo virtual deberían estar disponibles para todos, sobre todo teniendo en cuenta que en general las empresas ya cuentan con el software necesario (o hay opciones gratuitas o de muy bajo costo) y que no deberían demandar mucha infraestructura adicional a la que una empresa suele tener sólo por estar en el rubro de sistemas. Pero que al mismo tiempo deben establecerse ciertas reglas. Un horario en el que todos deberían estar en el mismo lugar, ciertas reuniones a las que sea obligatorio asistir en persona, cierta flexibilidad diaria (2 o 3 horas en una jornada de 8), una cuota de horas a cumplir por mes, ese tipo de cosas.

Debemos, en definitiva, tratar estas herramientas como a todas las demás: por más casos de éxito que escuchemos, por más buzz que se haya generado alrededor de ella, tiene que ser adecuada para nosotros.

Curados de espanto.

No son todos malos hábitos los que adquirimos los programadores en el transcurso de nuestra vida profesional. Para nivelar un poco quiero traer a cuento varias características que casi todos compartimos, y que de seguro estarán presentes en un buen programador… tienen que estar presentes en un buen programador, ya que todas giran alrededor de un tema que es central en el desarrollo de software: los errores.

Todo software no trivial tiene errores (y como siempre digo, la mayoría de los triviales también). Y si por buena ventura un software en particular no los tiene seguro que los requerimientos que le dieron origen sí. Y si por alguna de esas casualidades cósmicas los requerimientos (y por tanto el software) son consistentes en los papeles, seguro que el usuario o el analista o el redactor o el programador se ha equivocado en su interpretación u omitido alguno de ellos con tal mala suerte que el resultado es consistente aunque, por supuesto, erróneo… y en el imposible caso de que todo esté bien… serán las necesidades del cliente las que cambien o las que cambiarán en breve.

Y hay que tener en cuenta que los innumerables errores detectados (ya sea durante el desarrollo o como defectos en el producto) son apenas una pequeña fracción de los que cometemos todos los días… y sin embargo aquí estamos.

Aunque a veces sucede, no es usual que ante un problema un programador se rasgue las vestiduras, se deprima, paralice o caiga presa de delirios apocalípticos. Esto es, básicamente, porque nuestra vida laboral es una eterna sucesión de problemas y soluciones… que generan más problemas.

¿Qué es lo que –al menos creo yo que- he aprendido?

El camino para estar a salvo de los problemas no es evitar que se produzcan (son inevitables) sino tener alternativas.  Para eso existen los resguardos, los procedimientos alternativos, las salidas de emergencia. Prevenir no es sólo prevenir el problema, sino también sus consecuencias.

Los manotazos de ahogado no sirven. La suerte existe, pero es escasa y no se puede confiar en ella. Hay que medir el costo de un intento a ciegas. ¿Podemos hacer una prueba rápida, a ver si funciona? ¿No romperemos algo más en el intento? Bueno, hagámosla. Pero no podemos perder tiempo tirando tiros al aire, la magia no existe y hay que pensar, buscar, investigar, rastrear, no queda otra.

Identificar precisamente el problema es siempre el primer esfuerzo. Tratar de arreglar “algo” que no se sabe qué es es sencillamente imposible. Trabajar sobre las consecuencias es una opción para ganar tiempo, pero nunca una solución a mediano o largo plazo.

No se puede resolver un problema de fondo sobre la emergencia. Cuando se presenta una emergencia hay que resolverla (en lo posible rápidamente) para aliviar la presión y poder pensar y resolver el problema de fondo con tranquilidad… Creo que en esto todos fallamos más de una vez, tal vez no tanto en la resolución rápida, sino en la disolución de la causa subyacente. ¿Cuántas veces dejamos parches provisorios como soluciones “definitivas” que no tardan en crear más y más graves apuros?

Presionando no se resuelve nada, por lo menos en sistemas. No es de mucha ayuda gritarle lo obvio al administrador de la red –que todas las terminales están fuera de servicio o que el mundo va a explotar-. Si encuentra la solución en un tiempo razonable será a pesar de ello y no gracias a ello. Ya habrá tiempo de repartir responsabilidades y amenazas luego, hay que concentrarse en buscar una solución.

Hay que dejar trabajar. Si nos es posible paliar las consecuencias o aliviar la presión, ésa es la forma de ayudar. Y si no está entre nuestras posibilidades hacerlo… mucho ayuda el que no estorba, dice el refrán.

Aprender por prueba y error implica resolver, aunque sea parcialmente, problemas de fondo. De cada problema, de cada situación, tenemos que quedarnos con alguna mejora. Puede ser pequeña, tal vez no una solución completa, tal vez apenas una alerta temprana para la próxima vez, algo, lo que sea. Si vivimos en un interminable devenir de emergencias, la única forma de salir de ello es de a poco, aprovechando el poco tiempo que nos queda para ganar más tiempo.

La carrera.

Otro gran aporte de @Cerebrado, que esta vez ubicó en Izismile una serie de ilustraciones que recorren una conocida historia desmotivacional: The Management Rowing Race.

Sistemas administrativos, software y poder.

El poder juega un papel central en la conformación de un sistema administrativo. Yendo un poco más lejos, estoy bastante convencido de que el sistema administrativo mismo no es más que el reflejo de la distribución del poder en la organización en un momento dado. Las modificaciones en la estructura o en la ubicación de las personas que la integran son en realidad fluctuaciones en la distribución del poder subyacente en la organización, y no al revés.

Es un buen momento para aclarar que hablo de sistemas administrativos y distribuciones de poder reales. Todos sabemos que los elementos formales (el organigrama, los manuales, las normas, el software de soporte) no siempre reflejan (rara vez reflejan, en realidad) el sistema administrativo real de una organización. Se dan casos extremos (y los he visto) en donde incluso las declaraciones de los integrantes de la organización sobre “cómo se hacen aquí las cosas” tampoco tiene mucho que ver con cómo se hacen realmente.

Los que participamos en el desarrollo de sistemas informáticos de gestión (software aburrido, bah) lo sabemos mejor que nadie, ya que el software que construimos pretende ser un soporte a ese sistema administrativo o  incluso el reflejo total de éste, en los casos más ambiciosos. Así que el proceso de desarrollo es extremadamente sensible a estas fluctuaciones que son, recordémoslo, fluctuaciones en la distribución de poder de la organización para la cual trabajamos. Los proyectos se paquequean, una y otra vez, se cancelan, se aplazan, se retrasan, se abandonan.

El problema radica en que el software es un elemento mucho más rígido, mucho menos maleable una vez establecido que el sistema administrativo al que pretende soportar o reflejar. Esta rigidez es un arma que utilizarán o contra la que lucharán los diferentes actores en pos de acumular poder o mantener el que han obtenido. En efecto, una vez plasmados en código determinados circuitos de información, autorización y sectores de discrecionalidad éstos se vuelven mucho más difíciles de modificar.

Así, tenemos al que ocupa una posición dominante dentro de la estructura de su organización, que desea que “todo siga igual, pero informatizado” y que en realidad ve al proyecto con cierta desconfianza y prefiere seguirlo de cerca y con mano de hierro. Otro que, percibiendo la implantación como una oportunidad, desea “establecer un sistema más racional en la distribución de las actividades” y lucha por introducir modificaciones (sabemos que la racionalidad poco y nada tiene que ver con esa distribución, aunque una racionalidad aparente ayuda a apoyarla). Y también tenemos al que, viendo el proyecto como una amenaza declarada, pone palos en la rueda retaceando tiempo, recursos e información.

A los usuarios finales, generalmente fuera del círculo de decisiones formales respecto del software, les queda la chance de evaluar su posición final dentro del circuito propuesto y apoyar o rebelarse según el resultado de esa evaluación. Se les llamará entusiastas y dinámicos a unos, estáticos o reacios al cambio a otros, o arribistas e imprudentes a unos y expertos a otros, según el lugar que ocupe el interlocutor, favorecido o amenazado por los cambios.

Pero cuidado porque, ya lo dijimos arriba, las estructuras formales poco y nada tienen que ver con las reales. Detrás de los puestos más insignificantes se esconden armas poderosas… puede ser que la empleada que ve su posición amenazada por el nuevo sistema comente al gerente general durante el viaje en que éste la acerca a su casa (en el mejor de los casos), una y otra vez, lo poco conocedores de la empresa que son los analistas del proveedor, y cómo el gerente de tal está influenciando las decisiones a su favor para quedar mejor ante los dueños.

Vemos que la “resistencia al cambio” puede ser feroz y provenir de los lugares más inesperados. Tal vez lo más difícil para el proveedor, pobre pajarito en este nido de serpientes, sea determinar de qué lado debe ubicarse, es decir, a quién escuchar y a quién no. Pero para complicar más la situación, el “pobre pajarito” puede que no lo sea tanto, que existan conexiones fuertes entre actores por fuera de las estructuras y no siempre entre los más altos representantes de ambos. Podría ser el analista funcional el que lleve a la secretaria a su casa escuchando la cantinela sobre la inutilidad del puesto de su jefe (el de la secretaria… o el del analista).

Si las estructuras de poder reales se pareciesen a los organigramas y los circuitos administrativos reales a los cursogramas programar sistemas de gestión sería juego de niños y las metodologías ágiles una verdadera pérdida de tiempo. Pero nada de eso es así, y por eso la agilidad en el proceso de desarrollo es una herramienta imprescindible para satisfacer siempre los deseos de aquél al que le toque estar (hoy) arriba y seguir cobrando… por cierto, tal vez el que está hoy arriba prefiera un contrato más tradicional y un ciclo de vida clásico, ya que éste compromete más a la organización con el diseño inicial, que es el que él puede influenciar… la idea de que todo puede cambiar en cualquier momento no es tan agradable cuando se mira el mundo desde arriba.

Es ante todo por estas lindas y por demás mensurables y calculables cuestiones que los proyectos de software de gestión suelen transitar senderos tortuosos. Cuestiones que, dependiendo del papel que juguemos dentro del desarrollo, nos quitarán más o menos el sueño, pero estarán siempre presentes ya que son las que dan origen a aquello que modelamos: sistemas administrativos. Cuando diseñamos una base de datos o codificamos estamos representando, finalmente, relaciones de poder. ¿Lo habían notado?

Crisis, ajuste, motivación, productividad, oportunidad.

Corren tiempos de crisis. Traducido al argentino esto implica, aunque sea implícitamente (vía inflación, que aquí el que no corre vuela y el margen de beneficio a corto plazo se valora incluso más que la supervivencia), “ajuste” de salarios. Escribo “ajuste” y no ajuste porque con el entrecomillado pretendo denotar que “ajuste” no es ajuste sino un eufemismo para baja que suena feo. Y es baja y no “congelamiento” o “suspensión de aumentos” debido al pequeño detalle de la inflación mencionado más arriba.

Pero bueno, es lo que marca el mercado y si el golpe de la crisis se distribuye justa o injustamente entre capital y trabajo (o la suposición de que justicia y economía están relacionadas de alguna manera) no es el tema de este post.

Por otro lado, en la industria del del software (y supongo que en cualquier otra cuya base esté mayormente conformada por trabajadores del conocimiento) motivación y productividad están fuertemente relacionadas, si es que no son la misma cosa (¿podría decir que está motivado un programador que no produce? ¿por qué otra razón que no sea falta de motivación podría no producir un programador? Es decir, el que está motivado llega a un resultado, que puede no tener un gran nivel o calidad, pero producir produce).

Mi hipótesis es que si el mencionado “ajuste” afecta a la productividad en esta industria es -por lo menos principalmente- a través de esta forma indirecta, por su impacto en la motivación.

Es un buen momento para recordar aquello de que el motivador más caro es el dinero (creo que es una frase célebre pero no puedo encontrarla, tal vez esté formulada de otra manera). Es por ello que me cuidé de escribir que el ajuste “afecta” a la productividad y no que la disminuye o aumenta, ya que la productividad depende de la motivación y la motivación no necesariamente del dinero.

Me parece una explicación bastante sencilla de por qué hay emprendimientos o proyectos en los que la productividad aumenta considerablemente en tiempos de crisis: hay ajustes monetarios pero la motivación, y por tanto la producción (el desarrollo) se mantiene (o incluso aumenta) y la productividad (la relación entre recursos utilizados y avance obtenido) mejora.

Y también de por qué hay otros proyectos que florecen velozmente una vez pasada la tormenta: si el aumento de productividad es en la práctica una mejora en el proceso de desarrollo el proyecto actúa tal cual un resorte que absorbe el impacto primero e impulsa al equipo, empresa, organización o producto cuando la crisis pasa.

Y de por qué otros proyectos, incluso sobreviviendo a la crisis, no logran volver a ser lo que eran. Hay un punto en el que la motivación cae de tal manera que luego (parafraseando a un gran amigo) “a esto no se lo levanta ni con plata”.

Ejemplo un poco burdo: imaginemos tres equipos enfrentados a la misma crisis. En la práctica (aparte del “ajuste”), lo que sucede es que faltan horas/hombre de analistas funcionales para las pruebas, que el recurso de las horas extra está agotado (es decir, los actuales analistas están agotados) y que no hay posibilidades de contratar más.

• Equipo I: no hay respuesta. El equipo hace lo que siempre hizo: programar y punto. El proyecto se atrasa, el producto no mejora, se codifica pero no se prueba y las modificaciones no salen, etcétera. Para cuando pasa la crisis hay un retraso importante respecto de la tecnología y de los competidores que han sabido aprovechar o por lo menos capear el temporal.

• Equipo II: el equipo pone el hombro y se pone a probar. No son buenos probando pero hacen lo posible y la productividad sufre pero las cosas salen. Si pasa la crisis se vuelve al ritmo normal, y tal vez con más recursos se logra recuperar el tiempo perdido, aunque con gran esfuerzo extra.

• Equipo III: no se resignan a producir menos ni a trabajar más, por lo que buscan la forma de trabajar mejor. Así que buscan la forma no de cubrir las horas faltantes sino de requerir menos horas de pruebas. Descubren (imaginemos que no las conocían) las bondades de la programación orientada al test, herramientas para automatizar tests unitarios y funcionales, reducen costos con máquinas virtuales, programan simuladores de componentes y un largo etcétera. Para cuando la crisis pasa están mejor parados que al principio y cuando se recuperan los recursos éstos se utilizan para hacer más que antes logrando una gran expansión sobre un mercado depurado de competidores.

¿Cuál habrá sido el nivel de motivación en cada equipo antes de afrontar la crisis? ¿Y al final?

El noble arte del baseball.

Que consiste en

“batear las pelotas tan lejos como sea posible y dar vueltas al tema para hacer puntos”,

inspiradísima frase de “Trabajar por proyectos o la subversión organizativa”, el post de hoy de Sueños de la razón, que les recomiendo.

Twitteado por @Yoriento. BTW: ya sé, esto ya casi es microblogging, qué vergüenza.

Ladran Sancho, señal de que cabalgamos.

Y nada más cierto, sobre todo si hablamos de desarrollo de software. Con los años me acostumbré a interpretar como nubes en el horizonte lo que para otros es motivo de festejo. ¿Todo avanza sobre ruedas? Mmmm… mala señal. Pongamos por caso…

…que todo comienza con la típica frase apocalíptica “Esto es una pavada”. Que leemos o nos comentan los requerimientos y todo parece sencillo…

…que a partir de ello hemos elaborado una estimación y vuelve a las pocas horas con un escueto “ok”. ¿Ok? ¿No falta nada? ¿No nos olvidamos de algo? ¿No les parce demasiado, o demasiado poco, o muy caro, o muy barato?

…que luego el diseño va surgiendo sin graves problemas, y que después de remover algunas piedras y hacer un par de ajustes menores se termina todo en tiempo y forma.

…que las pruebas no arrojan errores de gravedad…

¿Qué clase de proyecto es ese? Uno que va a explotar como fuegos artificiales.

Lo primero que se me ocurre para justificar lo anterior tiene que ver con las zonas grises, los cambios, los errores.

Todavía suponiendo que -en un proyecto muy particular- los dos primeros elementos –zonas grises y cambios- no estén presentes, el tercero –errores- estará siempre ahí. En cualquier metodología -ya sea ágil, evolutiva o lineal- se establecen puntos de control a lo largo de todo el proyecto y las tareas son divididas –o deberían serlo- de manera tal de que todos los componentes pasen a lo largo del proceso bajo la mirada –supuestamente atenta- de por lo menos dos pares de ojos (aunque con par y medio alcanzaría). Si todo va más o menos bien surgirán incongruencias, malos entendidos, omisiones, errores de interpretación, de diseño, de codificación y de cualquier otro tipo imaginable. Si todo va realmente bien se irán corrigiendo con el tiempo, aunque aparecerán nuevos problemas. Por eso su ausencia es clara señal de que algo anda mal: la ausencia de ladridos indica la ausencia, la distracción o la indiferencia de los perros.

Los sistemas informáticos –incluso los más triviales- son lo suficientemente complejos como para que un componente menor o una situación improbable mas no imposible tire todo abajo. Incluso sin llegar a ese extremo tenemos que recordar que el software en su conjunto –sobre todo el de gestión- es necesariamente un subsistema de un sistema mucho mayor, una organización (el “negocio”). Desde este punto de vista no es más ni menos que un servicio para esa organización. Como pasa con todos los servicios, solamente notamos su presencia a través del sinfín de problemas e incomodidades que surgen cuando andan mal. Y ahí sí que aparecen los perros –pero ahora mostrando los dientes- y será mejor que cabalguemos rápido.

Un ejemplo simple: la falta de un calefactor o uno averiado en invierno puede interrumpir el trabajo por varios días, con todos quejándose amargamente. Si esto no sucede –las quejas, quiero decir- es que a) no hay trabajo que interrumpir, b) la calefacción no hacía falta, c) todos murieron congelados, d) se fue todo el mundo a casa o al bar de la esquina, o… en fin, en todo caso vemos que no es tan malo enterarse de que algo no anda, que peor es hacerlo a último momento o, sobre llovido mojado, que nadie se queje o que las quejas se aplaquen solas ante la falta de solución (¿resignación? ¿abandono?).

Luego, la famosa frase –que no es del Quijote, según revela el oráculo- se aplica también a nivel de empresa u organización… y no necesariamente en cuestiones de infraestructura o servicios: pensemos en la diferencia entre las reacciones ante cada pequeña o gran caída de Google o pifie en Microsoft (el mundo entero se transforma en una gran jauría enfurecida) y el lento, continuo y casi silencioso desangrarse de Yahoo!

Así que ¿problemas? ¿quejas? Cabalgamos.

Calidad y consultoras, software factories y demás.

Hoy leí por un lado Welcome to the machine en Oh My Blog! I Can’t Believe It!, que nos relata la experiencia del desarrollo de software desde las trincheras de los grandes ejércitos:

[…] Pongamos que trabajas en un proyecto en el que participa un consorcio de diecisiete empresas, y estás subcontratado por parte de una de esas empresas […]

[…] Y entonces el alucinómetro estalla cuando te dicen que no hay diseño ni especificaciones hechas. Que tu vayas tirando código, que ya ellos haran ingeniería inversa para sacar la especificación y diagramas de clases y demás en base a lo que tu hagas […]

Más tarde me crucé con Burro (o consultor) grande, ande o no en Diario de un director de sistemas:

[…] Como otras veces, el debate sobre el precio y el valor de las consultoras grandes. […] Yo estuve siete u ocho años en una de esas consultoras. […] No cabe duda de que en el coste hora de un consultor de estas compañías estás pagando una parte de la oficina de Picasso o La Moraleja, la esponsorización de una estrella del golf o un equipo de Fórmula 1, y los salarios "indecentes" (es una forma de hablar, yo no los considero así) de los socios o partner o principals, según como se llamen en cada casa. Todo esto es verdad. No creo que nadie lo discuta.

[…] tampoco ofrece dudas que un documento bien preparado por gente de estas compañías suele significar un cuidado en la presentación y en el contenido bastante mayor del que te presentan otras empresas más pequeñas. Y lo mismo que hablamos del documento podemos aplicarlo al desarrollo y ejecución de los proyectos, siempre y cuando estemos hablando de proyectos de cierta magnitud/dificultad […]

¿Qué imagen es más cercana a la realidad? ¿La de la consultora de renombre y proyectos desastrosos que de alguna manera terminan funcionando o la de la experta en la ejecución de proyectos a gran escala bajo estrictos estándares de calidad? Tal vez no haya una única respuesta, sino dos caras de la misma moneda.

Hablando de imágenes, de percepciones, es deber aclarar primero fuentes y preconceptos. Mi visión es la del programador, del desarrollador que conoce un poco tras bambalinas e intuye otro tanto. Aunque nunca he trabajado en una gran consultora o en una empresa con un área de desarrollo gigantesca como las que se mencionan, conozco y he compartido proyectos con programadores y analistas que sí y con los que he comentado muchas veces los contrapuntos entre éstas y los equipos pequeños o medianos.

A partir de esa muestra de experiencias (y juzgando contra mis propios estándares), yo me formé la idea de que:

• La irracionalidad de la metodología empleada (no la enunciada, sino la de todos los días), ya sea etiquetada como ágil o tradicional, llega a extremos insospechados transformándose en un conjunto de rituales vacíos.

• La conveniencia de las herramientas y lenguajes que se utilizan con respecto a los requerimientos de cada proyecto es -por lo menos- cuestionable en la mayoría de los casos. Se utiliza un martillo y todos los proyectos son clavos. Si el cliente pide tornillos se le entregan clavos en cajas de tornillos.

• La robustez de la arquitectura de los proyectos es similar a la del queso gruyere. De todas maneras su utilización (es decir, cuánto se respeta en la práctica esa estructura enunciada) es prácticamente nula.

• La calidad del código suele ubicarse entre mediocre y WTF.

• Los documentos de análisis internos (no los bonitos que se presentan a los clientes sino los que se terminan utilizando, si es que existen) no sirven más que de punto de partida para que los desarrolladores hagan volar su imaginación.

• Y por supuesto, las modificaciones y el mantenimiento son un infierno para ellos…

• que de todas maneras es raro que tengan que soportar por más que un par de años (la rotación es vertiginosa).

Ya sé, ya sé, hay proyectos y proyectos. La misma firma de pobre desempeño en uno desenvolverse bien en otro, y mucho tendrá que ver con ello el control y la seriedad del otro lado del mostrador. Pero sigamos.

El cliente de “Pelota Plus Consulting” no es “Megaempresa S.A” que necesita un ERP. El cliente es el gerente-de-lo-que-sea de “Megaempresa” que contrata a “Pelota Plus” sabiendo que toma una decisión irreprochable más allá del resultado del proyecto, y eso es lo que compra: cierta (mas no absoluta) seguridad para sí más allá de los resultados. ¿Para qué arriesgarse? “Megaempresa” tiene mucho dinero para gastar y el precio está consolidado por el mercado.

La atención que brinda la consultora a su cliente (el gerente-de-lo-que-sea) es inigualable: un contrato importante con muchos ceros a la derecha, presentaciones, carpetas, folletos, aulas para capacitación, equipos, gente de traje con una tarjetita a la altura de la solapa y toda la parafernalia necesaria para hacer de él alguien importante dentro de “Megaempresa”.

Todos los puntos oscuros que mencioné al principio son invisibles tanto para el cliente como para “Megaempresa”. Conforman una deuda técnica que la consultora adquiere (resultado inevitable de la industrialización del desarrollo) pero que luego transfiere a “Megaempresa” al facturarle capital e intereses (más su propio margen de beneficio) en forma de horas de mantenimiento. El cliente no sabe -ni le interesa- por qué se tardan 8 horas en correr un botón de un formulario.

¿Que se podría hacer mejor? No tiene que ser perfecto, sólo funcionar. ¿Que podría ser más barato? La pequeña consultora o equipo de desarrollo implica más riesgo y el cliente ya está asumiendo mucho… si la cosa se complica él puede terminar viendo el partido desde la tribuna.

Por lo menos así lo veo yo.

Sistemas administrativos, software, avances, cambios, revoluciones.

 

Encontré la imagen que ilustra este post en Acceso Directo (que a su vez lo vio en Abadía Digital, que lo sacó de Digg… ¿es que nadie dice nada nuevo ya?). Viene muy a cuento de lo que estaba escribiendo, que es lo que sigue:

Es un camino posible para los proyectos de desarrollo de sistemas (de soporte a la gestión en las organizaciones) el que se inicia con trabajadores de las distintas áreas (futuros usuarios) comentando con un analista funcional el recorrido de la información en los diferentes procesos en que participan. Es un camino que continúa con el analista transformando esa información en especificaciones (tal vez haciendo algunas recomendaciones de cambio al cliente), alguien modelando una base de datos, programadores codificándolo en forma de formularios, validaciones, autorizaciones, un sinfín de ajustes, problemas menores y mayores, retrasos… Sigue luego de la instalación con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino del desarrollo a medida.

En el otro extremo de un amplio espectro de relaciones posibles entre el cliente y el equipo de desarrollo, otro camino comienza más o menos igual, en esa famosa charla entre analista y usuario. Pero luego es el analista el que indica las adaptaciones al recorrido de la información necesarias para la implantación del software. Sigue con la capacitación a los usuarios, la implantación del software, migración de datos… y termina más o menos igual que el anterior, con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino de la adopción de un sistema de software “enlatado” (ya sé, no es enlatado exactamente pero para el caso está bien, no seamos muy estrictos con los términos).

Esos son dos extremos, obviamente teóricos (o por lo menos muy poco frecuentes), de una escala absolutamente arbitraria creada al sólo efecto de poner en tema al lector de este artículo.

Lo que ubica a todo desarrollo de la vida real en algún punto intermedio de esa escala es una negociación entre cliente y proveedor que tiene lugar en algún punto o a lo largo de todo el proceso previo al desarrollo propiamente dicho. En ella se establece en qué aspectos se adaptará el recorrido de la información en la organización a las necesidades específicas del proveedor del sistema y en qué otros aspectos se adaptará el proveedor del sistema a las necesidades o caprichos del cliente.

Lo que es seguro es que el resultado final -en términos de circuitos administrativos- no se apartará demasiado del original del cliente (en un extremo) o del implementado anterior y repetidamente por el proveedor (en el otro). Tampoco será sustancialmente diferente al que gente de sistemas como yo, analistas, programadores, administradores, contadores, ingenieros y demás profesionales hemos aprendido en la facultad o a través de la experiencia.

Finalmente, y para resumir, la organización termina haciendo más rápido (mucho más rápido) más o menos lo mismo de antes o pareciéndose (usualmente para mejor) a todas las demás en el mercado.

Con lo que volvemos a la imagen que ilustra todo esto. Hemos resuelto efectivamente el “problema”. Hemos reducido costos y personal, acelerado los procesos administrativos, optimizado tiempos y recursos… todo mejor y más rápido y sin embargo, por debajo de todo eso, persisten los mismos problemas que enfrenta la administración… porque nada ha cambiado realmente todavía.

Que no se entienda lo anterior como una queja, que no lo es. A lo que apunto es a esto: la tecnología ha revolucionado nuestra vida y sociedad en muchos aspectos. Hoy la mayoría de las organizaciones cosechan el fruto de esta revolución en forma de un aumento en la velocidad, alcance y menores costos de funcionamiento de sus circuitos administrativos. Este aumento no ha sido lineal sino exponencial, por lo que los cambios han sido profundos. Pero en este aspecto (el de los circuitos administrativos en las organizaciones) no podemos hablar de revolución, por lo dicho anteriormente: las organizaciones siguen funcionando más o menos como antes.

Creo que en el transcurso de nuestras vidas este “cambio” se transformará en una “revolución”. Comienzan a surgir nuevas formas de organización. Formas de organización que no “aprovechan”, sino que tienen origen en las posibilidades inherentes a la tecnología de la que disponemos ahora y de la que no disponíamos antes, marcando una diferencia cualitativa.

Proyectos de software colaborativos, Wikipedia y demás wikis de todo tipo, comunidades creadas alrededor y a través de determinados servicios o soportes como Facebook, Twitter, Digg… toda esa (aunque no solamente esa) cosa “2.0”.

Es un comienzo. En definitiva todos esos proyectos, empresas o comunidades/servicios que mencioné se apoyan o son en alguna medida organizaciones “comunes” con un lado “tradicional”. Pero creo que tienen el potencial de generar algo diferente. Diferente y seguramente también ajeno a ellos mismos. Algo revolucionario.

¿Nuevos recorridos para la información? ¿Ningún recorrido en absoluto, un especie de caos acotado y dirigido hacia determinado objetivo? ¿Organizaciones sin objetivos concretos propios? ¿Organizaciones con un objetivo amplio (beneficio económico, por ejemplo) y sin reglas formales establecidas? ¿Con wiki-reglas que pueden hacerse y deshacerse, que “todo el mundo puede editar”? ¿Que un sistema implementa automáticamente en forma de circuitos cambiantes? ¿Organizaciones que se generan espontáneamente y que desaparecen tan rápido como se crearon, también espontáneamente? Quién sabe.