08 | 关于需求变更（下） : 化变更于无形

Dec 7, 2017

08 | 关于需求变更（下） : 化变更于无形-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

08 | 关于需求变更（下） : 化变更于无形

2017-12-07 邱岳来自北京

《邱岳的产品手记》

课程介绍



讲述：邱岳

时长08:18大小3.80M



“拥抱变化。”——阿里巴巴价值观之一
上一次的文章中，我聊到了需求变更的原因，以及通过引入需求评审来尽可能避免需求变更，并在文章的最后提到了一次并不成功的项目经历。
这次项目已经根据项目流程开过了需求评审会，却没有在这个环节暴露问题，直到临发布的最后一刻才引入了变更。那么，怎样改进需求评审才能避免未来可能的变更呢？
“具体”的力量大部分的需求评审会都是过场，大家下面玩玩手机，产品经理在上面对着需求文档读一遍，再开开心心散会，除了浪费了时间，什么用都没有。
这里最大的问题不是参会的人员不负责任，而是需求评审时的方案不够“具体”。
我曾听说在微信团队里，不少产品在做出来之后，需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断，还听说有不少东西已经做出来了，但没有通过实际使用测试，所以一直压着没能发布。
我想，或许你也有同感，一个东西画在线框图上总是觉得很远，只有在指尖动一下才能有真切的体会和判断。
所以对一些关键性的特性，在资源配置合理的情况下，尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的，架构可以是假的，但看起来和用起来要尽量保真。
我记得以前有一次观摩一场游戏 Demo 制作比赛，团队在上面试玩展示，游戏角色在地图上能跑能跳，我特别不解地问旁边人：“这不都做好了吗，为啥还要参加比赛拿投资做开发？”他告诉我，虽然这看起来很完整了，其实后面都是空壳，大头还没开始呢。
在此之后，我经常提醒自己，对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的，让评审的人可以有真切的体验，把可能的问题都尽早暴露出来。有很多工具可以做到这一点，重一点的 Axure、轻一点的墨刀。如果实在不想学，用 PowerPoint 和 Keynote 也可以。
哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。
变更时机的选择如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要平衡收益和成本。
最好的变更发生在需求分析过程中，在产品经理脑子里，变更发生多少次都没关系，基本是无害的，所以刚才说要尽可能给产品经理留出足够多的时间，让他先自己跟自己打一架，把方案尽可能想完整。
第二好的时机是在需求文档结束，工程师接手前，这是的修改可能会造成需求分析延期，但因为需求分析主要是通过脑子完成，所以这里返工的伤害并不大，需求评审也是这个作用。
在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。
稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。
如果你的项目组里有专职的 QA，这时候最好也让 QA 参与进来。如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，这种情况挨骂是肯定的，态度好点儿，可能可以躲一顿打。
如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。在这个节骨眼上发生重大变更基本就可以领盒饭走人了。
我在职业生涯里遇到一次特别大的临发布的变更，是因为不可抗力造成的。那个项目涉及一百多人，我当时头皮都是麻的，跟人说话甚至都有些口吃。
总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。
让团队能消化需求变更虽然大家本能上都讨厌需求变更，但我们永远都不可能彻底杜绝需求变更，更何况我认为有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。
这个传递过程需要市场行销人员和产品经理的敏感，也需要工程师团队的宽容。如果整个团队抗拒需求变更，甚至建立流程对抗需求变更，久而久之就会越来越不敏感。
我体验过一个叫作“需求基线”的环节，就是需求确认结束以后大家签字画押，承诺绝对不变，连文档的编辑权限都封存，然后开发才接手，所有需求变更都必须审批到高管，启动一个冗长的评审程序。
这个制度导致的直接结果就是大家开始互相推诿，然后文档变得极其庞杂，效率降低，需求冻结以后，即便发现了问题和错误大家也不乐意提，就眼看着错的做出来了以后再说，整个产品线的节奏越来越慢，士气很快就磨没了。
没过多久，这些问题很快有了民间解法，产品经理和工程师在半夜的烧烤摊上把酒言欢，沟通需求变更，产品把变更的内容私下发给工程师，工程师直接改，等项目结束文档冻结解除之后再去改文档。
项目经理睁一只眼闭一只眼，工程师继续调侃这帮产品经理天天变，产品经理自嘲两句，然后咣咣请客吃夜宵，团队士气却一点点回来了。
后来大家慢慢意识到，这个本意用来限制甲乙方权责的流程不该在互联网公司中采用，也就逐渐废掉了。
产品经理脸皮虽然厚，但也是肉做的。如果整个团队都抗拒变更，一出现变更都恨不得把产品经理点了，他们也会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。
尤其在互联网行业，变化是永恒的，你不可能规划好路线一帆风顺，你总要随时准备好用最快的速度追击或躲闪，这才是求胜的不二法门。
记得多年前，我在某次开发过程中又一次变更了需求，于是我主动找到对应开发负责人那里“自首”，我扭捏地说：“不好意思啊兄弟，又变更了。”
他抬头看了我一眼，轻描淡写地说：“正常，不怪你，还是要怪我们自己做得不够快。如果已经做完了，你这就是一个新需求，而不是变更了。”
我喜欢跟这样的硬汉合作。
到这里，我们关于需求变更的分享就结束了。大家有没有在自己的项目中遇到过需求变更，你又是如何处理的？如果重新回到那个场景中，你能不能找到更合适的解决方案？不妨在留言中一起讨论。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 9

