大规模产品技术团队需求管理实践

背景

随着业务的发展，组织会从创业期的一个主要产品，扩展到多个产品。从产品技术的角度，也会逐渐抽象出共享技术部门，进而发展为技术中台、业务中台。随着产品线的扩大，产品需求管理（背后是协做协同、资源调度），就变成了一件越来越复杂的事情。若是不能妥善处理，会形成协同困难、效率低下，没法支撑业务发展。本文介绍有赞从由单一产品到多产品线，产品技术团队从百人到千人规模的需求管理实践。

组织目标与产品需求待办列表之间的关系

成功的商业组织，未必是资源多，而是把资源用到了对的地方。一维之上有二维，系统之上有系统，在更高维度才能看清楚低维度系统的全貌。从产品看技术，从业务看产品，从行业看业务。产品需求，从源头上来看，承载的是一个组织的战略目标和客户的诉求。

有赞使用的是 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”公众号！