大規模產品技術團隊需求管理實踐

背景

隨着業務的發展，組織會從創業期的一個主要產品，擴展到多個產品。從產品技術的角度，也會逐漸抽象出共享技術部門，進而發展爲技術中臺、業務中臺。隨着產品線的擴大，產品需求管理（背後是協做協同、資源調度），就變成了一件越來越複雜的事情。若是不能妥善處理，會形成協同困難、效率低下，沒法支撐業務發展。本文介紹有贊從由單一產品到多產品線，產品技術團隊從百人到千人規模的需求管理實踐。

組織目標與產品需求待辦列表之間的關係

成功的商業組織，未必是資源多，而是把資源用到了對的地方。一維之上有二維，系統之上有系統，在更高維度才能看清楚低維度系統的全貌。從產品看技術，從業務看產品，從行業看業務。產品需求，從源頭上來看，承載的是一個組織的戰略目標和客戶的訴求。

有贊使用的是 OKR 來管理戰略目標，咱們常說不積硅步無以致千里， O 就是千里以外的目標，是指南針； 從OKR出發衍生的需求待辦列表，就是使得咱們致千里的硅步。以產品和服務爲載體的商業組織，不管目標多麼遠大，最終是落實在一條條需求上。產品需求的取捨依據是組織的目標，要與這個源頭對齊，也就是須要與 OKR 對齊，以免資源和時機的浪費。

需求待辦列表的產生與更新：多方作輸入， 產品負責人作決定

產品需求從」事「的角度來源於戰略。從」人「的角度來自內外部客戶、干係人，具體來講外部有用戶、客戶、合做方等，內部有決策者、產品、運營、服務等。

若是不能有效統籌管理上游干係人的指望，就會產生以下的負面反饋。決策者：個人 X 需求很重要,怎麼那麼久了尚未動靜？
客服：客戶關心的 Y 棘手問題，何時能解決？信息不對稱，就會陷入混沌狀態。

需求來源不少，但對產品需求待辦列表負責的惟一 owner ，是產品負責人 PO （ Product Owner ）。在輸入端，要保障內外部干係人的信息都能被聽到。但在決策階段，不能是多頭決策 （有贊有一個文化：不用投票解決問題。能夠普遍吸取意見，可是靠投票或者平衡術來作決定，一般是由於缺少方向性的認知和擔當）。 PO 要充分收集來自各方的訴求，但切勿被任何一方牽着鼻子走。 PO 須要有本身對產品的 Vision ，獨立的思考和判斷。一部交響樂是由羣體來演奏，但不是由羣體來創做。做爲產品負責人須要在其位謀其政，用產品需求待辦列表來體現產品願景和實現路徑，這是不可推卸的責任。

對絕大多數組織而言，一個重大的問題和挑戰，是如何把不少分散的、零碎的信息合爲總體。這份需求待辦列表，就是一個信息的整合。需求待辦列表確認以後，就能夠同步給決策者、運營、服務等角色。他們關心的事情，能夠有一個肯定性的結論和反饋。歸入規劃的需求，能夠有一個預期時間與節奏；沒有歸入的，也能明確告知，以便他們調整策略。

需求優先級的排列策略

不管是 PMP 、敏捷或者精益等，背後都有一個假設，時間、資源、人的智力創意等都是稀缺的，須要有效地被利用。有限的資源與無限的需求之間，是一對矛盾，咱們須要結合用戶價值、商業價值及成本投入作綜合考量。

需求優先級的排列策略，有比較多工具能夠用，好比用戶故事地圖、影響地圖、 MoSCoW 等，有許多公開資料能夠查到，再也不贅述。好比有贊使用的用戶故事地圖（灰色卡片爲優先級較低的需求）：

這裏須要特別關注的是，需求待辦列表，須要有 more with less 的理念，由於戰略的精髓是聚焦。
需求列的很長是容易的，可是能聚焦到最有價值的需求，是頗有挑戰的。

需求待辦列表自己是能夠隨時更新的，但下一個迭代或者研發週期的需求，須要有一個肯定性。 Scrum 是經過時間盒， KanBan 限制 WIP ，都是在長期的不肯定性和短時間的肯定性之間找到一個平衡。在有贊是採用固定週期的方式肯定下一個研發週期的需求列表(月規劃-周迭代-日站會)。

這裏須要注意的是，需求規劃應該是漸進明細的，不要追求長期且細緻的需求規劃，這樣是很危險的。在瞬息萬變的 VUCA 時代，須要在長期的遠景規劃與當前細緻行動計劃之間作好平衡，不斷迭代。

