关于“开发评估时间”的思考

 

昨天同事分享了一篇文章，programmers-are-bad-estimating， 

链接在这里：http://java.dzone.com/programmers-are-bad-estimating

 

没怎么认真看这篇文章，但这篇文章引起了我的思考
 

身处互联网行业，敏捷开发被一致认为是“制胜法宝”，大家一致认同快速开发，

快速收集用户反馈，快速迭代。其中经常出现的一幕是，在需求会上，产品同学问开发同学，

这东西要搞多久，什么时候可以发布。然后开发同学开始痛苦地尽其所能地在需求没看懂，

甚至原有代码不熟悉的情况下用几秒钟的时间去评估，

即使开发同学发现在这种情况下还不能比较准确地评估时，产品同学也一般也会要求给个大概时间，

然后开发同学只好绞尽脑汁去评估，然后给出一个“大概时间”。

如果给出的“大概时间”超出产品同学的预期，产品同学就会去质疑开发同学，

一种常见的做法是，找一个开发leader，或者他觉得可以评估地更好的开发过来评估。

期望是这个人评估出一个更短的“大概时间”。

 

一个很简单的场景，一直在重复着，如果不是昨天同事分享的文章，还真没怎么想这件事情。

 

产品同学侧

1：产品同学不懂技术，无法知道技术实现，更无法评估时间，所以对他来说，

时间多少是未知的东西。人对不确定的东西和未知的东西都有一种天生的恐惧感。

消除这种恐惧感的方法就是把不确定变成确定，所以产品同学会要求开发评估时间。

2：开发时间是产品同学对需求优先级评定的一个重要因素。这很容易理解，

如果投入和产出不成正比，产品同学需要去调整或者延迟这个需求。

3：希望开发时间越短越好，越敏捷越好。这样产品才能更快地去对产品根据用户反馈做出调整，

在这个竞争激烈的市场中更有竞争力。否则，很可能就被淘汰。

 

开发同学侧

1：互联网的开发不像传统软件的开发，前期有很严格的需求评审，架构设计等等，

可以什么都确定下来再动工。互联网讲究有感觉就去尝试，就去做，发现不行再调整。

快当然是好事也是优势，同时也带来了一些需求不确定，需求文档比较粗糙。

有时候连产品同学自己都没想好细节，只是有个大方向。

2：发现需求不确定，或者原有代码不熟悉时，不敢轻易评估，

因为曾经的“伤害”已经深深地在印在他的脑海里了。“因为评估不准导致影响整个项目进度”，

“因为需求的一个小改动导致全盘推倒重来”，

“不确定的情况下评估出来的时间远远大于实际时间，只好精神高度紧张，然后加班加点，

耐心地跟产品同学解释”，“担心别人对你的能力的否定”等等。

这些担心导致了开发同学在不确定的情况下不敢轻易评估，

因为开发同学和产品同学一样，对不确定的事情感到恐惧。

3：产品同学的再三要求，开发同学只好给出“大概时间”，

这个“大概时间”有点用脚投票的感觉。比如说，评估的“大概时间”为一周，

可能3天就搞完了，也可能要个两周。相关因素很多，需求文档的清晰度，

产品策划的变更情况，开发个人的能力，现有代码的框架和质量等等都会影响开发的进度。

 

从上边可以看出，问题很容易就产生了。

1：产品同学本身不了解开发的实现等，需要多少时间来开发实现对于产品同学来说是一个黑盒。

但是产品同学又会经常根据以往的经验对开发时间产生一个心理预期，

而且要求开发同学在几秒钟就给出个“大概时间”。

因为这个“大概时间”会影响到很多产品同学的决定。

 

2：开发同学每次都痛苦地用脚投票，给出自己都不信服的“大概时间”。

“大概时间”的不靠谱如上边所说。

有经验的开发给出“大概时间”时往往会留出一些缓冲时间来让自己不处于上边所说的被动的情况。

但让自己处于舒适区，不管是对自己，还是团队和项目，都是不太好的。

 

3：产品同学的做法，找一个开发leader，或者他觉得可以评估地更好的开发过来评估。

期望是这个人评估出一个更短的“大概时间”。这种做法其实比较伤害团队气氛，

如果那个被找过来的人的做法不是很恰当，比如在不了解情况当面就做出快速给出“评估时间”，

会伤害到去真正去实现开发的同学。所以，当你是那个被找过去的人时，

不要不负责任地随便给出“评估时间”。起码先考虑下那个去真正去实现的同事的能力，

以及对现有的架构的熟悉程度和和现有的代码质量，

然后再去了解清楚需求和真正去实现的同事的担忧的地方。

 

事情好像无解了，互联网要求敏捷开发，而且变化很快。

产品同学需要根据开发同学给出的评估时间来安排以后的工作和策略。

技术同学又需要时间去了解需求，而且受限于自身的能力以及对代码的熟悉程度，

以及现有的框架和代码质量。

怎么办？

首先，一个相互信任，团结合作的工作气氛是基础。

开发同学和产品同学是一条战线上的战友，都是想把产品做好，把项目做好，没有冲突。

起码那种希望自己的项目做的越来越差，希望自己处于一个一团糟的团队里边的人还是少数。

不要轻易去怀疑别人，去质疑别人。如果有这样的气氛，开发同学也更敢于去给出评估时间，

更敢于去挑战自己，因为不会以为一次估计错误而导致种种质疑和“伤害”。

估计错误了，去总结和学习，以后不会在同一个地方跌倒就ok了。

 

其次，做好沟通

产品同学为什么会要求开发给出评估时间？开发同学为什么难于给出比较准确的评估时间？

需求在实现过程中为什么需要修改？为什么这点小的调整需要格外的两天？

等等，还有很多，如果发生这种情况的时候，尽量去沟通好，为什么会这样？

你知道或你觉得应该这样的，别人不一定知道或觉得应该这样。

 

第三，多点理解

不管是产品同学还是开发同学，当对方做出了让你不爽的事情的时候，多点信任，多点理解。

千万不要把问题放大，不要去猜测，不要去幻想。然后在心情平静下来后，去主动沟通，

去了解对方这样做的原因。寻找好的，你就会找到好的，甚至会创造出好的。

 

第四：开发同学需要提高自身能力

如果开发同学能力很强，产品意识很好，甚至比产品强，技术能力也很好，那么一个需求出来，

不确定的地方必然就少了很多，需求不清晰的地方，他可以补全，对代码现有框架和质量了如指掌，

对现有细节很熟悉，开发效率很高，那你评估时间必然会很轻松和愉快。

因为你给出的评估时间往往比产品同学经验当中的都要短，而且评估时你是很清晰的，

不是用脚投票的。那么，你慢慢就会成为一个靠谱的人。

 

第五：给充足的时间给开发同学评估

很明显，越充足的时间，开发同学越能跟清晰的评估。觉得这一点也不影响敏捷，

相反，这样做会更敏捷。因为如果能给出更准确的评估时间，一般都会比那些“大概时间”短很多。

我说的，不一定是对的