Como la metodología RFC puede transformar la forma en la que coordinas un equipo técnico remoto

Soy un amante de las metodologías. Ser experto, tener seniority y saber de tu materia es a lo que todos aspiramos, pero lo que realmente transmite una imagen inmejorable de profesionalidad es tu metodología de trabajo. Ser capaz de entregar un trabajo confiable, de calidad y profesional es lo que puede ayudarte a diferenciarte de la mayoría y en consecuencia, a exigir más por tu trabajo.

Y si no lo haces por tu imagen o por tu dinero... hazlo por los gatitos. Cada vez que un equipo remoto hace reuniones para debatir un proyecto con un montón de gente en la reunión, o se produce un cambio aplicando una solución para luego darte cuenta de que habían otras opciones mejores y que si hubieras preguntado podrías haberte enterado... muere un gatito.

Así que si no quieres que mueran más gatitos, sígueme.

TL;DR:

Los RFCs son documentos que describen la solución a un problema, y están creados para mejorar la coordinación y comunicación de equipos deslocalizados que trabajan de forma asíncrona.

Estos documentos contienen un título, estado, resumen, contexto del problema, propuesta, definición de éxito y un template.

Esta metodología ha ayudado a solucionar problemas difíciles de resolver y a distribuir responsabilidades, compartir conocimiento, permitiendo contribuir a su ritmo y proporcionando una guía clara para futuros proyectos.

Que es un RFC?

Los Request for Comments/Change (RFC) existen desde los anales de internet. Se usaron en un principio para describir estándares de protocolos de comunicación cuando internet no era ni lo que conocemos ahora. Pero lo que más me flipa de esta herramienta tan antigua en este campo, es que se haya reconvertido en una herramienta increíblemente útil para la coordinación y comunicación de equipos deslocalizados que trabajan de forma asíncrona.

Un RFC se ha convertido en un documento que describe la solución técnica a un problema y herramientas de trabajo colaborativo como Notion, Confluence o un simple Google Docs han ayudado a mejorar la comunicación y a documentar el proceso de diseño de una solución entre los miembros de un proyecto, incluyendo a compañeros del equipo de desarrollo, stakeholders o simples colaboradores. La clave de estos documentos es que, desde su misma concepción, quedan publicados al acceso de todos los implicados para que sean revisados y se creen de forma colaborativa, lo que termina creando una solución construida y retroalimentada por la experiencia y participación de todos los interesados.

Cuando creamos un RFC?

En mi caso, uso los RFC en las siguientes circunstancias:

• Cuando alguien del equipo quiere proponer un cambio o visibilizar un problema, al que desea aportar una solución.
• Cuando quieres diseñar o definir la ejecución y la implementación de un proyecto.
• Cuando quieres diseñar, comunicar, dar a conocer y hacer participativo un cambio o decisión importante.
• Cuando buscas la opinión o revisión de un tema en el que puede que no tengas una solución o ni siquiera conozcas en profundidad.

Además, en mi forma de trabajar para mí es importante dejar claro en el equipo que en un RFC no se espera una respuesta inmediata y precisamente, si ayuda en equipos deslocalizados y remotos es porque todos los implicados pueden participar cuando puedan dentro de su flexibilidad horaria y disponibilidad. A diferencia de la comunicación síncrona como un Slack, en un RFC cada uno contribuye cuando puede o ni eso, ya que simplemente puede servir para que la gente se pase a verlo, este enteradá del mismo, pero no necesariamente aporte. Para mí, es como tener una reunión permanente a la vista de todos.

Obviamente, por su propia naturaleza colaborativa y pública, los RFC no son ni para tratar temas personales ni confidenciales. Además, tampoco los recomiendo para explicar cambios o decisiones jerárquicas donde, para tomar la decisión final, no se le da mucha importancia a la participación colectiva.

De que se compone un RFC?

