pronto estará impulsando a su equipo a proponer una nueva arquitectura para el inicio de sesión SSL. También podemos tener algunas personas que no tendrán mucho que contribuir y podrían usar su tiempo de manera más productiva, 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á familiarizado con el proceso de inicio de sesión. Por eso hemos decidido que solo las personas interesadas o las personas clave en el tema de los RCs estarán presentes. Otras personas también están invitadas, pero no es obligatorio para ellos.
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!
Comments