Últimamente me han transferido a otro departamento de nuestra empresa.
El equipo iba bien, pero noté que tenían algunos problemas con nuestro Arquitecto de software. En nuestro equipo, estamos separados en dos divisiones en las que actualmente estamos haciendo la mayor parte del desarrollo de front-end y en la otra división que se concentra en hacer las API de back-end (Desarrollo de back-end). Las dos divisiones se reúnen solo una o dos veces por semana a través de reuniones telefónicas. Ambas divisiones están separadas geográficamente en dos países diferentes. Por eso colaboramos a través de llamadas y correos electrónicos.
Seguimos recibiendo los resultados de los comentarios con el equipo de back-end sobre lo que han completado en los últimos 2 meses. El Arquitecto de Software del equipo de back-end nos dijo que el back-end iba bien y siguen repitiendo la misma respuesta, ya que queremos sus resultados que aún no han dado durante el último mes.
Últimamente en nuestra División (Desarrollo Front End). Tuvimos una reunión con el equipo de back-end, así como con el gerente del proyecto y los gerentes comerciales. Mi equipo (Front End) planteó nuestra preocupación sobre cuáles son los plazos y los entregables del proyecto de nuestro proyecto web y también sobre los resultados del equipo de back-end. Nos sorprendió mucho que hayan desarrollado solo dos API durante los últimos 2 meses que no están relacionados con lo acordado en primer lugar. Sin ninguna base de datos en absoluto. Es muy inimaginable.
Uno de los gerentes de proyecto (de un departamento diferente) hizo varias preguntas al arquitecto de software.
Gerente de proyecto : ¿Qué lenguaje de programación usó su equipo en las API de back-end? (Java, PHP, etc.).
Arquitecto de software : ¿Es eso importante? Déjame llegar al equipo
Arquitecto de software : Tengo una pregunta rápida, ¿qué es Agile Scrum y por qué lo estamos usando?
Arquitecto de software : también necesitamos el código fuente de la API del departamento (del director del proyecto) para que podamos reutilizar el código de nuestra parte.
Realmente estábamos tan sorprendidos que ni siquiera sabía qué es Agile Scrum.
Como miembro del equipo, ¿qué puedo hacer para que las cosas vayan bien con ambos equipos?
(Actualizado: ya lo hemos hablado con la gerencia comercial y parecen tomar el lado de los Arquitectos de Software sobre nuestras preocupaciones)
Este es un problema mayor que solo el Arquitecto. También tienes un PM ineficaz.
Seguimos recibiendo los resultados de los comentarios con el equipo de back-end sobre lo que han completado en los últimos 2 meses. El Arquitecto de Software en el equipo de back-end nos dijo que el back-end estaba yendo bien [pero] todavía no lo han dado durante el último mes.
El PM debe administrar las interacciones entre los equipos, pero está seriamente dormido al volante si acepta que el equipo remoto ha realizado trabajo sin ninguna evidencia de ello . Asimismo, si no cree que el trabajo está hecho pero no actúa. Si el arquitecto entiende Scrum o no, no es el punto más relevante: él y su equipo hacen promesas, no las cumplen y no se les exige que rindan cuentas. Presumiblemente, todo el fracaso saldrá a la luz en un futuro lejano cuando nada funcione según lo planeado, pero para entonces será demasiado tarde para rectificar la situación.
Es necesario que la dirección tome medidas. Si el arquitecto ni siquiera tiene idea de cómo hacer su propio trabajo, habrá un gran impacto, a menos que haya alguien más para hacer su trabajo y el suyo propio, lo que tendrá un impacto a largo plazo. La gerencia necesita averiguar sobre ese tipo y cómo lo contrataron para empezar, tal vez tenga habilidades en otros lugares y esté fuera de lugar, pero esas son respuestas muy, muy malas para un arquitecto.
Un arquitecto debe tener una sólida experiencia en desarrollo, así como en el diseño de programas durante todo el ciclo de vida y, por lo general, con varios idiomas, a menos que esté especializado en ciertas tecnologías. La parte ágil no me preocupa tanto, aunque debería estar al menos familiarizado, incluso si no lo ha trabajado antes, pero las respuestas sobre los lenguajes de código y el código exigente para copiar son impactantes, junto con la salida del otro. El equipo parece pobre por lo que dices. Algunas API son muy complejas y toman tiempo, pero si se trata de una API simple y se supone que hay muchas y no están rindiendo bien, entonces la gerencia necesita motivarlas para que se desempeñen o hacer algunos ajustes de personal para que las cosas sucedan.
Eleve sus inquietudes a la gerencia de inmediato y haga que tomen medidas o esperen demoras debido al otro equipo.
Claramente, hay problemas de administración y potencialmente problemas de comunicación. El problema de la gestión está cubierto por otras respuestas. Me gustaría agregar algunas de las sugerencias técnicas que puede expresar cuando discuta el problema con su gerencia:
Como miembro del equipo, ¿qué puedo hacer para que las cosas vayan bien con ambos equipos?
Respuesta simple : el arquitecto debe irse. Esta persona ya debería saber la respuesta a las preguntas que mencionaste en la publicación.
El no tan simple cómo:
Tratar con un mal arquitecto de software es muy difícil. Si su empresa ha decidido que necesita uno (primero) y luego lo contrata, tiene un cierto estatus elevado. Solía trabajar con uno a quien llamé experto en Google, no podía codificar ni implementar ejemplos de conceptos simples.
La forma en que nuestro equipo los trató fue desafiarlo técnicamente de manera constante y pedirle que proporcionara maquetas de conceptos (más de lo que puede simplemente buscar en Google) que quería que el equipo implementara. Al final, después de hacer esto constantemente, la gerencia comenzó a ver que, aunque la persona tenía un título elegante, en realidad no podía hacer mucho para agregar valor al equipo y lo despidieron.
Tomó un tiempo, y fue doloroso. No envidio tu posición.
chucho
jane s
Walfrat
cdkMoose