需求管理那些事儿

96
javaadu 595a1b60 08f6 4beb 998f 2bf55e230555
5.5 2019.04.13 17:22 字数 1965

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

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

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

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

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

阅读摘抄

  1. 需求是整个产品的源头,所以说需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求,可能就会一步错,步步错!
  2. 产品需求是在分析提炼用户的真实需求后,提出的符合产品定位的解决方案。
  3. 软件项目的需求不是一个需求,而是一系列的需求,所以软件项目的需求分析需要使用下面这几个迭代循环的步骤:收集需求、分析需求、评估需求、需求设计、验证需求。
    软件项目的需求分析
  4. 用户需求背后的真实需求有三个层次:表层需求,用户对解决问题的期望,例如马车更快;深层需求,用户的深层次动机,诉求产生的原因,例如对出行速度的要求;底层需求,人性本能的需求,这里还可以参考马斯洛需求层次理论。
  5. 评估需求的优先级,可以使用“紧急重要四象限法”来区分,在项目中要优先做紧急重要的事情,再做不紧急但是重要的事情,这个理论同样可以用于个人的工作内容管理。
    image.png
  6. 在软件工程中,还有一个专业的模型,可以用来评估需求的优先级——kano模型。它把需求分成三个类型:必备属性、无差异属性和魅力属性。
  • 必备属性来说,是你必须优先做好的,你不做好,客户就会不满意,你做好了,客户的满意度只能达到基本的水平;
  • 无差异属性来说,它的客户满意度增长曲线是线性的,也就是说,做到一定程度,对客户的满意度提升就趋于0了,例如,某个场景的可靠性只需要做到3个9,你努力做到5个9,其实对客户的满意度提升并没有很明显的作用;
  • 魅力属性,属于客户自己没想到,你帮客户发现了他之前没有意识到的需求,iphone的出世就属于这种需求的例子。
    image.png
  1. 在需求变更这件事上,没有赢家,每个人都是受害者
  2. 对于软件工程这样偏理论知识的学习,你一定不要仅仅停留在了解有什么样的解决方案上,而是要追本溯源,研究问题背后的原因,研究理论背后的来龙去脉。因为,就算你记住了再多的解决方案,换个项目环境可能就不适用了,所以我们要多去分析、归纳、总结背后的逻辑,这样遇到类似的问题,才可以做到对症下药,甚至在没有现成解决方案的情况下,能自己创造合适的解决方案。
  3. 需求变更的管理,作者提出了三个解决方案
  • 提升需求确定性,减少需求的变更。这种方案的优势是对需求理解透彻,后期返工少,缺点是对产品经理的需求分析能力要求高;
  • 提升需求变更的成本,规范需求变更流程,减少需求变更的频次。这种方案的优势是可以立马起到效果,缺点是过于繁琐的流程不利于项目协作。
  • 降低响应需求变更的成本,积极响应需求变更。这种方案的缺点是对软件架构和项目管理要求比较高。

阅读心得

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

广告时间

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

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

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


javaadu
软件工程
Web note ad 1