Este es el, témplate que uso para mis RFC](https://docs.google.com/document/d/1Zyn_QlxiInjz7AEDDAqBr6Cl6Sd4ViHACvU8BX-al7Y/edit?usp=sharing) y aunque un RFC puede cambiar de proyecto a proyecto y de equipo a equipo, habitualmente, sigo el siguiente esquema::

• Título: Cada RFC tiene un número único y secuencial que sirve para identificarlo, un estatus (del cual hablaré ahora) y un título que debe ser lo más descriptivo, claro y directo posible.
• Estatus: El estatus ayuda rápidamente a identificar la situación del RFC para dejar claro que se espera de los colaboradores.
  • WIP: El autor está trabajando en él y todavía está verde para ser revisado.
  • Review: El RFC se encuentra en estado abierto de revisión, ya sea para revisar el problema o la solución.
  • Approved: Cuando el RFC propone un cambio y los responsables le dan luz verde. En esta fase, el RFC puede ser implementado.
  • Implemented: Cuando el RFC propone un cambio y este cambio ha sido implementado.
  • Closed: Cuando el RFC ha llegado al final de su ciclo y ya no se encuentra disponible para una colaboración activa.
  • Abandoned: Cuando por cualquier motivo, el RFC se ha dejado de lado en cualquiera de sus fases anteriores de forma consciente.
• Resumen: Un texto corto y sintético que aporte contexto del problema-solución. En mi opinión, aunque este punto es de los primeros, es ideal completarlo el último cuando ya se tiene todo el resto de información clara.
• Contexto: Aquí irá el contexto necesario para entender el posterior problema-solución. En esta sección debemos usar hechos, datos y métricas y no simplemente opiniones.
• Problema: Una descripción del problema que intentamos afrontar con el RFC, en que nos perjudica y porque merece ser resuelto.
• Propuesta: Una descripción de la solución para el problema propuesto. El autor no tiene por qué completar esta sección (quizá porque no tenga la confianza de ninguna solución en mente), ya que podría usar el RFC con la única intención de generar debate y crear una propuesta entre todos.
• Definición de éxito: ¿Cómo podemos estar seguros de que la propuesta al problema es exitosa? ¿Qué podemos medir? ¿Qué podemos empezar a contabilizar? Como cuando exponemos el contexto, debemos usar hechos y datos medibles, no opiniones.

En este contexto, usamos los RFC para describir procesos, procedimientos y cambios, pero lo más importante, es que es un documento que se crea, se revisa el proceso y los pasos necesarios para llevar a cabo un proyecto de manera efectiva en un entorno de trabajo remoto. Por ejemplo, un RFC podría incluir información sobre cómo se deben comunicar los miembros del equipo, cómo se deben manejar los conflictos y cómo se deben realizar y revisar las tareas.

Así que explicado todo esto, que nos aporta en el trabajo remoto, asíncrono y deslocalizado?

En mi experiencia, esta metodología ha ayudado a mejorar problemas de fondo muy difíciles de resolver, pero sobre todo, listaré los que me parecen más relevantes:

• Nos ayuda a garantizar que todos los interesados (recordemos que pueden ser los integrantes del equipo, pero también stakeholder, consejeros, etc.) estén informados en todo momento de los avances del RFC. Esto es especialmente importante en entornos remotos donde la comunicación activa es de vital importancia.
• A que cada cual participe dentro de su flexibilidad y situación, pudiendo contribuir dentro de su huso horario, mientras está de viaje o sencillamente esperando en la consulta del médico. En entornos remotos y deslocalizados cada vez más se nos aprecia no por calentar un asiento, sino por los resultados y riqueza que aportamos.
• A distribuir responsabilidades, pues el mismo autor del RFC no tiene por qué ser el encargado de implementar la solución. De esta manera, incentivamos la proposición de cambios y mejoras por cualquier integrante del equipo, ya que proponer no es igual a comerte el marrón.
• Nos ayuda a compartir conocimiento, dado que aunque creas tener las cosas claras sobre un cambio y su solución, puede sorprenderte encontrar a contribuyentes con diferentes ideas, soluciones y experiencias, creando de forma colaborativa soluciones que en un principio jamás hubieras llegado solo. Y ni que contar, de que todo ese debate queda reflejado en el RFC para la revisión de todos.
• Que cada uno aporte a su ritmo y le dedique el tiempo que necesite. ¿Por qué formar parte de interminables reuniones donde sientes que no tienes nada que aportar? De esta forma, aquellos más implicados participarán más y aquellos menos implicados, le dedicarán menos tiempo, invirtiendo cada uno únicamente el tiempo y atención que considera.
• Además, un RFC bien escrito y seguido puede ser útil para futuros proyectos similares, ya que proporciona una guía clara y documentada para el trabajo asíncrono remoto.

Una reflexión final

Documentar se ha convertido en la piedra filosofal de mi profesión. Sin ella, me siento perdido y dependiente de aquellos conocimientos que solo se comparten de forma oral. Y Siendo un ferviente defensor del trabajo realmente flexible y remoto (no a simplemente cambiar la oficina por tu despacho de casa) los RFC se han convertido en mi santo grial. Si tu día a día es apagar fuegos constantemente y el miedo a la dependencia de técnica de ciertas personas, esto no es para ti. Pero si lo que buscas es cambiar precisamente eso... entonces los RFC te están esperando.

Gracias por llegar hasta aquí y ojalá te sirvan tanto como me ha servido a mí (y salves a tantos gatitos como yo he salvado).

Algunas fuentes

https://en.wikipedia.org/wiki/Request_for_Comments
https://en.wikipedia.org/wiki/Change_request
https://philcalcado.com/2018/11/19/a_structured_rfc_process.html
https://handbook.sourcegraph.com/company-info-and-process/communication/rfcs/