domingo, 19 de diciembre de 2010

¿Para quién Trabajas?

Uno de los grandes desafíos que tiene la construcción de soluciones de software es lograr romper el círculo vicioso cliente-programador. No es poco común ver que en sistemas en producción aún se requiera la participación de los programadores de la solución para realizar labores de configuración, mantención y/o explotación. No estoy considerando en estos problemas los relacionados con errores en la solución y que deban ser corregidos por los programadores.

El gran desafío entonces está en concebir el desarrollo de software como el desarrollo de productos (independiente de si es un desarrollo a la medida o no). La definición más simple de producto es "algo que puede usar otra persona". Algunos de los atributos más básicos para lograr esto son:
  • Usable. Que resuelva el problema/necesidad del cliente.
  • Instalable. Que se pueda instalar por un humano normal (no el programador).
  • Configurable. Que se pueda configurar por un humano (no el programador).
  • Administrable. Que se pueda administrar por un humano (no el programador)
  • Explotable. Que se pueda explotar por un humano (no el programador)
Lo principal, como traté de dejarlo explícito, es que todo lo anterior se pueda hacer sin el programador. En este contexto, el programador abarca un concepto más amplio que va desde el que desarrolla hasta la empresa que implementa. Hay varios problemas derivados del no cumplimiento de alguna de las condiciones anteriores. Algunos ejemplos y/o errores típicos que me ha tocado ver:
  • El sistema no tiene mantenedores.
    Hay que hacer todas las actualizaciones por la base de datos.
  • La configuración se realiza en archivos planos ó XML.
    Hay que enseñarle al usuario los nombres de las propiedades, la ubicación de los archivos de configuración, etc.
  • La configuración no se refresca
    Hay que reiniciar el sistema para que un cambio se materialice.
  • La configuración de la base de datos está en duro en el código.
    Hay que matar al programador.
  • Para recuperar los logs de la aplicación hay que ingresar por ssh al servidor.
    Hay que hablar con los encargados de la seguridad para pedirles acceso a los logs.
  • No hay manual de operación ni administración.
    Hay que preguntarle al programador cómo arreglar los problemas.
  • No hay interfaces de administración.
    Hay que actualizar los estados por la base de datos.
  • El sistema no tiene interfaces para exportar los datos.
    El cliente debe copiar y pegar desde la página a Excel.

La lista de errores es, obviamente, mucho más amplia. Lo principal es comprender que al no lograr cortar el vínculo entre el cliente y el programador, se pasa a una modalidad en que el programador pasa a ser una piedra de tope en el proceso general y, además, según el nivel del problema, los involucrados pasarán a trabajar para el computador y no al revés. Un ejemplo típico de esto es la poca capacidad de automatizar los procesos en donde, nuevamente (ver La Experiencia de Usuario), los involucrados se acostumbran a realizar la misma actividad una y otra vez.

martes, 14 de diciembre de 2010

La Experiencia de Usuario

En la relación de Cliente-Proveedor (en la que habitualmente estoy como proveedor), la conversación siempre gira en torno a lo que falta, lo que hay que mejorar, los errores, lo que está pendiente, etc., y, pocas veces, en base a las mejoras a los procesos y/o las soluciones tecnológicas que se pueden/deben realizar para los usuarios finales.

En la relación de Cliente-Vendedor, habitualmente el cliente está en dos estados:
  • Buscando. Lo que implica que la venta se basa en demostrar porqué uno tiene/provee la mejor solución (hay otras estrategias comerciales como basurear a la competencia con las cuales no estoy de acuerdo)
  • Disconforme. Lo que implica que la venta se basa en demostrar porqué uno tiene/provee una solución que resuelve los problemas actuales del cliente.
Hoy fue uno de esos días en que pude, por un rato, estar del otro lado de la relación Cliente-Proveedor, es decir, en la de Vendedor y, además, con un cliente en estado Disconforme.

Lo más interesante de poder estar en una situación como la anterior es que:
  • Se pueden "ver" errores en la implementación actual.
  • Se abren mejoras a la Experiencia de Usuario.

