项目管理实战20讲
雷蓓蓓
网易杭研项目管理部总监,《网易一千零一夜》核心作者
立即订阅
3862 人已学习
课程目录
已更新 21 讲 / 共 20 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么说项目管理是每个人的底层能力?
免费
常识篇 (3讲)
01 | 角色转换:程序员做项目管理的三大误区
02 | 十大领域五大过程组(上):程序员必须要了解的项目管理常识
03 | 十大领域五大过程组(下):程序员必须要了解的项目管理常识
硬技能篇 (12讲)
04 | 启动:识别项目中的四类干系人
05 | 规划:排除计划中的“延期地雷”
06 | 执行:打造品质,要从头开始“闭环”
07 | 监控:进展“巧”汇报,学会用数据说话
08 | 收尾:项目复盘,小团队也要持续改进
09 | 需求变更:化解程序员的“头号噩梦”
10 | 风险管理:如何系统化应对风险?
11 | 质量管理:一次把事情做对!
12 | 高效会议:项目中要开好哪些会?
13 | 故事案例(上):新手上路,如何引入变化?
14 | 故事案例(下):小步快跑,小而美的敏捷
15 | 工具方法串讲:手把手教你高效管理
免费
软实力篇 (4讲)
16 | 向上沟通:你必须要注意的三个误区
17 | 跨部门沟通:怎么让不归你管的人积极配合你?
18 | 向下沟通(上):无权无势,他们不听你的怎么办?
19 | 向下沟通(下):无权无势,他们不听你的怎么办?
特别放送 (1讲)
特别加餐 :“学习”到“实战”的距离,到底有多远?
项目管理实战20讲
登录|注册

09 | 需求变更:化解程序员的“头号噩梦”

雷蓓蓓 2019-11-16
你好,我是雷蓓蓓。今天,我们来聊一聊如何应对需求变更这个话题。
需求变更一直都是一个热门话题,特别是在奉行唯快不破的互联网公司,需求变更可以说是程序员的头号噩梦,也是“996”的直接元凶。
阿里有句非常有名的口号,叫作拥抱变化。既然需求变更无法被消灭,那么我们就要通过学习,掌握更好地应对需求变更的方法。我们先来看看常见的需求变更流程。
首先要发起变更申请,由变更委员会来综合评估,评估的内容包括变更范围、风险、对现有计划的影响程度等,以此来判断是否接受变更。变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成,如果接受变更,那么就需要判断项目计划是否需要进行相应的调整,最后公告处理结果。
其实,流程本身很简单,关键在于能否被有效地执行。在这一讲,我会给你介绍几种亲测有用的方式,你可以把它们作为自己的“防身锦囊”。

锦囊 1:达成最小共识,变更是有代价的

