Domanda:
Trattare con qualcuno che pensa di essere "divinamente giusto"
Karlson
2012-04-11 19:44:26 UTC
view on stackexchange narkive permalink

Recentemente mi sono imbattuto in una situazione in cui ho a che fare con la persona (architetto del software) che sembra pensare che la soluzione software che aveva escogitato sia fondamentalmente "divinamente corretta" e possa essere applicata per ogni situazione. Senza entrare troppo nei dettagli su quale sia la soluzione, abbiamo fatto una rapida analisi dell'applicazione della soluzione al problema in questione e siamo venuti via con più domande e problemi che mi interessa elencare nella domanda, ma questa persona persiste nell'applicazione del soluzione.

Alcuni dei primi tentativi di utilizzare la soluzione che questa persona ha inventato ha prodotto le macchine di Rube Goldberg che avevano dimostrato di funzionare in modo misurabile più lento delle soluzioni precedenti (non importa come obsoleto e scritto male).

Ciò che fondamentalmente torna da questa persona quando iniziano a farsi domande è: "Questo è il modo in cui ho deciso di farlo ed è quello che faremo!"

Come gestisci una persona come questa?

Cosa ha a che fare questa domanda con il principio di Pietro?
OP ha tralasciato una componente critica: quanto apprezzi la tua sanità mentale :) In tutta serietà, se sono nella posizione, qualcuno probabilmente li supporta. Finché vale, probabilmente non hai opzioni.
@JohnFx Perché da qui sembra che questa persona abbia raggiunto "il livello della propria incompetenza" ma l'ho rimosso comunque.
@AffableGeek Essendo un consulente non mi interessa molto dal momento che le macchine di Rube Goldberg possono pagare le bollette quasi indefinitamente. :)
Meta discussione correlata: http://meta.workplace.stackexchange.com/questions/35/do-we-have-a-quality-control-issue
Quattro risposte:
kevin cline
2012-04-11 21:11:47 UTC
view on stackexchange narkive permalink

L'unica soluzione rapida che ho trovato in queste situazioni è trovare una nuova situazione. Hai a che fare con la follia organizzativa e non sarai in grado di risolverlo presto. La persona sbagliata è stata promossa e la sua direzione sembra non saperlo né preoccuparsene. Non hai abbastanza influenza per effettuare un cambiamento e gli argomenti tecnici non funzioneranno .

L'alternativa è seguire il processo inefficace e aspettare il tuo tempo. Alla fine il superamento dei costi costringerà qualcuno a prenderne atto. L'architetto sarà incoraggiato a fare qualcos'altro. Se sei rimasto in giro, collaborando e conquistando amici, forse sarai il prossimo architetto.

A proposito, ho lasciato una situazione molto simile cinque anni fa. I capi tecnici incompetenti sono stati sostituiti l'anno scorso.

* forse sarai il prossimo architetto * non in questo caso ma buon pensiero.
Può volerci un sacco di tempo prima che persone come questa vengano sostituite. Se questo è un problema cronico, dovresti pensare seriamente di voltare pagina.
Yea, there's always a little A -> B vector thing going on, where the visible incompetent person B is being supported by some senior person A who vouches for them being A Good Person And Therefore Not the Source Of Our Problems.
+1 for finding a new situation. I have struggled with the 'divine rightness' of a key decision maker for a few years. The big frustration for me is not personal disagreements or not having it my way but the business cost of a bad decision diminishing the success of my colleagues - if you work as a team, you should strive to win as a team.
jefflunt
2012-04-11 20:12:50 UTC
view on stackexchange narkive permalink

