时间: 2021-07-30 11:39:13 人气: 3 评论: 0
关于需求的优先级评定一向是产品人工作中的重要部分，但现在大多数产品经理的优先级评定都是看经验原则、看感觉。这难免**导致某些错误评估。笔者告诉我们，可以通过阿姆达尔定律更加科学地评估优先级。
需求管理是产品日常工作中很重要的一部分，在项目中**接触到各种各样的角色，产品用户、付费用户（在企业应用服务、教育行业中付费用户与体验用户是两个角色）、老板、运营、客户等等…..**花式提出各种的要求。
按照传统的方法去调研时，得到的场景往往是这样的：
产品——请问哪个问题最重要呢？
需求方——都重要！
产品——请问哪个问题最紧急呢？
需求方——都紧急！
面对有限的研发资源，最后自己扣着脑袋根据用户使用频次、重要紧急程度拍脑袋决定。殊不知需求优先级是一个项目开始阶段最重要的环节，直接影响了项目研发进度以及团队的精力分配。
特别是在各个市场都充分竞争的今天，我们提供给客户的不仅仅只是一个软件，而是一种服务，一种解决用户某种问题的服务能力。SaaS-软件即服务，PaaS-平台既服务，IaaS-基础设施既服务，企业都渐渐将自己提供的各种能力定义为了服务，而不再是原来的软件、平台、基础设置。
这就要求我们在定义产品时，不能仅仅局限在软件维度，不然就像市面上很多打着xxaS口号的产品，只有功能，没有服务，最后在竞争中落败。
划分服务优先级时，要有下面的意识：
不是所有的问题都需要通过软件解决，目的是提高整体服务效率，软件只是一种方法。
服务是由整个团队提供的，涉及市场、售前、销售、产品、运营、研发、售后等多个环节，不能只专注于自己眼前的产品工作。而我们设计的也不仅仅再是一个个功能点，而是一串完整的业务流，用于解决用户的某一个问题。
那具体如何划分呢，大家根据常用的需求优先级划分的工具如 KANO模型、波士顿矩阵、四象限（这里就不一一介绍了，感兴趣的大家可以自行百度）等方法也可以将需求划分为P0到P3四个等级，可当项目复杂度很高，发现N多需求都是P0时，到低先做哪个后做哪个呢？
这个时候更多的是依靠二八法则、核心业务优先、投入产出比等经验原则来做判断，更多的是依靠大家的工作经验以及积累，对于新的项目和业务更多的是凭感觉……但我们设计的一个个业务流的目的是提升我们服务客户的效率，凭借感觉往往是不可靠的。
划分需求优先级本质上是需要一个To Do List，而排序的标准是依照“效果”这里我为大家介绍一个方法——阿姆达尔法则。
阿姆达尔在设计计算机时，意识到要使计算机整体性能最佳，计算机各个部分的性能必须平衡，才能使整体性能最佳。
同样地，我们提供服务时，内部各个业务流的效率必须平衡，才能让整体服务效率最佳。具体的计算公式如下：
公式左边：
S（大写）：在做出某项改变（迭代了某个功能）后，系统整体的效率提升。
公式右边：
下面以计算机系统为例：
假设计算机运行某个程序，其中内存的读写访问占了计算机程序运行20%的时间，如果你把内存运行速度提升到原来的2倍，那么整个计算机性能提升多少呢？
按照定义可知：
按照整体效率提升效果，排定需求优先级，下面再以计算机系统为例：
假如内存读写占用程序运行时间的20%，处理器运算占60%。今天有两个技术，一个可以将内存读写速度提升到现在的6倍，另一个可以将处理器的速度提升到现在的150%，由于成本的限制和研发时间的限制，下一个版本只能采用一项改进。应该选用哪个？
停留60秒，思考下如何决定？
直观的数据感受，内存读写是提升到现在的6倍，处理器是提升到现在的150%。很多人**选择内存技术。阿姆达尔法则给出的结论则恰恰相反。
S（处理器）＞S（内存）得出了和我们直觉相反的答案，此时应该选择提升处理器的技术。
将这个公式带入到我们日常的需求优先级评定中，哪些环节最先需要优化是不是一目了然。同时这里我对公式做了一点调整，公式仅考虑了效率提升，而没有考虑到成本投入，这时只要将公式两边同除以投入的工时，就得到了两个需求每投入一个工时，对整体效率提升的百分比，同样以上面的计算机系统为例：
假设提升内存技术需要投入研发人力“2人天”提升处理器技术需要投入研发人力“3人天”。
此时对比投入效率又应该选择提升内存技术。
每一个项目都面临着时间紧、任务重、预算有限的情况，合理的评定优先级可以帮助大家在推进过程中找到主线，确定需求边界，在沟通时减少内耗，让大家逐步建立信任，使项目推进井井有条。
否则大家**陷入到无尽的进度跟踪当中去，无法自拔。
最后，优先级是根据业务进度动态调整的，不要沉迷于工作流而忽略了你的用户。
作者：萌面赵先生，个人公众号：G_Gluck
本文由 @萌面赵先生 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