提建议

07 | 关于需求变更（上）：需求背后的需求

09 | 产品案例分析：Hopper的“人工智能”

 写留言

精选留言(39)

听天由己
置顶
2017-12-07
最近就遇上了需求变更，是在项目开发过程中发生的，早先的需求文档讨论都已确认，可在真正开发过程中却发现因为数据结构与真实性考虑，将原有流程重新拆分。此时面临着马上就要发布版本的情况下，好在开发还没做到这一步，临时变动还有挽回空间，只是项目上线压力更大了，最后那个例子看完了真的深有感触，我也希望遇见心态如此淡定的开发同事。回顾工作，我的经验就是两点：一是需求评审一定要细致；二是产品迭代一定要迅速。我们总说要设立项目里程碑与节点，可实践中却总是有各种问题，可能和公司整个管理方式有关吧。继续修行。
展开
11
剑走偏锋
2017-12-21
站在一个开发角度，结合敏捷实践，谈谈自己的想法： 1. 团队的整体设置一定是快速响应变更的，需求的变更程度和sprint长度成反比，这个对于dev team的要求极高； 2. 做技术的一定要积极投入需求评审会中，不断challenge产品经理，一方面帮助他们更多思考，另一方面探究自己的理解对不对，一定不能闷头执行；这就要求dev team一定是跨职能的，否则在开会时就他妈是走过场； 3. 在技术层面，快速响应变更后面意味着有一套完整的TDD，CI/CD流程，否则无法形成可靠的workflow。依然在不断践行中........
展开
13
野山门
2017-12-07
写的很具体，很有参考价值。很喜欢和这样的产品经理一起工作，可以有很多机会蹭烧烤吃哈哈。
作者回复: 哈哈哈哈哈哈好哇欢迎
12
Bonnie Mei
2017-12-21
把需求文档凉了半天再去看，发现调整的地方还是有的，以前是不想看自己已经做完的东西，现在要勇敢面对。
作者回复: 看过去的东西觉得不完美，也说明自己进步了
11
Atom
2017-12-07
哈哈哈哈哈哈我用PS+PPT，不仅做静态原型，偶尔还做小动效。PPT打到屏幕上还是比用网页好的，6的屏幕750*1334，两侧空出黑色留白，视觉效果很集中。
作者回复: PPT 的交互效果好像可以做得更酷炫
10
桃园悠然在
2017-12-07
赞同“留给需求发酵的时间”，实际工作中要求是当前版本提测时下个版本就要需求评审，但由于白天时间被各种“会”占据，经常只有晚上才有时间发酵需求，很容易陷入疲惫的循环。二爷能简单讲讲日常产品工作流或精力分配么，谢谢
8
Jason
2018-06-07
这上下两篇写的好。作为研发，我终于了解了需求变更的前世今生。同时觉得，产品经理真不容易，笑哭😂
7
GeekAmI
2017-12-07
二爷这都是血的教训的总结啊。我们团队是技术、设计、老板一起讨论需求，让设计出设计稿，大家一起填坑和优化。没有产品经理这个职位。
6
张楚琪
2017-12-07
看过一个段子：「产品经理经常变更需求怎么办？」「打一顿就好了……」有时候需求变更是没考虑周全，这时如果有比较充裕的需求发酵时间，可能可以减少被打的次数，因为没准自己就把自己给打了，自己打自己下手可以轻点。有时候是不得不变更，比如有更好的满足需求的方案了。感觉无论哪种情况，第一时间「自首」特别重要。跑过去，相视一笑，嘻……嘻嘻嘻，嘿……嘿嘿嘿，「兄弟喝什么奶茶？我请」，等愉快的喝完奶茶后，「这个功能如果我们这么做，你觉得怎么样？」，在奶茶带给人的愉悦感还没消失的时候，一般就不太会被打了，即使被打，也会轻一些。
展开
作者回复: 哈哈哈哈哈哈哈哈哈哈哈哈哈
4
vincent
2017-12-07
这不光是硬汉，更是大牛
作者回复: 嗯，硬汉一般都挺牛的
4
abillow
2017-12-07
拥抱变化，做到不易，即需要开放心态，又要能力过硬
作者回复: 情绪也要稳定
4
丸子
2018-04-14
最近接手了个半路撂挑子的项目，前任不明确的需求在我提给研发的时候收到了负面反馈。他的意思是我做好了你为什么要改？我的想法是你做的是错的我这不是新需求只是提 bug。不欢而散。最近越来越觉得，有个认真负责的产品把需求都想清楚，可以避免很多无用功，接过别人几个烂摊子之后就很反感人人都是产品经理这个说法，其实产品的门槛不低，不是人人都能做的来的。
展开
作者回复: 产品经理进门的门槛不高，但做到合格挺难的
3
Henglu
2018-01-02
虽然是产品实习，但是已开始看到二爷说的所有产品变更的场景。
作者回复: 常态，习惯就好了
2
拾叔
2017-12-26
其实我就一直觉得需求评审很无聊，我们的需求评审叫KT～knowledge transfer ，含义就是将需求同步各方。所以其实需求评审，我理解，其实就是需求的最后一步，最关键的都在评审前。需求变更，我们的定义一般处于评审之后到kick off之前，如果已经开发了，再变更，基本要挨刀子，小的变更还好，出个邮件，更新下文档就可以，开发基本能忍，如果大的改动，基本都要重新需求评审重新走流程，不管开发是否要求，从需求准确性考虑都要这么走，否则，很有可能到时候需求没同步到位，导致坑一大片
展开
2
时间之树
2017-12-25
对于投入产出比的权衡，是一个产品经理很重要的能力，同时也是不断学习的目标。对于二爷提出的通过流程来对抗变更，深有同感啊，看似降低了成本，实则严重降低了效率。
作者回复: 嗯有时候只想着用流程来限制问题发生，却忽视了流程可能带来的伤害
2
grayson
2017-12-18
原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。这里有个前提很重要，找到对的人。知道谁是对的人这个也是职场需要锻炼出来的。
作者回复: 没错，在不知道怎么识别的时候，一般是直接找项目的技术负责人，如果他完蛋，基本项目也就完蛋了
2
heha37
2018-10-20
硬汉
1
杜子
2018-01-27
我是技术，也是特别讨厌改需求，不过，也是可以理解的，一切都是为了做好产品
1
Xg huang
2017-12-15
经历过二爷说的变更基准线的制度，确实会出现这样的问题，做法就是暂停现有的开发，需求方新提需求，再一起重新开发。这样开发流程很长，然而，没关系！领导认可
作者回复: 传统软件公司可以理解，互联网企业这么做效率太低
1
Lynn
2017-12-12
关于最后一点，让团队消化需求变更。其实也是产品的沟通能力之一，还有就是公司工作流程问题。需求变更出现在各个层级，领导要求变，ui设计又要变，开发过程中又会变又或许是需求方的业务需求变，那么对于这些场景来说，该用什么样的语言跟对方沟通？
作者回复: 对方是什么世界的人，就用什么语言。比如跟开发尽量用技术语言，跟业务多说业务语言，争取打成谅解
1

