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.

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

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.

Web vs. Desktop.

  La eterna batalla, la eterna duda: ¿Debería ser una aplicación desktop o un servicio web? Para mí no hay dudas: allí donde una conexión entre cliente y servidor esté disponible, web, y no se hable más. Pero es sólo una opinión de programador fundada exclusivamente en mis gustos y preferencias a la hora de construir el software.

Acabo de leer el largísimo (y sin desperdicio), muy recomendable post Why I’m Done Making Desktop Applications, donde el autor compara no sólo los resultados técnicos sino también los económicos y comerciales entre las versiones web y desktop de su aplicación.

A modo de resumen, y para tentarlos a seguir hacia el artículo original, enumero las razones que expone Patrick para su nueva preferencia por las aplicaciones y servicios web:

• The Shareware Funnel Is Lethal: el camino que debe atravesar el posible cliente hacia la compra es largo y penoso (una frase inspirada acerca de la instalación: “Click through six screens that no one in the history of man has ever read”).

• Web Applications Convert Better

• Your AdWords Strategy Is Very Sensitive To Conversion Rates

• Web Applications Are Easier To Support

• The Age Of The Pirates Is Coming An End, Jack

• Phone Home vs. Google Analytics

• Web Apps Can Be Customized Per User

• Long Cycles Mean Low Innovation.  Short Cycles Mean Fast Innovation

Cada punto está muy bien expuesto y las razones sólidamente fundamentadas. Vale la pena leerlo en profundidad para beneficiarse de la experiencia de quien ya ha dado el salto. Link:  Why I’m Done Making Desktop Applications.

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.

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?

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.

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.

Entre la formación y la realidad.

Creo que hay una gran brecha entre la orientación que brindan las distintas carreras de sistemas y la realidad del mercado del desarrollo de software, por lo menos aquí en Buenos Aires y con respecto a la UBA (la Universidad de Buenos Aires, que es la universidad pública, gratuita y –por lo menos para las carreras que nos ocupan- de acceso irrestricto).

IMHO, por un lado el mercado requiere programadores para satisfacer una demanda creciente (incluso en estos tiempos de crisis) de desarrollo, mantenimiento (sobre todo), adaptación o implantación de sistemas de gestión de la información. Sistemas de pago, de facturación, de cuentas corrientes, de control de la producción, etc., y cada vez más orientados a negocios o rubros específicos (panadería, gestión de un taller mecánico, de una tienda de ropa), donde pequeñas empresas o equipos de desarrollo y profesionales independientes encuentran un nicho al que no pueden llegar los sistemas más conocidos como SAP o Tango (supongo que sólo tiene vuelo local, pero es muy conocido aquí).

Desde el punto de vista de la programación o codificación estos sistemas no son muy complejos… de hecho no son complejos en lo absoluto. Como se mencionaba hace algún tiempo en ¿Aburrido?, básicamente existe una base de datos que representa objetos y transacciones de la vida real, un software que materializa en múltiples pantallas de ingreso las reglas que indican cómo y cuándo esa información puede ser actualizada y un montón de reportes a través de los cuales es distribuida a través de la empresa o, hablando más en general, la organización.

Cada sistema tendrá algunas funcionalidades únicas (si no es así probablemente esté condenado al fracaso) o problemas particulares que representarán un verdadero desafío, pero no suelen representar más que un pequeño porcentaje de la funcionalidad total, y muchas veces son extras más orientados a diferenciarlo en la venta que al uso real y cotidiano.

El éxito o fracaso de un proyecto dependerá, más que de la pericia o ingenio de los programadores para crear algoritmos complejos que resuelvan problemas complejos, del conocimiento que posean, tanto éstos como los analistas y líderes del proyecto, del negocio que están modelando.

Este conocimiento tiene más que ver con facturas, recibos, remitos, balances, arqueos, tickets, inventario, impuestos, control de costos y esas cosas que con optimización, índices, grafos, métodos de ordenamiento, operaciones por ciclo de máquina, lenguajes, compiladores.

