产品规划：中、大型公司的PM沟通瓶颈

首先我们来定义一下“中、大型互联网公司”：一般200人以上，各部门配置健全，融资处于B轮或以上。

如果你正在这种公司担任PM，那么恭喜你，你可能遇见过以下问题：

• 协同办公平台上显示你们的开发人员将某项网页开发任务标注为“已完成”，这比你的预期提早了不少。但当你测试该功能时发现，手机上适配不了！（你才想到你忘记强调移动端需要适配）
• 客服部门发现了一条看不懂的用户反馈，并找到你，希望调取该用户的信息（你才想起那是你们没有删除的测试数据）
• 设计部门为你做了一个精美的幻灯片，用于会议展示（你意识到你忘记告诉他们你需要的只是一个功能验证测试，只要前端能看懂就行）
• 经过1周的测试，BI部门终于发现他们没法完成你需要的数据分析报告，因为他们没有采集正确的数据指标（史诗般的失败，重来吧）……

对于百万级用户的产品来说，产品质量、进度风险、开发周期等等都是由无数个细节决定的。

这对于大型甚至中型公司来说，就是对团队的沟通提出了更高的要求：

• 强迫批判性思考，确保沟通细节没有纰漏
• 多部门的协同与沟通，对时间周期有全局观念
• 提高问责性，哪个部门、什么工作、做到什么程度、具体负责人是谁……

其实所有这些需要的就是一份Product Spec.（产品规范）

一、什么是产品规范？为什么要写产品规范？

产品规范（Product Spec.）可以看成是一张蓝图，用来描述你们正在设计什么产品，为谁设计，以及各个环节交付和结果应该是什么。

很多人在听到“规范”这两个字的时候都会忍不住抱怨，因为他们觉得这东西根本没有人会读，却要浪费好几个星期来写。

其实不是这样的：

• 一个好的产品规范是清晰明确的，它为用户、业务需求和其他标准提供相关叙述，帮助产品经理在设计和构建解决方案时做出明智的决策。
• 撰写产品规范根本不是白费功夫，恰恰相反，它能大大帮你节省很多不必要浪费的时间。
• 有效的产品规范是搭建出优秀互联网产品中至关重要的一部分。它会带领你的团队开启批判性思维，量化所有沟通，并提升你们的可信赖度，由此获得更高的产品质量、更低的规划风险和更少的时间浪费。

合格的产品规范应当回答以下问题：

• 我们在开发什么？以及为什么开发？
• 最终的产品是什么样？
• 成功的标准是什么？

下面我们将为你介绍来自Janna Bastow的5步法完成product Spec.

二、设计过程中如何完善产品规范？

注意，这不是从0开始的教程，而是提供核心思路，以“如何提升沟通力”为出发点的5步。

第一步：从用户反馈和数据中寻找问题

寻找问题的最佳去处便是——用户反馈。

用户反馈有很多种形式：抱怨、提问、产品建议和功能要求。面对各种各样的用户反馈，最重要的是不要只看字面意思。

用户提出的不是一条指令，反馈中的每一件事项都是一个能帮助你深入问题根本的数据点。

一些有助于寻找问题的问题：

• 所有这些反馈的背后是什么？其中隐含的问题是什么？
• 有很多用户提出这个要求吗？用户需求有多大？
• 这个问题有多重要？是否会让你很难获得未来的更多用户？
• 它会否阻碍你获得更多用户或订单？

第二步：把问题拆解成一系列假设

这是强迫你批判性思考的好方法：

用户反馈的问题到底有多大？在这一步，你将继续认识你面对的问题范畴。

受到用户反馈的启发，你可能会开始彻底地把检验流程过一遍，之后你肯定会产生很多各种各样的想法。

但是这些想法不一定都有意义，你可以通过以下三种划分方式来给它们归归类：

• 必不可少的：这是类似MVP的东西。如果没有它，什么都白搭。
• 值得拥有的：不是必要的，但是可以为用户带来所见即所得的价值。
• 让人高兴的：撒在雪顶咖啡最上面的巧克力屑，能让人会心一笑的小东西。

通过这样的方式，你依然可以站在完整的视角看待问题，只不过，必不可少的东西才是你的最高优先级，其他所有都要等它完成了再说。

第三步：在你的团队开展产品讨论

“撰写产品规范是干掉所有恼人的大大小小设计抉择的最好办法，即使是最微小的分歧也可以被一份产品规范解决。”Frog Creek Software的Joel Spolsky如是说。

道理人人都懂。但是，那些微小的决定会累积，而当它已经稳坐在你的积压待办当中的时候，就没有人愿意来挑头解决掉它了。

屡见不鲜的一个错误就是当产品规范已经在制作中了却还把讨论都拖到最后——你必须创造出一个空间，以便你的团队可以在想法成型的时期就开展讨论。

现在就开始邀请你周围的同事，让他们帮你把想法润色好。一个高效产品团队的关键特点是能够打开话题，围绕什么需要完成以及怎样完成进行产品讨论。

第四步：和你最亲近的顾客做用户测试

目前为止，你做的所有事在纸上看起来都挺像回事的，但实际怎样就不得而知了。

现在就是检验你的假设是否成立、你的用户是否会按照你想像的方式做出反应的时刻了。

用户能完成你给出的任务吗？他们能轻松找到那些按钮吗？他们清楚自己看到的都是什么吗？

之后你通常会发现有些假设是错误的，按钮没有那么好找，或者操作流程没有你想的那么直观。

不过你也可能发现一些惊喜：

• 极端案例
• 意外要求
• 被误读的功能
• 被拓宽或改变的视角

第五步：如果一切就绪，发送给开发

即便开发过程中一切都进行得完美无缺，到了质检环节就又是另一回事了。一旦你开始到处随便点击，你很可能就会发现一些被遗漏掉的细小问题。

不要害怕查漏补缺。直到我们成为最好的自己，这会一直持续发生。完美需要时间。

当你自信地认为你实现了想要的效果，再加上最后一笔：最终原型、技术信息、关键情景等等。

搞定！

———— / END / ————

作者：七日辑（微信公众号：七日辑），在线项目式学习课程平台，帮助你七天完成一个小目标