上一篇 我们已经确认了 PRD 和 UI，接下来我们继续了解「研发测试」的过程。

研发测试

这个阶段的参与者？

虽然标题是叫「研发测试」，但是大家千万不要以为这个过程只有研发小哥哥和测试小姐妹的参与。是的，作为产品 owner 的产品经理和参与设计的 UI 同学都是需要参与「研发测试」这个过程的。只是产品经理参与度比较深，需要和各个角色协同沟通；UI 同学参与度稍微比较浅，大多只需要和前端沟通，保证前端同学最大还原自己的设计稿。

作为产品经理，你一定不要成为沦落到只写 PRD 或只画原型。因为如果只是纯设计，不参与开发过程，很多设计问题你完全是意识不到的。比如：我们在做操作日志的时候，有个规则是角色「管理员」可以看到所有人的操作日志，其他角色只能看到自己的操作日志。

当时，我在设计【操作日志】界面的搜索时，就是统一按照「操作人」、「操作时间」做为筛选项，但是在真正开发过程中，由于需要对「操作人」做权限判断，就稍微比较麻烦，最后经过讨论，我们将「搜索项」拆分为：

• 当前登录用户非管理员时，只有「操作时间」；
• 当前登录用户为管理员时，「搜索项」为：「操作人」、「操作时间」。

其实如果不是深度参与整个开发过程，一些设计的问题自己可能很难发现。当然，类似的例子还有很多。

那 UI 为啥要参与研发测试过程呢？

之前听过这样一个例子，领导把研发做的最终界面发到群里：“这是谁设计的界面”，群里一片寂静。做设计图的 UI 跟我讲，因为研发做出来的效果和自己的设计图完全不相符，甚至可以说是两张图，那我为什么要承认。

我不知道这位 UI 在说这句话的时候有没有意识到这个问题，但是我相信有很多 UI 面临着相同的疑惑。研发不按照我的设计图开发的时候，应该怎么做？

其实 UI 参与研发测试的过程就可以解决这个问题了，作为 UI 千万不要认为你的图做完了，你的事情就做完了。我之前一直在考虑 UI 设计的终点，是完成 UI 图？还是验收前端开发结果？甚至是跟踪线上用户反馈，并根据用户反馈改进设计？虽然我还没想到更合理的答案，但我认为从完成 UI 图到根据用户反馈改进设计，每往前走一步，对 UI 来说都是一个里程碑式的进步。

每个角色在当前阶段都需要做什么？

我们以瀑布开发模式为例，简单粗暴地把这个阶段分为：研发阶段和测试阶段。

研发阶段和测试阶段的分界点，可以简单通过测试人员是否介入来判断。如果测试人员没有开始测试，那就是研发阶段；如果测试人员开始测试，那就是测试阶段。

瀑布开发模式瀑布开发模式，也叫瀑布模型（Waterfall Model），是指软件开发过程是按照一系列顺序展开的，刚开始是需求分析，然后是产品设计，然后是编码，然后是测试，然后才是上线。因为开发过程是一步一步进行的，所以才被成为瀑布模型。和瀑布模型相对应的也是现在业内比较流行的是「敏捷开发」，感兴趣的小伙伴可以了解下。

（1）研发阶段

每个角色在研发阶段需要做什么：

• 产品经理：跟踪研发过程，合理调整需求；
• UI：跟踪前端开发过程，合理调整 UI 设计；
• 研发：设计数据库 + 定接口及编写接口文档 + 编码 + 单元测试；
• 测试：整理测试点和测试用例。

（2）测试阶段

• 产品经理：跟踪测试过程，评估 Bug 优先级、是否需要在当前版本修改、以及修改建议；
• UI：对前端开发成果予以验收，并提出具体的改进意见；
• 研发：改 Bug；
• 测试：发现 Bug + 发版。

项目启动

枯燥的流程介绍完了，我们来看下每次项目启动的紧张时刻。首先，这里是把产品的一个开发周期（或一个迭代）称为项目。

项目启动时要准备什么？

主要是产品经理准备啦，平时我都是提前准备好 PRD、UI 图，然后定好会议室，等待这一紧张的时刻到来。

每次都会提前一天左右准备好这些资料，但是在会前做最后的检查时，总是会发现这样或那样的小问题。有人告诉我，今天的设计明天在来看的时候，可能又会有新的想法冒出来。嗯，总是感觉不到最后一刻，我就不会停止修改。

项目启动时要说什么？

所谓的项目启动，可以理解为把需要参与这个项目的人拉在一个会议室里开个会，告诉大家：

1. 我们要开始做这个项目了，嗯，只是告知。
2. 为什么要做这个项目？
3. 这个项目的目标是什么？
4. 这个项目要做哪些功能？

嗯，是的，这里没有说明「Deadline」。如果你定了一个 Deadline，而你的团队成员都不认可，其实这个 Deadline 是形同虚设的。我们在做项目的时候，都是在启动会之后给团队成员半天到一天的时间熟悉需求，然后让大家来领任务，然后每个人预估时间，预估完成之后进行最后的调整，并设置一个大家都认可的 Deadline 作为项目的截止时间。

需求的冻结与变动

项目启动，又见需求

有读者跟我说，你这个系列讲需求，都讲了好多篇了，从头到尾都是再讲需求。我……没办法，产品就是离不开需求，如果你不理解，只能说你还需要修炼。

由于项目启动的时候需要跟团队成员讲解需求，所以此时需求也会有小范围的调整，但是大范围的需求列表（也就是当前项目要做哪些需求，即项目的范围）是不太容易变动的。除非老板要求这个版本提前上线，我们会临时砍掉一些需求以保证上线时间。其它时候，不太容易有项目范围的变动。