Eso por el lado del mercado.

El problema es que, del lado de la formación, las carreras de sistemas con contenido de programación poco y nada tienen que ver con el mundo de los negocios, y viceversa. Esa fue siempre mi sensación. Para este artículo estuve haciendo un poco de investigación tratando de verificarla o refutarla.

De las carreras de grado de la UBA, las que tienen algo que ver con sistemas son:

• De la Facultad de Ingeniería, la Licenciatura en Análisis de Sistemas y la carrera de Ingeniería en Informática. Esta última cuenta con tres orientaciones: en Gestión Industrial de Sistemas, en Sistemas Distribuidos y en Sistemas de Producción.

• De la Facultad de Ciencias Exactas, la Licenciatura en Ciencias de la Computación.

• De la Facultad de Ciencias Económicas, la Licenciatura en Sistemas de Información de las Organizaciones.

Más o menos a ojo (espero no haber pifiado mucho, si alguno de ustedes es o fue alumno de esas carreras me gustaría conocer su opinión al respecto), por los nombres de las materias, se deduce que:

• Para Análisis de Sistemas (Fc. de Ingeniería, 1739 alumnos) el 27% de las materias están orientadas a la programación propiamente dicha, y sólo el 7% tiene que algo que ver con lo administrativo, lo contable o la gestión de una organización.

• En Ingeniería en informática (Fc. de Ingeniería, 3194 alumnos), la programación ocupa entre el 26 y el 33%, contra un 4%, 2% y 15%, con la salvedad de que éste último porcentaje corresponde a la Orientación en Sistemas de Producción, por lo que imagino que estará enfocado a esa área.

• En la Licenciatura en Ciencias de la Computación (Fc. de Cs. Exactas, 1573 alumnos), los porcentajes son 38% contra… 0%. 38% para el lado de la programación, por supuesto. Debe ser duro para un egresado de esta carrera enfrentarse a un ERP o a un CRM armado sólo con lo que la universidad le ha enseñado.

• En la Licenciatura en Sistemas de Información de las Organizaciones (Fc. de Cs. Económicas, 1566 alumnos) nos encontramos que el estudio acerca del funcionamiento de la organización ocupa el 29% de la carrera (menos mal, ya que es de la Facultad de Ciencias Económicas), pero la programación sólo un 12%.

Pueden consultar la lista de materias (fuente oficial aquí, siguiendo el vínculo de cada carrera), cuáles conté para uno y otro lado y cuáles dejé afuera, aquí. La cantidad de alumnos proviene, desgraciadamente, del Censo de Estudiantes 2004, que es el último disponible (ese vicio tan habitual en la cosa pública Argentina, de ir a ciegas por la vida).

Es obligatorio aclarar que esto no dice nada acerca de la competencia de los profesionales que egresan de esas facultades (habrán buenos y malos en todos los casos). La experiencia aporta el resto y si hay algo que hace (en mi opinión) a la UBA una de las mejores universidades (seguro que de Argentina y puede que de Latinoamérica) es que sus alumnos salen con una innegable capacidad de seguir aprendiendo y enfrentarse a nuevos problemas, gracias también a que el resto de la plantilla brinda un conjunto de herramientas teóricas de carácter general que el profesional puede adaptar a su situación específica. Finalmente unos tendrán que aprender qué es eso de la partida doble y otros qué es una lista doblemente enlazada, si es que lo necesitan.

Se me dirá que se requiere de profesionales de más de una de esas carreras para completar un equipo. Cierto. En los papeles. Es verdad que en un proyecto mediano o grande habrán analistas (probablemente egresados de económicas) que interpreten el negocio y lo transmitan a los programadores.

Pero yo veo eso no como una característica inherente a los equipos de desarrollo sino como un problema (tal vez generado por la segmentación de las unidades de formación, las universidades) que afecta directamente al mercado de software “de gestión”.

