Aplicar principios de la Comunicación no Violenta en el desarrollo de software

¿Escuchaste y/o emitiste alguna vez un juicio negativo sobre tu código o el código de otra persona? ¿Te sentiste abrumado, cansado o exasperado por un Bug, por una fecha o alguna demo ante el cliente?

Si alguna vez te encontraste frente a estas situaciones, este post quizás te brinde algunas ideas sobre cómo mejorar tu comunicación y tu bienestar.

Trataremos de unir dos cosas aparentemente lejanas, pero, dado que el desarrollo de software requiere para mejores resultados de mucha interacción humana, mucho más cercanas y vinculadas de lo que se podría pensar.

La Comunicación no violenta (CNV) tiene muchísimas definiciones. Una de las que más me conforma es:

"La CNV es una forma de involucrarnos más con nuestro lado humano en procura de vincularnos con otras personas, entender nuestros sentimientos y necesidades, por medio de la observación sin juicios, comprendiendo así los sentimientos y las necesidades de los otros. Se logra, de este modo, empatizar y hacer pedidos o poder escucharlos, sabiendo aceptar el no como respuesta.”

El objetivo final es que podamos vivir en mayor armonía con otras personas.

La CNV se consolida sobre cuatro pilares para buscar una mejor relación y empatía entre las personas. A veces, también lo suelo pensar como un framework de comunicación, Dicho esto, puede pensarse que es aplicable en varias situaciones y contextos. La CNV puede ser una herramienta muy útil que nos puede ayudar a lograr relaciones más honestas y conectadas con nuestro ser.

En este post no voy a desarrollar medularmente qué es la CNV. Lo descrito en los párrafos anteriores es un resumen. Voy a intentar aplicar algunos conceptos en algunas posibles situaciones diarias y descubrir cómo abordar las mismas desde el punto de la CNV.

Si acabo de darles mucha curiosidad y descubren ahora mismo esa necesidad, la mejor estrategia es proponerles que lean el libro escrito por Marshall Rosemberg, su creador. Ya fuera del ámbito técnico es una lectura muy recomendable como crecimiento personal.

Hablemos sobre comunicación no violenta aplicada al desarrollo de software.

“El que codeó eso no tenía idea de la vida”

El objetivo en este paso es ser más objetivos con nosotros, con las implementaciones que realizamos y brindarnos la posibilidad de la duda en la calidad y eficacia de las mismas.

Creer que nuestras implementaciones para solucionar un problema, al menos en una primera intención, suponen la mejor opción constituye un cambio que quiero proponer. Hablaremos de las observaciones sin juicios.

Confiamos en nuestro criterio simplemente porque la experiencia nos dice que ya  resolvimos, de una forma y con anterioridad, otros casos similares, aunque puedan existir sutiles diferencias. Y, como sabemos, el diablo está en los detalles.

Es más común de lo que parece la situación de escuchar ideas o formas acerca de cómo resolver un problema y que no se condigan con nuestro “criterio”, que las mismas se encuentren teñidas de juicios más allá de la observación puntual del problema: Ir desde el juicio bajo la expresión “está mal”, o el escuchar manifestaciones que juzgan despectivamente ya no sólo las ideas y/o implementaciones de otro de una manera más despectiva aún, incluso referido a la persona que dice esa idea. Son ejemplos de observaciones desarrolladas con aditivación de juicio, un tema que la CNV propone evitar.

Estoy puntualmente hablando cuando la observación recae en una solución que pueda estar sujeta a puntos de vista y criterios diferentes, pero que resuelve el problema en cuestión.

Aceptar que una solución es probablemente la más adecuada al contexto que poseemos y conocemos actualmente es un buen acercamiento. Pero en este momento quiero tomar distancia de llegar al juicio de “está bien” o “está mal”. Observar sin juicios.

Esta forma de comunicarse no solo nos afecta negativamente a nosotros, sino que afecta negativamente a nuestros pares. Así como nosotros podemos evaluar una idea en función del contexto que poseemos, otros podrán brindar ideas en función del contexto que poseen.

Es por eso que promuevo la idea de dejar de pensar, al momento de escuchar o analizar soluciones o mismo al momento de revisar PRs, que éstas no sean evaluadas en el sentido de  “buenas” o “malas”, sino simplemente de soluciones que carecen o poseen otro tipo de contexto.

Sugiero entonces:

• Ser propositivo con observaciones concretas.
• Ser constructivo.
• Evitar los juicios de valoración sobre las tareas ajenas.
• Evitar personalizar las observaciones.
• Entender que quizás nosotros no estamos viendo la foto completa del problema y, en función de ello, poder estar abiertos a estar equivocados.
• Explicar con fundamentos objetivos el porqué de un desacuerdo:
• “Tenes la posibilidad de aplicar este patrón de diseño que te permite mayor reusabilidad en vez de dejarlo hardcodeado”
• “Si pones un nombre correcto a la variable, evitarás dejar comentarios explicando qué guardarás en ella”

En conclusión, no perder la capacidad crítica, sin llegar al sesgo de “yo estoy en lo correcto, lo del otro está mal”.

Y en buena medida dejar de degradar ideas, cuya acción a veces por simple falta de contexto promueve que otras personas no nos compartan sus inquietudes al momento de resolver un problema.

