De la Confusión a la Claridad: Aprovechando las RFC en Entornos de Alto Rendimiento

al equipo, y luego la revisión externa. El asesor también estaría presente junto con la persona que está escribiendo en esos tres pasos. El segundo paso estaba abierto a comentarios. Al menos una semana de anticipación para que las personas puedan prepararse y tener una semana para leer la RFC. Luego, la persona que estaba escribiendo en conjunto con el asesor la presentaría al equipo y luego harían los ajustes si fuera necesario. Y por último, pero no menos importante, 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 proceso de revisión de diseño. Nos dimos cuenta de que nuestro tiempo sincrónico es muy valioso y tiende a producir excelentes resultados en una primera fase a través de nuestras discusiones. Pero para lograr un uso óptimo del tiempo para cada persona, cambiamos el horario y el formato. Cambiamos los invitados para que sean seleccionados por su dominio de conocimiento e intereses. 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 API o el gerente de ingeniería que pronto impulsará a su equipo a proponer una nueva arquitectura para el inicio de sesión SSO. También podemos tener personas que no tienen mucho que aportar y podrían utilizar mejor su tiempo. Como un ingeniero de backend que actualmente está resolviendo un desafío en el campo o otro equipo que no tiene nada que ver con el inicio de sesión. O un ingeniero full stack que actualmente se está enfocando en integrar varios servicios de alta complejidad en los últimos meses y no está al tanto del proceso de inicio de sesión. Por eso hemos decidido que solo las personas interesadas o las personas clave en el tema de las RFC estarán presentes. Otras personas también están invitadas, pero no es obligatorio que asistan. Lo segundo relacionado con el proceso de revisión de diseño fue programar revisiones de diseño precisas en lugar de una reunión fija semanal. Cambiamos nuestras reuniones de revisión de diseño de semanales a un horario no programado, lo que significa que la persona que está escribiendo la RFC programará la reunión de revisión de diseño. Junto con el asesor, serán responsables de elegir y alinear a las personas que serán invitadas para la discusión. Junto con el asesor, preseleccionarán las aprobaciones clave que requerirán una revisión obligatoria para que su RFC se cierre, 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 tendrán el tiempo y estarán allí para revisar la RFC de manera sincrónica. Y otra acción que tomamos y que me gustaría presentar aquí fueron las iniciativas de capacitación personalizadas. Hemos desarrollado capacitaciones que se centraron 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 avanzadas. Por ejemplo, Introducción al Análisis de Problemas, donde aprendimos a identificar correctamente un problema inicial, 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 Visión General de la Arquitectura de Soluciones, donde aprendimos los conceptos detrás de la arquitectura, una descripción general de los microservicios, microcontenedores, MVC y otros socios, comunicación sincrónica frente a comunicación asincrónica, consulta o tema, publicación-suscripción, UTL y puertas de enlace de API. Esas capacitaciones nos brindaron una caja de herramientas para escribir RFC y encontrar soluciones que podrían ser potencialmente buenas. Y eso nos ayudó a acelerar la revisión también, porque la calidad de nuestras RFC aumentó significativamente. Entonces, ¿cuáles fueron los resultados de esas acciones? Primero, hemos aumentado la densidad de personas técnicamente

capaces de tomar grandes decisiones arquitectónicas. Ese era nuestro objetivo principal. Y hoy tenemos personas que son muy, muy capaces de escribir buenos RCs. En segundo lugar, hemos aumentado el número de RCs que se leen. 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 las soluciones implementadas. No solo las revisiones, sino también los primeros borradores 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 en este caso. Espero que lo hayan disfrutado. Y muchas gracias. Y como decimos en portugués, Obrigado.