Recientemente me encontré con la situación en la que tengo que tratar con la persona (arquitecto de software) que parece pensar que la solución de software que se le ocurrió es básicamente "divinamente correcta" y se puede aplicar a cada situación. Sin entrar en demasiados detalles sobre cuál es la solución, hicimos un análisis rápido de la aplicación de la solución al problema en cuestión y salimos con más preguntas y problemas que me gustaría enumerar en la pregunta, sin embargo, esta persona persiste en aplicar el solución.
Algunos de los primeros intentos de utilizar la solución que se le ocurrió a esta persona produjeron las máquinas de Rube Goldberg , que se había demostrado que funcionaban mucho más lentamente que las soluciones anteriores (sin importar cuán anticuadas y mal escritas).
Lo que básicamente regresa de esta persona cuando comienzan a hacerse preguntas es: "¡Esta es la forma en que he decidido hacerlo y esto es lo que haremos!"
¿Cómo lidias con una persona así?
La única solución rápida que he encontrado en estas situaciones es encontrar una nueva situación. Está lidiando con una locura organizacional y no podrá solucionarlo en el corto plazo. Se ha promovido a la persona equivocada y su gerencia no parece saberlo ni preocuparse. No tiene suficiente influencia para efectuar un cambio, y los argumentos técnicos no funcionarán .
La alternativa es aceptar el proceso ineficaz y esperar su momento. Eventualmente, los sobrecostos obligarán a alguien a darse cuenta. El arquitecto se animará a hacer otra cosa. Si te has quedado, cooperando y ganando amigos, tal vez seas el próximo arquitecto.
Por cierto, dejé una situación muy similar hace cinco años. Los líderes técnicos incompetentes fueron reemplazados el año pasado.
Si esa persona tiene el poder de decisión, eso es todo. Si no cumple con los requisitos del cliente (es decir, el cliente no está de acuerdo con que la solución cumpla con sus requisitos), entonces no necesariamente tiene que pagar por ella (a menos que un contrato diga lo contrario), y puede decir algo tan simple como "Ok , escuché por qué quiere ir por este camino, pero eso no resuelve el problema que necesito que el [software/producto/solución] resuelva".
Los egos se disparan. Esto es parte de cualquier lugar de trabajo. Cuando se trata de tipos de ingenieros, puede intentar presentar métricas de rendimiento y calidad objetivas y medibles (si eso se aplica a su situación): los ingenieros (al menos en general) responderán a argumentos razonados. Si eso falla, entonces debe considerar quién tiene realmente el poder de tomar decisiones, si vale la pena luchar o no, y cómo afectará a sus clientes y negocios. No creo que esté de más dar a conocer sus preocupaciones, siempre que sea un punto de vista razonado y objetivo, y no un ataque personal al ingeniero.
Habiendo dicho todo eso, lo que no vemos de su pregunta es el punto de vista del ingeniero; tal vez esté equivocado en esto, tal vez no lo esté; es difícil tomar una determinación sin conocer ambos lados.
En situaciones similares, dependí de obtener una lista de recursos (libros, blogs, estándares y orientación de los principales proveedores en su espacio de desarrollo particular, por ejemplo, IBM, Microsoft, Idesign, Thoughtworks, por nombrar solo algunos) para respaldar los puntos que Estoy tratando de comunicarme y, lamentablemente, tuve que producirlos en las reuniones.
Si ha pasado por ese proceso y todavía se le dice que está equivocado, incorrecto o saben mejor. Luego, haga lo que se le indique, pero conserve su material de origen si las cosas salen mal para protegerse a sí mismo y a su propia integridad profesional. En una nota positiva, ayudará a mejorar su conjunto de habilidades, ya que aprenderá cómo hacer la investigación necesaria para respaldar sus declaraciones y cómo lidiar con las dificultades (personas, situaciones y enfoques defectuosos).
Finalmente, solo pregunte cómo llegaron a los resultados de sus decisiones. Es el trabajo de un arquitecto de software mostrar la intención y el propósito de un diseño y cómo las partes funcionales encajan para brindar una solución.
Lo que puedes hacer es hablar con él en grupo al respecto. Si se trata de un esfuerzo compartido, entonces necesita ver qué piensan otras personas sobre su solución y si hay una alternativa mejor.
Si cree que la calidad de su solución no es lo suficientemente buena y haría que su cliente no estuviera satisfecho o pondría en peligro su proyecto. Hable con su líder de equipo o jefe. Explíqueles por qué cree que su solución no es correcta. Muestra tu alternativa. Sin embargo, si usted es el único en su equipo que piensa que está equivocado, me temo que tendrá que seguir la corriente.
JuanFx
friki afable
Karlson
Karlson
shog9