编辑导语：在上一篇文章《超硬干货：如何把需求变成产品方案？》中，作者从前期准备、方案设计、需求评审三个层面，为我们分享了如何把需求变成产品方案。本篇文章中，作者和我们聊一聊在评审会之后，进入到产品开发过程有哪些关注点。

上一篇文章，我给大家介绍了把需求变成产品方案过程，以及为了通过需求评审，要注意的几个点。

那通过评审会之后，我们产品要做的工作，就是推进项目、关注进度、并按时上线。所以，这篇文章，我会在“实用”的层面，从项目排期—>需求开发—>上线前体验—>产品上线，这四个步骤，给大家从介绍下，在产品开发过程中要关注点。

一、项目排期

通过评审会的需求，需要根据需求的优先级，进行资源分配，排期开发。

如果大厂的话，一般都会有项目经理来支撑这块工作；如果是中小公司的话，通常是由研发负责人来承担分配任务的角色的。此时，我们产品需要做的工作就是，关注自己需求的排期情况。

如果是较紧急的需求，或领导比较关注的需求，要尽可能需求提高优先级，为自己的争取开发资源。

在这个场景下，沟通技巧就很重要了。如果是优先级较高的需求，我的方法是：先跟对方陈述需求背景，然后强调需求尽快实现重要性，辅以领导关注的背景，将压力传递过去，提高需求优先级。

其次，在沟通时，最好是线上沟通，否则资源紧张排不上期，后面领导问起来，也有文字留档。

二、需求开发

需求排期之后，一般项目经理会通过既定渠道告诉你，你的项目已经分配到对应的开发了，那次是，我们就可以跟进需求开发的情况了。

根据经验，在开发阶段，是最容易导致需求延期的。所以，我们要利用项目管理的方法，尽可能避免出现延期的风险。总的来说，需求开发跟进过程要保证分工具体、工作量化、风险可控这三个点。

1. 分工具体：方案同步，拆解工作

首先，在开始之前，我们首先要根据需求文档，跟对应的开发阐述需求。

力求对方和自己要实现的需求预期是一致的，如果是多端合作的大需求，工作分配要具体到人的话，每项工作，每个功能模块都必须拆解出来，并以会议形式同步。

关注明确需求的负责人，将负责人落到会议纪要，并最终在项目群群里同步。

2. 量化工作：明确开发周期

在同步好方案后，就需要明确开发的开发时间。即：我们要关注谁，在什么时候开始，预期什么时候能完成。

我们团队的开发流程，一般是需要开发根据需求文档，出技术方案，然后提交到技术团队，进行内部技术方案评审，评审通过之后才能知道具体的开发工作量。

所以，在前期沟通方案时，我也会先跟对方明确技术文档完成时间和上会时间。在明确技术方案之后，再和相关同事对齐具体的开发排期，并在群里同步。

这里我有个小技巧，就是我一般会在开发评估的时间上，多加上1-2天，然后再同步出来。因为人都是会高估自己工作能力的，所以在开发过程中，很可能会超出既定预期的。

我们团队的项目经理会通过“甘特图”来明确项目的进度和落地进展。

所以，工作量如果确定下来，我们可以用上面甘特图的方式，将拆解出来的任务、预计进度、实际进度，统统进到表中。我们一般是在“腾讯文档”上，通过建立共享文档的方式，来给团队各成员同步项目进展的。

3. 风险可控：设置反馈节点，按时回收反馈

在确定好项目安排之后，就可以正式进入开发阶段了。在开发阶段，最容易出现的风险的，就是因为开发未按照预定时间开发，导致延期。

所以，我将从向下和向上的两个角度，来介绍如何让风险可控：

1）向下管理：负责的项目，及时了解项目进展

在开发过程中，我们项目根据甘特图排好期之后，还需要另外设置反馈节点，然后定期回收反馈信息，才能知道我们手里需求的开发的进度。

我如果手里有多个需求在并行的话，我每天早上和下午都分别会花1-2小时，分别跟进开发的开发进度，并且叮嘱对方，如果有发现困难需要我支持的，要及时跟我同步。

因为，在实际工作中，并不是所有开发都是很主动的，所以我们自己要主动去了解开发进展，看是否有方案上的调整，开发延期的情况。

如果有方案上的调整，尤其是涉及产品功能的调整，我们要及时用文字方式，在群里跟项目成员同步调整的原因和调整后的结果。

而后，尽快抽时间更新需求文档，明确调整时间。如果是大项目的话，可以定个一周/次的项目同步例会，以便定期和各方同步项目进展，以及遇到的困难。

2）向上管理：跟领导及时汇报进展，同步困难

在了解项目进展之后，我们也要及时和领导同步自己手中的需求进展情况，有困难要及时暴露出来。我见过一些刚入行的新同学，可能是碍于情面，不敢或不好意思跟领导说明困难，最终导致项目延期的。

其实，这是一个非常不好的“学生气”。我们遇到问题时，能够适当寻求领导支持，对工作来说，也是很重要的。

但注意，我这里说的要“适当”，是我们要注意把握“度”，遇到困难我们要先尝试自己解决，不能说每个需求都让领导支持，否则领导也会怀疑我们的工作能力。

我的习惯是会在每周的周三下午，在有领导的项目群里，@下领导和对应开发，同步开发进展、完成时间和项目困难。

