隨著業務的發展，組織會從創業期的乙個主要產品，擴充套件到多個產品。從產品技術的角度，也會逐漸抽象出共享技術部門，進而發展為技術中臺、業務中臺。隨著產品線的擴大，產品需求管理（背後是協作協同、資源排程），就變成了一件愈來愈複雜的事情。如果不能妥善處理，會造成協同困難、效率低下，無法支撐業務發展。本文介紹有讚從由單一產品到多產品線，產品技術團隊從百人到千人規模的需求管理實踐。
成功的商業組織，未必是資源多，而是把資源用到了對的地方。一維之上有二維，系統之上有系統，在更高維度才能看清楚低維度系統的全貌。從產品看技術，從業務看產品，從行業看業務。產品需求，從源頭上來看，承載的是乙個組織的戰略目標和客戶的訴求。
有讚使用的是 okr 來管理戰略目標，我們常說不積矽步無以至千里， o 就是千里之外的目標，是指南針； 從okr出發衍生的需求待辦列表，就是使得我們致千里的矽步。以產品和服務為載體的商業組織，無論目標多麼遠大，最終是落實在一條條需求上。產品需求的取捨依據是組織的目標，要與這個源頭對齊，也就是需要與 okr 對齊，以避免資源和時機的浪費。
產品需求從」事「的角度**於戰略。從」人「的角度來自內外部客戶、干係人，具體來說外部有使用者、客戶、合作方等，內部有決策者、產品、運營、服務等。
如果不能有效統籌管理上游干係人的期望，就會產生如下的負面反饋。決策者：我的 x 需求很重要,怎麼那麼久了還沒有動靜？
客服：客戶關心的 y 棘手問題，什麼時候能解決？資訊不對稱，就會陷入混沌狀態。
需求**很多，但對產品需求待辦列表負責的唯一 owner ，是產品負責人 po （ product owner ）。在輸入端，要保障內外部干係人的資訊都能被聽到。但在決策階段，不能是多頭決策 （有讚有乙個文化：不用投票解決問題。可以廣泛吸收意見，但是靠投票或者平衡術來做決定，通常是因為缺乏方向性的認知和擔當）。 po 要充分收集來自各方的訴求，但切勿被任何一方牽著鼻子走。 po 需要有自己對產品的 vision ，獨立的思考和判斷。一部交響樂是由群體來演奏，但不是由群體來創作。作為產品負責人需要在其位謀其政，用產品需求待辦列表來體現產品願景和實現路徑，這是不可推卸的責任。
對絕大多數組織而言，乙個重大的問題和挑戰，是如何把很多分散的、零碎的資訊合為整體。這份需求待辦列表，就是乙個資訊的整合。需求待辦列表確認之後，就可以同步給決策者、運營、服務等角色。他們關心的事情，可以有乙個確定性的結論和反饋。納入規劃的需求，可以有乙個預期時間與節奏；沒有納入的，也能明確告知，以便他們調整策略。
無論是 pmp 、敏捷或者精益等，背後都有乙個假設，時間、資源、人的智力創意等都是稀缺的，需要有效地被利用。有限的資源與無限的需求之間，是一對矛盾，我們需要結合使用者價值、商業價值及成本投入做綜合考量。
需求優先順序的排列策略，有比較多工具可以用，比如使用者故事地圖、影響地圖、 moscow 等，有許多公開資料可以查到，不再贅述。比如有讚使用的使用者故事地圖（灰色卡片為優先順序較低的需求）：
這裡需要特別關注的是，需求待辦列表，需要有 more with less 的理念，因為戰略的精髓是聚焦。
需求列的很長是容易的，但是能聚焦到最有價值的需求，是很有挑戰的。
需求待辦列表本身是可以隨時更新的，但下乙個迭代或者研發週期的需求，需要有乙個確定性。 scrum 是通過時間盒， kanban 限制 wip ，都是在長期的不確定性和短期的確定性之間找到乙個平衡。在有讚是採用固定週期的方式確定下乙個研發週期的需求列表(月規劃-周迭代-日站會)。
這裡需要注意的是，需求規劃應該是漸進明細的，不要追求長期且細緻的需求規劃，這樣是很危險的。在瞬息萬變的 vuca 時代，需要在長期的遠景規劃與當前細緻行動計畫之間做好平衡，不斷迭代。
隨著產品功能覆蓋的使用者場景越來越多，團隊規模擴大也越來越大，乙個待辦列表進行需求管理，排優先順序、規劃資源等都已經比較困難。
這個時候的策略是：按照業務、產品領域的特點，把產品待辦列表分成多份。需要特別注意，不要按照職能團隊來劃分待辦列表（比如前端、後端、測試各有乙份，會造成職能深井，目標迷失）。
比如零售業務和團隊規模越來越大，劃分二級：
有許多組織是採用職能型的組織結構，比如產品、技術等是不同的團隊，技術內部按照前端、後端、移動等分成不同的團隊。但是在需求層面，需要始終保持使用者視角，不要過早從職能視角來拆解需求。如果非要做取捨，寧可這個需求保持較大顆粒度，也不要讓客戶視角碎片化淹沒在多職能團隊（比如前端 後端 移動端等）的技術視角任務裡。這樣以客戶、戰略目標為導向的需求待辦列表，有利於組織形態從深井向 feature team 的演進。
君子善假於物。做組織效能提公升，不能僅坐而論道，需要把理念落到實處，落到太陽每天照常公升起，落到我們協作的每乙個日常。空談不會誤司，但止於空談會誤司。文章前面提到的策略設計，基本在有贊效能平台有產品化的落地，支撐需求相關理念在操作層面有效實施。
比如除了為各產品線建立唯一的產品待辦列表，待辦列表之間也會根據需求之間的關聯關係進行互動，方便協同。比如共同依賴中颱的需求，需求卡片上會標註多團隊依賴需求的排期情況。如下圖所示的 3/3 ,意味著需要 3 個產品線共同協作完成的需求， 3 方都已納入各自的需求待辦列表。如果顯示的是 2/3 ，會提醒 po ，具體是哪個團隊還未將該需求納入待辦列表。
產品、技術、服務運營、市場、管理者等不同角色，會有不同視角的訴求。我們基於同一套需求待辦列表看板，配置出不同視角的資訊。比如服務運營市場等業務側視角，希望看到各類需求的上線時間，我們會配置出「上線日曆」模組方便檢視。
用電子看板視覺化整個需求流轉的過程，相關過程節點會有時間和狀態的記錄，可以自由地生成各種報表。不同角色的干係人，可以看到他所關心維度的資料包表，檢視需求待辦列表的吞吐、週期等情況，用於決策或者調整改進。
大規模Web服務開發技術
大規模web服務開發技術 日 伊藤直也,田中慎司編著 李劍 譯 isbn 978 7 121 13884 3 2011年7月出版 定價 59.00元 16開 356頁 內 容 簡 介 hatena是日本最大的web 服務提供商之一，它提供的服務包括關鍵字 類似於維基百科 部落格 相簿等。本書的內容主...
大規模Web服務開發技術
大規模web服務開發技術 日 伊藤直也,田中慎司編著 李劍譯 isbn 978 7 121 13884 3 2011年7月出版 定價 59.00元 16開 356頁 內 容 簡 介 hatena是日本最大的web 服務提供商之一，它提供的服務包括關鍵字 類似於維基百科 部落格 相簿等。本書的內容主要...
大規模Web服務開發技術
大規模web服務開發技術 日 伊藤直也,田中慎司編著 李劍譯 isbn 978 7 121 13884 3 2011年7月出版 定價 59.00元 16開 356頁 內容簡介 hatena 是日本最大的 web 服務提供商之一，它提供的服務包括關鍵字 類似於維基百科 部落格 相簿等。本書的內容主要來...