ERP
Lo que se quiere decir, lo que se dice, lo que se entiende ...

La relación entre cliente, analista y programador: ¿condenados a no entenderse?

En primer lugar, tratemos de definir los conceptos de cliente, analista y programador. Aunque podemos recurrir a Wikipedia, podemos resumirlo bastante en otros términos menos formales y más acordes con mi experiencia y la de otros compañeros de profesión:

  • Cliente. Aquel que expresa una necesidad en su sistema de información (S.I.)
  • Analista. Aquel que recoge la necesidad o problema de un cliente y lo analiza, desmenuza, estudia su alcance y finalmente, se lo endosa a un programador.
  • Programador. Aquel que transforma la necesidad del cliente en código ejecutable para el ordenador, lidiando con las carencias de las especificaciones dadas por el analista y la falta de concreción del cliente. Resultado, un producto más orientado a sus necesidades que a la del cliente.

Sí, es cierto que en un entorno de producción de software puede haber más personal involucrado, el comercial, el técnico comercial, el diseñador, el analista-programador, … pero en la mayoría de casos, y por la estructura de las nano y microempresas tecnológicas existentes en España, no suele existir una estructura jerárquica tan amplia, recayendo multitud de tareas en la misma persona. No es anormal empresas informáticas donde el analista ha de ejercer como tal, como técnico comercial y ocasionalmente como programador.

Sé que la gente que tenga la suerte (o desgracia) de pertenecer a grandes empresas que trabajan para la Administración Pública o para grandes corporaciones pensarán que esta situación es imposible, pero la realidad es que la gran mayoría de las empresas de tecnología españolas poseen estructuras de personal muy reducidas donde los trabajadores realizan tareas de muy diversa índole y no siempre vinculadas a su categoría profesional o simplemente, para las tareas para las que se le contrató. En definitiva, que los que estáis acostumbrados a proyectos de desarrollo de S.I. de 6 y 7 cifras, penséis que en la PYME se lucha por proyectos que están más cerca de 4 que de 5 dígitos. Pero esto es tema de otro artículo.

El día a día nos marca unos proyectos con muy pocas especificaciones pero gran exigencia. En términos generales el cliente no ha hecho un análisis pormenorizado de sus especificaciones, peticiones o problemas, simplemente se limita a expresarlos en voz alta, muchas veces incluso, sin haberlas preparado, por lo que las reuniones se convierten en sesiones de brainstorming en las que se divaga o incluso se discute de forma discordante entre los mismos usuarios acerca de lo conveniente de ciertos cambios. De ahí, el analista ha de extraer los puntos clave y darle la forma que el cliente entienda y acepte. Lo normal es que realice un documento de especificaciones, alcance, procedimientos de trabajo, cronograma de implantación, etc. y el cliente realice su feedback. Sin embargo, esto no siempre es posible si el tiempo apremia, si no hay colaboración por parte de los usuarios, o si conlleva un coste no asumible por el cliente.

A modo de anécdota…

Hace un par de años, en una instalación bastante grande se realizó un ‘Checklist de requerimientos’ donde se trató de analizar las necesidades de la empresa cliente. En principio, desde el conocimiento del sector en el que me movía y del bagaje de la empresa que conocía de hacía años, se realizó un exhaustivo listado de especificaciones (80 páginas en total) sobre la que se solicitó a los distintos departamentos y personas involucradas su revisión para obtener una retroalimentación con la que completar ese documento. Para agilizar, gran parte de esos requerimientos estaban formulados mediante pregunta y una respuesta ya previamente desarrollada (con las opciones posibles o imposibles y con anotaciones que ayudaran a tomar decisiones por parte del usuario), sobre todo las que desde mi punto de vista parecían obvias.

El resultado fue que en las 5 reuniones realizadas, la mayoría de usuarios, yo diría el 90%, no habían leído el documento, por lo que todas las preguntas les sonaban a chino y no tenían una opinión formada sobre las cuestiones expuestas. Y el que lo leyó, lo hizo el último día, por lo que no hubo posibilidad de aclarar términos y conceptos (o reformular las preguntas) para la reunión posterior. El cabreo del responsable del proyecto en la empresa fue mayúsculo y se terminó aceptando y firmando el checklist prácticamente tal y como fue formulado inicialmente.