Lo primero tiene relación con la posibilidad de ver, a través de los ojos del cliente, los problemas de la implementación actual. Esto, inevitablemente, siempre ha sido para mi un aprendizaje ya que, hasta ahora, siempre he podido confirmar que, en un porcentaje alto, los errores obedecen a una visión "informática" de la solución/problema y/o una solución determinada por la tecnología subyacente (ver la sección Amo la Tecnología, en Las Dos Ilusiones).

Lo segundo tiene relación con la posibilidad de, obviamente, ver cuáles son las mejoras posibles a la implementación actual. Estas mejoras, dichas y conversadas con el cliente, tienen la magnífica gracia que estarán declaradas desde un punto estríctamente funcional lo que, obviamente, permite comprender mejor el problema. Toma aún más relevancia esto cuando el cliente está representado por las áreas operativas y/o aquellas que les toca lidiar día a día con la implementación actual.

Eso fue lo que pasó hoy. Casi todos los problemas mencionados por estos usuarios tenían que ver con desconfianzas y labores de reprocesamiento derivadas de lo anterior. Habitualmente, uno espera que las soluciones informáticas trabajen para los clientes y no al revés. Lamentablemente, en este caso creo que no se cumplía este aspiracional. Algunos ejemplos de las preguntas realizada por el cliente como mecanismo de validación fueron:
  • ¿Si ingresamos X archivos, obtendremos X archivos como resultado?
  • ¿Es posible que la respuesta del sistema se demore dos días?
  • ¿A veces nos pasa que tenemos una respuesta A, pero en el sistema dice B?
  • ¿A veces nos pasa que tenemos una respuesta A, pero en el sistema no tenemos nada?

La conclusión más evidente de este tipo de situaciones y que me ha tocado ver muchas veces es que el ser humano se acostumbra a todo. Por las razones que sean, los usuarios con los que estuve hoy, sencillamente estaban resignados, pidiendo ayuda a gritos para mejorar una situación que los tenía agotados y agobiados, sin embargo, aún así, estaban haciendo esfuerzos sobrehumanos por cumplir y seguir adelante. Esto es algo que hay que tratar de evitar a toda costa si se quiere tener un cliente felíz y, más aún, una solución tecnológica de primer nivel.

lunes, 6 de diciembre de 2010

Las Dos Ilusiones

Dos errores típicos de las personas que desarrollan software y/o trabajan con computadores:

1. Estoy Conectado
En términos simples, una persona que trabaja en desarrollo realiza casi todo frente a la pantalla y con la llegada y masificación de distintos mecanismos de comunicación (messenger, e-mail, facebook, twitter, etc.) puede más que antes, estar frente al computador y tener la ilusión de estar conectado y comunicado con el resto del mundo. Esto probablemente no produce mucho impacto ni mucha diferencia respecto a las relaciones sociales y/o familiares ya que típicamente estos vínculos se refuerzan en persona fuera del horario de trabajo, sin embargo, para la dinámica requerida en el trabajo no ocurre lo mismo.

Típicamente, una asignación llega por mail y/o por chat y, como resultado de lo anterior, se producen muchos supuestos relacionados con la solución requerida. El juego del teléfono, aunque en otro medio, se mantiene y, peor, es mucho más fácil y cómodo mantener una conversación por uno de estos medios que ir personalmente a hablar con los involucrados, agudizando el problema. Otro ejemplo de esto son los mails con copia a millones de personas que típicamente no generarán una acción por si mísmos. Es mucho más eficiente y seguro levantar el teléfono y hablar con la persona que uno requiere realice alguna acción.

2. Amo la Tecnología
Al momento de elegir resolver un problema, típicamente se privilegia la tecnología por sobre la solución. Esto va desde la manera de resolver el problema (patrones de diseño, por ejemplo) hasta la tecnología utilizada y, el problema, es precisamente ese. Muchas veces la solución es ajustada para utilizar una tecnología determinada. Esto no sólo puede producir con certeza un problema en el deployment de la solución sino que, además, no permite enfocar la atención en el problema que se quiere resolver y aquí, para complementar el punto anterior, es fundamental aprender a determinar y comprender cuál es el problema que se quiere resolver.

