什么？产品还要被打分？

编辑导读：很多职位都有KPI考核，以此来衡量他们的工作，但是产品经理的工作很难以一个简单粗暴的标准去衡量。给一个产品打分，可以从侧面可以反映出产品经理的能力。本文将从两个方面分析如何给产品打分，希望对你有帮助。

产品经理们，你们想过这个问题吗？如何给产品打分？

这个真的很难，开发是有标准的，因为他们有明确的执行任务，最终交付的产品是之前就预设好的。

但产品经理不一样，产品设计本身就是一个开放性命题，同一个功能，每个产品经理设计出来的流程、交互效果就是不一样的，也很难说某个方案一定是最好的，何况很多时候还受限于开发的实现能力。

有的公司会把产品的业绩指标绑定到产品经理身上，这或许是一个衡量标准，但更多的时候，产品经理其实没有强标准的考核指标。

且不说调研等阶段的工作，我们对外最有力的输出是产品文档，我们先来看看完整的文档应该包含哪些内容。

一、完整原型包含哪些？

完整原型至少要包含以下5大模块：修改记录，项目介绍，功能框架图，全局说明，原型。

这些都有是不是就60分及格了呢？还不是，比如优质的文档至少要做到以下4点。

1. 没有逻辑错误

逻辑错误指前后对不上，闭环走不通，这是最致命的问题，开发会不知道怎么做，即便勉强做出来了，用户也用得云里雾里的。比如大一点的：微信端提交了订单，后台没有显示的地方；小一点的：微信端显示的自定义字段，后台却没有地方设置。

2. 逻辑清晰

逻辑要有条理，这样开发可以按着思路一步步做下来。如果逻辑比较混乱，这边写一点，那边写一点，写得又不清晰，开发实现起来就很困难，就像一团麻线一样，不知道哪里是头，要从哪里下手，也不知道下一步要做什么。

3. 少细节疏漏

要想完全避免细节疏漏是不可能的，特别是当系统做得很复杂时，一个功能点往往和其他的点有着直接或间接的联系。我们能做的是，尽可能想到所有的影响点，没有大的疏漏，小的疏漏可以在开发过程中再补充。

4. 可读性强

很早之前公司的PRD文档大多是用word写的，一个系统能写上3-4万字。每次看文档都特别累，原型图小，看不清，还要上下来回的对照页面和规则。而且一旦发生内容变更，需要重新发送给所有人，协作极其麻烦，现在有了在线文档会好一点。

后来很多公司用AXURE直接写PRD，原型旁边附上规则，可读性就强多了。产品经理内部通过AXURE协作写文档，然后上传到服务器上，只要给出链接即可，随时更新都不受影响，大大降低了协作成本。

但你会发现，这些标准更多的是让文档便于开发理解，这和一个产品的好坏并没有关系，我们构建的质量体系还应该包含对产品设计的考核。

关于这个体系如何构建，没有标准答案，我就抛砖引玉，说说我的看法。

二、如何量化产品？

我是从产品设计、文档书写，产品价值3个方面来看的，具体如下。

产品设计：

文档书写：

产品价值：

随便找个之前的文档我们来看看能得几分，大概都要负上千分了吧，所以我们的初始分是不是1000分比较合适，这样看起来不会太尴尬。

如果真的要按这些标准来考核，恐怕花费的时间和人力成本有点划不来，但是自己做个自我检验还是有利于产品的设计能力的。

题图来自Unsplash，基于CC0协议。