Se quella persona ha il potere decisionale, allora è tutto. Se non soddisfa i requisiti del cliente (ovvero il cliente non è d'accordo sul fatto che la soluzione soddisfi i suoi requisiti), non deve necessariamente pagare per questo (a meno che un contratto non indichi diversamente) e può dire qualcosa di semplice come "Ok , Ho sentito perché vuoi andare in questo modo, ma questo non risolve il problema che mi serve il [software / prodotto / soluzione] per risolvere. "

L'ego corre alto. Questo fa parte di qualsiasi posto di lavoro. Quando si tratta di tipi di ingegneri, puoi provare a presentare metriche di qualità e prestazioni oggettive e misurabili (se ciò si applica nella tua situazione): gli ingegneri (almeno in generale) risponderanno ad argomenti ragionati. Se fallisce, devi considerare chi ha effettivamente il potere decisionale, se questa è una lotta che vale la pena combattere e come avrà un impatto sui tuoi clienti e sul tuo business. Non credo che faccia male rendere note le proprie preoccupazioni, purché si tratti di un punto di vista ragionato e obiettivo e non di un attacco personale all'ingegnere.

Tutto ciò che è stato detto, ciò che noi doniamo Non vedo dalla tua domanda il punto di vista dell'ingegnere - forse su questo ti sbagli, forse no - è difficile prendere una decisione senza conoscere entrambe le parti.

* Se non soddisfa i requisiti del cliente *. Purtroppo il cliente è interno all'azienda e non ha modo e nessuna conoscenza per valutare la soluzione.
* quello che non vediamo dalla tua domanda è il punto di vista dell'ingegnere * Vorrei che lo desse oltre "ecco i tuoi ordini di marcia".
Per quanto riguarda il cliente che non ha conoscenze per valutare la soluzione, non vedo come sia possibile. Vedo che un cliente non ha le capacità tecniche per argomentare a favore o contro una soluzione basata su ** meriti tecnici **, ma il cliente ** si interessa di cose come se il software svolga il suo lavoro in fornire il valore aziendale richiesto, se il software produce risultati corretti, ecc. Se la soluzione tecnica che l'ingegnere propone non influisce in alcun modo sul cliente, perché è importante quale soluzione viene scelta? Vengono assunti per essere esperti tecnici.
Hai ragione, non hanno competenze tecniche da valutare ma viene venduta una distinta base che avrà un impatto su di loro. Il problema è che la persona che vende (ingegnere) non è la persona che implementa quella soluzione. La soluzione avrà un impatto sull'azienda, ma la responsabilità dell'implementazione non è dell'ingegnere.
Non so se posso aiutarti in questo - questo mi fa venire in mente molte domande. Non è chiaro il motivo per cui l'ingegnere è coinvolto nella discussione se non sarà coinvolto né nell'implementazione né nel supporto continuo. Questa persona è un capo reparto / team a cui sono affidate queste decisioni? Stanno coinvolgendo altri ingegneri che implementeranno / supporteranno la soluzione e considereranno il loro punto di vista nella decisione? Sembra solo strano.
Supponiamo una banca colossale che abbia "Technology Architecture Group", "Trading Group" e "Software Development Group". Il "Technology Architecture Group" ha escogitato la soluzione e ha incaricato il "Software Development Group" di implementarla, vendendo al "Trading Group" che questa è la cosa migliore dopo il pane a fette. Ad un'altezza di sangue dal naso, i gruppi Architecture e Dev riportano alla stessa persona, ma sfortunatamente è così alto che: http://www.fortunecity.com/campus/books/845/shithap.htm
Ok, ma in quel caso ti stai concentrando su aree di politica, struttura e organizzazione. Ti sei completamente allontanato dalla domanda originale, che era come trattare la persona / ego. L'aggiunta di tutte queste condizioni e specificità inizia a trasformare questo in una domanda fondamentalmente diversa: ovvero come navigare nelle strutture e nelle politiche coinvolte nel modo in cui vengono prese le decisioni nelle organizzazioni. Non posso dare una buona risposta a questo nell'ambito di ** questa ** domanda, perché è una domanda completamente diversa.
Ourjamie
2012-05-15 15:06:46 UTC
view on stackexchange narkive permalink

In situazioni simili ho fatto affidamento sull'ottenere un elenco di risorse (libri, blog, standard e linee guida dai principali fornitori nel tuo particolare spazio di sviluppo, ad esempio IBM, Microsoft, Idesign, Thoughtworks per citarne solo alcuni) per eseguire il backup i punti che sto cercando di trasmettere e che, purtroppo, ho dovuto presentarli durante le riunioni.

Se hai seguito quel processo e ti viene ancora detto che non hai ragione, non conoscere meglio. Quindi fai come ti viene ordinato, ma mantieni una presa del tuo materiale di partenza se qualcosa va storto per coprire te stesso e la tua integrità professionale. Una nota positiva, ti aiuterà a migliorare le tue abilità mentre imparerai come fare le ricerche necessarie per sostenere le tue affermazioni e come affrontare le difficoltà (persone, situazioni e approcci imperfetti).

Infine, chiedi solo come sono arrivati ​​ai risultati delle loro decisioni. È compito di un architetto di software mostrare l'intento e lo scopo di un progetto e come la parte di lavoro si combina insieme per fornire una soluzione.

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

La cosa che puoi fare è parlarne in gruppo con lui. Se si tratta di uno sforzo condiviso, è necessario vedere cosa pensano gli altri della sua soluzione e se esiste un'alternativa migliore.

Se ritieni che la qualità della sua soluzione non sia abbastanza buona e cliente insoddisfatto o mettere a repentaglio il tuo progetto. Parla con il tuo capo squadra o capo. Spiega loro perché pensi che la sua soluzione non sia corretta. Mostra la tua alternativa. Tuttavia, se sei l'unico della tua squadra che pensa di aver sbagliato, allora dovrai seguire il flusso, temo.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...