產品管理

[PM工作]如何讓團隊對開發目標真正有共識 “ on the same page “?

這個題目看似很廣,事實上依照我自家實際執行過的經驗後,我發現比想像中出現更多問題!以下逐一拆解問題及解法。

PM 寫的任何文件不是自己寫得開心、製作精美為主,重要的是「大家一起看過」

為什麼需要大家一起開會、過文件項目?因為沒有凝聚共識,過程中就會需要有非常繁瑣的確認的過程,甚至在開發初期彼此想法是南轅北轍,這是非常嚴重的狀況,當產品無法預期上線直接影響到公司營運。以下提到的產品經理(Product Manager)都以 PM 簡稱。

我很喜歡整理任何的文件,大方向會先評估現在的團隊規模組成、這個團隊負責的產品,接著會產出既定的產品開發文件,包含但不限於像是以下常見的這幾種文件檔案:產品規格(Product Spec)、產品需求規劃書(Product Requirement Document, PRD)、產品待辦清單(Product Backlog);小方向則會細看到每一份文件的「每一列」、「每一欄」,是否要先套用資料驗證功能,以利團隊協作或我自己在管理上可以直接選填項目即可,就不用自行輸入⋯⋯等諸多細節。

但是,絕多數開發團隊,特別是技術專家(前端及後端工程師)很少會逐一細看產品規格,不是沒有!我想表達的是很少,或者是過目了但用「自己理解的意思就去做了」。因為吃過幾次這樣的虧,所以文件我還是會整理得好好的,接著要直接約一場會議(Kick-off Meeting),從大方向逐項過到小項目。

PM 要懂得營造會議上和諧的氣氛,讓閱聽者覺得有動力繼續聽下去

雖然不同的 PM 無論在個性及做事方式風格皆不同,我分享我的做法比較像是「班長兼任康樂股長」的角色,不是刻意讓團隊喜歡我,而是「先願意」看我、聽我想表達什麼。

我會先讓團隊看到這個產品的願景是什麼,看手邊的產品路線圖(Product Roadmap)規劃到哪個時間點,假設是未來一年,那就和團隊分享未來一年我們要抵達到什麼位置?再拆解成上半年(H1)、下半年(H2)、每一季(Q1-Q4)而到每個月(Jan-Dec)最後則是每一個衝刺目標(Sprint)。切記不要抱持走一步是一步地進行產品開發,先彼此對焦「長中短期」的目標後,並落實敏捷開發的實踐方法,才是我認為比較理想的狀態。

這種作法的好處是,通常團隊氣氛是融洽的,但缺點也可能會讓 PM 缺少適當的權威性,以及鮮少有衝突,會變成該衝突的時候可能會不敢大膽發聲產生衝突。所以在與團隊互動過程中要不斷觀察並調整符合當下的事宜作為。

要怎麼知道真的對焦清楚了,在同一個頁面了 “Really on the same page”

從當下的會議結論就可以先確認,通常我會習慣做階段性的小結論、而在結尾做一個結論,並詢問在場有沒有還需要討論的?然後開玩笑說離開會議室就表示畫押囉(全場笑)。笑著笑著,但真正落實到產品開發時,事情還是得要好好做的:)

每天的站立會議(Daily Scrum Meeting)的回報進度就能最快知道了,PM 通常要非常專心地聆聽每一個成員回報的進度內容,假設說法上略顯含糊、範圍太大,PM 請勇敢的提問:為什麼?請問這是什麼意思呢?那我們可以怎麼做?預計何時?等⋯⋯ 其實這樣的一問一答我覺得不只是適用於產品開發的作業流程中,各行各業的各位工作人士都相當適用呀!有疑問就要勇於提問。

隨著做產品的經驗累積,即使非技術背景的 PM,我相信都可以「比較能夠」去掌握各功能的預計開發時程。通常我會先把預計開發的時程做成 Milestone 讓團隊知道這個時間點我們要完成什麼項目,而中間的開發細節則透過每天站立會議和 2 週的一次 Sprint 進行覆核確認,如果可以最好也讓工程師的技術主管也參與會議,能幫忙確保任務執行的正確性。

牢記敏捷精神:百密仍有一疏,越快發現錯誤及時修正,導正回正確道路上

直到現在,在製作產品待辦清單(Product Backlog)時,即使我已經詳細的標注是在「哪個單元」的「哪個區塊」要做「什麼事」?也可能讓開發的成員誤會,我先前的經驗是當功能已經部署到開發站台上,我在測試功能時發現與想像中不同,且差異頗大,這時候回頭與前端工程師確認時,發現彼此的認知不同,確定誤會了!所幸這個功能要修正不會花太多時間,但我學到的經驗是即使每天在過開發內容時,仍以為是「正確的功能」,沒想到做出來仍是不一樣的。

這也帶出另一個警惕是當越重要的核心功能要上線時,在產品交付的週期時程要安排得更謹慎,無論是開發時間及 QAQC 的產品驗收階段,時間如果抓得太緊可能導致驗收功能時不夠落實而匆促上線,最後導致功能不完善造成客訴,得不償失。


總結,讓團隊彼此有共識,在進入開發前期就需要「對焦」彼此對產品目標、產品功能等認知有其必要性。身為 PM 必須不厭其煩的一再的確認進度,以及開發成員是否真的對功能有所理解,最後是做出來的成品的驗證。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *