Preguntas clave que todo arquitecto de software usa

Hacer buenas preguntas es una de las habilidades más subestimadas de un arquitecto de software. Aprender a preguntar te ayuda a mapear el contexto, alinear lenguaje técnico con negocio y diseñar mejores soluciones sin que tu interlocutor se sienta atacado. Si lideras decisiones técnicas o quieres formarte en arquitectura, este es un terreno que necesitas dominar.

¿Por qué hacer preguntas es clave en arquitectura de software?

Preguntar bien implica entender tu propio contexto y, al mismo tiempo, leer el de la persona que te responde. No siempre tiene toda la información, y a veces puede sentirse evaluada cuando indagas sobre una decisión que ya tomó.

Aun así, preguntar te entrega algo que ningún diagrama te da: un mapa compartido y un lenguaje común para diseñar. Y cuando una respuesta se queda corta, repreguntar desde otro ángulo casi siempre destapa información que no estaba en la primera versión.

No hay preguntas malas, salvo contadas excepciones. Lo que sí hay es curiosidad mal calibrada.

¿Cuál es la mejor forma de preguntar sin que la otra persona se ponga a la defensiva? Cambia las preguntas que inician con "por qué" por preguntas que inician con "para qué". Así, el foco se mueve hacia la decisión y no hacia la persona.

¿Qué patrones de preguntas puede usar un arquitecto de software?

A los arquitectos nos gustan los patrones, y para preguntar también existen. Estos cinco funcionan en casi cualquier proyecto:

• ¿Qué entendemos exactamente por…? Útil cuando aparece un concepto nuevo o ambiguo.
• ¿Cómo se soluciona actualmente este problema? Te permite comparar tus alternativas con lo que ya existe.
• ¿Quién es responsable de resolver, ejecutar o aprobar esta tarea? Le pone nombre a los roles y a las personas que debes seguir entrevistando.
• ¿Para qué hacemos esta tarea específica? Revela los resultados esperados y las fallas del sistema actual.
• ¿Cómo llegaste a decidir X o cómo evalúas Y? Invita a extenderse y deja a la vista lo que aún no se sabe.

El truco está en sustituir el por qué acusatorio por para qué o cómo. Cuando preguntas "¿para qué usamos esta herramienta?", la respuesta suele venir cargada de matices: "la usamos para A, B y C, pero no para D, porque ahí usamos otra".

¿Cómo reformular un por qué sin sonar agresivo?

Mueve el objeto de la pregunta. En lugar de cuestionar a la persona, cuestiona la decisión o el proceso. Para qué y cómo son tus mejores aliados para que la conversación fluya y la otra persona se sienta cómoda compartiendo lo que sabe.

¿Qué preguntas le hacen al arquitecto de software y cómo responderlas?

Del otro lado del mostrador, las organizaciones también te van a preguntar. Y esperan respuestas con más profundidad y amplitud que el problema inmediato.

¿Cuál es la política para una tarea específica?

Aquí asumen que tienes una respuesta lista para cada caso posible. Lo recomendable es evaluar el problema puntual, contrastarlo con los diseños que ya tienes y, si no encaja, mejorar el diseño o sumar políticas que cubran ese requisito.

¿Por qué está tan lento el sistema, la pantalla o la base de datos?

Apóyate en los requisitos no funcionales y en los acuerdos de nivel de servicio (SLA). Con observabilidad bien implementada puedes ubicar el cuello de botella y dar una respuesta cuantitativa, no una intuición.

¿Qué son los requisitos no funcionales? Son las características de calidad del sistema, como rendimiento, disponibilidad o seguridad, que definen cómo debe comportarse, no qué debe hacer.

¿Quién debería hacer esta tarea?

Las áreas de negocio suelen ver al equipo de desarrollo como unidimensional, asumiendo que cualquier persona puede hacer cualquier tarea. Tú sabes que existen especializaciones. Toma en cuenta las capacidades reales de tu equipo y propón asignaciones más equitativas y acordes a sus habilidades.

¿Por qué el resultado X es distinto al resultado Y?

Muchas personas miran solo los números finales, no el contexto en que se generan. Los sistemas que agregan datos para analítica suelen normalizar o aplicar técnicas estadísticas que dejan diferencias ligeras o notorias respecto a lo esperado. Sé estricto al identificar qué argumentos estadísticos o agrupaciones están detrás de cada respuesta que reciben tus usuarios.

¿Cuánto debería demorar esta tarea, proyecto o mejora?

La pregunta más común y la más traicionera. Tus estimaciones se suelen tomar como verdad absoluta. Para responder con criterio considera:

• La estructura y diseño actual del sistema.
• Las dependencias evidentes y las ocultas.
• Las capacidades del equipo.
• Las restricciones y riesgos conocidos.

Todas estas preguntas comparten un mismo trasfondo: la organización espera que el arquitecto de software vea más allá del problema inmediato. Esa visión amplia y profunda es justo lo que diferencia a quien diseña sistemas de quien solo los implementa.

¿Qué pregunta sueles hacer (o te hacen) que te haya destrabado un proyecto? Cuéntalo en los comentarios.