En términos simples, el problema que se quiere resolver siempre és y será lo que el cliente necesita, lo que el cliente quiere resolver. Previo a intentar determinar esto es necesario tener claro quién es el cliente. Para estos dos problemas la solución es simple: hay que preguntar y validar una y otra vez hasta estar seguro.

Como siempre le digo a mi equipo, la responsabilidad de asegurar que lo que se va a realizar cumplirá las expectativas del solicitante es del que la recibe. Mucho se puede discutir respecto a las responsabilidades respecto a la definición de los requerimientos, etc., sin embargo, en contextos en donde la agilidad prima sobre la burocracia y/o uno espera que las personas aporten, esto es fundamental.

martes, 30 de noviembre de 2010

Los Anglicismos

En la industria en la que trabajo es habitual encontrarse con miles de términos, siglas y frases del inglés que se utilizan diariamente para reforzar, expresar y/o explicar conceptos de una manera simple y fácil. Hay que reconocer que el inglés, en general, tiene esa gracia: en pocas letras y palabras se puede expresar mucho. Los américanos son especialmente hábiles para utilizar esto en combinaciones-léxico-marketeras de sus productos (Ziploc, Duracell, Phillishave, etc.)

Palabras del tipo WorkAround, Go-No-Go, Release, Handover, SOW, HotFix, GoLive, etc., son un clásico en las conversaciones en las que me toca participar. Cada una de ellas utilizada en un contexto específico y con un objetivo muy particular, sin embargo, muchas veces, sencillamente son utilizadas para reflejar un cierto "status" tecnológico. No sólo importa saber utilizar la palabra si no que, además, importa saber pronunciarla.

En un país en donde la tasa de manejo de inglés no supera el 5% según todos los estudios realizados, ser capaz de utilizar estas palabras es un plus bien excaso. Dado esto, desde hace un tiempo he estado registrando el uso de algunos anglicismos de manera errónea. A continuación la lista y algunas interpretaciones informales de ellos:
  • Mei-ling (Mailing)
    La china buena para mandar mails.
  • Walking Closet (Walk-In closet)
    El closet que camina solo.
  • Know House (Know How)
    La casita de conocimie-to.
  • Están Bay (Stand-By)
    La bahía donde están todos.
  • Lavase de Datos (La Base de Datos)
    La base de datos que se lava.
  • Baby Sister (Baby Sitter)
    La hermana que cuida a los niños.
  • Baby Door (Baby Doll)
    La puerta para hacer niños.
  • Brain Torment (Brainstorming)
    El cerebro atormentado.
  • Look&Film (Look & Feel)
    La película con un look conocido.
  • Big Bank (Big Bang)
    La explosión del Gran Banco.
  • Business Intelligent (Business Intelligence)
    Un negocio muy inteligente.

El acceso a internet y las herramientas asociadas (messenger, mail, etc.) obviamente facilitan el acceso a este tipo de conceptos y su uso y adopción errónea, razón por la que debiera insistirse en las políticas para promover y mejorar la adopción del inglés a nivel país.

Hace un tiempo se hablaba de que había que lo que había que aprender era Chino Mandarín, sin embargo, creo que esto es igual que cuando nacía internet y se presagiaba el fin de los medios impresos. Sigo creyendo que el camino es dominar bien el inglés.

martes, 12 de octubre de 2010

El Plan B

En los últimos días, el tema del rescate de los mineros ha sido, obviamente, el tema más relevante de la realidad nacional. Hoy comienza el rescate y, bien desde afuera, lo que se aprecia es una realidad construida desde el día cero (día del derrumbe) hasta ayer (68 días después) que no deja de impresionarme.

