【需求管理】大規(guī)模產(chǎn)品技術(shù)團(tuán)隊(duì)需求管理實(shí)踐

背景
　　隨著業(yè)務(wù)的發(fā)展，組織會(huì)從創(chuàng)業(yè)期的一個(gè)主要產(chǎn)品，擴(kuò)展到多個(gè)產(chǎn)品。從產(chǎn)品技術(shù)的角度，也會(huì)逐漸抽象出共享技術(shù)部門(mén)，進(jìn)而發(fā)展為技術(shù)中臺(tái)、業(yè)務(wù)中臺(tái)。隨著產(chǎn)品線的擴(kuò)大，產(chǎn)品需求管理（背后是協(xié)作協(xié)同、資源調(diào)度），就變成了一件愈來(lái)愈復(fù)雜的事情。如果不能妥善處理，會(huì)造成協(xié)同困難、效率低下，無(wú)法支撐業(yè)務(wù)發(fā)展。本文介紹有贊從由單一產(chǎn)品到多產(chǎn)品線，產(chǎn)品技術(shù)團(tuán)隊(duì)從百人到千人規(guī)模的需求管理實(shí)踐。
　　組織目標(biāo)與產(chǎn)品需求待辦列表之間的關(guān)系
　　成功的商業(yè)組織，未必是資源多，而是把資源用到了對(duì)的地方。一維之上有二維，系統(tǒng)之上有系統(tǒng)，在更高維度才能看清楚低維度系統(tǒng)的全貌。從產(chǎn)品看技術(shù)，從業(yè)務(wù)看產(chǎn)品，從行業(yè)看業(yè)務(wù)。產(chǎn)品需求，從源頭上來(lái)看，承載的是一個(gè)組織的戰(zhàn)略目標(biāo)和客戶的訴求。
　　有贊使用的是 OKR 來(lái)管理戰(zhàn)略目標(biāo)，我們常說(shuō)不積硅步無(wú)以至千里， O 就是千里之外的目標(biāo)，是指南針； 從OKR出發(fā)衍生的需求待辦列表，就是使得我們致千里的硅步。以產(chǎn)品和服務(wù)為載體的商業(yè)組織，無(wú)論目標(biāo)多么遠(yuǎn)大，最終是落實(shí)在一條條需求上。產(chǎn)品需求的取舍依據(jù)是組織的目標(biāo)，要與這個(gè)源頭對(duì)齊，也就是需要與 OKR 對(duì)齊，以避免資源和時(shí)機(jī)的浪費(fèi)。

　　需求待辦列表的產(chǎn)生與更新：多方做輸入， 產(chǎn)品負(fù)責(zé)人做決定
　　產(chǎn)品需求從”事“的角度來(lái)源于戰(zhàn)略。從”人“的角度來(lái)自內(nèi)外部客戶、干系人，具體來(lái)說(shuō)外部有用戶、客戶、合作方等，內(nèi)部有決策者、產(chǎn)品、運(yùn)營(yíng)、服務(wù)等。
　　如果不能有效統(tǒng)籌管理上游干系人的期望，就會(huì)產(chǎn)生如下的負(fù)面反饋。決策者：我的 X 需求很重要,怎么那么久了還沒(méi)有動(dòng)靜？客服：客戶關(guān)心的 Y 棘手問(wèn)題，什么時(shí)候能解決？信息不對(duì)稱，就會(huì)陷入混沌狀態(tài)。
　　需求來(lái)源很多，但對(duì)產(chǎn)品需求待辦列表負(fù)責(zé)的唯一 owner ，是產(chǎn)品負(fù)責(zé)人 PO （ Product Owner ）。在輸入端，要保障內(nèi)外部干系人的信息都能被聽(tīng)到。但在決策階段，不能是多頭決策 （有贊有一個(gè)文化：不用投票解決問(wèn)題?？梢詮V泛吸收意見(jiàn)，但是靠投票或者平衡術(shù)來(lái)做決定，通常是因?yàn)槿狈Ψ较蛐缘恼J(rèn)知和擔(dān)當(dāng)）。 PO 要充分收集來(lái)自各方的訴求，但切勿被任何一方牽著鼻子走。 PO 需要有自己對(duì)產(chǎn)品的 Vision ，獨(dú)立的思考和判斷。一部交響樂(lè)是由群體來(lái)演奏，但不是由群體來(lái)創(chuàng)作。作為產(chǎn)品負(fù)責(zé)人需要在其位謀其政，用產(chǎn)品需求待辦列表來(lái)體現(xiàn)產(chǎn)品愿景和實(shí)現(xiàn)路徑，這是不可推卸的責(zé)任。
　　對(duì)絕大多數(shù)組織而言，一個(gè)重大的問(wèn)題和挑戰(zhàn)，是如何把很多分散的、零碎的信息合為整體。這份需求待辦列表，就是一個(gè)信息的整合。需求待辦列表確認(rèn)之后，就可以同步給決策者、運(yùn)營(yíng)、服務(wù)等角色。他們關(guān)心的事情，可以有一個(gè)確定性的結(jié)論和反饋。納入規(guī)劃的需求，可以有一個(gè)預(yù)期時(shí)間與節(jié)奏；沒(méi)有納入的，也能明確告知，以便他們調(diào)整策略。
　　需求優(yōu)先級(jí)的排列策略
　　無(wú)論是 PMP 、敏捷或者精益等，背后都有一個(gè)假設(shè)，時(shí)間、資源、人的智力創(chuàng)意等都是稀缺的，需要有效地被利用。有限的資源與無(wú)限的需求之間，是一對(duì)矛盾，我們需要結(jié)合用戶價(jià)值、商業(yè)價(jià)值及成本投入做綜合考量。
　　需求優(yōu)先級(jí)的排列策略，有比較多工具可以用，比如用戶故事地圖、影響地圖、 MoSCoW 等，有許多公開(kāi)資料可以查到，不再贅述。比如有贊使用的用戶故事地圖（灰色卡片為優(yōu)先級(jí)較低的需求）：

