La teorÃa del detalle
Mi “teorÃa del detalle” puede parecer algo obvia, lógica y fácil de ver. En algunos casos tan evidente que parece insultante hablar de ella. Pero precisamente por eso pasa desapercibida con gran facilidad.
Según mi “teorÃa del detalle”, por muy bien que hagamos una aplicación, el cliente sólo será capaz de recordar los casos en los que tuvo algún tipo de traba. Bien porque la aplicación falló, o bien porque el resultado obtenido no se correspondió con lo que se esperaba obtener. Es lo que suelo denominar como “no aciertos”.
La consecución del detalle no es algo exclusivo de los últimos eslabones de la cadena de producción, a quienes es fácil culpar por no haber acertado con lo que el cliente esperaba. Es labor de toda la cadena de producción conseguir hacer llegar los deseos del cliente desde la petición hasta la entrega del producto.
Cuando un consultor toma nota de los requerimientos de un cliente, no sólo toma nota de unos procesos concretos que deben realizarse, sino de unos deseos subjetivos sobre como se desea que se llegue a la consecución de cada uno de esos requerimientos. El consultor tiene que tener en cuenta que en la definición de esos requisitos entran en juego los gustos del cliente, los hábitos de uso, los impedimentos actuales que desea evitar, el conocimiento que tenga de la tecnologÃa y sobretodo la capacidad de comunicarse y de ser entendido por quien le escucha.
El consultor debe transformar todas esas ambigüedades, sutilezas y falsas concreciones, en explicaciones claras y concisas que puedan plasmar los programadores en soluciones acordes a lo que el cliente originariamente desea.
En todo este proceso nos encontramos con grandes obstáculos a salvar, y como suele ser habitual muchos de ellos poco tienen que ver con la tecnologÃa.
- Primero, el cliente debe de tener la suficiente capacidad comunicativa para expresar todo aquello que pretende obtener de su encargo, y que muchas veces es algo tan vago, tan abstracto y tan amplio que podrÃa resumirse como “sentirse satisfecho del resultado obtenido”. Normalmente en este apartado son más útiles los clientes que no tienen conocimientos técnicos, ya que se centran más en el resultado que esperan que en los pasos tecnológicos necesarios a dar para alcanzar dicho resultado, aunque suelen ser los que con mayor facilidad se sienten defraudados cuando la aplicación no funciona tal y como esperan, al no comprender las implicaciones tecnológicas que han llevado a tal situación.
- Segundo, el consultor debe ser capaz de entender de un modo adecuado los deseos del cliente, ofreciéndole en ese mismo momento ideas que puedan satisfacer sus deseos. En estos casos, lo mejor es que el consultor se base en su propia experiencia tras haberse enfrentado a muchas situaciones similares y al conocimiento real que tenga del medio sobre el que versa el proyecto.
- Tercero, una vez el consultor se reúne con los programadores debe ser capaz de comunicarles objetivos concretos a lograr con los que satisfacer los requerimientos del cliente. El mejor consultor para hacer esto, es el que es capaz de olvidarse de las abtracciones comerciales, y de la palabrerÃa mareante, más propios de los vendedores de humo, y sea capaz de hablar al programador en el lenguaje técnico que entiende, de un modo conciso, directo y claro; organizando los pasos a dar, y encajando cada paso para que entre todos se alcance la meta.
- Cuarto …
Como se puede apreciar los “no aciertos” tienden a tener mucho más que ver con los problemas propios de los procesos de comunicación humana, que con los propios del campo que nos atañe [ desarrollo, testeo, instalación, ... ] Por lo que cuando entreguemos a un cliente algo que no coincide con lo que querÃa, veremos más claramente lo que ha ocurrido si observamos los pasos del proceso en los que la tecnologÃa ha tenido menor implicación y no culpando rápidamente a los últimos eslabones de la cadena de producción.