El conocimiento de mis compañeros de trabajo no coincide con mi concepto de sus roles [cerrado]

Soy un desarrollador junior y recientemente me uní a mi empresa. Hay desarrolladores y consultores. Algunas personas son solo consultores sin conocimientos de programación. Estoy trabajando en un proyecto importante donde el cliente es un gran banco. El equipo está compuesto por mí (un junior), un consultor más experimentado, un arquitecto de software y un desarrollador senior.

Ambos seniors (arquitecto y desarrollador senior) no se caen bien, pero muestran respeto la mayor parte del tiempo, sin embargo, están constantemente en desacuerdo sobre las decisiones técnicas.

Se supone que el arquitecto es la persona responsable de las decisiones técnicas generales y creo que no es esa persona.

  1. No sabe cómo construir un proyecto y pidió un equipo (construyó el proyecto por primera vez en 7 Sprint, cada sprint tomó 15 días)
  2. No sabe hacer un deployment continuo con Jenkins
  3. No sabe cómo enviar a Nexus Repository una nueva instantánea y cuál es el archivo settings.xml en Maven

¿Cómo puede un arquitecto no saber estas cosas? Es muy estresante responder a sus preguntas de desarrollo porque soy un desarrollador junior y comparto todo mi conocimiento y me pagan menos (también soy un consultor de enseñanza, él no tiene ninguna habilidad de codificación).

Se supone que debe ser mi entrenador técnico y ayudarme, no al revés. En una situación específica, tuvo una reunión con un cliente para obtener los requisitos del sistema y luego explicárselos al equipo, pero tuve que salir por 2 horas y no obtuve parte de la explicación. Unos días después, le pregunté sobre una tarea, respondió una cosa y la codifiqué. Al final, dijo:

  • Está incorrecto
  • Pero esta mañana me lo explicaste así
  • yo no
  • Sí, esta mañana dijiste que necesitaba una base de datos de acceso, etc.
  • Cuando se lo expliqué a todo el equipo no estabas

Me enojé mucho después de eso porque no admitió su error y lo tergiversó al cliente.

Al gerente de proyecto no le gusta el desarrollador senior porque es el único que trabaja en la oficina de su casa toda la semana y no va a la empresa a ayudarnos (el gerente lo ha pedido) y no responde al equipo rápidamente. .

Me gusta el mayor porque es el único que sabe cómo resolver mis problemas y explicarme las cosas.

¿Qué puedo hacer para tener una mejor relación con el arquitecto? ¿Debo pedir una mejor calificación salarial? ¿Qué hago si, en el peor de los casos, el desarrollador senior es despedido?

¿Su comunicación con estas personas es en inglés? Tal vez no se están entendiendo.
El arquitecto de software en general es responsable de crear y decidir el diseño arquitectónico del sistema. él / ella no necesariamente necesita saber cómo configurar CI / CD con jenkins o enviar instantáneas, esas parecen ser tareas orientadas a devops.
Se supone que debe ser mi entrenador técnico y ayudarme, no al revés. ¿Está seguro? ¿Alguien ha dicho que eso es parte de su papel? Porque me parece que el desarrollador senior estaría entrenando a los desarrolladores junior.
(1) No tenemos absolutamente ninguna forma de saber qué se supone que debe saber un "arquitecto" en su empresa, (2) ni podemos decirle si debería recibir un aumento, (3) ni sirve de mucho discutir qué debe hacer en caso de que suceda algo que aún no ha sucedido. Le sugiero que elimine esas preguntas y se ciña a la restante: "¿Qué puedo hacer para tener una mejor relación...".
Sin ofender, pero esto parece ser más una diatriba que una pregunta real... ¿Podría editar esta pregunta en una forma más genérica?

Respuestas (3)

El trabajo de un arquitecto es diseñar el flujo general del sistema. Podría escribirle un documento de arquitectura para diferentes aplicaciones sin ningún conocimiento del lenguaje de programación subyacente o del marco de desarrollo. ¿Y por qué tengo que saber eso? Le voy a decir con la arquitectura: mire, esta información debe procesarse en ese punto, y esta entrada del usuario se necesita ahora, y este archivo debe crearse después de que finalice este procedimiento.

