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

背景

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

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

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

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

file

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

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

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

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

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

需求優先級的排列策略

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

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

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

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

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

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

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

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

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

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

好比零售業務和團隊規模愈來愈大,劃分二級:
file

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

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

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

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

需求待辦列表的承載工具

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

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

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

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

後記

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

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

相關文章
相關標籤/搜索