我选周中是因为我预留了调整的时间，如果真有问题，周四周五可以及时调整，时间上才不会太紧。如果有人对进展或需求有问题的话，也可以及时在群里讨论解决。

这样做，除了同步进展和预留时间之外，还有一个好处：在群里通过文字留档，起到保护自己的效果。

三、上线前体验

在需求开发完成后，需求离正式上线只有最后两步之遥——产品测试和产品走查。

1. 产品测试

在需求开发完成后，首先进入测试环节。测试环节，我们首先需要在测试环境，体验产品核心流程是否符合开发预期。

然后，根据需求文档，给测试介绍整个需求的背景和需求预期，以便测试输出测试用例，这里主要是针对异常流程的测试。这里的重点是，必须让测试对产品的理解和你是一致的，否则容易出现部分异常流程没有测到的情况。

最后，就是让测试同学的工作，也要遵循在开发阶段，需求推进的三步走策略——明确分工、量化工作、风险可控这三点。

2. 产品体验走查

在这个环节，主要是针对有前端页面的需求，在产品的使用流程和前端的页面设计的走查。这部分的工作，通常需要交互和设计同学支持，看这里的体验是否符合产品设计的预期。

而在这个阶段，产品也需要和交互设计一起，体验产品的细节。这是一个非常磨炼产品人，可是却不能偷懒的工作。我见过所有优秀的产品经理，都对产品细节有极致的追求。

我一开始其实也做的不好，主要是沉不下心来做这个事，所以也经常因为粗心出过错。

但后来，我看过一本叫《清单革命》的书：书中主旨是：因为粗心出错的情况，在各行各业都比比皆是。但所有的复杂流程，都可以通过建立清单的方式，减少出错的情况。

即：把工作中所有的必做项，都列成清单，在具体实施的时候，一项项勾兑完成。这样就能极大地减少出错的情况，做到不重不漏。后来我也建立了属于自己的《上线走查清单》，从页面中从上到下要关注的细节，流程中从入口到出口的页面，逐一体验通过。

所以，我建议大家如果没有建立走查表清单的同学，也开始建立一套属于自己的清单，可以极大地减少，由于粗心导致的问题。而且，如果有问题但当前版本已经来不及调整的话，我们也可以把这个优化点放到需求池中，下个版本的规划中，再放进去。

四、需求上线

在完成上线前的测试和走查之后，需求就可以根据原定的时间安排上线了。而在上线前，可能还需要准备一些资料。

如app上线的话，需要准备一些应用商店的文件、描述、图片；或是产品内帮助中心的文档、智能客服的描述；但如果是B端产品，可能需要准备新功能的客服或销售的培训文档等。

因为产品的不同，需要准备的东西可能也不一样，这里大家要根据自己的产品或行业准备即可。当然，如果比较复杂的，也可以用上面说的清单的方式，来建立走查表。

除此之外，我还想讲两个，个人认为非常重要的点：

1. 关注数据变化：是产品优化的方向

我之前有很多需求完成之后，没有及时关注数据变化的。当时我的领导在会上有“提醒”过我，他说：有些同学工作习惯还是要加强下，产品上线后不看数据的，你根本就不知道你这个产品功能有没有用户用。你不看数据和没做需求有什么区别？

后来，我领导为了专门培养我这个习惯，隔三差五就会问我某个功能的数据情况。而后，我为了减少被领导问到的窘况，我每天早上都会花一个小时的时间，看产品数据，并尝试分析数据抖动的原因。

2. 项目复盘：不复盘=白忙活

产品的工作，失败的需求要远多于成功的需求。我们团队的产品，为了实现破圈，去年一年在产品上新增的功能，无一不是失败的。

为了增加产品留存，我们增加过游戏模块，上过签到返现能力，也弄过积分体系、会员体系，可无一被用户接受。可失败之后，我们一直在复盘，因为复盘，是我们唯一能从失败中获取的最有价值的东西。

我觉得对产品人来说，最好，也是成长最快的捷径，就是复盘。具体复盘的话，可以从整体的产品流程入手。

从前期调研—>需求分析—>方案设计—>需求开发—>产品测试—>产品运营入手，对整个项目流程进行复盘。结合当时背景、遇到问题、当时处理方式等，进行反思和总结，最终得出优化的复盘方案。

我们也可以从目标入手。对比目标预期和实际实践环节，对比差别，看到不足之处，以及如果重新做的话，我该如何优化实施环节。并且，我们还要结合产品数据表现，进行更全面的思考分析，输出优化的结论。

这样，我们的项目，才形成了一个优化迭代闭环，在下一个需求或项目时，才不会重蹈覆辙。

五、写在最后

产品需求落地的过程，就是项目管理实操的过程。

• 首先，我们要先明确项目排期，可以用背景+领导关注的阐述方式，提高需求优先级；
• 其次，需求开发和测试过程中，要遵循分工明确、工作量化、风险可控这三个原则；
• 然后，在上线前体验过程中，可以通过自建走查表的方式，减少出错的可能性；
• 最后，需求上线之后，需关注数据变化，并及时复盘，记录优化点，输出改进结论。

这样，我们才构建了一套完整的需求闭环。

本文由 @豆奶 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。