敏捷开发学习笔记：需求优先级方法（需求做还是不做）

转自：https://mp.weixin.qq.com/s?__biz=MzIwMDMyNTE4Ng==&mid=401739882&idx=1&sn=531e9ea49456e55a8437cd8b995c5237&mpshare=1&scene=23&srcid=0306Xub1QrGlx3FpBAAux7W1#rd

莎士比亚戏剧《哈姆雷特》中的名句“to be or not to be, that is thequestion."，描述的正是哈姆雷特遇到的困境。其实我们在软件开发中，也经常需要做这样的抉择：“这个需求做还是不做：就是这个问题”。

1. 每个需求都是为了带给我们客户和系统价值，但这个价值如何衡量？这是个问题。

2. 麻烦的是，做个需求并不是免费的，它是需要工作量的，是需要成本的。成本有多大？这是个问题。并且投入到这个需求，很有可能就没有精力投入另一个需求的工作了。还有，我们如何正确的评估工作量？

3. 最可恶的是，需求一旦提出，是有交付时间要求的。需求什么时候能够交付；这是个问题。这个很麻烦。如果我们能全职投入这个需求，或许我们能够承诺一个时间，但往往时间投入并不完全控制在我们手里，因为有多方面的需求来源，我们根本忙不过来。

怎么办？我们处在一个困境中，而且这个困境一而再，再而三重复地发生在我们的身上。遍体鳞伤之后应该有所经验了吧？我们还是需要持续学习的。本文会介绍几种办法和思路，供你参考。

1. 卡诺模型：需求必要性分析

首先，我们不仅仅要考虑实现了这个需求能带给我们的收益，更要考虑如果我们不实现这个需求又会怎么样，这就是成熟的卡诺模型方法的本质。比方说，你看到一件新衣服或者一款新手机等等，你特别喜欢，特别想买，这时不妨问问自己，如果不买会怎么样？如果不买也没什么大不了的，那就不买呗，这能防止一时的冲动。

卡诺模型的本质就是把必要性分析系统化。当接到一个需求的时候，卡诺模型建议你考虑两个问题：

1. 正面问题：如果实现这个需求，用户会有什么感觉？

2. 反面问题：如果不实现这个需求，用户会有什么感觉？
   

   
   

针对这两个问题，你会有以下其中的一种反馈：

1. 喜欢（Like）：做为用户，我喜欢（I like it that way）。

2. 基本期望（Expect）：做为用户，我觉得本来就应该是这样的（I expect it to be that way）。

3. 没感觉（Neutral）：做为用户，我没什么感觉（I am neutral）。

4. 可容忍（Tolerate）：做为用户，我可以容忍（I can live with it that way） 。

5. 讨厌（Dislike）：做为用户，我会讨厌（I dislike it that way）。

比方说，如果在手机或笔记本中，运营商或者厂商安装一些所谓的免费应用，对于这个功能，

• 如果实现的话，用户会很［讨厌］，很反感。

• 如果不实现这个需求，反而你觉得是一个［基本期望］，本来就是应该这个样子的。 

再比方说，一个手机能够非常智能的帮你美拍。

• 如果实现这个需求，用户会很［喜欢］。

• 如果不实现的话，用户有可能觉得［无所谓］。
  

  
  

如图所示：不同的需求会有不同的正反面的反馈。横轴表示假如没有这个需求，用户的态度是什么；竖轴表示假如有，用户的态度又是什么，两者交叉就得出了这个需求的用户价值，这样就能帮助我们更客观地决策：这个需求，做还是不做的问题。

在每个交叉点，卡诺模型区别需求必要性的类别如下：

1. 有吸引的－Attractive（A）

2. 必需的－Must-be（M）

3. 正向的－One-dimensional（O）

4. 无所谓：Indifferent（I）

5. 反向：Reversed（R）

6. 可疑：Questionable（Q）

按照卡诺正反面矩阵，我们刚才的例子可以区分为：