换句话说，项目启动之后，需求列表就确定了，也就是俗称的「需求冻结」。需求冻结之后，不是说需求就不能改了，只是不能再增加了。

如果一味地往一个项目里增加需求，一来团队成员总觉得需求做不完，可能打击团队成员的积极性，二来项目启动其实就没什么意义了，因为开不开效果是一样的。

至于项目启动之后，需求能改动到什么程度，主要看团队成员之间的配合。如果是初次配合，不建议改。当然，这并不是意味着配合次数多了，就可以随意改。好吧，我更正上句的说法，不管是什么时候，最好不要更改。当然，从我自身的经验看，这点确实很难做到，不过，可以尽力一试～

需求必须要变动，怎么办？

需求的变动包括以下几种情形：

1. 减少现有的需求列表删需求对大家来说都是一件好事，毕竟大家都可以少做点工作。不过，决定做这件「皆大欢喜」的事情时，还是需要跟团队成员解释为什么要这么做，让团队成员之间不要有误会，也不要有不信任。毕竟，你想，万一人家刚做完，你就给人把需求砍了，这谁心里会舒服啊。
2. 调整现有需求列表的细节最好能不调整，但是如果真的要调整，最好在沟通需求的时候就说明「这里还需要确认，后续确认之后再沟通……」，让团队成员心里有底。如果后续真的需要调整，大家心里也会稍微舒服点，同时，提前沟通好后续可能会有的变动，大家在预估工作时间的时候也会留有余地，免得后续因为需求的调整使得某位成员加班赶工期而导致其心里不痛快。
3. 增加需求相对来说，「增加需求」这一点最难处理。如果你直接以「老板说的」为借口，其实还是很好处理的。但是久而久之，会给别人一种「你没有独立思考能力」的感觉，因为你凡事都是「听老板的」。我现在能想到的更合理的做法是，先「讲道理」说明为什么一定要这么做，然后「重新评估需求优先级」，因为有需求临时「加入」，看有没有哪些需求可以临时移到下一个版本。这样经过调整之后，大家心里稍微舒服些。同时，万一真的没法把其它需求移到下一个版本，大家也稍微能理解。

研发过程沟通

为什么要沟通？

项目启动之后，大家就开始完成自己的任务了。作为产品经理，要及时和研发沟通，以免因为设计不合理或者规则不合理导致研发任务很难完成。比如：最近我们有个「结束日期不选即为至今」的需求，研发在实现的过程中就遇到了很多问题。因为在很多人的理解中，「至今 = 今天」，这样的理解会有一个潜在的规则「开始日期不能晚于今天」，否则会进入一个悖论的状态。

经过沟通，我才发现「至今」的文案不够准确，因为我想要表达的是「开始日期之后的某一天」，而「至今」在冥冥之中增加了一条规则，而「开始日期晚于今天」在业务上是合理的。比如：我们在定 OKR 或做年度计划的时候，「开始日期」肯定是会晚于今天的。这样的情况在实际工作中还会遇到很多，举这个例子只是想说明，研发过程中的沟通是十分必要的。

讨论出结果，就结束了吗？

新人产品经理还会常犯一个错误就是，当产品经理和研发 A 沟通之后，然后就不自觉地认为已经沟通完了。但真的是这样吗？难道不需要和团队其它成员同步沟通结果吗？

刚开始工作的时候，我总会忘记和团队其它成员同步沟通结果，这就导致和 A 说过的事情，测试 B 要问一遍，项管 C 还要问一遍，沟通效率极低，而且从情绪上也会有所抵触。其实，就是在群里发个消息，一句话的事情就能解决的问题，为啥非要搞这么麻烦呢？自此，我就学聪明了。

测试用例评审

谁要参加测试用例评审？

推荐产品经理、测试、研发。

产品经理参与是为了保证测试理解的需求和自己想要的一致，因为产品最终是由测试来验收的，如果测试和产品经理理解的不一致，那最终出来的产品会和想象之中差距比较大。

为什么研发需要参与？因为测试用例和研发编写的代码息息相关。敏捷开发中有一条就是要求研发根据测试用例编码，以降低 Bug 率。

跨部门沟通

作为产品经理，免不了要跟其它部门的人合作。那怎么处理跨部门沟通的事情呢？

• 首先，你需要知道哪些点上是需要跨部门合作的？
• 其次，这些点是完全依赖对方的工作的吗？如果是强依赖，那就要求对方完成之后，我们才可以开始。如果不是强依赖，双方就可以同步进行。
• 最后，一定要沟通清楚对接的具体内容和具体的时间点，并文字留底。

因为跨部门合作的时候，经常出现所谓的「责任不明确」现象，文字留底是为了保护自己。

下一篇我们将继续关注「测试与上线」，敬请期待。

好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：黄色为当前进度～

相关阅读

一个项目带你走进产品经理的世界（1）：从收到一个需求谈起

一个项目带你走进产品经理的世界（2）：需求分析

一个项目带你走进产品经理的世界（3）：从用户需求到产品功能

一个项目带你走进产品经理的世界（4）：产品规划

一个项目带你走进产品经理的世界（5）第一个版本：MVP ？MDP ？

一个项目带你走进产品经理的世界（6）：设计确认

#专栏作家#

佐珥，微信公众号：产品碎月（ID：pm_lab），人人都是产品经理专栏作家，专注互联网产品，乐于通过幽默诙谐、图文并茂、结合实际的文字分享自己的产品经验，期望同大家一起快乐成长

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议