¿Qué papel debe jugar un arquitecto técnico en la Gestión de Proyectos?

Si va a trabajar en varios proyectos, creo que debe asegurarse de que su atención se centre en la imagen de todos los proyectos y no demasiado intensamente en un solo proyecto. Si se convierte en el principal responsable de la toma de decisiones/propietario de la arquitectura del núcleo de cada proyecto, eventualmente se convertirá en un cuello de botella, ya que el equipo lo inundará con preguntas sobre lo que ha decidido.

Soy un fuerte defensor de que las personas que toman la decisión final sobre la arquitectura deberían ser las personas que se quedarán con la implementación y la corrección de errores del producto final.

Dado que está haciendo trabajo entre proyectos, creo que sus responsabilidades deberían ser:

• Desarrollar y sembrar los equipos que trabajan en estos proyectos con el conocimiento, las personas y la visión adecuados.
• Mantener cierto grado de consistencia y polinización cruzada de ideas entre proyectos.
• Siendo la llamada final solo en áreas donde hay una razón para mantener los proyectos consistentes.
• Extinción de incendios ocasional en un proyecto específico según sea necesario debido a la calamidad.

Si no hay una persona en cada proyecto que tenga la responsabilidad principal de ese proyecto , entonces tienes un problema. En el momento en que su rol se convierta en el propietario principal de un proyecto determinado, tendrá que tomar la decisión entre centrarse en ese proyecto y un enfoque general en todos los proyectos.

El arquitecto técnico es un rol específico, ya que las expectativas de la persona que lo cumple difieren mucho según la organización e incluso con la misma organización dependiendo de un proyecto.

En resumen, el arquitecto técnico debe asumir la responsabilidad total de la arquitectura del software. No solo significa diseñarlo de una manera que permita cumplir con todos los requisitos no funcionales, por ejemplo, escalabilidad, rendimiento, sino también hacer que sea razonablemente fácil para los desarrolladores crear software. No obtiene puntos por una arquitectura sofisticada de primer nivel si el equipo de desarrollo tiene dificultades para crear la aplicación y mantenerla.

Cuando pienso en la responsabilidad, la considero a lo largo de todo el proyecto. El trabajo del arquitecto no termina cuando comienza el desarrollo, ya que la arquitectura puede evolucionar con el tiempo, y por lo general debería evolucionar.

Además, en muchos proyectos ágiles, puede encontrar una arquitectura que se construye de manera incremental : establece solo los bordes generales al principio y luego los agrega y los cambia a medida que agrega nuevas funciones. Nuevamente, si planea ajustarse a los requisitos cambiantes en lo que respecta a las características, debe planificar lo mismo para la arquitectura para que el trabajo no se realice al comienzo del proyecto.

También diría que es el arquitecto técnico quien debe preocuparse por la deuda técnica en el proyecto . Si se incurre en él y cuándo, si alguna vez, se devuelve. Por supuesto, siempre y cuando a alguien le importe tal cosa.

Por lo general, no es responsabilidad directa del arquitecto, pero agregaría la responsabilidad del mantenimiento del proyecto, ya que a menudo vemos proyectos que incluso se terminan a tiempo, pero luego los costos de mantenimiento se disparan y, a veces, la razón principal es un mal diseño de la arquitectura o una ejecución deficiente, es decir, no garantizar ese equipo de desarrollo está siguiendo las pautas.

Ahora lo vago aquí es cómo entendemos la arquitectura . Puede ser cualquier cosa, desde solo algunas pautas generales de alto nivel hasta reglas detalladas sobre lo que se debe y lo que no se debe hacer, qué herramientas, bibliotecas, patrones de diseño, estándares de codificación, etc., se usan y cuáles no. De todos modos, independientemente de cómo se defina la arquitectura en la organización o el proyecto, todas las cuestiones relacionadas con la arquitectura deben dirigirse al arquitecto técnico.

Para mí, es una gran señal de alerta que se le pida que sea el arquitecto técnico de la organización (responsable de la arquitectura de X cantidad de proyectos), que administre proyectos de Y cantidad de proyectos y que sea un desarrollador de Z cantidad de proyectos. No sé cómo te las arreglarás para tener éxito en los 3 roles, en X+Y+Z número de proyectos.

He intentado hacer tanto el desarrollo como la gestión de proyectos al mismo tiempo, y por lo general implicaba turnarse para descuidar una función frente a la otra.

El hecho de que te pidan que hagas todas estas cosas me dice que la organización piensa muy bien de tus habilidades y conocimientos, ¡así que eso es algo bueno! Pero simplemente no asuma más de lo que puede administrar con éxito.

En RUP , Software Architect es responsable del Documento de arquitectura de software (SAD), que es un puente entre la Especificación de requisitos de software (SRS) y el Documento de diseño de software (SDD).

En la práctica, significa que un Arquitecto debe ser responsable de la transferencia de información entre el dominio del problema y el dominio de la solución, a lo largo de todo el ciclo de vida del proyecto.

Como Arquitecto Técnico (TA), el siguiente es su papel y responsabilidad: Tener un punto de vista de Diseño, Construcción y Pruebas junto con proporcionar actualizaciones de documentos relacionados con el diseño de alto nivel, el diseño de bajo nivel y el desarrollo basado en pruebas según los requerimientos del negocio. Asumir roles principales para la toma de decisiones.

Por supuesto, todas las acciones anteriores deben, como consecuencia, conducir al equipo y al proyecto a un final exitoso, teniendo en cuenta que, para el cliente, lo más importante es la entrega exitosa del proyecto. Por lo tanto, es crucial que el arquitecto conozca el plan de lanzamiento.

En el aspecto técnico, además del diseño adecuado, también es importante cuidar los aspectos operativos y de infraestructura; sin entornos configurados consistentemente, un repositorio de código, un sistema de seguimiento de errores, integración continua y flujo de implementación adaptados al proyecto, la entrega del proyecto puede estar en riesgo. Obviamente, como en los casos anteriores, la AT no tiene que hacer el trabajo asociado a la implementación de estos aspectos con sus propias manos; él más bien colabora con el Gerente de Proyecto y el Gerente de Versión para asegurarse de que todo esté bien y cumplir con las solicitudes del equipo.

Los Arquitectos Técnicos que trabajan en proyectos de desarrollo son los responsables últimos de la solución técnica, asegurando que la arquitectura técnica sea adecuada dentro del contexto de la pila de tecnología del cliente y que esté alineada con las habilidades y el perfil del equipo de desarrollo. El arquitecto debe asegurarse de que la infraestructura de desarrollo satisfaga las necesidades del equipo. Estas son las responsabilidades de la AT: por la calidad técnica, por el éxito en la entrega y por una buena relación con el cliente.

En la mayor parte de MNC, habíamos experimentado una tendencia que otorgaba el papel de arquitecto de software al gerente de proyecto que había completado una buena permanencia (5 años) en una empresa. Esto sucedió en el momento en que el arquitecto de tecnología cambió de compañía para proporcionar KT apropiado a su gerente de informes, quien asumirá su rol de arquitecto en paralelo con la contratación de un nuevo arquitecto. Esto va a la persuasión de gestión de la empresa.