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

[TonyQ (自立而後立人)]

底下可以說明技術型 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:強推～不能同意你更多!!!
※ 編輯: 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:抓出三四倍的buffer,結果別人露出"你好遜"的表情...唉
→ TonyQ:寧可遜也得抓啊，不抓是會死人的。XD
推 phonelin:不用補班嗎
→ TonyQ:到時候提早完成就好了，在軟體界沒有比提早完成更好的credit
→ TonyQ:只要強調是因為時程緊迫所以要留一個確定的時間
→ TonyQ:一般都能諒解  如果要壓比較短就要有品質差甚至上不了線
→ TonyQ:有些人很喜歡裝懂的，我都會回他說不然你來做吧。XD
→ TonyQ:通常都會惦惦，不然不想自己來做那我們就來辯論時程吧。
→ TonyQ:要找一些可能延長時程的意外實在是太簡單了。
推 cjamhe01385:感謝各位回復，因為我方是發行商，所以pm多企劃行銷出
→ cjamhe01385:身，主要控管整個行銷發售的進度，對於技術了解不足，
→ cjamhe01385:這部分我會好好反省和改進的，感謝各位^^
推 CRPKT:這篇 m 起來啦, 你不要不好意思 XD
→ markov:T大 M 吧 好的有用的都可以留下來
推 alpe:我只能大推了
推 normanshi:這篇只能推了
推 VCLee:好文推一個
推 morewatertw:好文推
推 Ting1024:喔喔，原來PM還真的有這兩種類行呀！
→ Ting1024:這篇不M不是人
→ Lordaeron:怪不得台灣的軟體這麼差, 跟印度差不多的consultant程度
→ rocooshiang:rd轉pm的pm，溝通會不會好一點?
→ TonyQ:@rocooshiang RD 轉 PM 並不是技術的萬靈丹，因為每個專案
→ TonyQ:領域技術可能都會有許多細節出入，所以並不是 RD 轉 PM 就一
→ TonyQ:定比較好溝通。還是要看技術領域，還有他本身的管理能力。
→ TonyQ:RD 轉職 PM 雖然是技術型 PM 唯一的來源，但真的轉職的好的
→ TonyQ:其實也是百中選一。我們也必須承認 PM 是一種專業能力。
推 thinkniht:如果一個人由RD轉成PM之後，對技術的知識沒有再更新或
→ thinkniht:進步。那我想技術型PM的優點就會不見，反而過度依賴過去
→ thinkniht:的經驗而做出不符合目前實際情況的判斷...
推 IDanceAlong:好文共賞
推 wuliou:好文必須M
推 nopeace:推這篇，這篇點出一些台灣軟體公司PM會有的一些問題
→ viper9709:推這篇~分析得很精闢~~
推 sunts:好文推!
推 mirrorz:推推
推 cwlin0416:客戶-PM-RD, 我的觀點很簡單, 一定有溝通問題
→ cwlin0416:客戶到RD的距離是個定的, 所以看誰能強大
→ cwlin0416:自然就會有一邊會比較輕鬆
→ cwlin0416:如果我是RD當然會覺得能照自己的步調做事, 很好所以PM要
→ cwlin0416:做多一點
→ cwlin0416:但是PM也不能完全不做事通通都給RD自己想辦法
→ cwlin0416:我是覺得不論是技術型或管理型, 真要講都他不足的地方
→ cwlin0416:只是偏客戶,還是偏RD,這條線自己要很清楚,去補足另一邊
→ cwlin0416:回到對與PM跟RD的溝通,真的要管RD,那PM就必須從溝通的經
→ cwlin0416:驗去找溝通的方式,了解更細的可行性,又不失大局
推 cwlin0416:唯一最難做的就是要求,所以PM要對RD的產出慢慢了解,溝通
→ cwlin0416:即使RD在耍你,還是認真的理解一次兩次之後就找的到問題
→ cwlin0416:但綜觀全局,PM要了解RD,RD同樣也要了解PM
→ cwlin0416:這樣的工作才是最有效率的
推 cwlin0416:公司也不會希望RD太過WEAK,換一個PM就做不出東西了