需求管理做不好，等着9-12-7吧

在实际工作中，大家很少有机会经历从0到1的项目，绝大多数情况是加入到一个已经发展了一段时间的团队，参与维护已经运行了几年的项目。

回想起来，我这几年来经历过多种多样的项目：从0到1的项目、已经成熟处于维护期的项目、需要重构的核心项目、需要一步步废弃和下线的项目等等，可以说是项目经验十分丰富了。

经历了这些项目之后，我认为，站在开发团队的角度，评判一个软件项目成败的因素，最关键的就是两个点：需求管理和可行性分析。

• 需求管理做不好，体现在两个方面：需求分析不足、需求随意变更，这会让开发团队做一些臆想的、半成品的需求，做到一半发现没想清楚，然后陷入到边做边改、边改边做的魔咒。
• 可行性分析做不好，会让开发团队为了一个不可实施的方案去努力，最终获得的不是成就感，而是挫败感。

今天这篇文章，是我阅读和学习《软件工程之美》中关于需求的两篇文章写的阅读笔记，主要想学习下宝玉老师对需求管理的看法。下面这张图，是我针对文章的内容梳理的脑图：

阅读摘抄

1. 需求是整个产品的源头，所以说需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求，可能就会一步错，步步错！
2. 产品需求是在分析提炼用户的真实需求后，提出的符合产品定位的解决方案。
3. 软件项目的需求不是一个需求，而是一系列的需求，所以软件项目的需求分析需要使用下面这几个迭代循环的步骤：收集需求、分析需求、评估需求、需求设计、验证需求。
4. 用户需求背后的真实需求有三个层次：表层需求，用户对解决问题的期望，例如马车更快；深层需求，用户的深层次动机，诉求产生的原因，例如对出行速度的要求；底层需求，人性本能的需求，这里还可以参考马斯洛需求层次理论。
5. 评估需求的优先级，可以使用“紧急重要四象限法”来区分，在项目中要优先做紧急重要的事情，再做不紧急但是重要的事情，这个理论同样可以用于个人的工作内容管理。
6. 在软件工程中，还有一个专业的模型，可以用来评估需求的优先级——kano模型。它把需求分成三个类型：必备属性、无差异属性和魅力属性。

• 必备属性来说，是你必须优先做好的，你不做好，客户就会不满意，你做好了，客户的满意度只能达到基本的水平；
• 无差异属性来说，它的客户满意度增长曲线是线性的，也就是说，做到一定程度，对客户的满意度提升就趋于0了，例如，某个场景的可靠性只需要做到3个9，你努力做到5个9，其实对客户的满意度提升并没有很明显的作用；
  
• 魅力属性，属于客户自己没想到，你帮客户发现了他之前没有意识到的需求，iphone的出世就属于这种需求的例子。

1. 在需求变更这件事上，没有赢家，每个人都是受害者
2. 对于软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了，所以我们要多去分析、归纳、总结背后的逻辑，这样遇到类似的问题，才可以做到对症下药，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。
3. 需求变更的管理，作者提出了三个解决方案

• 提升需求确定性，减少需求的变更。这种方案的优势是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求高；
• 提升需求变更的成本，规范需求变更流程，减少需求变更的频次。这种方案的优势是可以立马起到效果，缺点是过于繁琐的流程不利于项目协作。
• 降低响应需求变更的成本，积极响应需求变更。这种方案的缺点是对软件架构和项目管理要求比较高。

阅读心得

1. 你了解AB测试吗，有在项目中使用过AB测试吗？听说过AB测试，但是没有再实际项目中使用过。目前公司的基础设施支持蓝绿部署，可以很方便得进行AB测试。
2. 极客时间的课程为什么要支持音频？从读者角度来考虑，主要是为了解决用户有一定自己的时间，但是又没有办法阅读的场景，例如：上下班开车路途中；从专栏作者角度考虑，有些话用文字和图片写出来，可能还需要再配合着讲解一遍，效果会更好。另外，支持音频，也增加了作者和读者之间的另一种沟通媒介，提升了读者的用户体验，例如有些专栏会将“作者口述”作为一个卖点来推广。
3. 你工作中有没有遇到因为需求分析没有做好而导致项目失败的案例？有，边改变做、边做边改的感觉太酸爽，最后项目虽然推进到了下一个阶段，但是团队的士气不可避免得受到影响。
4. 你参与的软件项目中，需求变更多吗？有多有少，都经历过。
5. 你们是怎么管理需求变更的？文中提到的三种方式，我们主要使用的方案1+方案2，目标是使用方案3。在做需求分析的时候，我们一定会有需求评审阶段和会议，提升需求的确定性；做需求变更的时候，我们会在需求迭代会上进行评估，提升变更的成本。不过对于技术团队来说，如果只是满足于使用这两个方案应对需求变更，那是不够的，因此，我们团队的目标是利用方案3，在产品中可能经常变动的地方提供配置化的能力，灵活响应需求的变更。

广告时间

这门课已经进行了三分之二，这是我的第9篇读书笔记，说实话，对我的帮助非常大，在工作多年后进行了一次软件工程理论的回炉重造。在这段时间，我有时候会在实际工作中应用在这门课中学到的方法和技巧，对于我的工作效果提升也很大。你是不是在软件项目中被各种琐事缠身，但是又不得其法，这门课应该可以提供一定的理论指导。

在这篇文章中，宝玉老师提到，解决需求变更的第三个方案是：积极响应需求变更，提供配置化的软件架构方案，但是对软件架构和项目管理的要求很高。这里说到了软件架构，同时我们在工作中还会接触到另一种角色——系统分析，系统分析和软件架构的区别在于，系统分析师面对的是固定的需求，而软件架构师面对的是未知的、可变的需求。最近七牛云的ceo许式伟在极客时间开课了——《许式伟的架构课》，这门课一出来，我就订阅了，这两天把第一篇音频听了三四遍，许大大讲得是真的好，我对这门课非常期待，是我另一门准备持续跟下去的课程，欢迎你也一起来学习。

---

本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。