Esto es básicamente libre de cualquier idioma de fondo. Cómo realizar esto es el trabajo del desarrollador senior (que a veces no estará de acuerdo con el arquitecto porque algunas soluciones pueden ser más fáciles de realizar en un marco específico que otras), y parece que el desarrollador senior hace bien su trabajo.

Así que no esperes que el arquitecto tenga todo ese conocimiento y te enseñe. Hágale preguntas si cree que el flujo general es incorrecto o si diseñó los algoritmos incorrectamente, pero el manejo de Jenkins o el Repositorio Nexus es irrelevante para esto.

Estos son algunos puntos en los que podrías trabajar:

  • Obtener cosa por escrito . Si tiene un arquitecto (técnico), se supone que debe desarrollarlo en base a un documento escrito (o ticket en Jira). Necesitas cubrirte. Si ve algo mal, comuníquelo por escrito y déjele la decisión a ese arquitecto. Si a él no le importa, ya no es tu problema.
  • Como arquitecto no técnico, puede simplemente escribir lo que debe ofrecer el proceso de construcción, cómo se debe dividir el proyecto en módulos y dejar los detalles de Maven/Nexus/Jenkins al desarrollador senior.
  • Como dijiste, el código no es su fuerte, lo que significa que la definición de "arquitecto técnico" en esa empresa no es la misma que la tuya. Creo que probablemente se parece más a un arquitecto funcional (suponiendo que tenga conocimiento de algo).
  • El desarrollador senior claramente evita ese equipo; esto es probable porque el arquitecto que carece de conocimientos técnicos está impugnando sus decisiones. El hecho de que trabaje a distancia les obliga a conseguir todo por escrito. Él responde a tus preguntas, así que aprende de él.
  • Como desarrollador bajo ese "arquitecto", no tiene una decisión a la mano, por lo que no es su problema. Haz lo que te han dicho (¡por escrito!), aprende de lo que has hecho y si el proyecto se hunde, lo he vuelto a decir, no es tu problema y si te quieren hacer el chivo expiatorio, tienes pruebas escritas.
  • Una vez que tenga un registro en papel, puede intentar programar una reunión con su gerente y plantear sus inquietudes sobre el proyecto. Idealmente, a su gerente le gustará si tiene ideas sobre cómo mejorar las cosas (es decir, dejar que el desarrollador senior tome las decisiones técnicas).

Si su gerente no parece estar interesado en mejorar las cosas (como despedir al desarrollador principal), puede comenzar a buscar otro trabajo.

Una analogía puede ayudar. otras personas lo hacen. Por ejemplo, usted dice que el arquitecto es responsable de las "decisiones técnicas generales" y luego enumera las habilidades técnicas muy detalladas que le faltan. Si no entiendes su papel, no puedes aprender de él.

¿Qué tal si consideramos la construcción de viviendas como una analogía?

Eres carpintero. Puede usar un martillo (¡una pistola de clavos!), una sierra, una cinta métrica, etc. Su jefe es un contratista. Érase una vez que ella era mejor en su trabajo de lo que es hoy. El arquitecto diseñó la casa. No saben mucho sobre carpintería eficiente, aunque un buen arquitecto SÍ entiende lo que se necesita para construir sus diseños en general. Quieren una casa que se pueda construir y que sea efectiva para ese propósito. Pero su experiencia principal se encuentra en otra parte. ¿Qué quieren los dueños de casa? ¿Cómo se traduce mejor eso en un diseño? Y muchos detalles generales... fuerzas, tensiones, calidad a largo plazo, requisitos legales, resistencia a la intemperie, drenaje, etc. El panorama general en general... muchas cosas de las que usted, como carpintero, no necesita preocuparse.

De nuevo a usted. Eres un desarrollador junior. ¿Conoce la experiencia del arquitecto? Puede ser completamente diferente de lo que estás pensando. Haz algunas buenas preguntas... como: ¿cómo se ve el proyecto desde la perspectiva del arquitecto? ¿Qué les parece fácil y difícil en este proyecto?