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看似一個負責計劃與管理修正的角色,但其實更是需要執行力的擔當,與其把心力放在一直不斷叮嚀追蹤進度,倒不如把時間花在對整體制度架構的優化上,最後所得到的回饋一定遠大於執行面追蹤的回饋。