題:
與認為自己“非常正確”的人打交道
Karlson
2012-04-11 19:44:26 UTC
view on stackexchange narkive permalink

我最近遇到一種情況,我不得不和那個人(軟件架構師)打交道,他們似乎認為他提出的軟件解決方案基本上是“絕對正確的”,並且可以適用於每種情況。在沒有過多討論解決方案是什麼的情況下,我們已經對將解決方案應用於當前問題進行了快速分析,並提出了更多的問題和我想在該問題中列出的問題,但是此人堅持使用該解決方案。解決方案。

此人最初使用該解決方案的一些嘗試是生產的 Rube Goldberg機器,其運行速度比以前的解決方案要慢得多(無論如何

當開始問問題時,這個人的基本想法是:“這是我決定這樣做的方式,這就是我們將要做的!”

您如何與這樣的人打交道?

這個問題與彼得原則有什麼關係?
OP遺漏了一個關鍵要素-您對自己的理智有多重視:)認真地說-如果他們擔任職務,那麼有人可能會支持他們。只要這樣,您可能就別無選擇。
@JohnFx因為從這裡開始,這個人似乎已經達到“自己的無能”,但是我還是刪除了它。
@AffableGeek作為一名顧問,我並不在乎,因為Rube Goldberg的機器幾乎可以無限期地支付賬單。 :)
相關元討論:http://meta.workplace.stackexchange.com/questions/35/do-we-have-a-quality-control-issue
四 答案:
#1
+22
kevin cline
2012-04-11 21:11:47 UTC
view on stackexchange narkive permalink

在這些情況下,我找到的唯一快速解決方案是找到新的情況。您正在處理組織的精神錯亂,並且您將無法在短期內解決它。錯誤的人已經晉升,而他的管理層似乎也不了解或不在乎。您沒有足夠的影響力來進行更改,並且技術論據不起作用

另一種方法是順應無效的流程並浪費時間。最終,成本超支將迫使某人注意。將鼓勵建築師做其他事情。如果您一直待在周圍,合作並贏得朋友,也許您將成為下一位建築師。

順便說一句,五年前我也遇到了類似的情況。不稱職的技術負責人於去年被替換。

*也許您將是下一位建築師*,不是在這種情況下,而是很好的想法。
這樣的人需要很長的時間才能被替換。如果這是一個長期問題,則應認真考慮繼續前進。
是的,總有一點A-> B的事情在進行,可見的不稱職的人B得到了一些高級人A的支持,高級人A保證他們是好人,而不是我們問題的根源。
+1尋找新情況。幾年來,我一直在與關鍵決策者的“神聖權利”作鬥爭。對我來說,最大的挫敗感不是個人分歧或不以自己的方式解決,而是錯誤決策的商業成本削弱了我同事的成功-如果您以團隊合作的方式,則應努力以團隊的方式取勝。
#2
+4
jefflunt
2012-04-11 20:12:50 UTC
view on stackexchange narkive permalink

如果那個人有決策權,那就是。如果它不能滿足客戶的要求(​​即客戶不同意解決方案滿足他們的要求),那麼他們不一定要為此付費(除非合同另有規定),他們可以說些簡單的話,“確定,我聽說您為什麼要這樣做,但這並不能解決我需要[軟件/產品/解決方案]解決的問題。“

自我高度評價。這是任何工作場所的一部分。對於工程師類型,您可以嘗試提出客觀,可衡量的性能和質量指標(如果適用於您的情況)-工程師(至少通常)將對合理的論點做出回應。如果失敗,那麼您必須考慮誰真正擁有決策權,這是否值得一戰,以及它將如何影響您的客戶和業務。只要是出於理性,客觀的考慮,而不是對工程師的人身攻擊,我認為將您的顧慮表達出來是沒有害處的。

總而言之,我們所做的從您的問題中看不出工程師的觀點-也許您在這個問題上錯了,也許您不是-在不了解雙方的情況下很難下定決心。

*如果不符合客戶要求*。不幸的是,客戶是公司內部人員,無法評估解決方案。
*從您的問題中我們看不到的是工程師的觀點*我希望他能提供的範圍超出“這裡是您的行軍命令”。
至於不具備評估解決方案知識的客戶,我不知道這怎麼可能。我可以看到客戶沒有基於技術優點**的技術技能來主張或反對解決方案,但是客戶**確實在意諸如軟件是否足夠快地完成其工作,提供所需的業務價值,如果軟件能夠產生正確的結果,等等。如果工程師提出的技術解決方案對客戶沒有任何影響,那麼為什麼選擇哪種解決方案也很重要呢?他們被聘為技術專家。
沒錯,他們沒有評估技術的專業知識,但是正在向他們出售會影響他們的貨物清單。問題是銷售(工程師)的人不是實施該解決方案的人。解決方案將影響業務,但實施責任不在於工程師。
不知道我能否在這里為您提供幫助-這使我想到了很多問題。不清楚為什麼工程師既不參與實施也不在持續的支持中,為什麼要參與討論。此人是負責這些決策的部門/團隊負責人嗎?他們是否邀請其他工程師來實施/支持解決方案,並在決策中考慮他們的觀點?這聽起來很古怪。
假設一個擁有“技術架構組”,“交易組”和“軟件開發組”的龐然大物銀行。 “技術架構小組”提出了解決方案,並責成“軟件開發小組”實施該解決方案,同時向“交易小組”出售這是切成薄片以來最大的事情。 Architecture和Dev小組向同一個人匯報了一些令人毛骨悚然的高度,但不幸的是,它是如此高:
好的,但是在那種情況下,您涉及的是政治,結構和組織領域。您完全擺脫了最初的問題,即如何與人/自我打交道。添加所有這些條件和細節開始將其變成一個根本不同的問題:即,如何在組織決策過程中涉及的結構和政治方面。在** this **問題的範圍內,我無法給出很好的答案,因為這是一個完全不同的問題。
#3
+2
Ourjamie
2012-05-15 15:06:46 UTC
view on stackexchange narkive permalink

在類似情況下,我依賴於備份資源列表(書籍,博客,標準和來自您特定開發空間中主要供應商的指南,例如IBM,Microsoft,Idesign,Thoughtworks等)進行備份

如果您已經經歷了這個過程並且仍然被告知您是不正確,不正確的,或者他們在會議上提出了這些要點,可悲的是,我不得不試圖在會議上提出這些要點。

更了解。然後按照指示執行操作,但是如果出問題了,請保留原始資料,以掩蓋您自己和您自己的職業誠信。積極的一面,它將幫助您提高技能,因為您將學習如何進行必要的研究以支持自己的陳述,以及如何處理困難(人員,情況和錯誤的處理方法)。

最後,只問他們如何得出決定的結果。軟件架構師的工作是展示設計的意圖和目的,以及工作部分如何相互配合以提供解決方案。

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

您可以做的是與他一起討論。如果這是共同的努力,那麼您需要查看其他人對他的解決方案的看法以及是否有更好的選擇。

如果您認為他的解決方案的質量不夠好,並且會使您客戶不滿意或危及您的項目。與您的團隊負責人或老闆一起處理。向他們解釋為什麼您認為他的解決方案不正確。顯示您的選擇。但是,如果您是團隊中唯一認為他錯了的人,那麼您恐怕要順其自然。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...