¿Cómo hacen uso los arquitectos de software de las habilidades de comunicación?

Answer 1

Los arquitectos de software deben escuchar al cliente, tomar notas y administrar la conversación según el temperamento del cliente.

En algunos casos raros, el cliente tiene una sólida comprensión tanto de los requisitos de implementación como del proceso comercial. Es entonces cuando solo escucha, toma notas y se asegura de que la sesión de análisis no se extienda demasiado.
A menudo, el cliente tiene una buena comprensión de su proceso comercial pero no tiene una formación técnica. En esa situación, es su trabajo traducir el proceso comercial en un diseño de solución.
Desafortunadamente, también hay casos en los que el cliente tiene una idea muy abstracta de lo que quiere. Allí, además de lo anterior, también debe educar al usuario, principalmente haciendo un razonamiento basado en casos, es decir, identificando proyectos similares en los que tenga experiencia y cómo abordó esos problemas.

Después de uno o pocos días de análisis de requisitos, debe volver con la documentación de diseño, que se compone principalmente de:

• estructuras alámbricas
• casos de uso
• otros artefactos como la transición de estado, flujo de trabajo, pseudocódigo, etc., según las necesidades del proyecto

Estos documentos se convierten en la base de la revisión inicial de la captura correcta de los requisitos, así como de los supuestos comunes que se aplican a otras partes del proyecto. Le dan confianza al cliente de que el diseñador / arquitecto sabe cómo articular formalmente sus requisitos, y ayuda a ambas partes a gestionar sus expectativas y llegar a una mejor comunicación. Es entonces cuando está en una buena posición para repetir el ciclo de diseño de análisis.

Lo importante es que su ejercicio de diseño debe ser iterativo, flexible y debe alentar al cliente a involucrarse.

También he tenido experiencias en las que los clientes son simplemente difíciles y donde no se aplica ninguna estrategia: D, pero tal vez también existen técnicas para manejar eso.

La comunicación debe continuar durante todo el ciclo de vida del proyecto. Después del análisis durante la etapa de desarrollo, hay más comunicación entre el arquitecto y el desarrollador. Para obtener eficiencias en esa etapa, el arquitecto debe asegurarse proactivamente de que el diseño técnico esté suficientemente documentado. Por ejemplo, para los sistemas de información empresarial, debe tratar de documentar las condiciones previas, posteriores, las respuestas del sistema a la interacción del usuario y los requisitos de E / S de la base de datos para cada pieza de funcionalidad.

Answer 2

¿Cómo crees que se implementan todas esas grandes ideas arquitectónicas? Es una función de comunicación efectiva a los equipos que están implementando.

Pero la comunicación es una calle de doble sentido. Los arquitectos también deben ser excelentes para comunicarse: en un proyecto grande, es posible que tengas múltiples gerentes de productos, gerentes / directores de ingeniería, así como otros arquitectos que te brinden información, y si estás Si no puede procesar toda esa comunicación con usted de manera efectiva, no será eficaz en su trabajo.

En términos de comunicar ideas arquitectónicas, debe poder elegir la herramienta adecuada para el trabajo; a veces, una presentación / presentación de diapositivas puede ser la forma de comunicar un diseño a un equipo grande. O tal vez es una serie de diagramas. O una pieza de código de prueba de concepto bien documentada que puede entregar a un equipo para ejecutar. A veces son todas esas cosas juntas. Una cosa que me gusta hacer es ejecutar una sesión diaria de “horario de oficina”, donde los miembros del equipo pueden subirse a un Hangout de Google y podemos resolver cualquier problema que enfrentemos colectivamente. Tal vez no sea ninguna de esas cosas, y todo lo que se necesita para resolver algo es una llamada telefónica de 3 minutos.

Además, como arquitecto, debe poder escuchar a su equipo y ajustar sus planes cuando resulta que está equivocado. No seas el arquitecto que se molesta cuando un desarrollador de tu equipo se te acerca y te advierte que tu diseño no funcionará debido a esta parte del sistema que olvidaste (o tal vez no sabías incluso existió). Ese tipo podría terminar ahorrando unos cientos de miles de dólares.