En la cultura vial, el Pare, mire y escuche es una secuencia de acciones que debe hacer una persona que conduce un automóvil ante de un cruce ferroviario con el fin de evitar un accidente por cruzar sin precaución.

A pesar que esta secuencia de acciones parece inofensiva y no aporta en mucho, sí puede salvar vidas, ya que es una indicación de prestar atención al entorno con tres simples pasos:

• Parar el movimiento del automóvil,
• Mirar si existe señales o evidencia del tren en ambos sentidos, y
• Escuchar si el tren ha hecho sonar su bocina.

En el ámbito del desarrollo de software también aplicamos el mismo principio de “parar, mirar y escuchar” antes de hacer código, ya que el código tiene su origen que permite resolver un problema o necesidad de una persona o grupo de personas: un código siempre tiene un objetivo, desde un inofensivo Clippy hasta un virus o ransomware.

Por lo general, uno de los primeros instintos del desarrollador es sentarse a imaginar el cómo resolver el problema: revisar las bases de datos, imaginar la arquitectura de servidores, pensar en cómo invocar ese servicio en la nube o, simplemente, armar su árbol mental de diseño de solución, sin considerar el resto del mensaje de nuestros usuarios y usuarias.

Antes de tirar una línea de código, de ponerse a discutir una idea, de lanzar la pelota contra el piso o hablar con el pato en tu computador, nos debemos preguntar: ¿entendí lo suficiente para poder comenzar?, ¿soy capaz de explicar el proceso a otras personas?, ¿sé quiénes son los actores involucrados?, ¿tengo claro el elemento entregable?

Por tanto, apliquemos el pare, mire y escuche:

• paremos y veamos si tenemos claridad de lo que tenemos que hacer,
• miremos el contexto del problema a resolver o la solución propuesta, y
• escuchemos las ideas de los demás actores y personas involucradas en el diseño de la solución.

Es tedioso preguntar, pero ganamos

Sí, es un trabajo tonto el que he propuesto, y “¿cómo se te ocurre que tenemos que preguntar al cliente tonteras?”… en ocasiones se da el caso que el cliente asume cosas de su dominio laboral que son importantes considerar en el diseño de la aplicación. Recordemos que desarrolladores y clientes hablamos idiomas distintos y poseemos distintos objetivos laborales, por lo cual hay precondiciones o lenguaje que no entendemos y viceversa. Aquí se hace fundamental el parar si no entendemos algo, mirar y comprender la explicación y escuchar todo lo que el cliente nos quiera decir, con atención y dejando espacio para que explique todo: al final preguntamos ideas, sino, se va por la tangente un problema e incluyen más problemas de los que estamos resolviendo.

Mejor pecar de precavido que condenarse por incauto

A veces las personas no dicen “no sé” por miedo a ser tachadas por ignorantes o sin la capacidad de estar habilitados a estar en la reunión, es decir el famoso síndrome del impostor. Este es un pequeño trauma que acarreamos desde la época escolar donde la ignorancia no es valorada positivamente y se tacha como un “tope para el aprendizaje constante a los demás estudiantes”.

En este caso, parar una reunión porque no entendemos algo o simplemente debemos ahondar en un tópico que parece irrelevante está bien, ya que eso permite descubrir a la otra persona que su proceso, idea o problema no está siendo comprendido por ti, quien es la persona que le pondrá pantallas, reglas e interacción al proceso. Por eso, no tenga miedo en preguntar…

La palabra de advertencia: no se pase de la raya…

Está bien preguntar si no sabemos, pero obviamente, no debemos preguntar todo o absolutamente todo lo que veamos, escuchemos y percibamos del cliente. Es decir, hay cosas o dominios que son de común conocimiento (validaciones de datos u obligatoriedad de ciertos procesos por temas legales), las cuales no son necesarias preguntar directamente al cliente.

Así mismo, considera que no existen los levantamientos perfectos, por lo cual muchas de las cosas que tendrás dudas o primeras aproximaciones de solución no serán perfectas, ni debes esperar la perfección para hacerlo, ya que no existe el requerimiento perfecto, solo una idea de cómo se hacen las cosas y cómo deberían funcionar o la salida esperada.