需求评审的维度与评分体系

作者：张鑫
链接：https://zhuanlan.zhihu.com/p/22342843
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

今天给大家一个思维工具，程序员们可以拿去用于评价一个产品需求是否靠谱。

这个既可以用于程序员与产品经理之间的日常沟通，也可以用于公司中流程化的需求评审，甚至可以建立评分体系做大团队的数据分析。

评估需求的三个维度

研发人员对于产品需求的评估可以分为三个维度：

价值认同 - 对用户有没有价值，投入产出比怎样

需求质量 - 需求是否易于理解，细节有没有说清楚，逻辑是否成立

技术可行性 - 能不能做，成本多大规模，有多大风险

对一个需求的评价分成独立且互斥的三个维度之后，开发与产品的交流就会更全面了。当我们说产品经理的需求靠谱或者不靠谱的时候，往往是指三个维度中的其中一两个维度。

举个例子，如果产品经理提出需求要在六一儿童节那天把所有用户的昵称都加上宝宝俩字，研发可以这样答复：

“需求我是理解的（需求质量 - 高），但是擅自修改用户的昵称不符合用户利益，还可能有法律风险（价值认同 - 低），改全部用户昵称实现起来有难度，我需要跟其它开发一起调研一下（技术可行性 - 低）”

分维度评分体系

我们在评估需求时，可以分别对三个维度进行量化评分。做量化评分有两个目的，一方面能让研发的评估结论更严谨且明确，另一方面，有了量化评分之后我们能做数据分析，比如横向对比每个产品经理的需求质量分布。

可以参考下面的评分标准，范围0-5，中位数为3。

价值认同：

0 - 完全不认同该需求的价值，不可能投入开发

1 - 价值有限，投入产出不成比例，不同意现阶段投入开发

2 - 保留意见，需要探讨

3 - 基本认同，可以投入开发

4 - 比较认同

5 - 非常认同

需求质量：

0 - 不可接受

1 - 需求质量很差，重新梳理之后再评审

2 - 有产品BUG/逻辑不清晰/有重要遗漏/难以理解，需要修改

3 - 基本可以理解，需要补充细节

4 - 需求质量较好

5 - 质量很好

技术可行性：

0 - 无法实现

1 - 难度较高，部分功能可能无法实现，需要调研

2 - 有一定难度，成本较高

3 - 常规项目

4 - 容易实现，或者不需要发布

5 - 不需要开发

每一个可能进入开发的需求都要有研发团队的评分结果，这个结果可以作为需求文档的附录记录下来，评分也要随着实际情况动态更新。

还是举儿童节给用户昵称加宝宝的例子，如果按评分体系去评估的话，可能是以下结果：

价值认同：0 - 擅自修改用户资料，违背用户利益，很可能有法律风险，不同意进入开发

需求质量：4 - 已经理解了需求

技术可行性：1 - 更改全体用户的昵称，实现有难度，需要讨论方案

这样一来研发团队对于这个需求的态度就已经很明确了。

总结

建立了评价需求的三个维度之后，开发者就可以与产品经理更全面地沟通。在此基础上，我们可以建立评分体系，使得结果更严谨、更明确。评分结果记录汇总之后还可以做团队数据分析。

数据分析方面的经验我会在后续的文章中具体展开。希望三个维度和评分体系会对你有用。