2.2 产品需求管理
从用户思维来看，需求的本质是用户动机，动机就是用户想要得到或想要满足某种欲望表现出来的使用目的；从工程思维来看，需求则是一个简单按钮大小的调整，或是一个数据计算口径的定义，抑或是一个系统架构设计方案。而在从某些抽象的动机或具象的需求，转化落地到产品的实现中，产品经理充当着绝对重要的角色。产品需求贯穿于一个产品的整个生命周期，是产品经理每天工作所围绕的中心，良好的需求管理亦是产品经理招聘中不可或缺的岗位要求。
2.2.1 需求来源与需求判断
首先回归需求的来源，产品需求通常需要通过用户调研、竞品分析、用户反馈、头脑风暴、数据分析等方面挖掘，数据产品通常也会有业务方直接提的数据需求。在需求对接后，产品经理会先根据需求类别进行梳理，是提数类需求、数据接口类需求、数据分析类需求、产品功能类需求，还是数据优化类需求等。产品经理通常需要与用户深入地交流才能确定真正的需求，通过用户的回复、行为、反馈、抱怨等现象，深刻把握用户最核心的需求，深度挖掘用户的需求，可能会发现其实用户要的并不是一匹更快的马，而只是想更快地到达目的地。
例如，运营人员小张对数据产品经理小王提出了一个需求，“最近我发现一些异常领积分的用户，需要你帮忙做一个反作弊数据系统，以方便我发现每天作弊刷积分的用户，然后做进一步处理”，这个时候数据产品经理小王应该深入了解业务，知道领积分功能是针对用户的一个拉新活动，在新用户领完积分之后可以用积分抽奖，在奖品累积之后，在产品的兑换中心可以兑换相关礼品，如电话充值卡、充电宝、数据线等，通过活动黏住用户，增加用户在产品上的停留时长，增大用户进行其他业务消费的可能性。梳理业务流程大致如图2-17所示。
图2-17 领积分案例业务流程
通过以上的需求梳理，可以发现运营人员小张真正的需求是想杜绝一些刷积分的用户，他们破坏了整个运营活动的生态平衡，小张想把活动资金准备的充电宝等礼品留给真正参与活动的用户。在知道了本质需求以后，数据产品经理小王建议也许不必大动干戈实现一个活动监控的系统，可以请挖掘同事接入用户行为数据，实现异常行为领积分的反作弊模型，比如领积分时间集中（同一IP、同一设备在1秒内领取多次积分，这明显是在正常使用业务时不可能出现的问题）、地域集中、其他行为异常（无停留时长记录，却有多次领积分的行为）等，挖掘同事通过作弊模型实时判断作弊用户，并把作弊用户列表通过实时接口提供给业务方小张，并在作弊用户领取奖品时做一些限制。通过这个方案，运营人员不必实时人工处理，也不需要调用前端、后端等同事开发系统，很好地解决了运营人员的本质需求。回头来看，最终完成的其实并不是运营人员小张最初提的实现作弊数据系统的需求，解决方案却比运营人员提到的更加系统、高效，这就是在需求来源环节把握需求本质与深入理解的重要性。
通过深度挖掘需求本质和需求判断，在大部分情况下产品经理并不会立即给出解决方案，而只是需要排期处理。在需求价值判断环节，产品经理需要找出场景合理、可以真正提升业务发展的需求，进行简单的需求归类、需求优先级标注、需求期望完成时间的记录，而对于那些不合理的需求，例如头脑风暴出来拍脑瓜的需求，在进行深入思考与讨论后，往往会发现很大的问题，这些可以滞缓或直接砍掉，产品经理在对自己的需求梳理和设计时，理应砍掉自己可以判断出来的不合理的想法。
数据产品经理小王将自己日常判断需求优先级的标准梳理如下，并整理成坐标象限图，如图2-18所示。对于其他不合理、不紧急的需求，需要把需求打回去让需求方重新构思方案。
图2-18 定位产品优先级的标准
2.2.2 产品需求池管理
建设产品需求池的目的主要是方便对需求进行管理，如何建设需求池需要经过全面的考虑，包括建设需求池需要的标准、需求归类、需求内容、需求优先级、需求对接人等。在项目的实际推进过程中，不加控制的需求变更往往给项目带来沉重的负担和无法预料的风险。因此，考虑应对计划之外的情况也是需求池需要考虑的一部分。可见，设计一套合适的需求变更管理流程和规范非常重要。
产品需求池的管理如表2-6所示。
当然，在日常需求管理工作中，可以借助JIRA、Tower等工具记录每个需求的内容，具体管理需求。如图2-19所示，以JIRA为例，JIRA是一个很方便的项目跟踪工具，广泛应用于需求收集、项目跟进、敏捷开发的各个领域，JIRA可以针对每次敏捷开发的版本创建Sprint敏捷看板，对当前版本的待办、处理中、完成等各种状态的任务情况一目了然，并且当每次有状态更新的任务时都会有邮件及时通知相关人员。在敏捷开发完成后，还可以针对项目生成分析报告，方便对项目进行复盘和总结。
表2-6 产品需求池的管理
图2-19 用JIRA工具管理需求
2.2.3 从需求跟进到需求落地
1.需求文档
在产品需求完全对接完成，并充分理解产品需求以后，产品经理可以进入撰写需求文档环节了，此时对需求的整体背景、用户情况以及需求目标已经有了明确的了解。需求文档面向项目的需求方、面向关注该需求的领导、面向需求对接的设计师，也面向团队中的研发和测试工程师，是项目成员重要的参考依据。
产品经理在撰写需求文档前，可以先梳理产品设计的方案，可以用笔在纸上画一个简单的产品方案和文档框架，在确认没问题后，就可以开始撰写完善的文档了。
需求文档的具体框架因项目而异，但通常情况下应该包含的模块有需求/产品概况、文档迭代记录、需求/产品背景、需求/产品定位、需求/产品优先级、需求内容等。下面简单示例。
第一部分：需求/产品概况，如图2-20所示。
图2-20 需求/产品概况
第二部分：文档迭代记录，如表2-7所示。
表2-7 文档迭代记录
第三部分：需求/产品背景。
这个部分要讲清楚为什么要做这个需求/产品，包括相关的业务背景、市场行情或竞品的简要对比分析、预计需求/产品完成上线之后可以达成的目标。
第四部分：需求/产品定位。
这个部分简要描述该需求/产品的用户定位和市场定位，描述清楚要解决的问题。
第五部分：需求/产品优先级。
一般情况下可以按照A、B、C、D划分需求/产品优先级，或按P0、P1、P2、P3依次降序说明该需求/产品优先级情况，以便研发工程师评估工期，如果有相关冲突项目，那么有协调项目资源的依据。
第六部分：需求内容
需求内容部分是需求文档最核心的部分，是项目开发中的主要依据。最好首先说明整个文档的框架图和产品的思路流程，内容的主体部分要详细说明每一个需求，具体说明需求的使用场景、功能描述、前置条件、处理方案、后置条件、补充说明等方面，以描述清楚需求为最终目的，当然必要时也需要附上相关的交互页面流程图，以方便文档使用者理解。
补充说明：
数据产品经理需要认识到一个问题，前期思考得再全面、再完善，需求文档也很难做到一步到位，谁也不可能保证一次把所有的问题想清楚，在完成满足交付标准的需求文档后就可以进行需求的评审。在一般情况下，会首先组织需求方评审，看需求内容以及要交付的东西能否满足用户的需求，在实际使用中会遇到什么问题，有没有其他改进意见。在这一环节之后，会进行技术评审，如果存在需求不合理或者技术难以实现的地方，产品经理会根据大家的意见进行文档修改。因此，在多轮评审环节后，产品经理进行需求文档的迭代是一件很合理的事情，要做好需求文档经过几番迭代的准备。
2.开发/测试进度把控
很多产品经理的工作内容包含项目经理的部分职责内容，需要协调开发资源，需要把控整个产品的开发进度。在需求排期确定以后，产品经理会发出项目排期邮件。
以数据产品经理小王刚完成的2.2.0版本为例，这个版本其实只是增加了3个实用的工具，采取立项的方法，时间节点有以下几个。
第一：6月20日，确认产品需求文档没有问题，各方可以按照文档逐步开发。第二：6月21日～6月28日，设计师排期可以完成设计稿，切图提交给前端研发工程师。
第三：6月21日～6月28日，这段时间前端研发工程师开发功能，等设计师把方案做出来后，6月29日～7月6日，完成前端页面开发；第一段时间为两个角色并行工作的时间。
第四：6月21日～7月6日，后端研发工程师进行后端功能开发、接口设计与开发。
第五：7月7日～7月10日，前、后端研发工程师进行程序联调，内测。
第六：7月11日～7月15日，测试工程师对产品进行测试。
第七：7月16日，封版。
第八：预计上线时间为7月17日。
从上面这个例子可以看出，虽然各个节点的时间都很明确，但是仍然会出现项目延期的情况。在大部分情况下项目中的每个人都会负责两个或者两个以上的项目，如果有临时紧急需求加入或者其他项目调整就都会影响当前项目的进度。因此在排期时，通常都会把这些因素考虑在内，在排期的时候预留出可能处理其他问题或者紧急情况的时间，做到有备无患。在把这些问题考虑进去之后，每到项目各个环节的时间节点，产品经理都需要跟进进度，确认进度是否正常，如果有项目延误风险，要及时寻找解决方案。如果项目比较重要或者紧急，还可以每天进行站立会，以天为单位跟进项目进度。项目需求一旦进入开发环节，所做的一切都是为了保证开发质量和开发进度，要尽量做到规避延期。
3.上线验收
对于上线验收环节，首先要制定项目的验收标准。一般意义上的验收标准可以从以下几个方面考虑：
（1）是否全部完成了需求文档中的需求。
（2）在测试环节中发现的重要问题是否都已经得到全部解决。
（3）紧急、严重的问题必须达到100%修复，普通级别的Bug要尽量解决，对不同的项目可以制定不同的百分比要求。对于优化型需求，可以在项目后期版本迭代完善。
（4）在验收通过后，项目组各成员如果确定自己负责的环节没有问题，就可以封版准备上线。