Comunicación escalable, esto no es solo código

Foto de Nick Fewings en Unsplash

Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.

En este articulo voy a hacer una crítica de la forma en que nos comunicamos, y lo que suele ser "normal" en el grupo de trabajo. Y para ellos voy a empezar dando un ejemplo de una situación típica, cuando ocurre un error en producción, y tenemos que explicar lo que está pasando a través de mensajes.

Si tenemos que comunicarnos con alguien que no es de IT, diríamos algo como:

Los usuarios no estaban pudiendo realizar acciones en la plataforma porque debido a un error introducido en la última versión lanzada la autorización al solicitar cualquier cosa no se estaba haciendo.

Y entonces lo "normal", o lo que estaría "bien", es llevar todo eso a un nivel más técnico para hablar con otros programadores:

Cuando el usuario autenticaba, se dejó de guardar el token necesario para la autorización de los servicios, porque el contexto donde se controla eso fue modificado debido a una tarea donde era necesario salvar otro dato que no teníamos.

Esto representa que tenemos que escribir más de un tipo de mensaje, uno para explicarlo a gente ajena al desarrollo un stakeholder por ejemplo, capaz habría que explicar también para un PM/PO(que va a querer además datos de impacto: tiempo de servicio out, usuarios afectados, pérdidas, etc.), y todavía tendríamos que hacer una explicación más con tal de explicarlo a nivel técnico(que generó el problema- commit, LOC, whatever -, propuestas para evitarlo en el futuro, etc.). Todo esto pensando que lo estaríamos haciendo en problemas grandes, en errores que son bloqueantes al usuario. Si además todas estas explicaciones en todas sus variantes lingüísticas habría que hacerlas para cada uno de los bugs que se encuentren en el día a día, podría apostar a que todos los días se irían solo escribiendo explicaciones.

¿Creo que es necesario dejar de dar tanta explicación? No, pero creo que podemos hablar en un vocabulario más general entre todos, y entrar en un detalle técnico solo si fuese necesario o pedido específicamente porque alguien quiere entender más a fondo el problema.

Usando el primer tipo de mensaje que puse como ejemplo(que apunta a un público ajeno a IT), una persona que también es programador entendería a grandes rasgos qué fue lo que pasó, ¿no? En mi cabeza pasaría algo así como "para autorizar las llamadas al backend entiendo que tenemos que mandar algun tipo de token, debe ser alguna cosa relacionado a eso".
Ahora veamos el caso que más me interesa mostrar. Tomamos el segundo mensaje(con un vocabulario más tecnico), y cuando lo va a leer una persona que también programa, pero no sabe de qué trata el proyecto del que se está hablando, porque todavía no participó o porque es alguien de otro ámbito(Backend, QA, DevOps, etc.), ¿hasta qué punto esa persona va a entender de lo que se está hablando?
Por ejemplo, ¿la persona va a saber lo que es un contexto?(siendo un concepto atrelado fuertemente al desarrollo frontend) ¿esa persona va a saber a que servicios hace referencia?

Entonces, ¿hasta qué punto tiene sentido perder tiempo comunicando cosas a nivel técnico, que precisan de un vocabulario que sólo tiene pleno sentido para una reducida parte del equipo?
Con esto no quiero que se me malentienda y piensen que yo digo que entonces no hay que hacer documentos como los Post Mortem; creo que tienen mucho sentido cuando son problemas realmente graves (major/total outage, un hackeo), pero he trabajado en organizaciones donde se hace un post mortem cada 2 dias porque se exige explicar hasta el porque el color de los botones no está alineado con lo que fue diseñado(Big Red Flag).

Otro tema que quiero abordar en la comunicación, es a la hora de escribir tareas. He estado en empresas que se utiliza muchísimo tiempo solo para escribir las tareas, y el problema reside principalmente en dos cuestiones:

• Falta de definición de lo que es realmente necesario hacer, sea regla de negocios o falta de claridad en el flujo.
• Querer adelantar lo que se debe hacer a nivel código para realizar esa tarea.

El primer punto no lo vamos a abordar, creo que es algo obvio que nos excede como desarrolladores que las decisiones de negocio o diseño no estén consolidadas. Pero obviamente quiero enfocarme en el segundo, que es un error muy tonto solo de pensarlo, pero que suele ser algo super comun de hacer durante las planificaciones. Y es normal que cuando nos digan "Hay que realizar X modificación en el flujo Y", ya tengamos una idea de lo que tenemos que hacer, si es que tenemos el conocimiento sobre el proyecto para realizarlo. Pero no por eso va a ser necesario que hagamos una transcripción de eso en la tarea, porque puede ser que:

• Lo simplificamos demasiado a lo que realmente es.
• Es otro el que lo va a hacer y no entiende de que se está hablando.
• El código que tenemos en la cabeza ya no es como pensamos, en el medio puede que hayan sucedido varios cambios.

La forma de evitar cualquiera de esos puntos es fácil, literalmente ir al código y comprobar todo eso, ¿no? Claro que sí, pero ¿no seria mas facil ya ir al código y resolver la tarea también, para evitar el context switching? Si, obvio que si, pero al mismo tiempo sería un desastre la organización general de las tareas; es un caos en sí mismo.
Entonces, ¿Qué hacemos? Dejamos la definición de las tareas lo más simple y explicativo posible, sin entrar en terminos muy tecnicos(a menos que sea realmente necesario), y en caso de necesitar ayuda por falta de conocimiento, o porque no entendemos la demanda, es tan solo enviar un mensaje a alguien o un grupo de personas que nos pueda auxiliar.

Todo esto parece un poco contradictorio en sí mismo, pero quiero dejar un ejemplo muy claro y evidente para que se logre entender la pérdida de tiempo que genera la sobre definición de las tareas.

Se necesita cambiar los brand colors de la aplicación, tal como se definió en el diseño. Link al diseño

Se da una mirada al diseño y creo que ya todos más o menos tendrían una idea de lo que se debe hacer, ¿no? Pero es más que común la situación, donde de esa tarea se realizan refinamientos(de los cuales hablaré más en el tópico de organización) y quedan tareas definidas así:

Se necesita cambiar los brand colors de la aplicación, tal como se definió en el diseño. Link al diseño
Para eso es necesario modificar en el theme del proyecto todas las propiedades brand tal cual definidas en la configuración del diseño system que está en el diseño.

¿Eso sirve? Si, y probablemente el que realiza la tarea, si lo lee, pueda resolverlo más rápido. Pero para hacer esa explicación de como resolverlo tuvimos que gastar un tiempo más en explicarlo, cuando tendría que ser algo que ya tendríamos que saber a priori al momento de leer la definición general de lo que es necesario hacer en esa tarea. Y como dije antes, en caso de no saber como resolverlo, es tan solo pedir ayuda para que nos expliquen por donde mirar.
Entiendo que hay mucha gente que no concuerde en este punto, pero yo no concuerdo en la perspectiva, casi moda, de ser ultra explicativos, teniendo que escribir las definiciones de las cosas como si el receptor de las mismas fuese una persona ajena al contexto del desarrollo. Obviamente que esto no aplicaría a gente muy Junior, o gente que está en proceso de onboarding, pero también no voy a explicar hasta lo último que debe hacer porque entraríamos a criar Juniors eternos, o un onboarding de nunca acabar.

Y como dije al principio, no voy a ofrecer una fórmula mágica para llegar a mi punto de vista ideal de esa comunicación, cada equipo, empresa y producto es un mundo diferente, con dinámicas diferentes, con exigencias diferentes y sobre todo con personas diferentes.