　　這里需要特別關(guān)注的是，需求待辦列表，需要有 more with less 的理念，因?yàn)閼?zhàn)略的精髓是聚焦。需求列的很長(zhǎng)是容易的，但是能聚焦到最有價(jià)值的需求，是很有挑戰(zhàn)的。
　　需求待辦列表本身是可以隨時(shí)更新的，但下一個(gè)迭代或者研發(fā)周期的需求，需要有一個(gè)確定性。 Scrum 是通過(guò)時(shí)間盒， KanBan 限制 WIP ，都是在長(zhǎng)期的不確定性和短期的確定性之間找到一個(gè)平衡。在有贊是采用固定周期的方式確定下一個(gè)研發(fā)周期的需求列表(月規(guī)劃-周迭代-日站會(huì))。
　　這里需要注意的是，需求規(guī)劃應(yīng)該是漸進(jìn)明細(xì)的，不要追求長(zhǎng)期且細(xì)致的需求規(guī)劃，這樣是很危險(xiǎn)的。在瞬息萬(wàn)變的 VUCA 時(shí)代，需要在長(zhǎng)期的遠(yuǎn)景規(guī)劃與當(dāng)前細(xì)致行動(dòng)計(jì)劃之間做好平衡，不斷迭代。
　　不同規(guī)模產(chǎn)品的需求待辦列表
　　單個(gè)小規(guī)模產(chǎn)品的需求待辦列表
　　單個(gè)產(chǎn)品，團(tuán)隊(duì)規(guī)模也不大，有一個(gè)唯一的需求待辦列表，按照優(yōu)先級(jí)自上而下排列。比如有贊在早期，主要是微信商城 SaaS 產(chǎn)品：

　　單個(gè)大規(guī)模產(chǎn)品的需求管理
　　隨著產(chǎn)品功能覆蓋的用戶場(chǎng)景越來(lái)越多，團(tuán)隊(duì)規(guī)模擴(kuò)大也越來(lái)越大，一個(gè)待辦列表進(jìn)行需求管理，排優(yōu)先級(jí)、規(guī)劃資源等都已經(jīng)比較困難。這個(gè)時(shí)候的策略是：按照業(yè)務(wù)、產(chǎn)品領(lǐng)域的特點(diǎn)，把產(chǎn)品待辦列表分成多份。需要特別注意，不要按照職能團(tuán)隊(duì)來(lái)劃分待辦列表（比如前端、后端、測(cè)試各有一份，會(huì)造成職能深井，目標(biāo)迷失）。
　　比如零售業(yè)務(wù)和團(tuán)隊(duì)規(guī)模越來(lái)越大，劃分二級(jí)：

