前陣子和一位合作過幾次的工程師閒聊，他提到目前的專案遇到一些問題，並且認為專案經理的角色很重要，建議我可以去考個PMP(我已擁有PMP身分將近10年)。雖然這個案子是由另一位PM主導，我則是協助的角色，但我們對於這案子其實也花了不少心力，我因此很驚訝，原來不同角色的觀點看待「管理」這件事，有如此顯著的差異。
和這位工程師合作的是個兩年以上、橫跨多部門的大型專案，目的是建立一個新平台，取代疊床架屋多年的舊系統。但舊系統的負責單位歷經多次轉手，早已沒有任何文件及Domain Know How可以傳承，因此在釐清規格的過程中，花了不少時間與心力，對於工程師來說，感受到的就是反反覆覆的規格版更，開發階段著實辛苦。
在這個專案內，我和另一位PM所執行的管理工作，大部分是在處理跨部門溝通、利害關係人管理，目的是讓團隊成員可以專注在規格的細節上，因此從工程師的角度來看，並不會有太深刻的感受，舉凡時程協調、資源調度，乃至於掌控sponsor的期望，都不會直接反應到團隊成員的面前，這些排除外力干擾的管理工作，雖然有效減少了範疇變更，也爭取到更多的開發時間，但對他們來說卻是相對「無感」的。工程師們專注於實現產品規格，因此對於規格的掌握度有較高的要求與期盼，不過這個專案有其歷史複雜性，所以很難使用waterfall的形式運作，但公司的文化偏向waterfall，造成另一個造成PM與工程師觀點差異的地方 -- PM認為規格可透過敏捷管理方式滾動、漸進，工程師則認為規格變動過於頻繁，難以掌控，影響開發時程。
回顧這個案子，確實有它待改善的地方，但我想探討的其實是「有效管理」和「有感管理」的差異，所謂「有效管理」是指透過管理的技巧，有效解決、降低了專案所遭遇的問題，而「有感管理」則是團隊成員能夠感受到專案「被管理」。我曾經待過一間軟體公司，專案團隊每天要填寫工作日誌、每週五提交隔週工作計畫、PM則是每週一彙整團隊成員上週工作重點、每月還要參與專案審查會議，由每個PM交叉查驗彼此的專案，針對缺失提出改善，並且需要追蹤進度。這樣的管理方式非常「有感」，但卻「事倍功倍」，PM和團隊成員都大喊吃不消。
從管理的對象來看，「有效管理」比較偏向事情的處理，例如專案面對的時程、範疇、資源、品質等議題，是以解決問題的角度來思考。「有感管理」則是偏向人的處理，因為只有人才會產生感覺、認知上的差異。專案管理的目的在促使專案如期如質完成，因此PM應該回歸問題的根本，優先追求「有效管理」，但是換個角度思考，如果團隊成員長期感受不到PM的「管理」，可能會對PM的能力產生疑慮，進而影響向心力，因此，適時的展現「有感管理」也是重要的一項工作。
如何讓團隊有感? 我認為「資訊透明化」是一個重要的基礎。由於每個人關注的重點不同，要讓所有人理解PM的工作內容原本就不容易，有些資訊不須高調宣揚，但可以適度透明化傳達給團隊成員，舉一個簡單的例子，這個專案本身有每周例行的會議，但參與的人主要為幹部與主管，工程師對會議通常不太感興趣，更別提會去查看會議紀錄，此時PM可以定時將會議上的決議，或者一些替團隊爭取到的權益(舉凡阻止主管縮短時程、否決不適合的提案等)，轉發到工程師手上，轉發的形式依團隊協作方式而定，有些團隊喜歡透過線上通訊軟體，有些則有固定的聚會或討論會。若是較重要的事項，例如專案變更、資源調度、風險應變等議題，則務必透過正式的會議來佈達。
雖然不少團隊成員需要專注投入自己的工作，才能發揮最大價值，但適時讓他們理解目前專案所處的位置，某種程度上可以降低心理上的疑慮，這種輕量的「有感管理」，對於PM想達成的「有效管理」或多或少會有些助力。
回到「認知差異」這件事來看，其實沒有誰對誰錯，雙方都是從自己的角度出發，提出如何讓專案更順利的想法，PM必須廣納意見，從中找出最適合的處理方式。有些問題不一定能夠馬上解決，例如前述的規格掌握度，但它或許是一個很好的學習經驗，當未來遇到類似的專案時，是否該提早確立管理方式? 能不能在規劃過程爭取工程師或分析師的資源投入? 這些都是可以思考的面向。
留言列表
