Uno de esos proyectos que tengo rondando por la cabeza desde hace tiempo (y que seguramente nunca llevaré a cabo por falta de tiempo) es el de escribir un libro que recoja todas las anécdotas que he podido guardar en mi mente durante tantos años de atención al usuario y analista programador. La combinación de asistir a personas las cuales en muchos casos no tienen un mínimo de conocimientos de informática y en otros directamente no tienen el más mínimo interés por aprender, es una fuente inagotable de historias divertidas. Divertidas ahora, porque en ese momento maldita la gracia que te hacen. Quizás me anime, y en lugar de un libro escriba un par de entradas en este blog contando estas anécdotas. Pero en esta entrada en concreto pretendo dar algunas claves para llevar a buen puerto la detección de necesidades del usuario y describir mediante un vídeo genial la sensación de impotencia que muchas veces se siente cuando tienes delante a un usuario con unas necesidades que sabe que tiene pero que no es capaz de identificar y mucho menos de transmitirte. Esta circunstancia es extrapolable fuera del mundillo de la informática. Basta con cambiar la palabra "usuario" por "cliente".
La labor de un analista es la de escarbar dentro de la cabeza del usuario para saber que necesidades reales tiene. Para ello tendrás que filtrar muchísimos datos irrelevantes que sólo producen distorsión y que si los valoras inadecuadamente pueden desviarte del problema real. Para realizar este trabajo sólo tienes una herramienta. La pregunta. Como si de un pico se tratara, cada pregunta ha de ser certera y golpear en el punto correcto para ir separando la piedra que sobra y dejar a la vista solamente el objetivo, el problema real.
El usuario tiene una tendencia inconsciente a hablar del problema y de la solución al mismo tiempo (problemas con soluciones incorporadas las llamo yo). O incluso a plantearte la solución directamente en vez de plantearte el problema. "Mira necesito un programa que haga esto, esto y lo otro". Esto es un error que hay que evitar. Es importante centrarse en hablar del problema y separarlo de las posibles soluciones. Pero habrá ocasiones en que el usuario trate de imponer la solución convencido de que el remedio está claro. En este caso (y lo digo por experiencia), es mejor no realizar el trabajo ya que se convertirá en una fuente de nuevos problemas. Un buen analista tiene que saber cual es el origen del problema y no aplicar soluciones sin conocer de donde vienen las dificultades que el usuario expresa. El usuario tratará de hacer hincapie en aspectos que para ellos son capitales pero que a la hora de realizar el trabajo son irrelevantes. Esto ocurre porque el usuario suele hablar de las consecuencias del problema y no del problema en si. Como si se tratara de un enfermo, el médico ha de interpretar los síntomas para combatir la enfermedad. Si se centra sólo en los síntomas nunca solucionará el problema y puesto que el usuario sólo había tenido en cuenta como causa del problema las consecuencias, seguramente las soluciones que proponga serán parches en lugar de soluciones definitivas.
Tras la fase de reuniones de recopilación de datos y tras tener un dibujo general de cuál es la situación y el problema real, hay que empezar a plantear soluciones. En este punto es muy importante la psicología. Hay que guiar al usuario hacia la solución y llevarlo de la mano por el camino correcto y no a tirones. Si accedes a adoptar las soluciones que el usuario te propone y que en muchos casos no son viables, con la esperanza de que el usuario no las valore al final, el proyecto no cumplirá sus expectativas y la culpa será del informático. Es importante fijar en las primeras reuniones el alcance y las características de las soluciones que se van a aportar y estas han de ser realistas y proporcionadas. Pero lo más importantes es que el usuario las acepte y que sobre todo las adopte como suyas.
El factor psicológico es muy importante a la hora de guiar el proceso por buen camino. Seguramente te enfrentarás al usuario con cierto grado de despotismo, que piensan que este tipo de reuniones son una perdida de tiempo y que el interrogatorio es innecesario ya que la solución es "hacer un programita muy simple que haga...". Te encontrarás el usuario creativo con afán de protagonismo y que pide extravagancias imposibles y botones mágicos que prácticamente hagan su trabajo. Al que no entiende tus preguntas y que te tacha de no ser colaborativo porque planteas los problemas van a aparecer. Al cenizo que está en la reunión obligado, con desgana y que a todo responde con negatividad y excepticismo. Y al entusiasta que aporta más de lo que se le pide y que hace la reunión improductiva contando sus experiencias como informático avanzado. En la cabeza de todos ellos está la solución final y lidiar con ellos para obtener la solución es lo que le da valor añadido a la función del analista. Manejar reuniones donde se piden cosas imposibles y cuando tratas de explicar los motivos por las que las soluciones no son viables te dicen: "Solucionalo. Tú eres el experto". Yo he asistido a reuniones como las del siguiente vídeo y cuando lo vi por primera vez no pude sentirme más identificado. Les aseguro que el vídeo no exagera mucho la realidad.
PD: Yo soy el chino.
La labor de un analista es la de escarbar dentro de la cabeza del usuario para saber que necesidades reales tiene. Para ello tendrás que filtrar muchísimos datos irrelevantes que sólo producen distorsión y que si los valoras inadecuadamente pueden desviarte del problema real. Para realizar este trabajo sólo tienes una herramienta. La pregunta. Como si de un pico se tratara, cada pregunta ha de ser certera y golpear en el punto correcto para ir separando la piedra que sobra y dejar a la vista solamente el objetivo, el problema real.
El usuario tiene una tendencia inconsciente a hablar del problema y de la solución al mismo tiempo (problemas con soluciones incorporadas las llamo yo). O incluso a plantearte la solución directamente en vez de plantearte el problema. "Mira necesito un programa que haga esto, esto y lo otro". Esto es un error que hay que evitar. Es importante centrarse en hablar del problema y separarlo de las posibles soluciones. Pero habrá ocasiones en que el usuario trate de imponer la solución convencido de que el remedio está claro. En este caso (y lo digo por experiencia), es mejor no realizar el trabajo ya que se convertirá en una fuente de nuevos problemas. Un buen analista tiene que saber cual es el origen del problema y no aplicar soluciones sin conocer de donde vienen las dificultades que el usuario expresa. El usuario tratará de hacer hincapie en aspectos que para ellos son capitales pero que a la hora de realizar el trabajo son irrelevantes. Esto ocurre porque el usuario suele hablar de las consecuencias del problema y no del problema en si. Como si se tratara de un enfermo, el médico ha de interpretar los síntomas para combatir la enfermedad. Si se centra sólo en los síntomas nunca solucionará el problema y puesto que el usuario sólo había tenido en cuenta como causa del problema las consecuencias, seguramente las soluciones que proponga serán parches en lugar de soluciones definitivas.
Tras la fase de reuniones de recopilación de datos y tras tener un dibujo general de cuál es la situación y el problema real, hay que empezar a plantear soluciones. En este punto es muy importante la psicología. Hay que guiar al usuario hacia la solución y llevarlo de la mano por el camino correcto y no a tirones. Si accedes a adoptar las soluciones que el usuario te propone y que en muchos casos no son viables, con la esperanza de que el usuario no las valore al final, el proyecto no cumplirá sus expectativas y la culpa será del informático. Es importante fijar en las primeras reuniones el alcance y las características de las soluciones que se van a aportar y estas han de ser realistas y proporcionadas. Pero lo más importantes es que el usuario las acepte y que sobre todo las adopte como suyas.
El factor psicológico es muy importante a la hora de guiar el proceso por buen camino. Seguramente te enfrentarás al usuario con cierto grado de despotismo, que piensan que este tipo de reuniones son una perdida de tiempo y que el interrogatorio es innecesario ya que la solución es "hacer un programita muy simple que haga...". Te encontrarás el usuario creativo con afán de protagonismo y que pide extravagancias imposibles y botones mágicos que prácticamente hagan su trabajo. Al que no entiende tus preguntas y que te tacha de no ser colaborativo porque planteas los problemas van a aparecer. Al cenizo que está en la reunión obligado, con desgana y que a todo responde con negatividad y excepticismo. Y al entusiasta que aporta más de lo que se le pide y que hace la reunión improductiva contando sus experiencias como informático avanzado. En la cabeza de todos ellos está la solución final y lidiar con ellos para obtener la solución es lo que le da valor añadido a la función del analista. Manejar reuniones donde se piden cosas imposibles y cuando tratas de explicar los motivos por las que las soluciones no son viables te dicen: "Solucionalo. Tú eres el experto". Yo he asistido a reuniones como las del siguiente vídeo y cuando lo vi por primera vez no pude sentirme más identificado. Les aseguro que el vídeo no exagera mucho la realidad.
PD: Yo soy el chino.
Comentarios
Publicar un comentario