　　多個(gè)大規(guī)模產(chǎn)品+業(yè)務(wù)中臺(tái)的需求管理
　　　當(dāng)組織的業(yè)務(wù)線、產(chǎn)品線越來(lái)越多，會(huì)有越來(lái)越強(qiáng)的訴求，要建設(shè)公共的業(yè)務(wù)、技術(shù)支撐能力，以避免重復(fù)造輪子，特別是這些基礎(chǔ)支撐能力還是對(duì)外建立生態(tài)的基礎(chǔ)，中臺(tái)業(yè)務(wù)線就產(chǎn)生了。比如在有贊，從一開(kāi)始的微信商城 SaaS 業(yè)務(wù)，發(fā)展出零售連鎖、資產(chǎn)、美業(yè)、教育，及對(duì)外提供PaaS能力的有贊云等，都需要中臺(tái)的支持。中臺(tái)的出現(xiàn)，對(duì)于業(yè)務(wù)來(lái)講是把雙刃劍。一方面，中臺(tái)可以提供許多基礎(chǔ)支撐能力，當(dāng)新起一個(gè)業(yè)務(wù)的時(shí)候，或者用到其他業(yè)務(wù)已經(jīng)沉淀的能力，可以快速?gòu)?fù)用；另一方面，也會(huì)造成多個(gè)業(yè)務(wù)都依賴中臺(tái)，會(huì)形成協(xié)作復(fù)雜、信息不對(duì)稱等問(wèn)題，中臺(tái)需要做取舍，就會(huì)形成瓶頸。在有贊的的實(shí)踐是，各個(gè)上層產(chǎn)品都有自己的需求待辦列表，中臺(tái)也建立自己的產(chǎn)品需求待辦列表。多個(gè)業(yè)務(wù)/產(chǎn)品團(tuán)隊(duì)都把自己對(duì)中臺(tái)的需求提過(guò)來(lái)，中臺(tái)基于自身建設(shè)規(guī)劃及其他業(yè)務(wù)的價(jià)值優(yōu)先級(jí)進(jìn)行排序。綜合客戶訴求、業(yè)務(wù)戰(zhàn)略規(guī)劃、中臺(tái)建設(shè)規(guī)劃，對(duì)中臺(tái)的需求待辦列表進(jìn)行排序、排期。

　　組織形態(tài)對(duì)需求管理策略的影響
　　有許多組織是采用職能型的組織結(jié)構(gòu)，比如產(chǎn)品、技術(shù)等是不同的團(tuán)隊(duì)，技術(shù)內(nèi)部按照前端、后端、移動(dòng)等分成不同的團(tuán)隊(duì)。但是在需求層面，需要始終保持用戶視角，不要過(guò)早從職能視角來(lái)拆解需求。如果非要做取舍，寧可這個(gè)需求保持較大顆粒度，也不要讓客戶視角碎片化淹沒(méi)在多職能團(tuán)隊(duì)（比如前端 后端 移動(dòng)端等）的技術(shù)視角任務(wù)里。這樣以客戶、戰(zhàn)略目標(biāo)為導(dǎo)向的需求待辦列表，有利于組織形態(tài)從深井向 Feature Team 的演進(jìn)。
　　需求待辦列表的承載工具
　　君子善假于物。做組織效能提升，不能僅坐而論道，需要把理念落到實(shí)處，落到太陽(yáng)每天照常升起，落到我們協(xié)作的每一個(gè)日常?？照劜粫?huì)誤司，但止于空談會(huì)誤司。文章前面提到的策略設(shè)計(jì)，基本在有贊效能平臺(tái)有產(chǎn)品化的落地，支撐需求相關(guān)理念在操作層面有效實(shí)施。
　　比如除了為各產(chǎn)品線建立唯一的產(chǎn)品待辦列表，待辦列表之間也會(huì)根據(jù)需求之間的關(guān)聯(lián)關(guān)系進(jìn)行互動(dòng)，方便協(xié)同。比如共同依賴中臺(tái)的需求，需求卡片上會(huì)標(biāo)注多團(tuán)隊(duì)依賴需求的排期情況。如下圖所示的 3/3 ,意味著需要 3 個(gè)產(chǎn)品線共同協(xié)作完成的需求， 3 方都已納入各自的需求待辦列表。如果顯示的是 2/3 ，會(huì)提醒 PO ，具體是哪個(gè)團(tuán)隊(duì)還未將該需求納入待辦列表。

　　產(chǎn)品、技術(shù)、服務(wù)運(yùn)營(yíng)、市場(chǎng)、管理者等不同角色，會(huì)有不同視角的訴求。我們基于同一套需求待辦列表看板，配置出不同視角的信息。比如服務(wù)運(yùn)營(yíng)市場(chǎng)等業(yè)務(wù)側(cè)視角，希望看到各類需求的上線時(shí)間，我們會(huì)配置出“上線日歷”模塊方便查看。

　　用電子看板可視化整個(gè)需求流轉(zhuǎn)的過(guò)程，相關(guān)過(guò)程節(jié)點(diǎn)會(huì)有時(shí)間和狀態(tài)的記錄，可以自由地生成各種報(bào)表。不同角色的干系人，可以看到他所關(guān)心維度的數(shù)據(jù)報(bào)表，檢視需求待辦列表的吞吐、周期等情況，用于決策或者調(diào)整改進(jìn)。

　　后記
　　從開(kāi)始做整體的需求管理策略設(shè)計(jì)及落地,至今2年多時(shí)間,整體的策略與框架沒(méi)有大的變化。但大的需求管理框架，只能保障有一個(gè)整體的運(yùn)作體系，過(guò)程中仍需要解決許多具體的問(wèn)題。每個(gè)階段，團(tuán)隊(duì)都會(huì)解決 1-2 個(gè)核心的過(guò)程障礙與問(wèn)題，但仍然在需求顆粒度、價(jià)值閉環(huán)等方面有不少改進(jìn)空間。以上總結(jié)，供大家參考，歡迎交流。