En los proyectos de software estamos llenos de personas
que no son “las adecuadas para responder nuestras preguntas”, para establecer las
verdaderas necesidades del negocio, para darnos a conocer el problema que
tienen, el problema detrás del problema, la causa raíz, el impacto de ese
problema y las áreas impactadas. Estamos llenos de personas que constantemente
no toman decisiones, que tienen que consultar con alguien más, que no entienden
lo que nos están contando durante un proceso típico de educción de requisitos,
es decir, durante las entrevistas, al responder cuestionarios o al analizar
prototipos, entre otras actividades.
Por eso es que nuestros proyectos están repletos de
supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son
supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los
supuestos le están haciendo mucho daño a la industria y conducen a la
producción de software de baja calidad o que no satisface para nada las
necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque
nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno,
y si no se produce la respuesta que requiere, entonces la presume.
Esta necesidad de hacer supuestos es inherente al ser
humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos
capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas
adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para
llenar el vacío y la insatisfacción que sobreviene, es la única manera de
sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no
obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la
respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de
saber.
Debido a ello, cuando un interlocutor, un usuario u
otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos
dice que no está seguro, que va a confirmar tal o cual asunto, que debe
reunirse la próxima semana con una o más personas para aclarar un tema, etcétera,
nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos
de trabajo tienen siempre una sección de Supuestos en la que registramos estas
conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es
eliminar esta sección de los documentos, son perjudiciales.
También es bien sabido que los usuarios típicamente no saben
lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones
basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al
preguntar porque somos propensos a creer que el problema de los usuarios es de
índole tecnológica y no algo puramente del negocio. Incluso, antes de eso,
fallamos al seleccionar y clasificar correctamente a los usuarios correctos o
alguien más toma la decisión por nosotros, lo que deja el proyecto en una
incertidumbre mayor que aquella con la que inició.
Los supuestos son atajos hacia la veracidad. El
problema es que casi nunca acertamos al escoger el camino apropiado. Siempre
que sea posible, reemplacemos esas hipótesis por hechos probados, por
evidencias que soporten la toma de decisiones, seleccionando mejor nuestros
usuarios, entrevistando al mayor número de personas en el menor tiempo posible,
así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y
de saber cuándo hemos llegado a la definición correcta del sistema. Invite a
varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que
una de ellas sea la adecuada aumenta.
Por eso, la siguiente ocasión que inicie un proyecto de
software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es
usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a
decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como
una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted
que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado
en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede
acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien
más puede tomar decisiones cuando usted no está?
¡Las posibilidades son infinitas!
La suposición es la característica principal del mediocre, concluir que algo está hecho sin tener la certeza de que si es así, acarrea a mucho problemas, no solo en proyectos de este tipo aplica para todo en la vida. Es muy importante que todas las personas que trabajan en proyectos de desarrollo de software no supongan cosas si haber hecho la diligencia completa, para que se identifique de forma oportunas los posibles riesgos lo más temprano posible y no dejarlos para el final, ya que esto genera costos y perdidas a la organización. Ingenieros trabajen en equipos y no seamos cuello de botellas de otros.
ResponderBorrarKelly, no creo que la suposición sea una característica del mediocre, más bien, como digo en el artículo es una necesidad de nuestras mentes de llenar los vacíos que experimentamos a diario por preguntamos que no somos capaces de exteriorizar y, por consiguiente, nos quedamos sin las respuestas apropiadas.
ResponderBorrarLo que debemos es precisamente mejorar nuestras habilidades de comunicación (efectiva) y nuestra forma de trabajar en equipo. Son asuntos que también se aprenden con la experiencia, "embarrándonos" y escuchando lo que tienen que decir los demás de nuestros resultados.
Saludos.
Buen dia
ResponderBorrarMuy interesante el articulo, como aporte, me gustaria comentar que es atraves de la suposiciones que se puede llegar al detalle y especificacion de requisitos. Ya que en muchas ocasiones los usuarios no saben como quieren las cosas, asi, teniendo una base de supuestos se podria profundizar en la especificacion de las necesidades.
Gracias.
Buen dia
ResponderBorrarMuy interesante el articulo, como aporte, me gustaria comentar que es atraves de la suposiciones que se puede llegar al detalle y especificacion de requisitos. Ya que en muchas ocasiones los usuarios no saben como quieren las cosas, asi, teniendo una base de supuestos se podria profundizar en la especificacion de las necesidades.
Gracias.