我刚到 A 团队的时候,交互妹子就可怜兮兮地拉着我说:“2 个月过去了,我们的第一个版本还在打磨,80% 的交互稿都已经改得大不一样了,越是临近上线越是不断地改。如果去跟策划们争辩,对方就甩过来一句‘老大要加的’,你说怎么办呢?”这个“老大”也就是 A 业务的负责人。他是产品经理出身,又是完美主义加说一不二的性格。于是,产品策划在团队中就有着绝对的话语权。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《项目管理实战20讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • 小金库so
    需求变更在一个项目里是不可或缺的一部分,也是项目趋于完善的自我矫正器,正确看待需求变更应该是项目经理必备的职业素能。一般会遇到两种需求变更,一种是项目进行中自我发现需求变更会更好的完善产品;另一种是外界压力下做出的需求变更。

    第一种可能更好的被接受,抵触情绪也会少很多。第二种来自甲方的压力或者老板的压力,要知道甲方、老板和项目经理看待问题的角度是不一样的,甲方更看重的是贴合自身利益,他不会考虑产品后续的扩展性,老板也许会考虑产品方面的诉求,但更多考虑的是公司战略层面的规划,因此,如何衡量这两者与产品之间的平衡性,其实非常难把握。

    堵不如疏,如果一直抵触无论对项目团队还是自身发展都是利大于弊的,一般情况下,如果需求变更不大,或者代价很小,可以快速试错,就算恢复相对也会容易很多;而如果变更比较大则需要深度挖掘内在需求,要知道除了产品经理和项目经理,外部其他人很难站在全局看待,也许我们可以提供更好的实现方案,尽可能将产品各方面考虑进去。

    另外,项目经理忌讳直接应需求的变更,再大的需求变更下,我们需要与团队更深入的沟通,这样才会将大家抵触情绪降到最低。

    作者回复: 你补充的特别好!

    2019-11-17
    6
  • 桃子-夏勇杰
    如果团队还是组件团队或者后端团队,估计先要解决需求描述的问题,而这样的需求不清也会导致大量痛苦的变更。
    2019-11-16
    2
  • 杨家二少爷
    这几个锦囊不错

    作者回复: 嗯……

    2019-11-16
    1
  • zw_learn_2
    我们团队现在有四条业务线同时进行,每天也会收到来自关键用户和大领导的一些任性需求(这些需求特点是必须做、抓紧做),不走规定的需求变更流程,这样搞得团队成员节奏很乱、怨声载道!
    针对需求变更,老师给出了锦囊妙计,下一步在团队内部实行一下看看能否改善我们的现状?
    真心希望有一位像您这样的领导😊

    作者回复: 谢谢,疏胜于堵,一步步来,你会找到好办法!

    2019-11-16
    1
  • 朋克是夏天的冰镇雪碧
    谢谢老师的点拨,我打算在部门年度总结的时候好好说一说这件事。我现在还遇到一个让我两难的事情,客户提出了一个需求,我认为是可以做的、合理的需求,而且我 demo 都已经写出来了,但是我的领导嫌麻烦,让我就跟客户说没法做。可是这个问题不解决,客户就不给我后面所需的资料,现在严重拖慢了项目的进度,请问老师这种情况我应该怎么做呢?

    作者回复: 先弄清楚你的领导嫌麻烦的原因是什么,有哪些隐性成本是你尚且没能考虑到的,跟你的领导对齐认知,包括你认为对于客户及整体进度的影响,你的老板是否有共同的认识。

    其实反过来看,这也是一个机会,去深入了解你们之间认知差异的部分,先找把信息对齐,再对齐思路,你会对这个项目有不同的理解。

    2019-12-04
  • weigtman
    老板开会,经典台词,数据有吗

    作者回复: 哈哈

    2019-12-04
  • Mars
    老师你好,我想问问关于锦囊2中的上墙文化是什么形式?上墙的内容是那些(排期、设计图、交互图)?驻足观望的程序员能根据墙上的内容就能理解整个产品或者某个模块的设计并能提出修改意见?

    作者回复: 当时是全站的重构,策划设计们在里面,从最初每个功能的承载页面开始梳理,抽取出公共功能重新设计,包括页面跳转逻辑图,打印出来贴在墙上,便于他们讨论。

    而这些中间过程的产物,也让其他角色更早地介入进来,提了很多意见,比如测试觉得这里有坑,这么设计的话,以前的某某客户的需求就无法满足了,提早就改掉了

    2019-12-03
    1
  • qpm
    看完这一篇,我感觉到项目管理真的是比技术难得多。道理我们都懂,但是要做好还是不容易。

    我自己对于需求变更都是比较宽容的,认为要一个策划或产品在构思一份文档中直接构思到位,这和要求一个技术一口气写完一大段代码而不允许有bug是一样的。我作为技术一般要求自己做到这两样:
    1、花时间和出需求的同学沟通,通过双向沟通确保自己完全明白需求的意思。同时根据自己业务上的经验,对需求可能发生变更的点直接质疑,反问,确保出需求的同学也知道明确自己的思路。(有时候出需求的同学蒙圈,自己想要的东西也不清楚,这样的需求基本上一定会改)
    2、通过合理的设计模式和代码结构,让代码具备一定的可修改空间。这是我对技术同学的要求,如果对需求变更过于抵触,可能是技术同学代码本身就写得不好。

    最后还是要讲究团队间的默契,加班是所有人都一起留下来的,遇到上线的时候是所有人都不得离开的,这也算是变更的一种成本。

    作者回复: 换位思考,做到这两点不容易,为你点赞👍

    2019-12-02
  • 阿昕
    「变堵为疏」的确是一个很好的思路,颇有大禹治水的架势,蓓格格讲得好。

    作者回复: 哈哈,偷学,被你看出来了

    2019-12-02
  • 朋克是夏天的冰镇雪碧
    老师,我所在的是一家 OA 软件公司,在给客户部署 OA 平台的过程中,需求变更可以说是家常便饭,有的时候可能一天就有十多条改动的事项。


    在我这里,改动所需要的代价往往不是很大,但是时间长了以后,某个地方改动过很多次,在测试的时候可能甚至都记不清这里究竟应该是什么样子了,和方案对不上的时候,我们都说不上来到底是我们配置错了还是后来客户提了要求。


    虽然改动的时候我们都有记录下来,但是好几个人你记一点我记一点,老实说真要查看记录文档的时候很难找到对应的那条记录,请问这种情况应该怎么办呢?

    作者回复: 你好,你所描述的这种变更频率,可以考虑用文档管理的工具来跟踪,我们用的是confluence,你也可以用石墨文档,历史记录的各个版本,谁改了什么非常清晰。

    2019-11-21
  • 赖赖猫
    首先说下我的读后感:老师的针对需求变更的方法论(以疏治堵,源头治理,顺势而为,闭环优化,数据说话)很棒,也具有一定的普世性。从实例中也看到了老师落地的能力很强:在以完成项目目标和提效的共同愿景下,借力打力,团结一切可以团结的人,充分发挥团队的智慧,运筹帷幄,团队氛围和正能量不断提升。佩服老师的领导力和智慧。
    就需求变更的管理,考虑到需求变更频繁/种类不一/对系统影响层面不同/变更时间不同对工作量影响不同等等因素以及对历史变更数据分析,我们会对需求变更做分类建模和应对方案方向及建议审批链(宽泛的/方向性的/易懂/不断优化的),并提前和各个业务线产品UED技术开会沟通达成第一步共识(算打预防针,也算是让不同工种互通有无),为后面需求变更的快速沟通处理做个铺垫。针对这类建模思想在项目管理中的应用,老师是如何思考的?

    作者回复: 谢谢你总结的25字箴言!建模的思路也特别好,建模方法与项目管理的结合,需要有大量的数据作为积累,目前我们正在通过自研的项目管理平台,做到全面的在线化和精细化,未来一定会走到精细化的差别流程管理,甚至是智能化决策。

    2019-11-21
  • Binds.Chen
    我们老板直接介入开发小组,对着开发的面说这个变更我明天就要。。。
    2019-11-18
  • Cy23
    看大家团队人那么多真羡慕,需求变更我只帮他分析可行性及需要的时间,老板觉得可以咱就弄,都你的钟,可你开心就好
    2019-11-17
  • 天天向上
    后两条太有用了!!!领导经常有各种想法,这下通过灰度实现数据说话。第二天产品和业务目前职能型组织架构,小PM扛不住,略有难度,可以找leader出面试试。

    作者回复: 很开心能帮到你!有难度的变化,是需要做一层一层做铺垫的,找到早期支持者很重要,你可以关注下第13讲,我会讲如何引入变化。

    2019-11-17
  • Nine
    锦囊 3 对我帮助很大。我就是我们团队的老板需求响应小分队。😊

    作者回复: 厉害了👍

    2019-11-16
收起评论
15
返回
顶部