软件项目管理中暴露的最大问题[1]

很多朋友都有过或者正在管理一个或者多个软件项目，那么我的文章就从这个问题开始：如果单纯从表象来说，软件项目管理过程中暴露的最大问题是什么?

不同的人的会有不同的答案，但是大致这样的答案我想大部分人都是会认可的，那就是“进度拖延”。进度拖延当然是表象之一了，其他诸如质量不过关、功能不完整等等，我觉得都是和进度拖延密切相关的。很多项目经理都想去做那些认为是十分必要的事情，比如计划、测试等，但是“没有时间”。为什么会没有时间?等到项目总结的时候，我们总会罗列出一大堆的理由试图来说服自己，说服公司甚至说服客户。但是如果限定项目经理只从自己身上找原因的话，我想问题就不难找了。

这里，我用“丰田”的“五次为什么”方法来问这个问题，以及我觉得可能的回答：

一、为什么项目进度会拖延?因为没有按照项目计划进行!
二、为什么不按照项目计划执行?因为进度总会有拖延，缓冲时间总会被用光。
三、为什么在计划时候不规划得更细更贴近现实一些呢?再细也总有额外的工作出现。
四、为什么不充分评估每一个工作，让预料之外的工作尽可能少呢?因为确实无法评估下去了，很多认为是原子级的工作都会产生出各种问题。
五、没有可以参考的其他项目的项目计划吗?因为两个项目的不同点太多，很难重用。

问到这里，我想一般项目的核心问题也就显露在我们的面前。现在先不去谈论这个问题，我们用几个简单的例子让他更生动一些。

我们用一个非软件的事情举例，让大家为这个例子作一个详细的项目计划并评估出最精确的时间。

例子1：请大家评估各自把我的这篇文章重新打一遍的时间。

这个例子最简单了，拿我自己来说，我打字速度为每分钟30个汉字，所以这篇文章重新打一遍的时间就是文章的总字数3000/30=100分钟。加上中间休息的时间，最多就是120分钟。

答案相当准确，我想也不会有太多人有异议，但是下一个例子可能就有些不一样了。

例子2：请大家解开下列的方程式：x2+px+q=0, p=2, q=1

初中的方程式阿，但是很多人可能忘记它的通用求解公式了，不过我们假设大家都知道这个求解公式：-p/2±sqrt(p2/4-q)。评估时间的时候我们首先要知道我们打开计算器的时间，输入数据的时间，抄录结果，并且为了保证计算准确，我们需要进行验算。嗯，这样估算时间的权威性恐怕不如例子1那样令人信服了，而且我们经常需要因为算错而重新计算，超时恐怕很难会避免。

例子3：请大家按照我的引言，结合自己的项目实践，重新写一篇吧。

嚯!如果谁能准确估算这个时间，就应该是高手了。看看我们为了完成例子3需要我们作多少事情吧：制定写作提纲，勾画写作内容，评估打字速度和每一个内容的量…依我看，不用计算了，计算再多，这个工作的进度依然会被拖延。

这三个例子有区别吗?当然有!例子1的估算方法大家都掌握，而且执行过程中的变数最少，因为并不需要我们去做任何的探索过程(猜某个字的五笔字型不算，至少我用微软拼音)。例子2的不同点是解题的方法需要外部因素的介入，而且这个技术并不是每个人都掌握(或者记得)，最重要的特点是每一个步骤我们都需要去估算它完成所需要的时间，如果我们已经计算过一次了，当然第二次就会估算的更准确一些。可是现实生活中的项目很少会给你机会重新做一遍。

当你完成项目之后，跟这个特定项目相关的各种方法也就失去了它的作用，它唯一的价值就是潜入你的记忆中，成为所谓的“项目经验”，而这个“经验”也常常会在下一个项目水土不服。相比而言，例子2好歹是一些看得见摸得着的动作，评估起来也会有一点依据，而例子3则几乎是一个纯粹的大脑运动，要让大家凭空组装成一篇好看的文章，我看这个进度要估算也太难了，谁知道为了一个内容，我们要反复推敲甚至发呆多少时间呢?!

我们把话题拉回到篇首的五次为什么上来。软件项目甚至其他项目能够按时完成的最主要一点就是要做好“计划”，能否规划一个符合实际的项目计划，是项目成败最大的晴雨表。

要让项目计划贴近现实，首先我们需要把项目中所有的工作都罗列出来，然后把每一个步骤地工作进行细分，以致细分到“原子级”，也就是不能再分的程度，从软件项目来看，就是分到“文件”，分到“类”甚至分到“函数”级别。然后对这些“原子级别”的工作进行评估时间，累计综合，最后乘上一个系数(一般是2)，就是最终项目所要花费的时间了。

说起来容易，做起来难!光是要求把工作细分到原子级，就已经足以让一大批项目经理当场晕倒了。

　我们再回来看例子2，如果解题的人忘记了这个求解的公式的话，前面估算的进度是否需要调整呢?回答是肯定的。这样的时间计算就需要考虑寻找资料的时间，只要找到公式，计算出结果就不是问题了，而找公式所花费的时间，在有通畅的网络连接情况下，包括网络搜索、询问同事等等方法，一个小时足矣!