产品经理常犯的错误（三）需求提交了就万事大吉了？

曾经有实习生问我：“需求提交完了，好像没啥事情做了，我该做什么？”纳尼？需求提完了就大功告成，万事大吉了？那还是太天真了，这个世界可没有辣么友好的哦。需求提交了，程序猿进入开发流程，你要做的事情可多着呢！

首先，做好变更需求的准备

什么？不是说需求不要轻易变更吗？少年郎，你该听过一句话“梦想是美好的，现实是骨感的”。虽然我们都希望需求确定以后尽量不去更改需求，但更改需求的情况还是比较常见。比如你确实没有考虑到这一点，比如开发同学发现技术成本太高，再比如市场情况有了变化等等，这时候作为产品经理要做的是快速整理新的需求，判断新需求是否需要在当前版本添加或更改，尽快和开发等相关部门制定出合适的变更方案，整理更改后的文档。

不要害怕去更改需求，更改需求并不是什么丢脸的事情。记得看过一句话，从来没有改过需求的产品经理不是好的产品经理。为什么？我的理解是说明你的思维是固定僵化的，也说明你缺乏自我驱动性，完成任务就不管了，没有继续观察产品，用户和市场。

其次，准备好测试所需的文档和计划

和测试人员的沟通同样重要，需要让测试人员清楚的明确需求的目的，需求的目标人员，功能点的设计目的，一起确定需要测试的测试点。只有这样，测试人员才能更好地梳理测试用例并执行。

如果你的团队里没有测试人员，又正好不愿意雇佣外包测试人员。那么只好你自己来写测试用例，安排测试计划并且执行了。那么测试用例如何来写呢？一般测试用例包含几个方面“测试的前提条件，测试步骤，期望结果，实际结果”。所谓测试前提条件是指该功能要运行需具备的前置操作或运行。

因为没有专业测试人员，那么测试者只能是团队成员和部分种子用户了。在测试用例之外，你还需要制定一个测试计划，比如需要多少台测试机，安卓和IOS各占多少，团队成员和种子用户各占多少，如何收集整理他们反馈的问题等等。这一个计划根据各自团队实际情况而定，这里就不展开说明了。

第三，对接运营、客服、市场推广等部门

一个产品的上线和发布，后期的运营，不是只靠产品和开发就可以的，还需要依靠运营，客服、市场等部门的共同努力。因此需求提交之后，你还需要和上述部门阐明需求。主要是下面几点

1、告知重要的功能点，让运营等部门理解需求的出发点，和他们共同制定产品的推广计划和策略；

2、告知涉及用户的重要功能点，整理一份初步的Q&A，便于客服人员提前准备用户咨询话术；

3、了解市场推广部门的特殊需求，比如某个应用市场首发，比如第三方联合做的推广活动，及时响应这些需求。

理论上这些前期都要和相关部门对接，但是架不住别的部门事情多啊，计划赶不上变化之类的，这个时间点再认真确认一次还是很有必要的。

第四，整理BUG等级表，清晰描述BUG

测试之后必然会有BUG。BUG也不会少，那是不是所有BUG都得马上改呢？如果你的团队有专职测试人员，就不用你操心了。但是如果你没有专职测试，那么这事还得自己来。BUG根据严重情况列优先级，如果时间紧张，一些不影响使用的小BUG可以放到后面改。崩溃的BUG当然马上改了。

优先级列完了，你还要将BUG描述清楚，BUG出现的页面，BUG出现的场景，重现的截图或视频等等。

本期总结：

做好需求变更的准备，整理好文档；

需要和测试、运营、客服、市场推广等部门提前沟通，准备好必要的文档；

梳理好BUG优先级，清晰描述或重现BUG

我是肥寒 九年产品经理 做过数字阅读，电商，兴趣社区，正在折腾教育，欢迎关注我个人微信公众号（产品狗日记），分享九年实战心得。

【相关推荐 】

产品经理常犯的错误（一）拿到需求就开始画原型

产品经理常犯的错误（二）你不是真的会画原型

产品经理常犯的错误（四）：总想要大而全的版本

从公厕里一张图谈用户体验的“情感价值”

把自己当做用户不是让你代表用户