Los Arquitectos deben “ensuciarse las manos”
Hace un tiempo me compre el libro “97 Things Every Software Architect Should Know”, libro que recopila algunos pensamientos de varios arquitectos. Ha resultado muy entretenido ya que son pequeños artículos de 2 o 3 páginas que van directo al grano.
Uno de mis axiomas favoritos hasta el momento: Architects Must Be Hands-on de John Davies, el cual resumo a continuación:
Un buen arquitecto debe liderar siendo el ejemplo, el o ella debe ser capaz de realizar las tareas de cualquiera de los miembros de su equipo desde cablear la red, hasta escribir los procedimientos de compilación, hasta escribir pruebas unitarias, etc. Sin una buena comprensión de todo el rango de tecnología un arquitecto no sería nada distinto a un líder o jefe de proyecto. Es perfectamente aceptable de que cada miembro del equipo tenga un conocimiento más profundo en su área específica pero es difícil de imaginar que el equipo pueda tener confianza en un arquitecto que no entiende la tecnología. Como se ha dicho siempre, el arquitecto es la interfaz entre el negocio y el equipo de tecnología; el arquitecto debe comprender cada aspecto de la tecnología para representar a todo el equipo sin tener que estar constantemente refiriéndose a otros. Similarmente, el arquitecto debe entender el negocio para conducir al equipo hacia su objetivo en función de servir las necesidades del negocio.
Un arquitecto es como el piloto de un avión; puede no parecer ocupado todo el tiempo pero usa años de experiencia para constantemente monitorear la situación, tomando acciones inmediatas si oye o ve algo fuera de lo común. El jefe de proyecto (co-piloto) ejecuta las tareas rutinarias del día a día liberando al arquitecto de tareas mundanas y la administración de personas.
Las personas aprenden mejor mirando a otros; así aprendemos como niños. Un arquitecto debe ser capaz de identificar un problema, juntar al equipo y, sin elegir a una victima, explicar de qué se trata el problema y proveer una solución elegante al mismo. Es perfectamente respetable que el arquitecto pida ayuda al equipo. El equipo debe sentirse parte de la solución pero es responsabilidad del arquitecto liderar la discusión e identificar la solución correcta.
Esto último, al menos a mí, me ha resultado muy bien. Lo único que se logra al identificar a una víctima es crear un clima laboral poco cálido en el cual es muy difícil sacar el 100% de las personas.
Un arquitecto viene generalmente con un muy buen curriculum y con un pasado impresionante, pudiendo impresionar al negocio y a los tecnólogos pero, a menos que pueda demostrar metiendo las manos lo que puede hacer, es difícil que se gane el respeto del equipo, dificultando la habilidad del equipo para aprender y como consecuencia hacer casi imposible entregar aquello para lo cual fueron contratados originalmente.
Lo anterior se fortalece un poco gracias a otro axioma de Mike Brown If you design it, you should be able to code it. Claro, ¿cómo puedo exigir a otros algo que yo no soy capaz de hacer? Aunque parezca insólito esto es bastante más común de lo que uno pudiera esperar…
