| 编辑推荐: |
本篇文章主要从组织目标与产品需求待办列表之间的关系、需求待办列表的产生与更新、需求优先级的排列策略、不同规模产品的需求待办列表及需求待办列表的承载工具几个方面来介绍了大规模产品技术团队需求管理实践。
文章来自于博客园，由火龙果软件Linda编辑推荐。 |
|
背景
随着业务的发展，组织会从创业期的一个主要产品，扩展到多个产品。从产品技术的角度，也会逐渐抽象出共享技术部门，进而发展为技术中台、业务中台。随着产品线的扩大，产品需求管理（背后是协作协同、资源调度），就变成了一件愈来愈复杂的事情。如果不能妥善处理，会造成协同困难、效率低下，无法支撑业务发展。本文介绍有赞从由单一产品到多产品线，产品技术团队从百人到千人规模的需求管理实践。
组织目标与产品需求待办列表之间的关系
成功的商业组织，未必是资源多，而是把资源用到了对的地方。一维之上有二维，系统之上有系统，在更高维度才能看清楚低维度系统的全貌。从产品看技术，从业务看产品，从行业看业务。产品需求，从源头上来看，承载的是一个组织的战略目标和客户的诉求。
有赞使用的是 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 个核心的过程障碍与问题，但仍然在需求颗粒度、价值闭环等方面有不少改进空间。
|