不一樣規模產品的需求待辦列表

單個小規模產品的需求待辦列表

單個產品，團隊規模也不大，有一個惟一的需求待辦列表，按照優先級自上而下排列。好比有贊在早期，主要是微信商城 SaaS 產品：

單個大規模產品的需求管理

隨着產品功能覆蓋的用戶場景愈來愈多，團隊規模擴大也愈來愈大，一個待辦列表進行需求管理，排優先級、規劃資源等都已經比較困難。
這個時候的策略是：按照業務、產品領域的特色，把產品待辦列表分紅多份。須要特別注意，不要按照職能團隊來劃分待辦列表（好比前端、後端、測試各有一份，會形成職能深井，目標迷失）。

好比零售業務和團隊規模愈來愈大，劃分二級：

多個大規模產品+業務中臺的需求管理

當組織的業務線、產品線愈來愈多，會有愈來愈強的訴求，要建設公共的業務、技術支撐能力，以免重複造輪子，特別是這些基礎支撐能力仍是對外創建生態的基礎，中臺業務線就產生了。
好比在有贊，從一開始的微信商城 SaaS 業務，發展出零售連鎖、資產、美業、教育，及對外提供PaaS能力的有贊雲等，都須要中臺的支持。中臺的出現，對於業務來說是把雙刃劍。一方面，中臺能夠提供許多基礎支撐能力，當新起一個業務的時候，或者用到其餘業務已經沉澱的能力，能夠快速複用；另外一方面，也會形成多個業務都依賴中臺，會造成協做複雜、信息不對稱等問題，中臺須要作取捨，就會造成瓶頸。
在有讚的的實踐是，各個上層產品都有本身的需求待辦列表，中臺也創建本身的產品需求待辦列表。多個業務/產品團隊都把本身對中臺的需求提過來，中臺基於自身建設規劃及其餘業務的價值優先級進行排序。綜合客戶訴求、業務戰略規劃、中臺建設規劃，對中臺的需求待辦列表進行排序、排期。

組織形態對需求管理策略的影響

有許多組織是採用職能型的組織結構，好比產品、技術等是不一樣的團隊，技術內部按照前端、後端、移動等分紅不一樣的團隊。可是在需求層面，須要始終保持用戶視角，不要過早從職能視角來拆解需求。若是非要作取捨，寧肯這個需求保持較大顆粒度，也不要讓客戶視角碎片化淹沒在多職能團隊（好比前端 後端 移動端等）的技術視角任務裏。這樣以客戶、戰略目標爲導向的需求待辦列表，有利於組織形態從深井向 Feature Team 的演進。

需求待辦列表的承載工具

君子善假於物。作組織效能提高，不能僅坐而論道，須要把理念落到實處，落到太陽天天照常升起，落到咱們協做的每個平常。空談不會誤司，但止於空談會誤司。文章前面提到的策略設計，基本在有贊效能平臺有產品化的落地，支撐需求相關理念在操做層面有效實施。

好比除了爲各產品線創建惟一的產品待辦列表，待辦列表之間也會根據需求之間的關聯關係進行互動，方便協同。好比共同依賴中臺的需求，需求卡片上會標註多團隊依賴需求的排期狀況。以下圖所示的 3/3 ,意味着須要 3 個產品線共同協做完成的需求， 3 方都已歸入各自的需求待辦列表。若是顯示的是 2/3 ，會提醒 PO ，具體是哪一個團隊還未將該需求歸入待辦列表。

產品、技術、服務運營、市場、管理者等不一樣角色，會有不一樣視角的訴求。咱們基於同一套需求待辦列表看板，配置出不一樣視角的信息。好比服務運營市場等業務側視角，但願看到各種需求的上線時間，咱們會配置出「上線日曆」模塊方便查看。

用電子看板可視化整個需求流轉的過程，相關過程節點會有時間和狀態的記錄，能夠自由地生成各類報表。不一樣角色的干係人，能夠看到他所關心維度的數據報表，檢視需求待辦列表的吞吐、週期等狀況，用於決策或者調整改進。

後記

從開始作總體的需求管理策略設計及落地,至今2年多時間,總體的策略與框架沒有大的變化。但大的需求管理框架，只能保障有一個總體的運做體系，過程當中仍須要解決許多具體的問題。每一個階段，團隊都會解決 1-2 個核心的過程障礙與問題，但仍然在需求顆粒度、價值閉環等方面有很多改進空間。以上總結，供你們參考，歡迎交流。

歡迎關注「有贊coder」公衆號！