Esta inversión de esfuerzo promueve además lograr una mejor armonía con nuestros colaboradores y como desarrolladores sabemos que en algún momento nos encontraremos ante un problema que no está en StackOverflow.

Nadie dice que tu solución de hoy no es la mejor, pero posiblemente un juicio tirado a la ligera puede quitarte la posibilidad de escuchar la mejor solución del problema de mañana.

Necesito Vacaciones, este feature me tiene Cansad@

Una situación común en los desarrolladores es la saturación. Nos suele ocurrir que terminamos adquiriendo una gran variedad de sentimientos negativos por el código (y no solo el código) con el que estamos a veces muchas horas vinculados, tratando de resolver un problema.

Es muy probable la situación de no darnos el espacio para analizar nuestros sentimientos.

La CNV nos propone la idea de que detrás de los sentimientos positivos hay necesidades satisfechas, y detrás de los negativos hay correspondientemente necesidades insatisfechas. Hablemos de los negativos.

¿Te identificás con sentimientos de rabia, frustración o insatisfacción al momento de resolver un problema? Hay que pensar en las necesidades. Las necesidades son abstractas y son comunes a todas las personas, más allá de la disciplina. Acá les muestro una lista de necesidades. Pienso que muchas de ellas las encontrarán relacionadas con uds. al momento de desarrollar software:

Tener claro qué necesidades estoy buscando satisfacer me ayuda a diseñar estrategias eficientes para resolverlas. ¿Qué quiero decir con “las estrategias”? Son las formas concretas de resolver las necesidades.

Para esto es útil entender que para resolver un problema que nos tiene atribulados es necesario entender cuál es nuestra necesidad y la del cliente, lo cual, a su vez, nos llevará a comprender y enfocar la mejor solución.

Por ejemplo:

El cliente necesita un feature urgente, ya que debe presentarlo como “funcionando” para lograr el éxito en una rueda de inversores.

¿Cuál es la necesidad real?

• El factor tiempo es fundamental para lograr el objetivo.
• La calidad técnica es una preocupación no menor para lograr que nuestra solución no falle en el primer intento.

Entender cuál es la deuda técnica que debemos crear implica la aceptación de una decisión consistente en priorizar ciertos temas sobre otros, que dejamos aparte en pos de comprender necesidades mutuas y satisfacer estrategias. Entender todas estas aristas al momento de desarrollar software es una forma de lograr una mejor y duradera relación con las personas que interactuamos al momento de definir nuevos requerimientos.

Entonces volviendo al ejemplo planteado, prioricemos las necesidades del cliente y las nuestras; iterativa e incrementalmente propongo manejar sabiamente nuestros tiempos. Un posible enfoque es:

1. Inicialmente tener desarrollado el feature solicitado quizás de la manera más rápida / simple posible
2. Ir puliendo y eliminando la deuda técnica que vamos dejando.

Cualquier parecido con aplicar una técnica similar a TDD (básicamente la solución más simple primero y luego ir mejorando la misma) es pura coincidencia ;) .

¿Tenés un segundo para ver esto?

El cuarto elemento que se menciona en la CNV es sobre los pedidos. Cómo nos enfocamos al momento de pedir o brindar ayuda o feedback sobre una solución también habla acerca de cómo nos predisponemos con otras personas. Esto es un factor no despreciable al momento de hablar sobre el descubrimiento de la mejor solución técnica.

Deberíamos tratar de ser concretos al momento de realizar un pedido si lo que buscamos son ideas renovadoras (ya que las que teníamos en mente ya las probamos o no nos convencen) y evitar que éstos constituyan una herramienta para influir o modificar las ideas de nuestro colaborador. Si buscamos las soluciones, ser concreto en los problemas nos ayudará a realizar pedidos que ayuden en el enfoque de las mismas.

No es lo mismo pedir ayuda diciendo simplemente “Me está fallando la API de Accounts” que decir “Cuando pruebo el servicio de clientes, en Accounts, en el ambiente de integración, con estos headers [...] y en este contexto [...] me devuelve un 406, ¿vos tendrás tiempo para colaborar conmigo en este problema, o sabés qué ocurre?”

Muchas veces incluso haciendo esto descubriremos que la técnica de Rubber ducking jugará a nuestro favor y no será necesario hacer el pedido concretamente.

Hemos hablado un poco sobre los cuatro pilares de la CNV:

• Las observaciones sin Juicio.
• Entender nuestros sentimientos.
• Entender las necesidades detrás de esos sentimientos.
• Hacer pedidos concretos , sin ser exigentes.

Vimos puntos interesantes de aplicación dentro de la disciplina del desarrollo de software. Hasta aquí, un mínimo aporte de lo que implica aplicar este modelo de comunicación aunque no hablamos todavía de la empatía, que sería otro de los temas fundamentales de la CNV;  nos llevaría a pensar un post completamente aparte y que seguramente pronto será escrito ¡Espero que esto les haya sido de interés!

¿Por qué la jirafa como foto de portada del blog? La Jirafa posee uno de los corazones más grandes del mundo animal. En la comunicación no violenta representa los valores positivos que se desean lograr. Como contraparte está el Chacal.