Estas situaciones en las que existe una importante falta de definición y concreción por parte del cliente, el analista las termina trasladando al programador con no menos precisión, originando unos resultados bastante distantes a los imaginados por el cliente. Situaciones que terminan generando tensiones entre todas las partes porque el cliente dice tener claro lo que quiere, el analista adquiere una percepción subjetiva de la necesidad, y el programador lo resuelve sobre su interpretación.

Lo que se quiere decir, lo que se dice, lo que se entiende ...

Quería decir, dijo, entendió… se hizo.

Frases como éstas expresadas por clientes seguro que no son nuevas:

  • Yo sé lo que quiero.  Ah claro, tú sí, pero yo no te entiendo, o si te entiendo, con los datos que me das, soy incapaz de formular una solución.
  • Tengo un problema, tú eres el informático, dame la solución. Efectivamente, incluso conozco tu nicho de negocio, pero no soy parte de tu empresa para conocer tus problemas.
  • Yo quiero pulsar un botón y que el ordenador me diga cual es la situación de mi empresa. A ver, alma de cántaro, ¿sabes analizar balances? ¿Y ratios? ¿Llevas una contabilidad analítica? ¿Haces -B-? ¿Cómo calculas los márgenes? ¿Has hecho los escandallos de tus artículos? ¿Sabes cual es la diferencia entre costes directos e indirectos? ¿Sabes calcularlos?
  • Esto no es lo que yo pedí. No es ni lo que pediste, ni lo que no pediste. Decir «Quiero controlar tiempos en fábrica» no es definir un proyecto, podrá ser su título, pero no las únicas especificaciones de éste.
  • ¡Pero si eso no cuesta nada! o ¡Eso es muy fácil! Vale, pues háztelo tú en una hoja de cálculo.
  • No creo que podamos hacerlo así, nuestro negocio es muy complicado. Ya, igual que todo el resto de tu competencia.

En cualquier caso, esto no es nada nuevo que surja únicamente en una relación cliente, analista y programador, sino que es una cuestión de degradación del mensaje  como en cualquier ámbito de la vida.

Y es que, son cosas distintas:

  • lo que se quiere decir y lo que se dice;
  • lo que se quiere oir y lo que se escucha;
  • lo que se escucha y lo que se interpreta;
  • lo que se interpreta y lo que se ejecuta;

Tratemos pues, todas las partes, de crear el ambiente propicio para que fluya la comunicación en ambos sentidos y antes de comenzar a trabajar quede lo más definido y detallado cualquier proyecto que se quiera abordar en el ámbito de las TIC.

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly
Seguir en Feedly
 

Sobre Sergio Martínez

Dirección desarrollo e implantación ERP en Daemon4 Socialmedia, TIC, IDi, e-commerce, 2.0... Blogger en https://mundoerp.com

4 comentarios

  1. Por eso es importante tener un buen analista, buen post !

  2. Estas en todo lo cierto y es lo que se vive el dia a dia.

    Saludos

Comentar

Su dirección de correo electrónico no será publicada.Los campos necesarios están marcados *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

x

Check Also

El Internet de las Cosas (IoT), la tecnología que impulsará el crecimiento de las empresas

El IOT es el conjunto de tecnologías que permite la interconexión de objetos con elementos de su alrededor.

Subvenciones y ayudas para proyectos TIC

Me siento desanimado y frustrado. Hace años que lo intentamos, pero no hay forma. Siempre ...

Deshojando la margarita… Proyecto sí, proyecto no…

Hace un par de semanas me llamaba un cliente con gran urgencia para acometer un ...

No todos los cambios son percibidos como buenos

De vuelta sobre el rechazo al cambio

Sé que hemos hablado en innumerables ocasiones sobre la gestión del cambio, pero no deja ...

Industria inteligente/digital (4.0), IoT, Big Data, … y los actuales ERP

Desde hace unos meses, parece haberse extendido nuevos conceptos tales como Smart Industries, Industria Inteligente, ...