计划中的那些坑

我们都很能做计划。大概的过程是这样的:内个,大家要做一个新浪微博,然后这个平台要有登录吧,要有这个发微博吧,要有看微博吧,然后登录要这样这样,然后要修改密码这样这样,要密码取回这样这样。然后一个礼拜过后,经理说,我觉得这玩意得三个月肯定能做完!老板说好,那你们开干吧!
这应该是我们在开发前常见的计划的场景吧。但当我们仔细回想起来的时候,“这玩意三个月肯定能做完”,有几次我们真的“三个月”做“完”了?
第一,我们对时间的估计准确吗?
第二,我们对完成的定义准确吗?上线就是做完了?
甘特图

计划的目的是个坑

为什么要做计划?在我们做所谓的项目计划,或是画甘特图之前,我们有想过WHY了吗?而这个WHY在整个团队中是不是一致的?如果这个WHY没有解释清楚,团队的执行力肯定会有偏差。
通常而言,我们的计划是给老板看的,老板心里要一个东西,这东西需要一个计划列出来来评估时间成本。他心里想的是“哦,原来我在三个月之后就能用上这个东西了。”
而互联网环境下更坑,你计划让用户按这个方式来用,可是用户会按另外的方式来用它,比如这个例子:
用不同的方式使用软件

这个时候,我会觉得计划不是个太靠谱的东西。因为我花了一大把时间来计划这东西,最后这玩意根本不是我当初计划的模样,我还计划那么细做什么呢?

计划不太重要,交付更重要

互联网讲究快速迭代,这个快速迭代讲的就是这回事。少做计划,多交付。因为你花了一个月做了完美计划,这时候外部环境都变化了。你这个计划已经不适应这个环境了,实施完成出来已经不靠谱了。那还要按这个计划执行么?

还有一个词叫“试错”。用小成本的东西来验证想法是不是对的。这也是快速迭代的特征。小东西,我们做起来就很快,而不是一直在规划一个很大而全的平台。如果你会问“平台是怎么来的”,我会回答“平台产品一定是重构出来的”。

但怎么交付就是件讲究的事情了。
好吧,我会再花篇幅讲交付的艺术。。

估算时间从来没准过!

是的,对一个大一点的产品的时间估算,我从来没做对过!因为做事情是一个团队的所有人在做,而在产品计划的时间估算的时候,却是我一个人在做估算。估算的时候,我会想着,这个功能我花两小时,张三估计要花一天吧,然后就分配给张三一天时间。

这种估算方式是有问题的。
1. 这个任务一定是张三做吗?
2. 这个任务张三会不会觉得两天时间才做得完?
3. 张三是不是全职在这个项目上?
4. 在项目期间会不会有其它临时更紧急的事务需要团队人力去处理?
……
各种因素会让我的估算变得越来越不靠谱。

其实团队能做多少东西是固定的,这个大体可以称为团队的开发速度。然后平均每周会出现多少个BUG或是临时状况,这个也是可以统计出来的。然后我们如果能估算出总的新任务量有多少,就可以估算出大约的完成点。
估算任务量的方法,敏捷中有一个“敏捷扑克”的方法来估算。比如这种。它的核心要点其实很简单:让开发团队成员来估算。而不是由团队经理来估算。
这种估算总比团队经理估算要靠谱多了!

好吧,坑没写完。。明天继续。。
文章思路讲得有点混乱,经常提出一些问题,希望读到文章的朋友也能有一些共鸣,给我一些你在解决这些问题的建议。或许我们能把事情做得更好:)

Copyright © 2014. All Rights Reserved.

《计划中的那些坑》有3个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注