Re: [請益] 比較難溝通的同事

[yauhh (喲)]

你應該先想想,當leader的意義是什麼? 身為leader,你真正的角色是什麼?

我認為,主管的真正角色,或稱為裏角色,是 "奴才"
對上要捧,對下要照顧. 你是不是奴才? 是奴才.
絕對沒有說那些人都是你的部屬,所以你比他們大的道理.

而且我認為更明確講,用 "乞丐" 來形容主管這種角色更恰當.
你沒有付給前線工作者們任何金錢,甚至在工作執行上,可能你還依賴他們的知識,
而你卻要向他們討一些工作產出來. 這個互動模式,基本上就是乞討來著.

所以,我看了你描述的,你的處置情況,我都覺得也許你不懂得溝通了吧.
你說那個工程師不懂得溝通,那我要問,你是leader,是你要會溝通還是他要會溝通.
當然是你要會溝通,而且你應該要在溝通所造成的結果上,展現出你溝通的實力.
但是,事實顯而易見,你沒有達成有效的溝通. 可是你卻把溝通的問題當做是他的問題.
你沒有覺得你自己也有問題. 這是我第一點看法.

第二個看法就是,因為你不會認為你自己也有問題,所以各種處置法在在都只是針對
對方下手. 這我就要問,你有沒有玩過即時戰略遊戲了?
戰略類型的遊戲,你會一直專注著看一個單位的動作,它的攻擊輸出量及生命值,
只去幫它加能量,並且一直花許多操作時間去控制它的舉動嗎?
這根本是浪費時間. 做個 leader 你要做的是帶隊去打,而不是押著一隊去強迫他們
打. 但你說你在做的事情,寫得洋洋灑灑的,看起都是在押解犯人.

你到底貢獻了什麼啊? 如果你的隊中有人很有產出,在他的產出其中屬於你的貢獻量
是多少?

第三個看法是,所謂溝通. 在你提的事裡頭,大概只說「他都不懂需求」
不懂什麼需求? 真要說明白,可能是說「他都不懂你所要的需求」
可是,在他這樣不懂的情況下,卻可以根據他所知道他懂的部份硬寫,你不覺得他很強嗎?
你不欣賞他獨立作業的能力嗎?
再說,你覺得他所做不符合需求,怎麼是發bug呢? 什麼叫做bug,什麼叫做需求,你要
混在一起談,這看起來很奇怪.

你退他一堆件很累又怎麼樣? 就算他不懂你想要傳達的需求,他就此變成白痴了嗎?
不會的. 我認為,當你發現溝通有問題的時候,應該是很坦誠找他講話.
當主管的人是要比部屬更有辦法當面坦誠講話的人,而不用各種電子媒介像TFS來
當做你可以有效與一個人溝通的工具.

你講的各種情況,我覺得你是錯的,理由如下:

1. 因為你覺得你是在上位的,你比較大,所以都要人跟你回報. 如果不跟你回報,
   就是一種你不能忍受的,失去你控管權的情況.

2. 你很懂客人的需求,但是,這些需求資訊從你的腦中轉移到部屬他們的腦中,
   需要多少頻寬? 你為了傳遞這個需求,準備了多少份量的channel?
   相對於你的文件,你的說明口語是幾句話呢?

   如果你的文件不夠清楚,問個屁? 不夠清楚是你的表達有問題,
   怎麼會是別人有責任要問?

3. 一個需求是幾張紙,幾句話就講完,但是這並不代表那些需求是這樣子就講得
   很清楚. 因為設計的工夫是遠超過你這幾句話,幾張紙的.

   當你發現設計不符合的時候,應該是做更多的溝通幫忙修正,而不是忙著做後設評論,
   立馬跳出來講一些客觀評析的話,說什麼 "當初倒不如先搞清楚需求".
   當你在批評那些設計不符合需求的時候,那些設計的存在是花很多心血,
   但是你講那幾句話根本是不必動什麼腦筋的屁話,這要怎麼比?

   所以我認為,你當了leader首先要學習珍惜這些人來幫忙賣命,心存善念,
   而不是急著做過河拆橋的事情. 請認清你的角色,基本上你是調度者的角色,
   但是如果哪天你表現得比較像乞討者,那就難看了.

