在实际工作中，大家很少有机会经历从0到1的项目，绝大多数情况是加入到一个已经发展了一段时间的团队，参与维护已经运行了几年的项目。
回想起来，我这几年来经历过多种多样的项目：从0到1的项目、已经成熟处于维护期的项目、需要重构的核心项目、需要一步步废弃和下线的项目等等，可以说是项目经验十分丰富了。
经历了这些项目之后，我认为，站在开发团队的角度，评判一个软件项目成败的因素，最关键的就是两个点：需求管理和可行性分析。
- 需求管理做不好，体现在两个方面：需求分析不足、需求随意变更，这会让开发团队做一些臆想的、半成品的需求，做到一半发现没想清楚，然后陷入到边做边改、边改边做的魔咒。
- 可行性分析做不好，会让开发团队为了一个不可实施的方案去努力，最终获得的不是成就感，而是挫败感。
今天这篇文章，是我阅读和学习《软件工程之美》中关于需求的两篇文章写的阅读笔记，主要想学习下宝玉老师对需求管理的看法。下面这张图，是我针对文章的内容梳理的脑图：
阅读摘抄
- 需求是整个产品的源头，所以说需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求，可能就会一步错，步步错！
- 产品需求是在分析提炼用户的真实需求后，提出的符合产品定位的解决方案。
- 软件项目的需求不是一个需求，而是一系列的需求，所以软件项目的需求分析需要使用下面这几个迭代循环的步骤：收集需求、分析需求、评估需求、需求设计、验证需求。
- 用户需求背后的真实需求有三个层次：表层需求，用户对解决问题的期望，例如马车更快；深层需求，用户的深层次动机，诉求产生的原因，例如对出行速度的要求；底层需求，人性本能的需求，这里还可以参考马斯洛需求层次理论。
- 评估需求的优先级，可以使用“紧急重要四象限法”来区分，在项目中要优先做紧急重要的事情，再做不紧急但是重要的事情，这个理论同样可以用于个人的工作内容管理。
- 在软件工程中，还有一个专业的模型，可以用来评估需求的优先级——kano模型。它把需求分成三个类型：必备属性、无差异属性和魅力属性。
- 必备属性来说，是你必须优先做好的，你不做好，客户就会不满意，你做好了，客户的满意度只能达到基本的水平；
- 无差异属性来说，它的客户满意度增长曲线是线性的，也就是说，做到一定程度，对客户的满意度提升就趋于0了，例如，某个场景的可靠性只需要做到3个9，你努力做到5个9，其实对客户的满意度提升并没有很明显的作用；
- 魅力属性，属于客户自己没想到，你帮客户发现了他之前没有意识到的需求，iphone的出世就属于这种需求的例子。
- 在需求变更这件事上，没有赢家，每个人都是受害者
- 对于软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了，所以我们要多去分析、归纳、总结背后的逻辑，这样遇到类似的问题，才可以做到对症下药，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。
- 需求变更的管理，作者提出了三个解决方案
- 提升需求确定性，减少需求的变更。这种方案的优势是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求高；
- 提升需求变更的成本，规范需求变更流程，减少需求变更的频次。这种方案的优势是可以立马起到效果，缺点是过于繁琐的流程不利于项目协作。
- 降低响应需求变更的成本，积极响应需求变更。这种方案的缺点是对软件架构和项目管理要求比较高。
阅读心得
- 你了解AB测试吗，有在项目中使用过AB测试吗？听说过AB测试，但是没有再实际项目中使用过。目前公司的基础设施支持蓝绿部署，可以很方便得进行AB测试。
- 极客时间的课程为什么要支持音频？从读者角度来考虑，主要是为了解决用户有一定自己的时间，但是又没有办法阅读的场景，例如：上下班开车路途中；从专栏作者角度考虑，有些话用文字和图片写出来，可能还需要再配合着讲解一遍，效果会更好。另外，支持音频，也增加了作者和读者之间的另一种沟通媒介，提升了读者的用户体验，例如有些专栏会将“作者口述”作为一个卖点来推广。
- 你工作中有没有遇到因为需求分析没有做好而导致项目失败的案例？有，边改变做、边做边改的感觉太酸爽，最后项目虽然推进到了下一个阶段，但是团队的士气不可避免得受到影响。
- 你参与的软件项目中，需求变更多吗？有多有少，都经历过。
- 你们是怎么管理需求变更的？文中提到的三种方式，我们主要使用的方案1+方案2，目标是使用方案3。在做需求分析的时候，我们一定会有需求评审阶段和会议，提升需求的确定性；做需求变更的时候，我们会在需求迭代会上进行评估，提升变更的成本。不过对于技术团队来说，如果只是满足于使用这两个方案应对需求变更，那是不够的，因此，我们团队的目标是利用方案3，在产品中可能经常变动的地方提供配置化的能力，灵活响应需求的变更。
广告时间
这门课已经进行了三分之二，这是我的第9篇读书笔记，说实话，对我的帮助非常大，在工作多年后进行了一次软件工程理论的回炉重造。在这段时间，我有时候会在实际工作中应用在这门课中学到的方法和技巧，对于我的工作效果提升也很大。你是不是在软件项目中被各种琐事缠身，但是又不得其法，这门课应该可以提供一定的理论指导。
在这篇文章中，宝玉老师提到，解决需求变更的第三个方案是：积极响应需求变更，提供配置化的软件架构方案，但是对软件架构和项目管理的要求很高。这里说到了软件架构，同时我们在工作中还会接触到另一种角色——系统分析，系统分析和软件架构的区别在于，系统分析师面对的是固定的需求，而软件架构师面对的是未知的、可变的需求。最近七牛云的ceo许式伟在极客时间开课了——《许式伟的架构课》，这门课一出来，我就订阅了，这两天把第一篇音频听了三四遍，许大大讲得是真的好，我对这门课非常期待，是我另一门准备持续跟下去的课程，欢迎你也一起来学习。
本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。
标签：需求,方案,12,项目,分析,软件架构,不好,变更 来源： https://www.cnblogs.com/nkduqi/p/10703970.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。