【需求管理】大規(guī)模產品技術團隊需求管理實踐
背景隨著業(yè)務的發(fā)展，組織會從創(chuàng)業(yè)期的一個主要產品，擴展到多個產品。從產品技術的角度，也會逐漸抽象出共享技術部門，進而發(fā)展為技術中臺、業(yè)務中臺。隨著產品線的擴大，產品需求管理（背后是協(xié)作協(xié)同、資源調度），就變成了一件愈來愈復雜的事情。如果不能妥善處理，會造成協(xié)同困難、效率低下，無法支撐業(yè)務發(fā)展。本文介紹有贊從由單一產品到多產品線，產品技術團隊從百人到千人規(guī)模的需求管理實踐。
組織目標與產品需求待辦列表之間的關系
成功的商業(yè)組織，未必是資源多，而是把資源用到了對的地方。一維之上有二維，系統(tǒng)之上有系統(tǒng)，在更高維度才能看清楚低維度系統(tǒng)的全貌。從產品看技術，從業(yè)務看產品，從行業(yè)看業(yè)務。產品需求，從源頭上來看，承載的是一個組織的戰(zhàn)略目標和客戶的訴求。
有贊使用的是 OKR 來管理戰(zhàn)略目標，我們常說不積硅步無以至千里， O 就是千里之外的目標，是指南針； 從OKR出發(fā)衍生的需求待辦列表，就是使得我們致千里的硅步。以產品和服務為載體的商業(yè)組織，無論目標多么遠大，最終是落實在一條條需求上。產品需求的取舍依據(jù)是組織的目標，要與這個源頭對齊，也就是需要與 OKR 對齊，以避免資源和時機的浪費。
需求待辦列表的產生與更新：多方做輸入， 產品負責人做決定
產品需求從”事“的角度來源于戰(zhàn)略。從”人“的角度來自內外部客戶、干系人，具體來說外部有用戶、客戶、合作方等，內部有決策者、產品、運營、服務等。
如果不能有效統(tǒng)籌管理上游干系人的期望，就會產生如下的負面反饋。決策者：我的 X 需求很重要,怎么那么久了還沒有動靜？客服：客戶關心的 Y 棘手問題，什么時候能解決？信息不對稱，就會陷入混沌狀態(tài)。
需求來源很多，但對產品需求待辦列表負責的唯一 owner ，是產品負責人 PO （ Product Owner ）。在輸入端，要保障內外部干系人的信息都能被聽到。但在決策階段，不能是多頭決策 （有贊有一個文化：不用投票解決問題?？梢詮V泛吸收意見，但是靠投票或者平衡術來做決定，通常是因為缺乏方向性的認知和擔當）。 PO 要充分收集來自各方的訴求，但切勿被任何一方牽著鼻子走。 PO 需要有自己對產品的 Vision ，獨立的思考和判斷。一部交響樂是由群體來演奏，但不是由群體來創(chuàng)作。作為產品負責人需要在其位謀其政，用產品需求待辦列表來體現(xiàn)產品愿景和實現(xiàn)路徑，這是不可推卸的責任。
對絕大多數(shù)組織而言，一個重大的問題和挑戰(zhàn)，是如何把很多分散的、零碎的信息合為整體。這份需求待辦列表，就是一個信息的整合。需求待辦列表確認之后，就可以同步給決策者、運營、服務等角色。他們關心的事情，可以有一個確定性的結論和反饋。納入規(guī)劃的需求，可以有一個預期時間與節(jié)奏；沒有納入的，也能明確告知，以便他們調整策略。
需求優(yōu)先級的排列策略
無論是 PMP 、敏捷或者精益等，背后都有一個假設，時間、資源、人的智力創(chuàng)意等都是稀缺的，需要有效地被利用。有限的資源與無限的需求之間，是一對矛盾，我們需要結合用戶價值、商業(yè)價值及成本投入做綜合考量。
需求優(yōu)先級的排列策略，有比較多工具可以用，比如用戶故事地圖、影響地圖、 MoSCoW 等，有許多公開資料可以查到，不再贅述。比如有贊使用的用戶故事地圖（灰色卡片為優(yōu)先級較低的需求）：
這里需要特別關注的是，需求待辦列表，需要有 more with less 的理念，因為戰(zhàn)略的精髓是聚焦。需求列的很長是容易的，但是能聚焦到最有價值的需求，是很有挑戰(zhàn)的。
需求待辦列表本身是可以隨時更新的，但下一個迭代或者研發(fā)周期的需求，需要有一個確定性。 Scrum 是通過時間盒， KanBan 限制 WIP ，都是在長期的不確定性和短期的確定性之間找到一個平衡。在有贊是采用固定周期的方式確定下一個研發(fā)周期的需求列表(月規(guī)劃-周迭代-日站會)。
這里需要注意的是，需求規(guī)劃應該是漸進明細的，不要追求長期且細致的需求規(guī)劃，這樣是很危險的。在瞬息萬變的 VUCA 時代，需要在長期的遠景規(guī)劃與當前細致行動計劃之間做好平衡，不斷迭代。
不同規(guī)模產品的需求待辦列表
單個小規(guī)模產品的需求待辦列表
單個產品，團隊規(guī)模也不大，有一個唯一的需求待辦列表，按照優(yōu)先級自上而下排列。比如有贊在早期，主要是微信商城 SaaS 產品：
單個大規(guī)模產品的需求管理
隨著產品功能覆蓋的用戶場景越來越多，團隊規(guī)模擴大也越來越大，一個待辦列表進行需求管理，排優(yōu)先級、規(guī)劃資源等都已經比較困難。這個時候的策略是：按照業(yè)務、產品領域的特點，把產品待辦列表分成多份。需要特別注意，不要按照職能團隊來劃分待辦列表（比如前端、后端、測試各有一份，會造成職能深井，目標迷失）。
比如零售業(yè)務和團隊規(guī)模越來越大，劃分二級：
多個大規(guī)模產品+業(yè)務中臺的需求管理
當組織的業(yè)務線、產品線越來越多，會有越來越強的訴求，要建設公共的業(yè)務、技術支撐能力，以避免重復造輪子，特別是這些基礎支撐能力還是對外建立生態(tài)的基礎，中臺業(yè)務線就產生了。比如在有贊，從一開始的微信商城 SaaS 業(yè)務，發(fā)展出零售連鎖、資產、美業(yè)、教育，及對外提供PaaS能力的有贊云等，都需要中臺的支持。中臺的出現(xiàn)，對于業(yè)務來講是把雙刃劍。一方面，中臺可以提供許多基礎支撐能力，當新起一個業(yè)務的時候，或者用到其他業(yè)務已經沉淀的能力，可以快速復用；另一方面，也會造成多個業(yè)務都依賴中臺，會形成協(xié)作復雜、信息不對稱等問題，中臺需要做取舍，就會形成瓶頸。在有贊的的實踐是，各個上層產品都有自己的需求待辦列表，中臺也建立自己的產品需求待辦列表。多個業(yè)務/產品團隊都把自己對中臺的需求提過來，中臺基于自身建設規(guī)劃及其他業(yè)務的價值優(yōu)先級進行排序。綜合客戶訴求、業(yè)務戰(zhàn)略規(guī)劃、中臺建設規(guī)劃，對中臺的需求待辦列表進行排序、排期。
組織形態(tài)對需求管理策略的影響
有許多組織是采用職能型的組織結構，比如產品、技術等是不同的團隊，技術內部按照前端、后端、移動等分成不同的團隊。但是在需求層面，需要始終保持用戶視角，不要過早從職能視角來拆解需求。如果非要做取舍，寧可這個需求保持較大顆粒度，也不要讓客戶視角碎片化淹沒在多職能團隊（比如前端 后端 移動端等）的技術視角任務里。這樣以客戶、戰(zhàn)略目標為導向的需求待辦列表，有利于組織形態(tài)從深井向 Feature Team 的演進。
需求待辦列表的承載工具
君子善假于物。做組織效能提升，不能僅坐而論道，需要把理念落到實處，落到太陽每天照常升起，落到我們協(xié)作的每一個日常。空談不會誤司，但止于空談會誤司。文章前面提到的策略設計，基本在有贊效能平臺有產品化的落地，支撐需求相關理念在操作層面有效實施。
比如除了為各產品線建立唯一的產品待辦列表，待辦列表之間也會根據(jù)需求之間的關聯(lián)關系進行互動，方便協(xié)同。比如共同依賴中臺的需求，需求卡片上會標注多團隊依賴需求的排期情況。如下圖所示的 3/3 ,意味著需要 3 個產品線共同協(xié)作完成的需求， 3 方都已納入各自的需求待辦列表。如果顯示的是 2/3 ，會提醒 PO ，具體是哪個團隊還未將該需求納入待辦列表。
產品、技術、服務運營、市場、管理者等不同角色，會有不同視角的訴求。我們基于同一套需求待辦列表看板，配置出不同視角的信息。比如服務運營市場等業(yè)務側視角，希望看到各類需求的上線時間，我們會配置出“上線日歷”模塊方便查看。
用電子看板可視化整個需求流轉的過程，相關過程節(jié)點會有時間和狀態(tài)的記錄，可以自由地生成各種報表。不同角色的干系人，可以看到他所關心維度的數(shù)據(jù)報表，檢視需求待辦列表的吞吐、周期等情況，用于決策或者調整改進。
后記
從開始做整體的需求管理策略設計及落地,至今2年多時間,整體的策略與框架沒有大的變化。但大的需求管理框架，只能保障有一個整體的運作體系，過程中仍需要解決許多具體的問題。每個階段，團隊都會解決 1-2 個核心的過程障礙與問題，但仍然在需求顆粒度、價值閉環(huán)等方面有不少改進空間。以上總結，供大家參考，歡迎交流。
頁:
[1]