Dentro de los temas más relevantes de esta situación están los siguientes:
  • El día cero no había nada, hoy hay una "ciudadela" armada con personas que viven, comen, duermen, negocian, compran, etc., en términos simples, una mini-ciudad.
  • El día cero no había ningún medio, hoy están todos los medios del planeta reporteando y esperando el momento del rescate.
  • Se realizaron varios sondajes para lograr dar con el refugio, todos realizados en paralelo y por distintas empresas, hasta que el día 17 de Agosto lograron dar con el refugio.
  • Se instalaron tres máquinas, el Plan A, B y C, para realizar las perforaciones para el rescate.
  • Se instaló un hospital de emergencia para hacer las evaluaciones de los mineros una vez que fueran rescatados.
  • Se instalaron diversas máquinas para realizar la faena de rescate, me refiero, explícitamente a la máquina con la guía del cable que sostiene la cápsula, el armazón que sostiene el cable, etc.
  • Se licitaron y construyeron tres cápsulas de rescate de alta tecnología (tema aparte lo sorprendente y sofisticado que me parece el diseño de las mismas respecto a lo que yo hubiera considerado)
  • Se definió un plan comunicacional, apoyo psicológico a los mineros, etc., destinado a protegerlos (tema aparte el hecho que si se mostró en vivo la salida de cada uno de ellos, siendo que se había dicho lo contrario).

En definitiva, del simple concepto de "hacer un hoyo y rescatarlos", se armó un plan, una maquinaria y se ejecutaron todos los procedimientos que permitirán comenzar el rescate hoy. De todos los puntos expuestos anteriormente, hay uno que no deja de asombrarme cada vez que lo pienso, probablemente, por la industria en la que trabajo y este es lo de haber habilitado tres máquinas para realizar las perforaciones: el Plan A, B y C. No deja de ser notable y sorprendente que, precisamente, la máquina del Plan B haya sido la que realizó la perforación que hoy permitirá rescatarlos.

No vivo en un país caracterízado por ser estructurado ni metódico y, más aún, mucho más cerca del típico "en el camino se arregla la carga", por lo tanto, el hecho de anticiparse a un error (por ejemplo, lo que pasó con el Plan A) me parece lo más rescatable de toda la operacion, obviamente, después del rescate de los mineros.

Haciendo ciencia ficción y considerando la habilitación de un plan de perforación secuencial, sin plan de contingencia, algunas preguntas básicas que habrían atentado contra el rescate serían las siguientes:

  • ¿Qué habría pasado si se detecta un desvío después de 20 días de perforación?
  • ¿Qué habría pasado si la máquina se hubiera echado a perder?
  • ¿Qué habría pasado si la máquina se hubiera destruído en el proceso?
  • ¿Qué habría pasado si la roca no hubiera permitido realizar la perforación?

Cualquier análisis simple a las preguntas anteriores permite determinar que el día del rescate se hubiera postergado de manera inversamente proporcional a la distancia del refugio (mientras más cerca del refugio la falla, más días habría que esperar) y, por lo tanto, toma mayor fuerza el hecho de haber habilitado los planes paralelos de perforación.

No tengo claro si en la industria de la minería esto es un "must" (obligación) o no, sin embargo, en la industria en la que trabajo no es algo que se ve todos los días y creo que es necesario incorporarlo como un hábito de reflexión importante en el desarrollo de software. Habitualmente estoy más cerca del desarrollo que de la infraestructura por lo que, típicamente, la dinámica obliga a desarrollar, probar y, probablemente, luego corregir una vez que los problemas y/o errores se producen.

Hay errores que no se pueden anticipar, símplemente porque los ambientes, datos y/o los volúmenes de los ambientes de producción no están disponibles para el equipo de prueba y/o desarrollo. Hay otros que a veces se pueden anticipar y que obedecen a errores de especificación de requerimientos y/o diseño y, por último, hay otros que se pueden anticipar y que obedecen a problemas de programación, típicamente gatillados por supuestos simplistas respecto a las entradas y/o las acciones de los usuarios de la aplicación.

Para estos últimos, las dos preguntas simples que hay que hacer al momento de programar son:

- ¿Qué pasa si?
- ¿Porqué?

No se que pregunta se habrán hecho los responsables del rescate al momento de definir que se requería habilitar tres planes de perforación pero creo que, alguna de las preguntas anteriores, en cualquier escenario de decisión, deben realizarse siempre para determinar que se han cubierto todos los posibles escenarios y que, efectivamente, existe un Plan B. Sin ir muy lejos, mi hija que hoy tiene dos años, hace esa pregunta cada dos segundos para intentar comprender su realidad...