时间: 2021-07-30 11:39:29 人气: 14 评论: 0
上一篇 我们已经确认了 PRD 和 UI，接下来我们继续了解「研发测试」的过程。
虽然标题是叫「研发测试」，但是大家千万不要以为这个过程只有研发小哥哥和测试小姐妹的参与。是的，作为产品 owner 的产品经理和参与设计的 UI 同学都是需要参与「研发测试」这个过程的。只是产品经理参与度比较深，需要和各个角色协同沟通；UI 同学参与度稍微比较浅，大多只需要和前端沟通，保证前端同学最大还原自己的设计稿。
作为产品经理，你一定不要成为沦落到只写 PRD 或只画原型。因为如果只是纯设计，不参与开发过程，很多设计问题你完全是意识不到的。比如：我们在做操作日志的时候，有个规则是角色「管理员」可以看到所有人的操作日志，其他角色只能看到自己的操作日志。
当时，我在设计【操作日志】界面的搜索时，就是统一按照「操作人」、「操作时间」做为筛选项，但是在真正开发过程中，由于需要对「操作人」做权限判断，就稍微比较麻烦，最后经过讨论，我们将「搜索项」拆分为：
其实如果不是深度参与整个开发过程，一些设计的问题自己可能很难发现。当然，类似的例子还有很多。
那 UI 为啥要参与研发测试过程呢？
之前听过这样一个例子，领导把研发做的最终界面发到群里：“这是谁设计的界面”，群里一**寂静。做设计图的 UI 跟我讲，因为研发做出来的效果和自己的设计图完全不相符，甚至可以说是两张图，那我为什么要承认。
我不知道这位 UI 在说这句话的时候有没有意识到这个问题，但是我相信有很多 UI 面临着相同的疑惑。研发不按照我的设计图开发的时候，应该怎么做？
其实 UI 参与研发测试的过程就可以解决这个问题了，作为 UI 千万不要认为你的图做完了，你的事情就做完了。我之前一直在考虑 UI 设计的终点，是完成 UI 图？还是验收前端开发结果？甚至是跟踪线上用户反馈，并根据用户反馈改进设计？虽然我还没想到更合理的答案，但我认为从完成 UI 图到根据用户反馈改进设计，每往前走一步，对 UI 来说都是一个里程碑式的进步。
我们以瀑布开发模式为例，简单粗暴地把这个阶段分为：研发阶段和测试阶段。
研发阶段和测试阶段的分界点，可以简单通过测试人员是否介入来判断。如果测试人员没有开始测试，那就是研发阶段；如果测试人员开始测试，那就是测试阶段。
瀑布开发模式瀑布开发模式，也叫瀑布模型（Waterfall Model），是指软件开发过程是按照一系列顺序展开的，刚开始是需求分析，然后是产品设计，然后是编码，然后是测试，然后才是上线。因为开发过程是一步一步进行的，所以才被成为瀑布模型。和瀑布模型相对应的也是现在业内比较流行的是「敏捷开发」，感兴趣的小伙伴可以了解下。
（1）研发阶段
每个角色在研发阶段需要做什么：
（2）测试阶段
枯燥的流程介绍完了，我们来看下每次项目启动的紧张时刻。首先，这里是把产品的一个开发周期（或一个迭代）称为项目。
主要是产品经理准备啦，平时我都是提前准备好 PRD、UI 图，然后定好**议室，等待这一紧张的时刻到来。
每次都**提前一天左右准备好这些资料，但是在**前做最后的检查时，总是**发现这样或那样的小问题。有人告诉我，今天的设计明天在来看的时候，可能又**有新的想法冒出来。嗯，总是感觉不到最后一刻，我就不**停止修改。
所谓的项目启动，可以理解为把需要参与这个项目的人拉在一个**议室里开个**，告诉大家：
嗯，是的，这里没有说明「Deadline」。如果你定了一个 Deadline，而你的团队成员都不认可，其实这个 Deadline 是形同虚设的。我们在做项目的时候，都是在启动**之后给团队成员半天到一天的时间熟悉需求，然后让大家来领任务，然后每个人预估时间，预估完成之后进行最后的调整，并设置一个大家都认可的 Deadline 作为项目的截止时间。
有读者跟我说，你这个系列讲需求，都讲了好多篇了，从头到尾都是再讲需求。我……没办法，产品就是离不开需求，如果你不理解，只能说你还需要修炼。
由于项目启动的时候需要跟团队成员讲解需求，所以此时需求也**有小范围的调整，但是大范围的需求列表（也就是当前项目要做哪些需求，即项目的范围）是不太容易变动的。除非老板要求这个版本提前上线，我们**临时砍掉一些需求以保证上线时间。其它时候，不太容易有项目范围的变动。
换句话说，项目启动之后，需求列表就确定了，也就是俗称的「需求冻结」。需求冻结之后，不是说需求就不能改了，只是不能再增加了。
如果一味地往一个项目里增加需求，一来团队成员总觉得需求做不完，可能打击团队成员的积极性，二来项目启动其实就没什么意义了，因为开不开效果是一样的。
至于项目启动之后，需求能改动到什么程度，主要看团队成员之间的配合。如果是初次配合，不建议改。当然，这并不是意味着配合次数多了，就可以随意改。好吧，我更正上句的说法，不管是什么时候，最好不要更改。当然，从我自身的经验看，这点确实很难做到，不过，可以尽力一试～
需求的变动包括以下几种情形：
项目启动之后，大家就开始完成自己的任务了。作为产品经理，要及时和研发沟通，以免因为设计不合理或者规则不合理导致研发任务很难完成。比如：最近我们有个「结束日期不选即为至今」的需求，研发在实现的过程中就遇到了很多问题。因为在很多人的理解中，「至今 = 今天」，这样的理解**有一个潜在的规则「开始日期不能晚于今天」，否则**进入一个悖论的状态。
经过沟通，我才发现「至今」的文案不够准确，因为我想要表达的是「开始日期之后的某一天」，而「至今」在冥冥之中增加了一条规则，而「开始日期晚于今天」在业务上是合理的。比如：我们在定 OKR 或做年度计划的时候，「开始日期」肯定是**晚于今天的。这样的情况在实际工作中还**遇到很多，举这个例子只是想说明，研发过程中的沟通是十分必要的。
新人产品经理还**常犯一个错误就是，当产品经理和研发 A 沟通之后，然后就不自觉地认为已经沟通完了。但真的是这样吗？难道不需要和团队其它成员同步沟通结果吗？
刚开始工作的时候，我总**忘记和团队其它成员同步沟通结果，这就导致和 A 说过的事情，测试 B 要问一遍，项管 C 还要问一遍，沟通效率极低，而且从情绪上也**有所抵触。其实，就是在群里发个消息，一句话的事情就能解决的问题，为啥非要搞这么麻烦呢？自此，我就学聪明了。
推荐产品经理、测试、研发。
产品经理参与是为了保证测试理解的需求和自己想要的一致，因为产品最终是由测试来验收的，如果测试和产品经理理解的不一致，那最终出来的产品**和想象之中差距比较大。
为什么研发需要参与？因为测试用例和研发编写的代码息息相关。敏捷开发中有一条就是要求研发根据测试用例编码，以降低 Bug 率。
作为产品经理，免不了要跟其它部门的人合作。那怎么处理跨部门沟通的事情呢？
因为跨部门合作的时候，经常出现所谓的「责任不明确」现象，文字留底是为了保护自己。
下一篇我们将继续关注「测试与上线」，敬请期待。
好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：**色为当前进度～
一个项目带你走进产品经理的世界（5）第一个版本：MVP ？MDP ？
佐珥，微信公众号：产品碎月（ID：pm_lab），人人都是产品经理专栏作家，专注互联网产品，乐于通过幽默诙谐、图文并茂、结合实际的文字分享自己的产品经验，期望同大家一起快乐成长
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
