• viernes, septiembre 22, 2017

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
 
Puedes compartir en ...
VN:F [1.9.22_1171]
Rating: 4.3/5 (3 votes cast)
La relación entre cliente, analista y programador: ¿condenados a no entenderse?, 4.3 out of 5 based on 3 ratings

Related Posts

3 Comments

  1. Dante Castillo
    26 febrero, 2014 at 3:27 PM Responder

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

    Saludos

  2. La relación entre cliente, analista y pr...
    10 junio, 2013 at 6:54 PM Responder

    […] La relación entre cliente, analista y programador no siempre es una relación de entendimiento debido a la falta o carencias en la comunicación entre ellos.  […]

Leave A Comment