Piensa en la respuesta a la pregunta “¿qué es necesario para hacer la mejor solución de software?”. Si en tu mente están ideas como “saber manejar bien los lenguajes y los frameworks de desarrollo” o “usar un ciclo de vida / método de desarrollo de última generación”, entonces debes leer este artículo con detenimiento.

Es muy común que los desarrolladores de software tengamos “God complex” y pensemos que podemos hacerlo todo solos y siempre tendremos razón (hablé de eso en este artículo). También, es frecuente que pensemos que nuestra única labor es programar o hacer cosas técnicas, y a través de eso lograremos el objetivo. Sin embargo, esto suele conducir a invertir muchas horas de trabajo en producir la solución incorrecta y la consecuente insatisfacción de los usuarios.

La mejor solución de software se consigue haciendo algo muy simple, que te describo en el título a continuación.

Habla con la gente

En mi trabajo como profesor, mis estudiantes de Ingeniería de Software deben definir un proyecto, que solucione un problema en el mundo real (de eso comencé a hablar en este artículo). En la revisión más reciente, todos los equipos manifestaron tener problemas para definir el problema que se debe resolver, o entender qué debe hacer la aplicación que van a diseñar. Ellos me dijeron todas las actividades que han hecho para encontrar la problemática y definir los requerimientos: investigación documental, ejemplos, casos. Yo les pregunté si ya han hablado con personas reales, a lo que me contestaron que no. He ahí, les dije, la causa de su situación actual.

En mi experiencia como desarrollador, participé en proyectos donde la mayoría del equipo nunca tenía contacto con los usuarios. Escribían el código y lo entregaban, pero no hablaban con los usuarios reales, nunca los veían y nunca sabían el impacto que generaban. A veces era por diseño del equipo: solo uno o dos hacían esta labor, pero otras veces se debía a que conscientemente todos decidían aislarse y concentrarse en lo técnico.

Esta forma de trabajo, en la que nos alejamos de los usuarios, da como resultado una alta inversión de horas en producir la aplicación de software incorrecta y la insatisfacción de los usuarios.

La solución es muy simple: habla con la gente y hazlo frecuentemente. Aquí algunas recomendaciones.

No les preguntes qué quieren

Nunca te acerques a un usuario a preguntarle qué aplicación quiere. Cada uno tendrá en mente algo distinto y complacerlos a todos será imposible. Además, pocos usuarios tendrán la capacidad técnica de describirte algo más allá de la interfaz y las funciones generales, dejando fuera cosas como la arquitectura y los requerimientos no funcionales.

El propósito es crear la solución de software correcta (no la aplicación deseada) y para eso necesitamos conocer cuál es la necesidad principal de la que adolece la mayoría de los usuarios.

Ten charlas casuales con ellos. Conócelos como personas. Entiende su día a día, sus preferencias, sus costumbres, lo que les frustra y lo que les entusiasma. Saber lo que les preocupa y por qué, es de la información más importante en el desarrollo de software.

 

Preséntales opciones y aprende de su retroalimentación

Aún después de hablar con las personas, nos encerramos en nuestro mundo de ingenieros y tomamos decisiones técnicas para la solución. Te reitero: no debemos asumir que nuestras decisiones son las correctas. Tenemos que ponerlas en las manos de los usuarios lo más rápido que podamos, si podemos hacerlo con más de una alternativa, es mejor.

Haz un poco de trabajo de software; resuelve una función o unas pocas a la vez y preséntala a los usuarios. Observa cómo la perciben, cómo la usan, qué problemas encuentran para poder emplearla, qué dicen de ella. Apóyate en todos los instrumentos posibles que te permitan llevar esa propuesta con ellos rápidamente y escucharles (prototipos en papel, prototipos no funcionales, la aplicación modificada con las nuevas funciones, etcétera). Asegúrate que esta información la escucha directamente quien hizo ese producto, nunca uses un intermediario.

No uses intermediarios

La práctica de asignar la responsabilidad de hablar con los usuarios a un anlista o product owner es muy común. Esto, además de generar cuellos de botella en el proceso de desarrollo, introduce ruido en la comunicación. El analista o product owner transmite la información de los usuarios al equipo de desarrollo después de haberla procesado; esta información ya incluye la interpretación y sesgo del analista, proviene de una sola fuente, sin contrastes, y carece de otros datos importantes: el tono de voz del usuario, sus expresiones, cómo manifiesta emociones, etcétera.

Mi recomendación es que mantengas al analista, es importante tener a alguien con experiencia, pero asígnale una responsbilidad más abierta: asegurarse que todos escuchan a los usuarios de viva voz y apoyarles en este proceso.

La mejor retroalimentación siempre te la darán los usuarios. Escúchalos frecuentemente, y mientras más rápido la obtengas es mejor. Es importante la excelencia técnica, pues esto te permitirá transformar las necesidades de las personas en soluciones funcionales y sin defectos, pero la tecnología sola no resuelve problemas.

Habla con la gente. Escúchala. Es lo mejor siempre.

¡Nos vemos en la siguiente entrega!