如果你也和我一样是一名互联网产品经理，大概率上肯定绕不开也离不开“需求”。产品经理对需求是又爱又恨，因为每天都在上演这些情境：
情境1：每个需求方都火急火燎地告诉你，他们的需求重要又紧急；不管研发资源是不是有限，立即马上上线
情境2：老板或公司的决策层提出一个想法，要求产品经理立即落实；可恨地是，这样的临时插队，产品经理也没法随口拒绝
情境3：按计划的产品迭代，一次次地被拖延，需求池里的需求越积越多，产品迭代节奏紊乱
怎么破解需求管理上的“急”和“乱”的难题呢？最近我在阅读的《B端产品经理必修课》中找到了一些启发。本文将先介绍作者针对需求管理的疑难杂症提出的良方，再结合自身在产品工作中是如何优化需求管理。
在此，也同步分享给挣扎在需求管理中的各位同仁。
需求管理方法论
作者认为，需求管理是通过协助来管理需求内容和进程，最终实现成功发布的目的。根据这个定义，那么关键因素是如何与需求管理中的干系人高效地协作。常见的干系人，比如需求提出方，产品经理，研发团队等。
产品经理在应对需求方提出的“急需求”时，作者建议的工作方法是：化散乱为规律，化应急为预测。在实际操作层面，借鉴急诊室的做法，对新提交的需求增加一个“预检分诊”的预处理模式。这样，一个需求经过预处理后，分流进入或是“需求设计研发”，或是“暂存需求池”，或是“打回需求方”等路径。
那么在应对需求管理“乱”，产品迭代周期不稳定时，作者认为产品经理需要协同研发团队，以公交模式为指导原则，让需求管理有规律地运转起来。
公交模式，是引自《启示录-打造用户喜爱的产品》一书中的“以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布”的火车模型发布模式。
为了更好地解释公交模式，以日常生活中乘公交车的场景为例来说明。假设从A-->B-->C的路线需要换乘2辆公交车，每趟公交车之间都有发车间隔和到站时刻。在这条路线，我需要来到A点等第一辆车，车来了上车，到达B点后下车并等待第二辆车，车来了上车，到达C点（目的地）。
那么在公交模式中有两个关键要素，即“需求管理周期”和“需求管理流程”。简单来说，
需求管理周期：完成需求管理中按顺序重复出现的活动所需要的时间。结合乘公交的例子，就是完成“来到车站--等车-上车-到达”这三步骤所需的时间。参照项目管理的经验，一般的需求周期是80个小时，即每一类需求管理活动周期是2周（按每周5天，每天8小时计算）
需求管理流程：在单个需求管理周期里，按照顺序依次进行需求管理活动。在产品工作中即，先进行需求收集，再进行需求设计，最后进行需求研发
小结一下，让需求不急不乱的方法是需求收集时的预处理模式和需求顺畅运转的公交模式。接下来，我会结合亲身案例，运用书中的需求管理方法，解决我在工作中遇到的需求管理难题。
一个实战案例
如果用一个形容词来描述创业公司，那么我会用“不确定性”来形容。业务不确定，战略不确定，团队不确定，总之有N个不确定。在产品工作中，最不确定的当属需求。
创业公司的需求不确定性，主要体现在两个维度。
一、在需求收集阶段，常常没有规律，说不定哪天刚上班就收到要紧急开发某某需求。这个问题的本源在于公司业务的不确定性。
二、没有需求上线的节奏，多半取决于研发哪天交付。
所以为了解决需求不确定性，我根据实际情况，优化了需求管理的运转模式，管理流程和信息传递。
运转模式
规定了产品的上线节奏是两周一次，需求管理周期是2周
需求管理活动中需求收集、需求设计、需求研发，三个步骤合并为两步，即需求收集&设计，需求研发；需求收集&设计阶段是产品经理主导，需求研发阶段是研发主导，产品跟踪管理。
结合公交模式，每个需求管理周期里的活动有，当期的需求收集&设计，以及上一周期的需求研发（如图示）。
运转模式示例图
需求管理流程
在单个需求管理周期里，活动按顺序依次进行：
1.收到需求反馈后，先是预处理，判断是否有资格进入需求池
2.每个周期的第一个周二召开需求评审会，目的是与需求方和研发团队同步：
2.1 需求的优先级、重要性
2.2 本周期待设计的需求
2.3 本周期已进入研阶段的需求状态
3.需求分析&设计，输出产品需求文档（PRD）
4.需求研发阶段，参照JIT的看板管理需求在研发中的不同状态
5.最后需求上线
需求管理流程示例图
信息传递
在需求管理流程中的信息传递，主要依靠文档的方式流转。需求周期中一般有4种文档需要管理。
文档一：需求反馈收集表
是否需要需求反馈收集表，取决于需求的来源。如果是产品经理按照项目规划的迭代需求，一般是直接接入需求池，也就不需要需求反馈收集表。如果是需求方来自产品部门外，则采用统一模板的需求反馈收集表会更高效。但需求来源是公司战略规划，一般也是直接进入需求池。
在管理需求收集文档，个人会建议用在线文档创建一个模板，并共享给公司所有人。需求方下一份副本模板填写需求，就可以在线提交（共享）给产品经理。
文档二：需求池
维护需求池的难点在于如何给需求分类和排序。根据公司的实际业务，通过定义优先级的方式，将需求按优先级进行分组。然后针对同一组同一优先级的需求按照重要性来打分。
重要性的打分范围，与需求所属的优先级有强关系。比如最高级别的需求，那么重要性可打分的范围是81-100分。个人认为重要性打分会受到产品经理主观因素的干扰，但通过先优先级分类，再重要性打分的方式，对需求排序的影响已经可以忽略了。
文档三：产品需求文档（PRD）
PRD是产品经理输出给研发的文档，是将一个业务需求落实为可进入开发的产品需求。
文档四：需求卡片
需求进入研发阶段就需要看板管理，那么需求卡片就是很好地方式进行追踪需求的状态。需求卡片主要展现的是需求的研发状态，但需关联需求收集反馈表、需求池、PRD的信息，即一个需求相关的所有数据。这样便于追踪状态，查相关信息。
关于看板管理和需求卡片，很多在线协同、项目管理类的工具都可以达到目的，比如Jira, teambiton等。
关于《B端产品经理必修课》的概况
本书的作者是小米物流系统产品经理的李宽。阅读完整本书，我惊喜地发现作者也是一个爱阅读产品经理。他阅读广泛，涉猎历史、哲学、科学、经管、互联网等多个领域。在每一篇章的开头，在章节的内容中，随处可见的是他对各类书的旁征博引。
在这本书中，李宽和读者探讨了B端产品的三个主题：
一、什么是B端产品，B端产品经理的工作流程，职业现状和规划
二、从软件工程和用户体验的角度，重点向读者讲解了单个产品管理流程
三、从自身的实战经验中提炼出产品经理该如何自我管理
如果你想了解B端产品经理的工作流程和必备技能，或是和我一样想深入学习李宽的需求管理方法论，推荐一读。
网友评论