Re: [請益] 該如何和工程師溝通？

看板Soft_Job作者TonyQ (自立而後立人)時間12年前 (2013/09/14 10:59)推噓18(18推 0噓 34→)

留言52則, 22人參與討論串4/7 (看更多)

底下可以說明技術型 PM 跟管理型 PM 在進度上本質的不同。先簡而言之，管理型的 PM 要找會自我管理的工程師、跟他們去協調時程（換言之，聽他們的），並且盡力讓他們不要被其他外務干擾。技術型的 PM 則可以隨便找一般的工程師，由 PM 制訂時程，外務干擾或支援在自己評估過的狀態會比較可以接受。兩種人各有優劣，前者適合做戰略性的布局，要有全局觀跟說服長官的本事（必要）。後者適合作為中小型系統的開發，可以穩定的為公司帶來產出，在重要專案時風險也相對比較小。但這些都得看ＲＤ跟團隊的狀態來安排，不是什麼人進來就可以當好一個ＰＭ的。 ※ 引述《cjamhe01385 (徹)》之銘言： : 不好意思，我是產品PM : 因為到了新環境，每次討論時，程式工程師態度很差 : 會酸我說：我都只要聊天講話就好，哪知道他們寫程式的辛苦 : 或著說這很麻煩很難做，他不願意之類的＠管理型 PM 非常倚賴 RD 的自我管理也就是說，當 RD 在跟你抱怨時就是警訊了。說穿了就是，談技術你不懂技術，你手上有的工具只有時程，運氣好一點還可以打個考績跟決定績效、人事，但這些工具都無助於 RD 解決問題。你真正該做的就是找個比較強的 RD 去幫他（或幫你）釐清這些規格的細節。管理型 PM 容易爆點爆在專案末期，專案快上線的時候發現完全搞不定狀況。 PM 很常抱怨工程師很難溝通，多是因為你根本沒有跟他共同溝通的語言，這狀況就很像一個英文很破的人去找美國人喇賽，結果美國人一直聽不懂這人在講三小，但對方就生氣了。XDDDD 其實我是不知道這種狀況下是誰比較難溝通，真的是看單位。但是技術是一種專業，在專業之前，只有用專業去制衡他或信任他有自我管理的專業。然後不要以為作過類似專案就能夠用時程概估，同樣的功能在不同 team 不同環境開發期程可以差到三四倍以上。＠技術型 PM 在帶的時候當他們接到任務的時候，大架構差不多就已經搞定了，細節實作方向至少都有 2-3 條路可以選跟 survey 。真的覺得很麻煩很難做，都是直接釐清哪裡麻煩哪裡難做，大家坐下來橋。 RD 通常不會有太多問題，就是照著做。應該說有問題的部份一開始就爆了，相對不會等到最後才爆。 : 導致我每次追他進度都覺得相當疲累 : 我是說XX東西好了沒，大概預計何時可以完成？ : 然後工程師就會開始：妳以為這很簡單嗎？很難做耶！ : 妳們這麼輕鬆，講講就會出來唷 : 我只是想要個時程進度而已耶，大哥... : 而且加班很晚的都是我，也沒讓工程師操到加班過阿 : 到底怎樣的說法 : 你們才會覺得PM有體諒工程師呢？ : 請各位以自己角度幫我解惑吧，感謝就專案運行目標而言：＠管理型 PM 只要負責規劃目標，負責擋事情，讓東西能夠出現 iteration，而不是規格朝令夕改，剩下的就交給工程師去煩惱，要密集跟工程師討論進行狀況，需要的支援跟決定可能造成問題的未定義規格。＠技術型ＰＭ一般來講他反而比較需要的是確認目標是否正確，並確保底下每個人的分工都有分到，沒有人被另一個人擋路。（管理型不是說不用確認分工跟擋路，是他這一塊責任只能轉嫁給工程師自己決定。）就專案評估而言：＠管理型 PM 要壓時程的工具只有找 consultant (or 關鍵技能內訓)、（國內十之八九不走這套，但國外很盛行），砍規格、砍人，這三種工具。但砍人成本太高而且無助於目前專案，所以一般不太常看到，主要都是砍或簡化規格。＠技術型 PM 要壓時程的工具是明確的規格、明確的實作規劃，找 consultant ，砍規格、砍人，自己跳下去做 seminar ，必要的時候還可以當團隊後援。（就是把自己當 consultant 用，但是不應該太常出現這種情況。） ------------------------------------- 工作並不是把你放到位置上，你就會自動發揮產值，當你是個ＰＭ，ＲＤ就是你的戰友，我們都知道團隊的組成要是互補的，如果你缺技術，你就需要強技術管理跟信得過的戰友幫忙，反過來如果你只有技術缺乏規劃力，你就需要具有規劃力的企劃或主管幫忙。也不是你站在位置上，你就能要求讓每件事情都照你的意思發生，那是你得去努力的部分。如果你覺得你只是照職責走，但實際上沒權也沒能力可以去管這群人，然後你又覺得都是他們態度不好不是真的做不到（換言之，信任度不夠），我只能說，這世界上有些工作不是什麼路人都做得來的。你真的在你接下這份工作之前，就準備好跟知道什麼是ＰＭ工作了嗎？你手上有什麼牌，你是什麼樣類型的ＰＭ，你明白了嗎？那現在，你又知道什麼是ＰＭ工作了嗎？該怎麼做的答案應該很清楚了。ＰＭ如果看不清楚自己職責跟該做的事情，那對團隊是蠻傷的。為什麼能夠會自我管理的ＲＤ遠比其它ＲＤ來得貴，也是很明白的事情。老板要的規格ＲＤ做不到就是做不到，這世界上沒有不能 delay 的時程。你受傷來自於你的經驗不足，一開始就敲一個這麼嚴重的時程，還沒抓個三四倍 buffer ，那時候你就先敗了... -- 筆者帶過 team 也當過 consultant ，職業生涯中有 50%的時間都在談規格，剩下 50% 也是主力一直在開發的工程師。 -- 網頁上拉近距離的幫手實現 GMail豐富應用的功臣數也數不清的友善使用者體驗這就是ｊａｖａｓｃｒｉｐｔ歡迎同好到 AJAX 板一同討論。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.228.181.44 ※ 編輯: TonyQ 來自: 61.228.181.44 (09/14 11:02)

推

changic

09/14 11:04, , 1^F

09/14 11:04, 1^F

※ 編輯: TonyQ 來自: 61.228.181.44 (09/14 11:05) ※ 編輯: TonyQ 來自: 61.228.181.44 (09/14 11:12) ※ 編輯: TonyQ 來自: 61.228.181.44 (09/14 11:17)

→

tyc5116

09/14 11:24, , 2^F

09/14 11:24, 2^F

→

TonyQ

09/14 11:40, , 3^F