软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6698 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

20 | 如何应对让人头疼的需求变更问题?

宝玉 2019-04-11
你好,我是宝玉,我今天分享的主题是:如何应对让人头疼的需求变更问题?
我以前在国内做开发的时候,加班加点是家常便饭。这几年在美国工作,极少加班,但是产出却并没有下降,所以我一直在思索其背后的原因。这里面涉及因素很多,包括大环境、管理水平、配套设施等,但是有一个因素至关重要,那就是需求变更。
在国内很多软件公司,需求变更是常态,开发到一半,很多原始需求就发生了变化,这时候当初的设计已经不能满足要求了,很多代码需要修改,不得不加班加点来赶上进度。
反观不加班的美国公司,需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计,而不用考虑太多可能的变更,从容地在项目计划的时间内完成任务,而不需要加班加点。
在需求变更这个事情上,没有赢家,每个人都是受害者。
程序员自己辛苦的工作白费了,得不到成就感,因为频繁变更的需求,不得不在设计的时候考虑很多可能的变更,导致代码臃肿,代码质量降低,加班加点成了常态。甚至有人说:“杀一个程序员不需要用枪,改三次需求就可以了!”
产品经理也觉得很委屈:“客户要改,我有什么办法?”程序员和产品经理似乎变成了两个对立的岗位,程序员怪产品经理乱改需求,产品经理觉得是客户造成的,人人都觉得自己委屈。客户同样不满意,觉得做出来的软件不是他想要的,进度总是在延后,还想加钱?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • kirogiyi
    需求变更的多少取决于产品团队、研发团队,甚至测试团队对需求的理解程度。理解越透彻,需求变更越少,很容易在做项目的过程中及时发现问题、解决问题,这就相当于把可能发生的变更分散到日常工作中去,使其不会有太多明显的变更,降低项目延期的可能性。

    宝玉老师讲到变更流程的规范化,确实深有体会。有些产品经理不按套路出牌,遇到用户提出产品需求问题,都是一口气答应下来,不去认真分析,也不去与用户探讨,觉得为了公司利益而满足客户需求是理所应当的,不加思考原原本本的将需求扔给研发,然后搬把椅子一脸焦急的看着一脸着急的研发人员。其实,有的时候加班就是这样产生的,无组织、无纪律、乱弹琴,遭殃的是患难兄弟,埋怨的是公司不人道。

    我体会过产品需求流程比较规范的公司,大家都知道什么时候该做什么,绝不跨部门或越级指挥,一切按产品需求流程办事,在搭配上比较强大的执行力,每个人工作时间的工作内容都是饱和的,到下班的时候绝不留恋工作,走慢点你就是最后一个下班的。

    另外,在谈论需求变更的时候,要学会拒绝,让用户知道你拒绝得很在理,有可以理解的难处;也要学会接纳,在某些合理、无伤大雅的需求上要满足用户的存在感。这样在进行项目交付的时候,即使项目完成度不是很理想,也会因你个人处事得当而加分,很容易的拿到项目的验收报告。

    作者回复: 👍很棒的分享!

    所以说项目管理是艺术,其中的平衡很难完全是一门艺术!

    2019-04-11
    1
    7
  • Felix
    三句箴言:
    走一步想三步
    能配置不定制
    不要相信产品经理的“绝对”

    作者回复: 👍谢谢分享

    这三句绝大部分时候都适用的,我觉得也要适当结合项目情况,有些时候考虑太远、做多手准备,容易做无用功。

    2019-04-18
    3
  • sotey
    老师,我参与的项目遇到了这样的情况,因为老板要求项目交付时间要提前,导致了大量的需求变更和重新设计,项目看似提前完成了,但是功能却被阉割了,后续项目的改进难度变的非常大,这种情况该怎么办啊?

    作者回复: 砍掉功能保进度很正常。只是不知道改进难度大的原因是什么?因为没有时间做架构设计?还是因为大的功能还没做?

    还是需要具体情况具体分析,你可否再发一条留言讲一下具体难度在哪,才好给具体建议。

    2019-04-11
    3
  • alva_xu
    老师今天讲的现象,实际上是软件开发部门最头痛的事情。通过三个手段来解决需求变更问题,总结得太到位了。按照软件质量的金三角理论,需求变更,就相当于范围变大,必然导致成本上升或者时间增加,否则,就是质量下降。
    比如说成本问题,由于业务领导对于软件开发没有成本意识,而且不考核他们的成本,所以他们可以随意变更需求,IT部门有苦难言。为了减少这个问题,我们尝试让业务部门在业务蓝图(需求)文档上签字,但对于强势的业务部门,依旧见效甚微。后来,又在发布频次上进行考核,减少发布频次。但结果又带来了用户真实的需求变更不能及时获得满足,直接影响业务。

    业务变更是必然的,IT部门必须快速响应用户需求,这是摆在IT面前的必然挑战,无法回避。
    真正掌握在IT部门的办法,只能是第三种选择:
    “降低响应需求变更的成本”。
    因此,我们开始建立统一应用框架(比如单体应用的java框架,微服务框架等)、建立CICD环境、推进云的建设,加快环境搭建速度,引入自动化质量工具,加快系统缺陷的检出速度,减少技术债务,甚至建立一些业务中台,加大业务的下沉力度和技术的上浮力度,加大技术和业务的复用,建立更高效的项目管理体系和工具平台,减少技术和业务的沟通成本。
    但是这样的基础建设长路漫漫,见效很慢。不知老师有没有这方面的经验分享,比如采取哪些措施,优先级是什么,来达到降低响应需求变更的成本的目的,这里又有哪些困难,如何克服。等等。
    谢谢

    作者回复: 基础建设方面我的一点建议:

    基础建设困难在于短期内会减慢开发速度,是和业务冲突的,如果业务部门不支持,会很难推进,压力很大。所以可以考虑分成短期、中期、长期三类,逐步做。

    首先,在不影响业务的前提下,优先做一些跟业务相关能短期取得正面效果的事,比如工具的使用,管理平台的搭建。这样取得效果后相当于为你自己积累了声望,以后推进其他事情会更容易。

    然后推进流程规范的建设,比如CICD、代码审查,这类事中期可以取得效果,但也需要投入大量精力保障制度的执行。

    跟开发相关的事是短期看不到效果长期的事,低调的做,一点点做,最好有专门的小团队做,比如你说的统一框架的事。这类事情阻力很大,因为既要兼顾新业务的推进,又要还大量精力对现有业务的改造。做成了绝对大功一件,没做成是要背锅的。所以低调一点,做成后再高调表表功,万一没做好或没达到预期就总结经验,下次再战,也不会导致太大影响。

    供参考!

    2019-04-12
    2
  • 果然如此
    1.提升需求确定性:设计高保真的原型,如用axure,不仅仅是画框图,还要加各种响应事件等;
    2.提高需求变更的成本:提前约定变更制度,签字画押;
    3.降低响应需求变更的成本:提高技术框架水平。

    以上是通过产品、流程、技术三个方面解决需求变更问题。

    作者回复: 👍很好的总结

    2019-04-11
    2
  • 打工皇帝
    老师!我的组长脑子有问题,经常干涉设计,前面确定了需求,等开发完又修改,总是说话跟放屁一样!还是巨婴!任性,说我就是要这样,很多开发和设计都好讨厌他,敢怒不敢言!请原谅我留言粗鲁不文明!供应商的人天花的是公司的钱,他没成本意识,这样一手遮天的人 怎么应对?

    作者回复: 首先,我觉得就你自己来说,先尝试利用软件工程的知识做好你应该做的,用科学的方法去管理这类事情,包括管理你的领导。比如我在前一条回复建议的:多确认、帮助领导意识到变更成本,提高他变更的成本。不管结果怎么样,你都可以从科学认真做事的方式中获得提高和成长。

    然后,对于国内的大部分公司来说,领导发言权很大的,能治领导的就只有更大的领导了,而且除非是严重错误,否则大领导也不会轻易换人。也可以考虑收集一些事实,越级投诉。但这样做风险比较大,慎重考虑。

    最后,就是用脚投票,骑驴找马,换组或者换公司。

    2019-10-18
    1
  • 小老鼠
    1、敏捷是美国人提出的,有一点很重要:拥抱变化。而中国需求变更的确很高,而中国人为什不拥抱变化?
    2、欧美软件企业的确加班比中国企业少得多,除了需求变更多,还有什么吗?

    作者回复: 1. 敏捷开发确实是美国人提出的,但是其实并不必可以区分中国人美国人,因为敏捷开发是针对软件开发的,而软件开发是有很多共性的,并不分中国人项目还是美国人项目。

    敏捷开发的拥抱变化,正是通过自动化提高效率,通过缩短开发周期,来优先做核心功能,来快速发布快速迭代,从而快速响应需求的变化。

    2. 还有文化上的差异,比如美国人很注意家庭生活;另外还有工会的制衡等等因素。

    2019-09-17
    1
    1
  • OnRoad
    客户需求频繁变更,大领导迫于客户压力全盘答应,导致开发节奏被打乱,除了量化风险上报之外,还有什么好办法?

    作者回复: 需要和你的领导私下协商,需要在他的帮助下一起作出一些调整:
    1. 要设立流程提高客户变更需求的成本,可以需求变更,但不能太过于频繁随意
    2. 缩短开发周期,采用迭代模型或者敏捷开发,2-4周发布一个版本,每个版本实现当前已经确定的最重要的需求,在一个版本内不接受需求变化,变化的需求放在下一个迭代中实现

    2019-05-12
    1
  • 舒偌一
    宝玉老师,您这边有没有做需求调研的工具或表格之类的,能更好的把握住客户的真实需求。

    作者回复: 抱歉我手头没有。
    人人都是产品经理网站上一个“需求调研”的Tag,里面有很多相关的文章。

    比如其中这篇文章《只需8步,需求调研表的标准制作流程》http://www.woshipm.com/pmd/407048.html 推荐你可以看看。

    2019-04-24
    1
  • 谭鹏
    很头疼 ,开发快完成时 ,老板突然想到了个很好玩的点子,让加需求

    作者回复: 告诉他点子很好,等我们这个Sprint/版本完成,马上加上 :)

    2019-04-15
    1
  • MJ
    今日学习应对需求变更的三种方式:

    提升需求确定性;
    提高需求变更的成本;
    降低响应需求变更的成本
    2019-04-12
    1
  • 胡鹏
    听了今天的课程,我收获的应对需求变更的方案有3
    1.用低成本的方式提前收集到变更信息,以提前预知变更
    2. 提高变更需求方的变更成本
    3. 对系统结构要求较高,就是研发工程师在可预知范围内,尽量可配置化需求

    作者回复: 👍很好的总结

    2019-04-11
    1
  • youjing
    把自己变成客户(深入了解客户)
    ,可行吗?

    作者回复: 我觉得就算假装自己变成客户,也得要是懂客户能说服客户才有用。

    2019-04-11
    1
  • 空知
    给政府部门做业务软件,也配置了变更流程,可是很多时候并没有效果,领导说不满意要改就得改,这个领导满意了,另一个领导又有意见...很多时候销售,项目经理 为了维护客户关系,研发这边就得让步,不改的也得改😂

    作者回复: 是的,光从流程上还不够,经常有绕过流程的情况发生。还可以结合前面讲的金三角,看是不是可以增加成本或者减少其他需求。

    2019-04-11
    1
  • calvins
    深有感触,需求分析不到位,变更控制不到位,对团队是灾难!
    2019-11-27
  • 舒偌一
    做需求变更规范的目的是提高客户对需求的重视程度,而不是阻止客户提出变更。
    需求变更规范明确变更处理流程、范围和费用。需求变更规范最好由双方领导签字确认。
    人做事就会犯错,不要事事较真,灵活处理,良好的合作关系很重要。

    作者回复: 👍是的,需求变更规范起来,目标还是为了共同努力开发出高质量的软件,而不是为了阻止客户变更!

    2019-04-23
  • 小伟
    多谢老师,很受益。
    自己在互联网公司,很多时候需求经常变更,是需求沟通的人或制定方案的人水平不行,觉得需求变更很方便,走一步算一步,导致来回反复。(规范需求变更流程)

    另外,很多程序员对自己不自信,觉得很简单的变更,随手就改了,觉得自己时间很廉价,殊不知,改动一个点,会涉及单测,继承测试等一系列工作,如果省略这些步骤,就会造成系统bug等等(变更成本高)

    作者回复: 是的,变更是有成本的,其实成本不低的,需要让程序员和PM都有这个意识。

    2019-04-18
  • 长眉_张永
    写了一些,竟然说是包含敏感词!仔细看了下,没找到

    作者回复: 抱歉我也不知道极客时间关键词是啥 :(

    下次可以分成几条发试试

    2019-04-15
  • 一路向北
    在做项目的过程中,需求变更是最常见的。几乎每个项目都会发生,特别是那种客户自己都不清楚最终要什么样的产品的时候。
    产品需求的知识,建议不管是公司的管理者,还是程序员,都应该认真的学习这方面的知识,可以把老师这样的案例拿来学习一遍,这样在项目开发中就会有相关的意识,对每一个阶段会有深刻理解。

    作者回复: 是的,需求变更是软件项目中最常见又最让人头疼的问题之一!

    你可以把这篇文章分享给你的同事或者朋友一起看看,有好的观点也欢迎留言讨论。

    2019-04-14
收起评论
19
返回
顶部