Andy是一家硬體公司的PM，公司一年要跑30多個案子，案子的大小狀況不一，有些是內部的開發計畫，有些是與客戶合作的開發項目。
身為一個PM，Andy最困擾的是手上的案子永遠都有狀況，成本不達標、產品功能不到位、設計出來的樣品高階主管不喜歡、案子總是因為各種狀況而延誤又延誤，雖然每位成員都看似很努力，但結果就是不那麼令人滿意。
而Andy的主管又忙於處理自己的案子，於是看不下去的Andy寫了一份企劃，找了總經理聊了幾次，最後在總經理的支持下推展出這個改造方案，剛開始很痛，但最後的果實是甜美的。接下來讓我們一起看看Andy做了什麼來改造了專案團隊，並且讓開發時間縮短且每個人都樂於提出對策協助解決問題。
重點不在管控，在目標是否一致
很多公司，尤其有一定規模都會已行之有年的開發規範來完成產品開發流程。久而久之帶來的就會是以保險、不出錯來取代創新、勇於嘗試的僵化思考邏輯。
我是ID，我不敢勇於創造令人驚艷的產品概念。
我是ME，我不敢設計前面沒有人設計過的結構。
我是EE，我不敢簡化電路追求效率思考。
我是PE，不管什麼新產品，我都堅持要符合現在的治具。
人人都只想遵守公司的規範，只要不出錯時間內完成即可。但產品完成後是不是能夠符合客戶的期待，老實說，這是PM自己的問題了，反正我做好我份內的工作就對了!
整個產品專案團隊目標並不一致，你發現了嗎?但最後誰必須吞下這苦果?當然還是公司啊!所以讓團隊的目標一致變成了優先要處理的要務。
賣不出去的產品設計再好也沒用
專案團隊最大的目標應該是讓產品完成後能夠在市場上大賣，而非追求極限的設計，每個規格都頂天，產品也未必獲得青睞。
讓專案團隊有一致的目標有以下幾個好處
- 方向清晰，減少做白工
- 解決對策會指向有效，而非全面
- 降低本位主義思考，增進團隊合作
太晚上市流程管理再棒也沒幫助
你的公司是不是也一環扣一環，一個卡一個，「品保說，RD沒弄好我不測」「採購說，BOM表沒建好東西我不買」「業務說，行銷文件沒弄好我不推廣」，最後的下場就是一個原本可以四個月上市的產品硬是搞到八個月，但對手早就搶在兩個月前推出搶走了你的市佔，環環相扣是好的，但我要的是活動的變換扣而非打死結。
團隊有共識讓產品盡早上市就會產生:
- 最佳流程思考，做到什麼就夠了，而是什麼都要做。
- 最短要徑卡控，非必要的節點能夠採取其他作法避開。
- 最壞風險評估，風險與時間的關係會依據目標調整
用制度綑綁流程、目標、團隊意識
上面描述了如何統一目標來讓流程與產出正相關，你心裡一定在想「怎麼可能這麼理想!」「如果能這樣就好了!」「這些工程師最好能聽懂人話」沒錯，現實怎麼可能這麼夢幻，大家都願意齊心協力來幫助PM完成自己的工作?所以前面提到Andy是先去找了總經理談過幾次後，取得總經理的支持才有辦法推動並且取得後續的改善。
好奇嗎?用什麼制度才能讓整個專案團隊都變成你的幫手!大家都願意為了專案的成功而付出，有幾個方向可以做到。
1. 調整原績效制度
多數公司的薪酬裡面本來就包含一定的績效評核制度，只是很多都只是看盈餘狀況來決定如何分配，並沒有目的性的設計與考量。在不多增加公司發放獎金的負擔下，將績效獎金設計成專案的時間、成本、業績的權重評核動態發放機制，就可以達到這個目的。
2. 增設專案評比
前面提到了Andy的公司一年要開30多個案子，總共有50多個RD以及前端的PM與後端的生產與採購的協助要進來，這麼多人在合作上產生的變數本來就會比較大，PM再厲害也不可能每次都搞定這些人，倒不如利用人性上的追求來讓這些人採取合作的角度溝通。
設定一個年度專案評比的制度，獎勵前三名的專案與對後三名的專案進行懲處，賞罰分明自然在裡面想要偷懶的人也會特別的有壓力。
3. 客戶滿意度回饋
如果是與客戶合作開發專案居多的朋友也不用擔心，可以在每個專案結束後都請客戶提供此專案的滿意度回饋，不管是單個專案的獎懲機制，或是年度的積分制度，只要適合在貴公司推展就是好方法。
改善很快，但持續修正很長遠
取得了資源，用對了方法在短期的執行改善上會非常有感，但長期的價值觀培養以及運作默契，是需要很長一段時間的調整。身為PM短期的達交是首要目標，但忽略了長期的組織調整還是可能讓你到處碰壁。
有些人會說，我只是一個小PM我哪能推動這麼多事啊!沒錯!光靠你一個人一定推不動，但如果你能取得主管的支持，在好好的計劃一番，用適當的企劃與執行計畫對管理階層進行說明，先以小範圍的點狀測試一兩個專案，取得小成功後再推展到整個全公司專案管理的運作上，我相信沒有公司會拒絕對全體有益的提案。
PM看似一個負責計劃與管理修正的角色，但其實更是需要執行力的擔當，與其把心力放在一直不斷叮嚀追蹤進度，倒不如把時間花在對整體制度架構的優化上，最後所得到的回饋一定遠大於執行面追蹤的回饋。
