【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
背景
随着业务的发展，组织会从创业期的一个主要产品，扩展到多个产品。从产品技术的角度，也会逐渐抽象出共享技术部门，进而发展为技术中台、业务中台。随着产品线的扩大，产品需求管理（背后是协作协同、资源调度），就变成了一件愈来愈复杂的事情。如果不能妥善处理，会造成协同困难、效率低下，无法支撑业务发展。本文介绍有赞从由单一产品到多产品线，产品技术团队从百人到千人规模的需求管理实践。
组织目标与产品需求待办列表之间的关系
成功的商业组织，未必是资源多，而是把资源用到了对的地方。一维之上有二维，系统之上有系统，在更高维度才能看清楚低维度系统的全貌。从产品看技术，从业务看产品，从行业看业务。产品需求，从源头上来看，承载的是一个组织的战略目标和客户的诉求。
有赞使用的是 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 个核心的过程障碍与问题，但仍然在需求颗粒度、价值闭环等方面有不少改进空间。以上总结，供大家参考，欢迎交流。
> 本文由博客一文多发平台 OpenWrite 发布！
来源：oschina
链接：https://my.oschina.net/u/4180867/blog/3147769