4. 你測試失敗而回拋工作, 以及他衡量自己不適合做前台工作,
   這些都是正常的事情. 你不應該把這些事列入你的氣頭清單.


※ 引述《uthily ( )》之銘言：
: 我待的公司是一個小公司，軟體部裡人只有4個半 (包含我，那半個人有機會再討論)
: 最近我升上來當 Project Leader
: 其中有一個同事，讓我很頭痛
: 想問問有經驗的前輩，有沒有比較好的解決方案
: 我想他主要的問題就是不太會溝通，包括聽、說都有點不擅長
: 衍生的問題包括
: 1. 請他工作完成要回報，講一次他回報一次，不提醒他就不回報
:    最後是靠 TFS 系統的回報功能才解決這個問題。
: 2. 對需求有問題不會問，告訴他如果需求寫得不夠清楚要問，
:    與其寫出來不符合客戶需求在那邊改改改，不如先搞清楚需求
:    (他不需要接觸客戶，負責接觸客戶的是我，他只要問我就可以了)
:    可是他95%的狀況都是硬寫，寫完再被我發 bug 改改改
: 3. 為了他，我已經把所有可能要注意到的細節都寫出來了，
:    但我覺得我的文字好像都掉到洞裡，
:    舉例來說，客戶網頁上的客服 e-mail 打錯了，我請他更改 (昨天的事情)
:    (事實上，之前自動寄信功能就發生過打錯事件，已經更改過一次了)
:    順便提醒他應該要整個專案搜尋一次，以免還有其他地方沒改到
:    結果 TFS 中他回報已完成，我把該聯絡方式頁面開出來看...
:    恩...第一個 e-mail 改對了，該頁面再往下拉又出現了一次 e-mail，是錯的
:    我只好在把該功能寫上測試失敗。
:    再舉一個今天發生的事情，有一個參加活動的連結壞掉了，網頁不存在
:    我請他修正，告訴她應該要連到 a 網頁
:    他回報修好了，我一點，卻跳到 b 網頁
:    我只好又給他一個測試失敗。
: 我目前能做的就是盯著他，交代工作的時候先用講的，再幫他把細節都寫下來
: (他自己寫都會漏東漏西)
: 然後他寫的功能我一定都要細細測試過才能安心
: 我覺得很累，我自己也要寫程式，現在當 leader ，
: 還要負責安排工作、檢查功能、跟客戶溝通、教其他人寫程式
: 跟他這樣檢查完退回去、檢查完退回去，真的好浪費時間
: 4. 又想到還有一個問題，就是他會拒絕分配的工作
:    其實之前他有負責比較核心的程式，該程式的工作其實很簡單，只要轉發訊息就好
:    但性質上很要求穩定性，而他寫的程式就是不穩定，常常被客戶抱怨
:    某次開會檢討怎麼又斷線了的問題時，他就提出希望由其他人接手他原本的工作
:    後來我就把這個程式的維護接下來，他轉去負責後台介面。
:    類似情況這星期又發生了一次，有個撤下一年的案子，客戶又回頭說要做
:    我們原本是打算照之前的分配把系統重新架起來
:    但他拒絕原本的工作分配，希望一樣轉而負責後台介面就好
:    我們後來也是讓他轉了，這次是另一個同事額外負擔了一些他的工作
:    其實我之前就很痛恨能力好的人活該要做比較多事情的這種狀況
:    我覺得很對不起另外那位同事
:    我們老闆只是跟我說，他放掉所有核心的工作，只處理可取代性高的介面工作
:    那是他在增加自己的可取代性
:    我並沒有想趕走他，總覺得不需要斷人生路，所以也跟老闆說我會再想辦法溝通看看
:    但我現在真的覺得很累
:    他一直被我退件、發 bug 應該也覺得很累
:    好像進入一個惡性循環了
:    不知道有沒有人有好的建議>"<

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 118.167.54.188
推 dnzteeqrq:換了位置就換了腦袋  百看不厭
推 Ting1024:推
→ andymai:完全不同意"需求不清楚，問個屁?"把責任完全歸在開需求的
→ andymai:人身上!或許是公司養成的方式不同?個人從第一家公司開始就
→ andymai:體會到什麼叫做"看不懂就要問"的道理和後果~做錯了是誰要
→ andymai:改?還是自己啊!那與其看需求的時候~不清不楚、囫圇吞棗~倒
→ andymai:不如立馬去問個清楚!人和人表達方式通常都會有某種默契在
→ andymai:不然不會出現講同樣技術的書~不同人寫就讓你有不同學習速
→ andymai:度的事情發生!所以日後我就算看懂了~但只要有些懷疑~我就
→ andymai:會主動去確認~常常就這樣發現"其實我不懂他的明白"...
→ andymai:拿老師教書來說~台灣學生很大一個問題點就是"有問題不問"
→ andymai:那學生不問~到底要老師怎麼知道"其實學生不懂"這件事?
→ KiroKu:我覺得leader有責任要確定下面的人知道正確的spec
→ KiroKu:能確定spec的人只有上面的人 做的人搞錯了他自己很難發現
→ lovdkkkk:一個情況是 不清楚的人不知道哪裡不清楚 要問什麼
→ lovdkkkk:清楚的人不知道別人哪裡不清楚 要說什麼
→ lovdkkkk:反正不管自己覺得清不清楚 通通向清楚的人講一遍就對了..
→ uthily:先謝謝你的建議，但有幾個點我覺得你有點誤會。
→ uthily:回應第一點關於誰要會溝通:
→ uthily:我認為溝通是兩個人的事，雙方都有責任
→ uthily:我認為我盡力做了我能做的部分，只是我做得很累,成效卻有限
→ uthily:也因此我才PO文請大家給我建議。
→ uthily:看有沒有什麼工具/技巧/訓練方式能解決目前的困境。
→ uthily:如果他真的看不懂連到 a 網頁這條需求是什麼意思，
→ uthily:應該來詢問我，而不是自己亂連。
→ uthily:關於回報機制: 看起來你反對主動回報，
→ uthily:你們公司的回報機制是主管定時去找工程師一條一條工作項目
→ uthily:詢問進度嗎?
→ uthily:關於問問題的責任: 我有責任講清楚，對方也有責任問清楚。
→ uthily:關於修正: 發現設計不符合我當然是向對方說明如何修正，
→ uthily:"弄清楚需求"意思是希望下次若覺得我說明不夠清楚時能提問
→ uthily:我覺得這不是什麼評析的話，而是一個正常的要求。
→ uthily:也因此我希望之後能夠不要浪費對方的心血。
→ uthily:關於過河拆橋:我前文就說過不希望趕對方走，而希望增強溝通
→ uthily:不了解為什麼你會對我有這樣的誤解。
→ uthily:氣頭清單同上，不了解為什麼條列問題點會反變成氣頭清單。
→ uthily:最後再謝謝lovdkkkk的建議，
→ uthily:請對方重述他所認知的 spec 的確是個好建議。
→ uthily:回應關於憑什麼發bug: 憑我文件上寫連到a網頁他卻連到b網頁
→ uthily:如果他真的看不懂連到 a 網頁這條需求是什麼意思，
→ uthily:應該來詢問我，而不是自己亂連。
→ uthily:我自己負責維護的程式範圍比對方更多，我很清楚設計的心血
→ uthily:也因此我希望之後能夠不要浪費對方的心血。
→ aries198012:就我目前身為現職PM的所看到情況,y版友說的情況
→ aries198012:我並不認同
→ aries198012:我見過很多技術能力和Domain Know遠在member之上的PM
→ aries198012:再來是PM的貢獻度問題,我的愚見是PM的貢獻度不在於
→ aries198012:解了什麼bug或是寫了多少程式、釐清多少需求
→ aries198012:最重要的功能是避免 "個人目標" 與 "團隊目標" 的抵觸
→ aries198012:或講的比較老生常談一點,就是指資源分配
推 gpmm:不太認同，不知道 y 板友有當過 leader 嗎？ XDD
→ Cocoma:乞丐...照您的邏輯，主管都是"白白"拿走您的勞力成果的乞丐
→ Cocoma:那麼客戶跟股東就是"白白"送你銀子的大善人了吧......