Las técnicas periodísticas
para entrevistar al cliente pueden ser de utilidad a la hora de relevar
rquerimientos, con miras a obtener una descripción completa y enfocada en la
solución que realmente se necesita.
Últimamente estuve leyendo algunas
cosas sobre herramientas para ingeniería de requerimientos y otras yerbas, y me
encontré con algo por demás interesante: el análisis lingüístico de textos.
Resulta que uno somete a las transcripciones de lo explicado por el cliente a
una de estas herramientas y, como por arte de magia, la herramienta devuelve
una lista de las cosas candidatas a convertirse en clases conceptuales del
modelo de dominio.
De ahí en adelante es todo cuesta abajo. Genial, ¿no?
No.
Lo que las herramientas
automáticas pasan por alto es que quienes describen el sistema a desarrollar
son seres humanos. No son máquinas, ni son Sheldon Coopers, ni Mr. Spocks. Son
seres humanos, y como tales, sus explicaciones están cargadas de defectos. No
sólo por las ambigüedades y demás complicaciones propias del lenguaje natural,
sino por las múltiples circunstancias que enturbian las narraciones y
explicaciones de quienes tienen a su cargo relatar
lo que necesitan
en términos de sistemas.
Los ejemplos que se
encuentran en libros de análisis y diseño suelen mostrar situaciones ideales,
con casos de uso en los que los escenarios están descriptos minuciosamente, en
forma concisa y completa, sin dejar escapar ni un detalle. Pero la realidad del
día a día es muy distinta.
Lo que solemos encontrar
cuando nos reunimos con el cliente (sin importar que el cliente esté
representado por sponsors, stakeholders, expertos en la
materia o incluso futuros usuarios del sistema) es que quien nos tiene que
contar lo que se necesita incurre en una o más
de las siguientes fallas:
-
No sabe lo que
quiere en términos del sistema a desarrollar.
-
Tiene una idea de
lo que quiere pero no la sabe explicar.
-
Sabe lo que
quiere, pero no sabe lo que su empresa u organización realmente necesita.
-
Tiene sólo una
idea parcial de lo que la empresa necesita, y la relata como si fuera el todo.
-
Sabe lo que la
empresa necesita, y lo sabe explicar, pero su explicación está sesgada y
prioriza aspectos del sistema que no son los más importantes para la empresa.
Si sometemos al análisis lingüístico a los relatos de una de estas
personas, obtendremos una serie de correctas sugerencias de las clases que
tiene que contener el modelo de dominio. Aclaremos: las sugerencias son
correctas, pero están fundamentadas en una narración defectuosa. Un amigo mío
suele decir: las herramientas automáticas se equivocan automáticamente.
Para corregir el factor humano que causa defectos en los inputs, lo
que se necesita es un factor humano opuesto. Aquí es donde aparece la figura
del entrevistador.
Quienes llevan años o décadas relevando requerimientos han
desarrollado un instinto para entrevistar, y saben cómo interactuar con el
cliente para obtener la información que necesitan y avanzar con el análisis por
las sendas correctas. Pero quienes somos más novatos, corremos el riesgo de tomar
al pie de la letra las declaraciones del cliente y utilizarlas como única,
veraz y completa base para el posterior análisis.
En mi caso, tengo la suerte (?) de haber pasado algunos años
trabajando en la industria editorial, escribiendo artículos y haciendo
entrevistas periodísticas. Y aprendí algunas cosas que pueden ser de utilidad a
la hora de relevar requerimientos.
La labor periodística
El verdadero periodista se enfrenta todos los días con la necesidad de
entrevistar a personas y sacarles información que no quieren dar, o que no
saben dar, o que no pueden dar. Pero se las tiene que ingeniar para salvar ese
obstáculo y obtener la información a como dé lugar. Si no, se queda sin
trabajo. Entonces, ¿qué mejor que emplear técnicas periodísticas para
entrevistar al cliente y extraerle todos los conocimientos posibles?
A continuación detallo algunos consejos de verdaderos periodistas que pueden
ser de gran utilidad a la hora de hacer ingeniería de requerimientos.
Lo primero que se debe hacer
antes de encarar una entrevista es seleccionar el tema a tratar. Desde el punto
de vista de un relevamiento, esto significa interiorizarse con la problemática
que debe resolver el sistema a desarrollar. Simple y obvio.
Elegir a la persona a quien
entrevistar. Esto no siempre está en nuestras manos; a veces la persona es
designada por alguna “autoridad superior” y debemos atenernos a trabajar
únicamente con esa persona (aunque no se descarta la posibilidad de que
propongamos a otras personas para que aporten información adicional).
Diseñar un cuestionario con
preguntas claves. Muy recomendable para encaminar el diálogo y evitar
olvidos. El cuestionario, sin embargo, debe tomarse como una ayuda-memoria, ya
que las preguntas más interesantes (y sus respuestas) suelen nacer en el
diálogo dinámico.
Establecer una conversación
relajada antes de abordar los temas claves. Esto lo sugieren los
periodistas para establecer un vínculo con el entrevistado. No está de más
tenerlo en cuenta; es bueno que exista una amistad con quienes deben suministrarnos
información valiosa, y con quienes vayamos a trabajar todo a lo largo del
proyecto.
No orientar, condicionar o
sugerir respuestas. De lo contrario, corremos el riesgo de que nuestros
preconceptos distorsionen la información. Hay que asumir que el que sabe es el
entrevistado, lo cual no quita que debamos empaparnos con anticipación en el
tema a tratar.
¡Que no se escape nada! Conviene tener
a mano un grabador de periodista para que no haya información “off the record”.
Para los periodistas, esta es una cuestión legal; para los analistas, es bueno
tener un respaldo para recordarle al cliente lo que dijo y pidió.
Algunos otros detalles: colocarse en un
nivel de igualdad con el entrevistado, sin faltar al respeto, pero dialogando
de igual a igual; ir de lo más sencillo a lo más complejo; manifestar interés
por la información vertida; dar al entrevistado el tiempo que necesite para
pensar las respuestas.
Quizás estas ideas no sean
herramientas infalibles, pero de seguro ayudarán a arrancar un proyecto de
desarrollo con el pie derecho.
