De la Confusión a la Claridad: Aprovechando los RFCs en Entornos de Alto Rendimiento

Hola a todos. Aquí Matheus Palano. Soy de Brasil. También soy un ingeniero de software senior y líder técnico en Quintana Roo, y estoy aquí para presentar esta charla, De Caos a Claridad, Aprovechando los RFCs en entornos de alto rendimiento. Así que primero que nada, me gustaría darles un poco de contexto sobre Quintana Roo y por qué los RFCs son tan importantes allí. Quintana Roo es la plataforma de vivienda más grande de América Latina. Ya está presente en más de 50 ciudades brasileñas y ha comenzado a dar sus primeros pasos en el mercado internacional. Actualmente, cuenta con más de 5,000 empleados, incluyendo 1,000 personas en el área de producto y tecnología. Por lo tanto, nuestro proceso de toma de decisiones de arquitectura debe ser muy, muy eficiente, y por eso hemos creado una iniciativa llamada AmazingRFCs.

¿Qué esperamos lograr al final de la iniciativa? Nos encantaría ver una mejora visible en la calidad de nuestras entregas, reducir el tiempo dedicado al diseño, utilizar los RFCs como una forma de compartir conocimiento, describir y fomentar la colaboración. Para lograr eso, necesitábamos aumentar la densidad de personas técnicamente capaces de tomar excelentes decisiones de arquitectura, y una forma de hacerlo es a través de los RFCs, pero escribir RFCs implica muchas, muchas áreas, y por eso hemos decidido dividirlo en tres áreas principales. La primera área en la que íbamos a trabajar era empoderar a los puntos focales en cada tribu. Esto significa tener liderazgo técnico local que sean expertos en la materia y puedan brindar asistencia. Esos líderes también serían responsables de reclutar directamente a personas de esas tribus. La segunda área serían los gerentes capaces de capacitar y guiar. También serán responsables de monitorear las decisiones técnicas, establecer la responsabilidad de tomar buenas decisiones técnicas dentro del área misma, y por último, herramientas, guías y procesos, creando orientación para ayudar con diferentes aspectos de la arquitectura, creando herramientas para el seguimiento y mejora de la calidad. Tomamos muchas acciones para lograr esos objetivos, pero me gustaría mostrarles tres acciones que realmente marcaron la diferencia para nosotros. La primera fue crear un grupo llamado Asesores de RFCs, personas que son responsables de ayudar a otros con los RFCs y crear una comunidad para que intercambien ideas, además de traer asesores específicos que sean expertos en áreas del sistema. ¿Cómo funcionó eso? Teníamos a los asesores en la parte superior, y el proceso de escribir un RFC se dividiría en tres pasos. Paso uno, escritura inicial, presentación al equipo y luego revisión externa. El asesor también estaría presente junto con la persona que está escribiendo en esos tres pasos. La segunda acción fue abrirlo a comentarios, al menos una semana de anticipación para que las personas puedan prepararse y tener una semana para leer el RFC. Luego, la persona que estaba escribiendo junto con el asesor lo presentaría al equipo y haría los ajustes si fuera necesario. Y por último, requeriría la aprobación de al menos dos revisores, y luego estaría listo para implementarse. La segunda acción que tomamos y que marcó una gran diferencia fue en relación al diseño y proceso de revisión. Nos dimos cuenta de que nuestro tiempo sincrónico es muy valioso y tiende a producir excelentes resultados, ya que son rápidos a través de nuestras discusiones. Pero para lograr un uso óptimo del tiempo para cada persona, cambiamos el horario y el formato. Así que cambiamos los invitados para que sean seleccionados por su conocimiento del dominio y su interés. Supongamos que estamos discutiendo una nueva arquitectura para los componentes de diseño que se utilizarán ampliamente en la página de inicio de sesión. Si bien podemos tener varios candidatos muy buenos para la discusión, como un ingeniero de front-end que contribuyó en el pasado al inicio de sesión, o un ingeniero full-stack que modificó la página de inicio de sesión e integró con las APIs, o el gerente de ingeniería que

Lo segundo relacionado con el proceso de revisión de diseño fue programar revisiones de diseño ad hoc en lugar de una reunión fija semanal. Así que cambiamos nuestras reuniones de revisión de diseño de semanales a un horario ad hoc, lo que significa que la persona que está escribiendo los RCs programará la reunión de revisión de diseño. Junto con el asesor, son responsables de elegir y alinear con las personas que serán invitadas a la discusión. Junto con el asesor, preseleccionarán las aprobaciones principales que requerirán una revisión obligatoria para que su RC sea incluido. Y la revisión de diseño se programará en un momento que sea conveniente para el escritor, el asesor y los participantes. De esta manera, podemos asegurarnos de que solo las personas interesadas estén presentes y tengan el tiempo y estén allí para revisar los RCs de manera sincrónica.

Otra acción que tomamos y que me gustaría presentar aquí fueron las iniciativas de capacitación diaria. Hemos desarrollado capacitaciones que se centran en mejorar las habilidades técnicas y el conocimiento necesario para la toma de decisiones arquitectónicas. Cubrió una amplia gama de temas, desde principios arquitectónicos fundamentales hasta técnicas[62] avanzadas. Por ejemplo, la introducción al análisis de problemas, donde aprendimos a identificar correctamente una iniciativa, recopilar requisitos, aclarar objetivos y definir el alcance, identificar posibles roles de usuario y partes interesadas, identificar posibles soluciones, esbozar estrategias y asignar resultados, y también probar y medir los resultados. Otra capacitación que tuvimos fue una descripción general de la arquitectura de la solución, donde aprendimos los conceptos detrás de la arquitectura, una descripción general de microservicios, micro-frontends, MVC y otros socios. Comunicación sincrónica versus asincrónica, Quill, Topic, PubSub, UTLs, y API gateways. Esas capacitaciones nos brindaron una caja de herramientas para escribir RCs y encontrar soluciones que podrían ser potencialmente buenas. Y eso nos ayudó a acelerar la revisión también, porque la calidad de nuestros RCs aumentó significativamente.

Entonces, ¿cuáles fueron los resultados de esas acciones? Primero, hemos aumentado la densidad de personas técnicamente capaces de tomar excelentes decisiones arquitectónicas. Ese era nuestro objetivo principal. Y hoy en día, tenemos personas que son muy, muy capaces de escribir buenos RCs. En segundo lugar, hemos aumentado la cantidad de RCs escritos. Las personas se sintieron más cómodas escribiendo RCs y, por lo tanto, escribieron aún más RCs. Y por último, pero no menos importante, hemos aumentado la calidad de los RCs implementados. No solo las revisiones, sino también el primer borrador de los RCs tienen una calidad realmente buena. Y esto nos ayudó a tener una mejor solución en producción. Esto es lo que decidí traerles y mostrarles este caso. Espero que lo hayan disfrutado y muchas gracias. Y como decimos en portugués, ¡Obrigado!