近期公司不斷討論「高績效團隊」，也讓我不斷思考一個高績效的產品開發團隊如何組成？事前要有哪些共識和建立什麼文化？我以「結果、流程、承諾、溝通」這四個面向來整理。
這篇會從四個關鍵方面：
- 成員對「結果」有共識嗎？
- 成員對「流程」有共識嗎？
- 成員對團隊有「承諾」嗎？
- 成員之間願意彼此「溝通」嗎？
一、成員對「結果」有共識嗎？
⠀⠀
對於「結果」，產品開發團隊的每個成員都需要知道彼此的工作目標是什麼、為什麼要這樣做、以及最終要達成的目標是什麼。
實際落地會有三個項目：長期目標願景、中期里程碑、短期任務
1. 長期目標願景
清晰的產品願景可以讓團隊成員更知道這艘船要開往哪裡，而這個宣達的 Owner，通常會由產品經理應該負責制定、並持續傳達這個願景，通常願景會包含兩個關鍵要素：
- 用戶價值：產品能為目標客群創造什麼價值？解決了哪些痛點？
- 商業價值：產品能為公司帶來什麼收益和影響？
整個團隊必須對這個願景都了解，才能將把中期專案與長期願景緊密聯繫起來。
2. 中期里程碑
為了達到長期願景，通常會經歷各種大小專案，每個功能開發時長 1-3 個月不等，但目標都應該要具體的、可衡量的、且與願景緊密相關，例如：
- 串接出貨：這個月先做正流程的出貨，下個月再串接逆物流。
- 訂單查詢頁：這週先做查詢功能，下週做訂單編輯功能。
但為了完成中期專案，通常還會搭配「整理開發文件、統一功能規則」，讓不同專案的開發規則都盡量一致。
3. 短期任務
在中期專案底下會再細拆各種任務，產品經理需要在 Kickoff Meeting / Planning 就說明清楚任務內容，特別是「驗收標準」，怎樣的產出 / 路徑才算是達成目標。
除了產品經理之外，測試工程師、前後端工程師也需要針對目標，一起提出潛在的風險，像是從測試角度確認有沒有遺漏的情境，從開發角度檢查有沒有遺漏的 API 需要修改。
確認每張工單（Story、Task）做完就代表完成了一個使用者任務。
二、成員對「流程」有共識嗎？
⠀⠀
在達成目標的過程，產品團隊內部的工作流程和協作方式也需要有共識。
1. 需求文件檢視方式
產品需求文件雖然是產品經理主責撰寫，但一份文件通常會經歷這些流程：
- 產品經理撰寫需求文件
- 團隊成員在 Kickoff Meeting 協助檢查是否有遺漏
- 前後端工程師按照需求開發
- 測試工程師按照驗收標準檢查開發內容
- 產品經理做最後驗收和把關
整個開發過程就像是大隊接力，需要一棒接一棒，因此團隊各成員需要對於文件都提出各自的看法，當有任何疑問，都可以隨時開一張「討論單」，確保彼此都有共識再繼續往下，避免工程師臨時更換開發內容，但測試人員不知道。
2. 專案的時程追蹤方式
呈上，因為開發流程是一棒接一棒，且同時可能會有多個任務進行中，因此彼此都要對時間保持透明，例如：
- 09/01 後端完成交給前端
- 09/02 前端串接完成交給測試
- 09/03 測試人員驗證完畢
每張任務都需要壓上前端、後端、測試的估時，才能讓所有人知道這一週我們總共會完成多少項目。
3. 每日站立會議流程
很多開發團隊都會有站立會議，意思是透過每天 15 mins 同步昨天做了哪些、今天要做哪些、以及釐清待確認事項。
因為時間較短，通常站立會議僅「更新重要事項」，比較不會「討論細節」，如要討論的話通常是會議後，由特定的關係人自行討論即可。
三、成員對團隊有「承諾」嗎？
⠀⠀
即使目標和流程都已經明確，要建立一支真正的高績效團隊，還需要每個成員對團隊目標和價值觀都有強烈的認同和承諾。
1. 共同的價值觀
在運行上述的流程和目標，需要大家都保持以下的價值觀：
- 時程透明：若開發會延遲就提早舉手，確認下一棒的人知道。
- 內容透明：工程師針對有改到的開發項目，都要如實向測試人員說明。
- 過程透明：針對每項討論都要有結論、筆記，確認未來可以查看。
這些方式我也是運行了 2–3 個月，才漸漸養成的習慣，但當每個團隊成員有這些習慣可以讓開發更順暢。
2. 對 Deadline 的承諾
有些專案會有滿嚴格的 Deadline，意思是無論如何一定要在該時間上線，像是比較嚴重的 bug 有時也會被要求及時修復。
因此當團隊收到這個 Deadline 時，大家都需要強烈意識到這個時間的重要性。
- 以 bug 來說，當 10mins、30mins 還找不到解決方法就要盡快找人支援。
- 以專案來說，若做了一整天仍沒有太大進展，則要趕緊找資深工程師協助。
3. 對流程的承諾
再延伸上述第二大點的流程，團隊成員共同訂出流程後，大家就需要謹記價值觀，例如站立會議盡量要控制在 15mins，因此每次會議都要控管時間，或是需求文件就需要包含驗收條件，因此產品經理在撰寫時就要自己留意。
四、成員之間願意彼此「溝通」嗎？
⠀⠀
共同目標和流程都需要仰賴溝通，因此良好的溝通方式也是高績效團隊的關鍵之一。
1. 暢通的溝通渠道
產品開發過程中，會有各種正式和非正式的溝通渠道，例如：
- 定期的團隊會議、包括每日站立、Review、Demo 會議
- 即時的線上溝通工具，如 Slack 或現場討論
- 非正式的交流場合，如下午茶、中午午餐、Team Building
2. 透明的進度共享
在開發過程中，如有任何需求異動，也需要保持高度的透明度，例如：
- 產品需求有變更，要及時在 Slack 通知開發人員，並在站會說明
- 開發過程有急件，要盡速布達並說明原因
- 開發前的盤點發現有些技術債要解，也要盡早提出方便預留時間
這些流程主要是避免只有特定人知道全貌，提早將訊息公開透明，也才能確認開發、測試都對目標有共識。
3. 真誠的反饋交流
在敏捷開發的流程，通常會有一個 Retro 會議，會進行：
- PM、RD、QA 針對彼此的工作內容給予回饋，像是需求清不清楚、開發估時是否準確、驗證是否多次來回
- 對於專案的看法、對於產品的看法
透過 Retro 會議，有時會讓團隊成員更清楚產品的目標，或是對於流程的共識和承諾，也可以更了解彼此溝通的默契和模式。
結語
⠀⠀
雖然這篇高績效團隊的內容看起來很制式，但我發現確實是需要一步步建立文化，也都是我親身經歷過的內容：
- 確保團隊成員對「結果」有共識
- 確保團隊成員對「流程」有共識
- 確保團隊成員對團隊有「承諾」
- 確保團隊成員之間願意彼此「溝通」
當然，不只是產品經理本身，要達到高績效其實核心在於「高度自主」，需要仰賴整個團隊的共識和默契，才能自行對結果有產出有承諾。
如對這系列文章興趣可以再觀看：
非常謝謝你的閱讀！上述單純以我的職場生活來整理，未能涵蓋所有案例。
如果文章有一點啟發或幫助，可以留言或來信讓我知道 👏
．撰寫於：2024/09/02 (一)