Para un producto que pretenda concentrarse y especializarse en un nicho pequeño (lo que llamamos con cariño “el programita del verdulero”) un equipo de desarrollo compuesto por analistas y programadores es extremada e innecesariamente caro.

En general es un nicho cubierto por uno o dos profesionales que se ocupan de todo, incluso del management de su propio emprendimiento. Si son egresados de alguna de las carreras mencionadas deben superar un duro aprendizaje acerca de “la otra mitad” del negocio, para la que la carrera no los ha preparado.

Recordemos que en conjunto los sistemas de gestión representan la gran mayoría de sistemas existentes, los más cambiantes y dinámicos (tanto como los negocios que soportan), y por ello los que requieren más mano de obra en desarrollo y mantenimiento. Finalmente es donde van a trabajar la mayoría de los programadores, analistas, líderes de proyecto o profesionales independientes con cualquier orientación.

Pero lo que la universidad está produciendo es una mano de obra sobre calificada técnicamente (son los que o se aburren en el trabajo o resuelven los problemas más simples con los algoritmos más inútilmente complejos y eficientes, o no entienden los requerimientos) o en conocimiento del negocio (que producen ese software que resuelve exactamente lo que el usuario necesita pero que por dentro es un desastre y que finalmente se vuelve imposible de mantener o modificar).

Lo que sucede finalmente es que prima la realidad, la necesidad del mercado, y los profesionales se ven obligados a complementar su carrera con experiencia y cursos. En este contexto devalúa el título obtenido. Antes de llegar a ese punto (del que creo que hoy por hoy estamos lejos, pero acercándonos progresivamente) la UBA debería orientar alguna de esas carreras hacia un contenido más balanceado. Una carrera de la cual egrese un profesional que pueda programar algoritmos simples (validaciones, búsquedas, interacción con bases datos, cálculos, reportes) y que conozca el funcionamiento administrativo de las organizaciones (circuitos administrativos, documentos, conceptos contables básicos). Creo que la Licenciatura en Sistemas de Información de las Organizaciones es la que más se acerca, más que nada por el contexto que brinda la Fc. de Cs. Económicas, su proximidad con la carrera de Administración de Empresas y la de Contador.

Frases: análisis de impacto o…

Una pequeña modificación a las apuradas aquí y… una gran explosión allí. ¿Qué paso?

- Y… falló el análisis de impacto.

- ¿Análisis de impacto? Acá no hacemos análisis de impacto. Hacemos análisis forense.

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.

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.

El usuario (II)

Recordemos la definición ad-hoc de usuario que había presentado en la primera parte de este artículo:

[...] es el que opera el sistema en una situación real para alcanzar un objetivo determinado que coincide con el que fue requerido al desarrollar el sistema.

Luego lo caracterizaba, un poco maliciosamente, diciendo que

El usuario es tonto o malicioso a menos que se demuestre lo contrario.

para luego mencionar algunas de las características más comunes que todos adoptamos cuando somos usuarios de un sistema:

• Distracción: no leemos, no miramos.
• Falta de memoria: no registramos nuestras acciones ni sus resultados.
• Descontextualización: no interpretamos lo que vemos en su contexto, sino que tendemos a trasladarlo literalmente al nuestro.
• Mecanicismo: repetimos secuencias automáticas de acciones mecánicas que nos han dado resultado.

El origen (siempre de acuerdo a mi modesto entender en estas cuestiones, de las que no soy un gran teórico) es que el usuario no está utilizando el sistema. ¿Cómo?

No. El usuario no utiliza el sistema. Nadie dice, "mi trabajo es utilizar un sistema" o "estoy un poco aburrido, voy a utilizar el sistema". El usuario quiere hacer otra cosa. Querrá pagar una factura, vender un boleto, consultar el horario de una película, actualizar el stock, divertirse...

Los seres humanos no somos demasiado buenos ejecutando varias tareas al mismo tiempo. Nuestro cerebro tenderá a siempre a concentrarse en aquélla que juzgue más importante o le demande más atención. No es ésta la verdad revelada, precisamente. Es, por ejemplo, la razón principal de que no utilicemos el celular cuando manejamos (no deberíamos, por lo menos) o de que apaguemos la radio del auto cuando nos perdemos. En estas conductas vemos otro punto sutil: tampoco somos muy buenos concentrando nuestra atención conscientemente. El celular y la radio nos distraen, aunque lo neguemos o querramos evitarlo.

Entonces el sistema es una herramienta que, si bien el usuario quiere o debe utilizar, lo distrae inevitablemente de su objetivo principal. Como no puede apagarlo hace lo que hace: le presta la menor atención posible. Cuando somos usuarios desarrollamos toda una serie de conductas que tienden a reducir al mínimo la cuota que nuestro cerebro debe dedicarle al sistema en sí.

Así que tenemos que estar conscientes de que cuando el sistema trata de atraer la atención del usuario está molestando. Siempre. Así que más vale que lo haga por algo importante.

Si están de acuerdo con en el razonamiento que me llevó a la frase anterior, tendrán que coincidir con que los errores respecto de este tema son muy, pero muy comunes en casi todo software:

Molestar con bobadas:

• Propaganda intrusiva e irrelevante, sobre todo en Internet. Si el usuario quiere leer el diario ¿por qué demoraría más de un segundo en cerrar esa imagen molesta que le impide hacerlo?

  Se me dirá que ese tipo de propaganda funciona. Es verdad. Funciona desde el punto de vista del anunciante, que actúa más o menos como un spammer: molesta a varios cientos de miles para alcanzar a ese par de decenas de usuarios que tienen algún interés en el producto o servicio promocionado.

  Por otro lado ¿no funciona mejor la propaganda contextual? Ese sistema se basa en lograr un encuentro entre lo que el usuario busca y lo que el sistema le ofrece. Si el usuario busca pasajes baratos, encontrará la frase "Viaje casi Gratis" así esté ubicada en el extremo inferior izquierdo de la pantalla, en azul con fondo negro y letra chica.

• Intentando meterse compulsivamente en lo que el usuario quiere hacer, o insistiendo en enseñarle lo que no quiere aprender. Software que parece un chico de 3 años que demanda atención o quiere demostrar que sabe. Que haga tal cosa si desea hacer tal otra, que mejor si lo hace así, que por qué no lo hace asá.

  El momento en que el usuario está utilizando el software para otra cosa no es precisamente el mejor para brindar capacitación.

  Hay que darle al usuario la posibilidad de que haga lo que quiera hacer de la manera en que lo desee. Lo divertido de los programas que cometen los errores mencionados (Microsoft se lleva las palmas, y el paquete Office el premio mayor) es que cuando el usuario realmente quiere propaganda o capacitación o consejos útiles o ayuda o información detallada no la encuentra, porque si el sistema no la ofrece automáticamente (y de forma molesta) no hay detective que pueda ubicarla.

Molestar con información a destiempo o fuera de contexto.

La medida de lo importante la da el objetivo del usuario: si el usuario está ingresando una factura, poco le importará que se ha ingresado un nuevo producto al stock, por más relevante que esto pueda ser para él en otro momento.

No saber atraer la atención del usuario cuando es necesario.

Si soy un contador y estoy apurado para cerrar ese balance con mi jefe mirando por encima del hombro, el mensaje "se está quedando sin espacio en la partición primaria de la unidad Z" titilando en letras rojas pasará absolutamente desapercibido, por más catastrófico que le pueda parecer a cualquier administrador del sistema.

Esto es un completo despropósito, sobre todo teniendo en cuenta que, en general, ése tipo de alarmas contiene un mensaje más pequeño a continuación, que usualmente reza "Guarde sus trabajo en una ubicación alternativa para evitar pérdida de datos".

¿Qué es más importante para el usuario y tiene más posibilidades de atraer su atención? ¿Que la unidad Z se queda sin espacio o que está a punto de perder su balance casi terminado?

Después el analista funcional no entiende cómo el usuario no vio eso.

