坊间流传一句话——“杀一个程序员不用枪,改三次需求就可以了”。问君能有几多愁,恰似调完代码改需求。需求变化是程序员眼中最大的痛,没有之一。
对程序员来讲,最理想的情况是,需求定下来后,直到软件交付都不发生一次变化。然而,需求的变化却是客观存在,无论你接受与否,稍微复杂点儿的项目,需求变化都是难以避免的事。所以,我们既要了解需求为什么说变就变,又要修炼面对需求的心态,,还要知道怎样控制需求变化。
老板为什么老调整需求
有位朋友在微信的一个群里问我:
安老师,如何保证项目进度呢?目前我们采用Scrum敏捷开发,分配的任务卡,还没等写完……需求就调整……告诉老板一个冲刺内尽量不要调整需求,可老板还是停不下来……
你是不是也有这样的老板?说好的需求不动了不动了,结果隔上半天就跑过来说“我们必须得调整一下,这个功能做成这样,那个砍掉,再加一个这个”……
为什么老板总在变?
我想你也知道原因的:
老板才是真正一心想要做好产品的那个人,才是日思夜想不断琢磨怎样把产品做好的那个人。他的思考一刻也不会停下来,他总是自发的去探寻、求索、完善自己的想法。他是那个没人催促也要自我燃烧的人。
所以,他比我们捉急,比我们更担心错失某个好点子、做错某个需求、做了无用的功能,所以,他总是想要不断调整来逼近他心中的最佳。
而我们呢,其实没老板那么把产品当回事儿,其实是不自觉地想着自己方便,越方便越好,最好需求定下来一年都不要变。
正因此有这样心态上的差距,所以冲突就起来了:我们总觉得老板反复无常,老板总觉得我们不尽心尽力拒绝把事情做好。
破除私心,拥抱变化
现在我们知道老板为什么不断调整需求了,那我们再来看看我们为什么不愿意接受需求变化。
前面说我们没老板那么全心全意、不惜一切代价想把产品做好,所以我们的心态和老板的心态有较大差距,所以不能理解老板为什么频繁对需求进行调整。那其实呢,我们并不是因为不想把产品做好才拒绝需求变化的。
我们拒绝需求变化,一方面是出于执行层面的考虑:
- 担心需求变来变去,不能按最初约定的时间点交付
- 认为自己已经投入时间完成了某些需求,变化会导致自己投入的精力浪费
- 因为调整需求,会导致设计、实现等多方面的变化,给自己带来更多工作量
另一方面也有心理上的原因:
- 当因为需求变化而扔掉已完成的代码时,认为自己的付出没有价值,也认为自己的劳动没有得到认可和尊重,心理上是拒绝的
- 喜欢计划和秩序,不喜欢自己的节奏被中断
- 认为老板本人脑子进水,做事没规划没常性,不考虑他人感受,本能的就对老板变更的要求抱有拒绝态度
- 拒绝变化(无常),总担心可能这个会有错那个会不好或者这样变会失去什么,心有焦虑
不管是哪方面原因,其实深思一下,你就会发现:你是因为过于关心自己的感受、不想勉强自己难受才希望需求不要变化。
也就是说,我们面对需求变化,心理和行为模式是这样发展的:
- 需求变化
- 我得要调整、舍弃、重做,我不爽
- 我要拒绝
- 拒绝不了,心生埋怨,消极对抗或四处埋怨
我有时就是这样的,你呢?
假如我们能穿上老板的鞋子走一走,可能就会得出不一样的结论,可能就会认为需求变化是可以接受的。
假如我们把自己的感受放下,将如何把产品做好放在第一位,可能就会理解需求变化,拥抱需求变化。
一件事情发生或,你的感受和压力,往往源自于你在思维层面对事件的解释。假如你改变了思维,改变了自己解释事件的逻辑,那原本让你感到不爽的、难受的、拒绝的,可能就会让你欣喜、赞同。
我们这么讲,是不是就是说,我们要毫不犹豫地接受一切需求变化呢?
非也!
控制需求变化
我们破除思维上、思想上、心理上对需求变化的抗拒,并不是为了让变化随意发生,而是为了使产品更好,所以,我们还要从实际上控制需求变化。
稻盛和夫在《干法》中有八个字,说了我们做一件事时应该持的态度:“动机至善、私心了无”。非常赞啊,不能比赞更赞了。
前面我们讲“一个人拒绝需求变化往往是因为私心,要拥抱变化,就要放下自我”,也是一样的道理。
当你放下了私心,没有自我,只有大道时,你就可以客观地看待一个需求,客观的分析它是不是为产品好,是不是对公司有益。当你以这样的基点来和老板讨论需求时,你拒绝某个需求,就不是因为它让带给实现层面的麻烦,就没有私心,没有情绪,就更容易与老板达成一致。
有了态度上、思维上的转变,就有可能优雅地拒绝不合理的需求。
那么当我们与老板商榷需求是否要被纳入当前的开发计划中时,有几种方法可以参考:
- 目标整理
- 后果揭示
- 优先级重排
一个一个简要介绍一下。
- 目标整理
老板提出新的需求或变更已有需求时,往往伴随着目标变化。此时我们需要重新整理项目或产品的目标。
你可以先问自己,老板这么做的目的是什么,我们产品的目标是什么,两者什么关系。当你想不明白,或者觉得新需求(需求变更)对产品目标害处多于好处时,你可以接着与老板沟通。(如果相反,接受就很自然)
你可以询问老板,这么做的目的是什么,我们这个产品的目标是什么,老板自然就会思考,这个新的需求会不会影响原来的目标,有没有必要做。如果他想一想,哦,这个需求没卵用,那他自然会取消。
如果老板觉得还是有必要加入这个需求,那你可以接下来和老板谈你的理解。有一个方法,你可以在白板上来对比,左边列出老板的想法,右边列出你的想法,请老板帮你看看是否你的理解存在问题。这样一对比,就容易找到差距,就容易统一认识。
这样的目标整理方法,有的是事实、分析、数据,没有私人情绪宣泄,通常都可以帮助我们和老板形成一致的目标。
- 后果揭示
假如很难和老板达成一致,而你又觉得老板的做法不妥,那你也可以把你的担忧理一理,把添加某个需求可能产生的后果推演出来给老板看。这种做法就是后果揭示。
有时老板不想改变他的想法,仅仅是因为我们没有触动他,没让他产生改变的动力。当老板能看到他的做法对产品的不良后果时,他会比谁都愿意放弃这个新增的需求——因为他比任何人都更愿意把自己的产品做好。
- 优先级重排
假如大家都觉得新增的需求很合理,那还有另一个问题:交付时间。原本评估一个月交付,加了需求后,可能需求两个月,而老板不能接受这个时间点。怎么办?
此时你就可以把手上的事情列出来,A、B、C,各有多大工作量,你有几个人,张三、李四、王二、马六,每个人做什么。新增需求需要多大工作量,什么时间才能开始做。然后就是事实:如果要加这几个需求,别的功能就会后延。再然后就可以请老板帮你来排A、B、C、D这些事项的优先级,老板排一排优先级,可能就会主动把新增的需求D放弃或延后。
福利,送书
这次送的书是《人人都是产品经理》,关注我的订阅号“程序视界”(微信id:programmer_sight),点击公众号底部的我可以菜单,选择查看历史消息,找到本文(最新一篇),即可参与活动。