¿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