Los mensajes tienen que estar orientados al usuario que los lee, y en lo posible (aunque ésto es mucho más difícil) relacionados con la tarea que está realizando. Una buena regla para la redacción de mensajes es que en vez de decirle al usuario lo que le pasa al sistema (que poco le importa) hay que decirle lo que a él le está pasando o le va a pasar.

Mensajes de error incomprensibles.

Este punto es típico, terriblemente típico (vinculé una linda colección de delirios en la entrada Mensajes de error), y que encima se nos vuelve en contra, porque aquí los que solemos quedar como idiotas somos nosotros, los desarrolladores.

Yo tengo dos reglas básicas:

• La primera es de redacción: el título del mensaje de error es siempre "No se pudo [hacer lo que el usuario iba a hacer]", en palabras del usuario: "No se pudo ingresar la factura", "No se pudo imprimir el tícket", etc. Un mal ejemplo es "El recurso de impresion \\ADMNET\Imp\EPS345 no está disponible".

  El detalle, más pequeño, tiene que responder siempre a la pregunta "¿por qué?", también en palabras del usuario. Es como un diálogo: título - ¿por qué? - detalle del error. "No se pudo cerrar el balance" (¿por qué?) "No hay espacio suficiente en disco". ¿Ven que queda mejor?

• La segunda tiene que ver con los errores no manejados, es decir, con los errores de programación. Cualquier intento de brindar información al usuario es peligroso, porque el sistema está en un estado desconocido, y puede pasar cualquier cosa (como muestran los ejemplos de la entrada anterior).

  Creo que lo mejor en este caso es el típico "Se ha producido un error inesperado" o algo así, y brindar un curso de acción (número de soporte, reintente tal cosa, pruebe tal otra). Pero ojo, no estupideces, sino cursos de acción razonables teniendo en cuenta que el usuario quiere completar una tarea. Es decir, llamar a soporte técnico es una opción, pero no la mejor en este sentido.

  Lo que voy a poner es brutalmente difícil, yo nunca lo implementé: pero si tengo un error inesperado, tengo que dar una solución de negocio de acuerdo a la operación que el usuario está haciendo. Ejemplo: si estoy en la carga de la factura, tengo que explicarle al usuario que tiene que verificar si se registró la factura ingresada, facturar a mano, y luego llamar a soporte o lo que sea. Es decir, primero le resuelvo el problema al tipo.

  Pero claro, lo anterior implica prácticamente un manual de incidencias para cada funcionalidad. Dije que era brutalmente difícil.

Una última aclaración: cuando el personal de soporte técnico está revisando la instalación, también es de alguna manera un usuario. Lo mismo cuando lo está instalando o cuando el administrador lo está configurando. Al igual que en los ejemplos anteriores, aquí también tenemos que utilizar el lenguaje del usuario, que en este caso es más técnico.

El mismo mensaje ambiguo de error inesperado que para el usuario común es más amable, para éste tipo de usuario es casi ofensivo, ya que la falta de información, que antes se traducía en simpleza, ahora le impide saber qué es lo que está pasando.

En general se utilizan ejemplos mencionando usuarios "comunes", pero no debemos olvidar que también hay usuarios u operarios (si les gusta la diferencia) que juegan un papel más técnico y que por ello deben recibir más información técnica. Como siempre, lo lógico, aunque también lo más difícil, es responder correctamente de acuerdo a la situación.

Para cerrar, digamos que es terrible crear un buen sistema que la pifie justo en el momento en que el usuario realmente lo está utilizando para algo. Y sobre todo si, como en el caso de los mensajes de error, es una cuestión fácilmente evitable durante el desarrollo. Simplemente es cuestión de pensar dos segundos antes de escribir esa frase maldita (o con faltas de ortografía) que nos hará quedar como bobos ante el cliente. ¿No vale la pena?

Proyecto de software típico.

Me acordé de esta secuencia, y estuve un buen rato buscándola por internet. No hay mucho mas que decir.