Navegando los primeros días como Software Architect. Parte I: Habla con la gente.

Los primeros días en esta posición crucial pueden ser tanto emocionantes como desafiantes. Muchas nuevas aventuras. Pero, en el lado práctico, ¿qué deberías hacer justo después de aterrizar en esta posición? Compartiré lo que funciona mejor en esta serie basándome en mi experiencia.

Este primer artículo es sobre el Día Cero. La tarea más importante con la que necesitarás comenzar.

Habla con la gente

Espera, ¿qué? 😕 ¿Hablar con la gente es lo primero que hay que hacer en una posición técnica? Lamento decepcionarte. Esta no es una posición puramente técnica. No eres el experto técnico más excelente de la compañía; eres quien construye puentes entre la gente técnica (incluidos esos expertos) y el resto de la organización. Eres un facilitador, un influencer y un secretario.

Haz siempre preguntas similares a todos los que conozcas:

• ¿Qué esperan de ti? ¿Qué piensan que son tus responsabilidades como Software/Solution/Enterprise Architect?
• ¿Cuál sería un buen resultado tangible que puedes entregar? En diferentes marcos temporales: corto plazo y largo plazo.
• ¿Cómo puedes ayudarles en su trabajo diario? ¿Cuáles son sus principales puntos de dolor? Déjalos hablar sobre cualquier punto de dolor, no restringido solo a los técnicos. Cuanto más conocimiento y contexto obtengas, mejor.
• ¿Quieren comunicarse contigo? Si es así, ¿en qué formato y con qué frecuencia? ¿Quieren involucrarse o solo estar informados?
• ¿Algo de contexto sobre el sistema desde su perspectiva?

¿Con quién deberías tener una charla? Tus stakeholders. Puedo darte algunas pistas sobre quiénes suelen ser estas personas:

• Tu manager. Por favor, también pregunta a tu manager qué esperan de ti en términos tangibles y medibles. La posición [Prefix-]Architect[-Suffix] es uno de los roles definidos de forma más vaga en muchas organizaciones.
• Otros ingenieros. No necesitas hablar con cada persona, pero asegúrate de obtener una representación de conocimiento diversa: backend, frontend, seguridad, plataforma, infraestructura, etc. A menudo es mejor hablar con ellos individualmente o en grupos pequeños.
• Product/Project Managers y equipos de estrategia (lo que aplique). Presta especial atención a su visión del producto o servicios de tu organización. Pide tanto material disponible como sea posible. ¿Qué quieren lograr a corto plazo? ¿Y a largo plazo? ¿Quiénes son nuestros usuarios, qué están buscando? Pregunta sobre user journeys, value streams, etc.
• Product Designers / UX. Usualmente, son buenos comunicadores de los objetivos del producto desde una perspectiva visual y pueden darte un ángulo adicional.
• Engineering Managers, Scrum Masters, Agile Coaches, etc. No son todos iguales, pero tienen algo en común: se preocupan por las formas de trabajar y los procesos. Esa también es una excelente perspectiva.
• Operaciones / Soporte. Te gustaría saber cómo la gente mantiene tu sistema vivo y cómo lidiar con las solicitudes de clientes e incidentes.
• Comercial / Ventas / Account Managers. Esta es también una de las perspectivas más valiosas que puedes obtener como arquitecto. ¿Cómo se vende todo esto? ¿Cómo puedes construir puentes entre esta parte de la organización y la ingeniería, por ejemplo?
• Otros, pero depende de tu organización: compliance, seguridad, recursos humanos…

Comienza presentándote si aún no se han conocido. Manténlo lo más informal posible ya que es más divertido, aunque puede que necesites adaptarte a tu audiencia. Cuéntales cómo llegaste a esa posición y por qué están teniendo una conversación. Escucha más de lo que hablas. Aprende. Hazles saber a las personas que estás en un viaje de descubrimiento, especialmente si preguntan sobre tus planes.

Toma notas. Puedes usar cualquier formato que te convenga. Si necesitas inspiración, creé una plantilla Miro con una tabla para ayudarte a recopilar las notas.

¡Alerta de spoiler! Basándome en mi experiencia, estos son algunos hallazgos comunes que puedes esperar:

• La gente fuera de ingeniería no entiende la arquitectura del sistema.
• La gente tiene suposiciones erróneas sobre tu rol o no entiende qué deberías hacer.
• La gente entiende tu rol pero no cree que seas necesario y puede considerarte un anti-patrón Agile/otra-metodología.
• La gente piensa que vas a resolver todos los problemas en la organización, especialmente en el lado técnico.

Puedes explicar las suposiciones erróneas y proporcionar más contexto sobre tu rol. Sin embargo, creo que deberías hacer esto después de la sesión de preguntas y respuestas para evitar sesgos.

Procesando la información

Puedes extraer algunas conclusiones cuando alcances una buena variedad de respuestas. Intenta agrupar algunas de las notas que tomaste como “Desafíos” y resúmelas con one-liners. Priorízalas.

Si ya tenías un plan inicial en mente, donde propusiste algunas soluciones, ahora es el momento de validar tus suposiciones: ¿Puedes vincular los problemas y expectativas de la gente con las soluciones que imaginaste?

• Si puedes vincularlas, eso es precisamente lo que debes hacer a continuación. Explica cómo abordarás los desafíos con tus objetivos imaginados. Documenta eso. Organiza un Architecture Kick-off y compártelo con todos. Pide feedback.
• Tienes un desafío más grande si no puedes vincular los problemas de la organización con tus planes. ¿Cómo es esto posible? Sé autocrítico: ¿te estás enfocando en los desafíos correctos? Quizás sea momento de revisitarlos. También es probable que la gente no pueda ver el bosque por los árboles: algunos problemas y desafíos menores son causados por problemas arquitectónicos más grandes que no son visibles. En este caso, es aún más crítico dividir tus soluciones y planes para que puedas mapearlos directamente a cómo resuelves los problemas actuales que la gente experimenta. No puedes defender un refactoring masivo y un cambio en la arquitectura del sistema si solo proporcionará valor al final.

Próximos pasos

Puedes navegar al siguiente artículo de esta serie, donde presentaré la caja de herramientas completa del Software Architect, que incluye este ejercicio de Entrevista con Stakeholders.