• 免费应用属于［反向］需求

• 美拍功能属于［有吸引的］需求
  

在开发一个产品的时候，应该先实现［必需的］需求，然后［正向的］需求，然后［有吸引的］。

1. ［必需的］需求不实现不行。一台手机不能够通话是不行的。

2. ［正向的］需求往往是性能需求，性能越好，用户越喜欢。当然，哪些性能指标要达成，达到什么程度，那是由【必需的】需求来商定的。

3. ［有吸引的］需求能给产品添增一些点缀，给用户一种友好的感觉。
   

2. ROI需求性价比分析

在文章的开头，我说过做一个需求是有代价的，是需要成本和投入工作量的。在考虑需求和必要性的时候，两个需求之间，哪个优先级比较高，不仅仅要考虑它的价值，还要考虑它的成本和工作量。

1. 两个需求，如果工作量一样，选择价值比较高的。

2. 两个需求，如果价值是同等，选择工作量比较低的。

3. 如果两个需求工作量和价值都不同的话，我们可以考虑他们的性价比（ROI－Return On Investment）。
   

工作量可以通过故事点、功能点、理想人天等来评估。不管大家对工作量的评估能力如何，准确性如何，大家应该有工作量评估的经验。但是，对于价值这方面，相信大家相对比较陌生。性价比（ROI）排序使用的前提是一个价值体系。

每个产品都是为了解决不同的问题，所以价值定义也不同。我简单的介绍一个供参考价值维度的定义:

1. 目标符合度：每个产品通常有些规划的演进方向，这个需求是否符合演进方向。

2. 有用度：这个需求对用户有多大的用途。

3. 好用度：使用这个需求的时候，用户必需要费多少力。
   

以下表格以一个类似Instagram的社交分享的应用为例。对每个维度，你可以简单的打个分。

比方说，“美拍功能”已经在今年的规划当中，所以目标符合度很高。相反的，“黑白照相”不在规划中，所以相对低。“一键式分享上传”对用户非常有用，而且能提高用户体验（好用），所以在这两个维度它的分数是很高的。综合价值是三个维度的乘法。性价比是综合价值除以工作量。从这个例子，你可以看到“一键式分享”的性价比远远超过其他需求，所以就立刻把它实现吧！

3.  容量分配和预测

团队的开发投入不仅仅是一直增加新功能。他们也必需投入一些技术的演进预研（比如从Java7升级到Java8，从SQL数据库升级到NoSQL数据库）。功能和技术演进基本上是两回事，该如何比较呢？解决这个问题的办法就是通过容量分配。比方说，每轮迭代分配50%的时间开发新需求，20%的时间进行架构优化，30%用来解决遗留问题。

这样一来，不同的新需求相互之间排序，架构优化工作相互之间排序，遗留问题相互之间排序。

不同种类的工作比重可以按照实际情况调整。以下图例是当前一个迭代和后续三个迭代的容量分配预测。有这样的预测，你才能够有一个或许可靠的需求完成时间预测。

不可回避地是，需求的实现，客户或领导是有交付时间要求的。往往这个时间要求是完全不考虑你当前在忙什么，当前有多少时间安排来实现他的需求。需求方和领导觉得他有你百分之百的时间，可是，事实上并不是这样的。容量预测就是解决这个问题。当然，这个容量预测必须透明化。每轮迭代有可能交付的需求和他们的工作量也必须透明。只有在这样一个公开环境的基础上，双方（需求方和实现方）才能够共同的向上改进。

4. 要点总结

软件开发中，需求管理是非常关键的。在这篇文章当中，我介绍了几种方法，我肯定它们能够在你的运作当中派上用场。

1. 卡诺模型考虑，某个需求不做又会怎么样。

2. ROI性价比排序，有工作量作为分母，促进需求的最小化。

3. 容量分配，把团队能够做的事透明化，减少需求方不合理的压力。