Pregunta:
Tratar con alguien que piensa que tiene "la razón divina"
Karlson
2012-04-11 19:44:26 UTC
view on stackexchange narkive permalink

Recientemente me he encontrado con una situación en la que tengo que tratar con la persona (arquitecto de software) que parece pensar que la solución de software que ha creado es básicamente "divinamente correcta" y se puede aplicar a cualquier situación. Sin entrar en demasiados detalles sobre cuál es la solución, hemos hecho 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 esta persona ideó produjeron máquinas de Rube Goldberg que se ha demostrado que funcionan considerablemente más lento que las soluciones anteriores (sin importar cómo desactualizado y mal escrito).

Lo que básicamente regresa de esta persona cuando comienzan a hacerse preguntas es: "¡Así es como he decidido hacerlo y esto es lo que haremos!"

¿Cómo se trata con una persona así?

¿Qué tiene que ver esta pregunta con el principio de pedro?
OP ha omitido un componente crítico: cuánto valora su cordura :) Con toda seriedad, si está en el puesto, probablemente alguien lo apoye. Mientras eso se mantenga, probablemente no tenga opciones.
@JohnFx Porque desde aquí parece que esta persona alcanzó "el nivel de su propia incompetencia" pero lo quité de todos modos.
@AffableGeek Como consultor, no me importa, ya que las máquinas de Rube Goldberg pueden pagar las facturas casi indefinidamente. :)
Meta discusión relacionada: http://meta.workplace.stackexchange.com/questions/35/do-we-have-a-quality-control-issue
Cuatro respuestas:
#1
+22
kevin cline
2012-04-11 21:11:47 UTC
view on stackexchange narkive permalink

La única solución rápida que he encontrado en estas situaciones es encontrar una nueva situación. Estás lidiando con una locura organizacional y no podrás solucionarlo pronto. Se ha ascendido a la persona equivocada y su dirección no parece saberlo ni importarle. No tienes suficiente influencia para efectuar un cambio y los argumentos técnicos no funcionarán .

La alternativa es seguir el proceso ineficaz y esperar tu momento. Eventualmente, los sobrecostos obligarán a alguien a darse cuenta. Se animará al arquitecto 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.

* tal vez seas el próximo arquitecto * no en este caso, pero bien pensado.
Puede llevar mucho tiempo reemplazar a personas como esta. Si se trata de un problema crónico, debería pensar seriamente en seguir adelante.
Sí, siempre está sucediendo una pequeña cosa del vector A -> B, donde la persona incompetente visible B está siendo apoyada por una persona mayor A que da fe de que es una buena persona y, por lo tanto, no es la fuente de nuestros problemas.
+1 por encontrar una nueva situación. He luchado con la 'justicia divina' de un tomador de decisiones clave durante algunos años. La gran frustración para mí no son los desacuerdos personales o no haberlo hecho a mi manera, sino el costo comercial de una mala decisión que disminuye el éxito de mis colegas; si trabaja en equipo, debe esforzarse por ganar como equipo.
#2
+4
jefflunt
2012-04-11 20:12:50 UTC
view on stackexchange narkive permalink

Si esa persona tiene el poder de tomar decisiones, 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), no necesariamente tiene que pagar por ella (a menos que un contrato indique lo contrario) y puede decir algo tan simple como "Ok , Escuché por qué quieres 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 objetivas y medibles de rendimiento y calidad (si eso aplica en 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 esta es una pelea que vale la pena pelear o no, y cómo afectará a sus clientes y negocios. No creo que duela dar a conocer sus preocupaciones, siempre que sea un punto de vista objetivo y razonado, y no un ataque personal al ingeniero.

Dicho todo esto, lo que hacemos No veo en su pregunta 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.

* Si no cumple con los requisitos del cliente *. Lamentablemente, el cliente es interno de la empresa y no tiene forma ni conocimiento para evaluar la solución.
* Lo que no vemos de su pregunta es el punto de vista del ingeniero * Me gustaría que lo diera más allá de "aquí están sus órdenes de marcha".
En cuanto a que el cliente no tenga conocimientos para evaluar la solución, no veo cómo eso es posible. Puedo ver que un cliente no tiene las habilidades técnicas para argumentar a favor o en contra de una solución basada en ** méritos técnicos **, pero al cliente ** ** le importan cosas como si el software hace su trabajo lo suficientemente rápido como para proporcionar el valor comercial solicitado, si el software produce resultados correctos, etc. Si la solución técnica que propone el ingeniero no afecta al cliente de ninguna manera, entonces ¿por qué importa qué solución se elija? Se los contrata para ser expertos técnicos.
Tiene razón, no tienen experiencia técnica para evaluar, pero se les vende una lista de bienes que los afectará. El problema es que la persona que vende (ingeniero) no es la persona que implementa esa solución. La solución tendrá un impacto en el negocio, pero la responsabilidad de la implementación no es del ingeniero.
No sé si puedo ayudarte en eso, esto me trae muchas preguntas a la mente. No está claro por qué el ingeniero está involucrado en la discusión si no participará en la implementación ni en el soporte continuo. ¿Es esta persona un líder de departamento / equipo a quien se le han confiado estas decisiones? ¿Están incorporando a otros ingenieros que implementarán / respaldarán la solución y tendrán en cuenta su punto de vista en la decisión? Esto suena loco.
Supongamos un banco gigante que tiene "Grupo de arquitectura tecnológica", "Grupo comercial" y "Grupo de desarrollo de software". Al "Grupo de Arquitectura Tecnológica" se le ocurrió la solución y le encargó al "Grupo de Desarrollo de Software" que la implementara, mientras vendía al "Grupo de Comercio" que esto es lo mejor desde el pan de molde. A cierta altura, los grupos de arquitectura y desarrollo informan a la misma persona, pero desafortunadamente es tan alto que: http://www.fortunecity.com/campus/books/845/shithap.htm
Está bien, pero en ese caso estás atacando áreas de política, estructura y organización. Te has alejado por completo de la pregunta original, que era cómo lidiar con la persona / ego. Agregar todas estas condiciones y detalles comienza a convertir esto en una pregunta fundamentalmente diferente: es decir, cómo navegar las estructuras y políticas involucradas en cómo se toman las decisiones en las organizaciones. No puedo dar una buena respuesta a eso dentro del alcance de ** esta ** pregunta, porque es una pregunta completamente diferente.
#3
+2
Ourjamie
2012-05-15 15:06:46 UTC
view on stackexchange narkive permalink

En situaciones similares, he confiado en obtener una lista de recursos (libros, blogs, estándares y guías 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 transmitir y, lamentablemente, tuve que presentarlos en las reuniones.

Si ha pasado por ese proceso y todavía se le dice que está, no está bien, es incorrecto o conocer mejor. Luego, haga lo que se le indique, pero conserve el material original si algo sale mal para cubrirse a sí mismo y a su propia integridad profesional. En una nota positiva, le ayudará a mejorar su conjunto de habilidades a medida que aprenda a hacer la investigación necesaria para respaldar sus declaraciones y cómo lidiar con las dificultades (personas, situaciones y enfoques defectuosos).

Finalmente, pregúnteles 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 la parte de trabajo encaja para proporcionar una solución.

#4
  0
Lucas Kauffman
2012-04-11 19:55:09 UTC
view on stackexchange narkive permalink

Lo que puede 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 existe una alternativa mejor.

Si cree que la calidad de su solución no es lo suficientemente buena y haría que su Cliente insatisfecho o comprometido con su proyecto. Coméntelo 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 eres el único de tu equipo que piensa que está equivocado, entonces tendrás que seguir la corriente, me temo.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...