¿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.

Tweet

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.

Tweet

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.

Tweet