这篇文章想和大家讨论的是作为一个产品经理，是如何完整地完成一个项目的流程。很多产品经理日常可能都在进行以下的工作，却比较少的去完善的整理，系统的汇总！不惜的绕道，点击右上角“X”，走好不送。志同道合的产品经理们，欢迎在底部留言评论，互相进步！

目录：

1、需求设计期
1.1、需求收集
1.2、需求预拟（自行完成）
1.3、需求审核会议
2、需求跟进期
2.1、设计师环节（美术、切图）
2.2、前端/后端环节
3、测试协作期
4、线上优化期

需求设计期

需求收集

1、0-1的产品，提前做好MRD（选对竞品），MRD内容重点分析：

• 竞品的框架层级结构
• 竞品的功能点拆分
• 竞品页面布局分析
• 详情可以查看我发布的《如何利用竞品分析，快速构建新产品的框架？》

2、优化迭代的产品，收集各个需求方的需求：

• 用户（意见反馈系统，社交工具，问卷调查等）
• BOSS（BOSS的需求，可以是必要，但不一定是优先）
• 同事（主要是运营和市场）
• 自己（自身日常对产品的跟进维护和使用，让自己成为一个目标用户）

需求预拟（自行完成）

1、0-1的产品，几个重要的思考点：

• 竞品的框架层级分布，是否适合我们的产品定位；这个定位，需要根据各PM的工作来自行定义了
• 竞品的功能点，是否是我们需要的功能点
• 在上一步的基础上，细分这些功能的出发点是什么？适用的场景是什么？我们能否进一步优化，以便于更贴合我们的产品

2、迭代优化的产品，几个重要思考点：

（1）需求甄别，区分需求方的需求是需求还是一个解决方案

举个最近比较火的游戏狼人杀！用户说我想要能够通过微信邀请好友！溯源到真实情况，原来是APP中支持各种第三方登录，也支持游戏中添加好友，但是无法对好友进行实时要求，同时用户想要进行社交，不仅仅是微信，还有QQ、手机联系人等；这个时候用户的真实需求是社交+实时要求，而不是我要微信邀请！

（2）需求价值评估，对甄别后留下的真实需求进行优先级评估：

• 充分利用四象限原则，重要，紧急为必然要实现的
• 重要，不紧急，要综合考虑到时间成本问题，来确认是否要在本次实现
• 不重要，紧急，在满足重要紧急的程度下，可以去完成
• 不重要不紧急，呵呵带过

（3）如何去判断重要紧急程度，附带几个参数

• 该功能覆盖的用户数为多少？
• 如果不是相爱需求，会造成什么影响
• 需求是不是老板重视的（一个笑脸）

需求审核会议

1. 与会人员

BOSS/上级、前端、后端、产品、运营等相关人员

2. 与会内容

• 预拟的需求是否可以实现
• 再次确认预拟需求的优先级
• 评估需求所需耗时
• 对预拟需求的增减
• 确认研发进度时间表【设计师/切图/前端/后端】

3. 会后

• 进行会议整理，评估是否需要下一轮补充会议。
• 对会议内容进行输出，体现为版本迭代计划，可以以任何内部能够接受的形式/写法输出。
• 书面邮件周知，背锅，你怕了吗？

需求跟进期

设计师环节（美术、切图）

1、需求文档，内容包含：

• 设计图初稿截止日期，最终定稿截止日期。
• 页面风格需求，建议使用参照页面，便于互相理解。
• 其余特殊细节需求。诸如：什么地方需要把图片和文字切到一起。

2、当面沟通，实现目的：

• 设计师正确理解你的需求，无论是风格还是细节。
• 设计师在日期进度上和你达成一致。

3、书面邮件周知

前端/后端环节

1、需求文档，内容包含：

• 每个功能点击时，要进行什么判断【登录/未登录，注册/未注册/】。
• 每个功能点击后，触发什么样的效果。
• 对同一个功能，进行多状态操作后，界面中要怎么展示【下载/暂停/安装/卸载但是不删除安装包/卸载并删除安装包】。
• 每一个数据要读取什么地方的数据，要进行怎么样的判断转换。
• 确认出测试包的时间和最终上线日期。

2、当面沟通，实现目的：

• 技术工程师正确理解你的需求。
• 技术工程师在日期进度上和你达成一致。

3、书面邮件周知

测试协作期

1、测试用例

• 不同的项目需求不一样，根据项目的简单/复杂程度，有些项目是不需要测试用例的。测试工程师只要对照我们提交给前端的需求文档，基本就可以满足了。
• 不同的团队需求不一样，有些是产品经理编写，有些是测试工程师自行编写，个人建议产品经理在时间充足的情况下自行编写，因为最清楚产品的是你。

2、测试参与

• 产品经理要对需求进行第一轮验证，确认技术工程师完成的功能，是我们想要的需求。
• 中途完全放权给测试工程师。
• 产品上线前要对产品进行最终验证。

3、确认测试时间进度

简单来说，就是规划测试时间进度，第一轮的测试时间是XX-XXX，诸如此类。

4、最终上线，报备，还是要，邮件通知！

线上优化期

1、意见反馈系统

建议每一个产品都有一个意见反馈入口，这个对产品的线上维护和下一次版本迭代更新起到一个直接/暴力的正引导作用。

2、用户沟通反馈

去融入到你的产品用户群，游戏类APP，可以去参与到各种游戏圈。生活类APP，就去找生活圈。

3、随意测试

在测试期，无论是产品还是测试工程师，进行的是系统化/逻辑关联化测试，目的是确保新功能无BUG；有个弊端就是，比较难去注意到新功能的用户体验问题。

针对这个，就需要随意测试：在家里，在车上，打开你的产品随意点击使用，让自己成为一个真实用户，体验用户体验环节，不断的发现一些体验性而非BUG性的问题！

小结

聊一聊产品推进过程中常见的问题如何解决吧：

技术说：这个功能做不了

技术是真做不了还是不想做？

然后看看竞品实现了吗？如果实现了，麻烦你啃下来！

啃不下来，再拉两个技术一起商量对策，集思广益；

技术说：时间来不及，太赶了！

真来不及还是技术想偷懒？

想偷懒，你可以把boss和技术拉到一个讨论组，问题/进度，直接在群里互相周知

真来不及，分两个情况：

• 必须上线的功能——女的可以撒娇卖萌，男的可以称兄道弟，多培养下感情，然后，技术大大，欢迎你加班，零食已经准备好了！一切，以解决问题为导向！
• 不是必须上线的功能——能说服你的老板，那你就砍需求吧！

大概就聊这么多了！真不是打广告，有喜欢狼人杀的小伙伴吗，哈哈！

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

题图来自 Pexels，基于 CC0 协议