尽管我喜欢阅读编程类图书,但是我发现,软件项目管理方面的书是最令人厌烦的一类。我觉得这可能意味着说我不适合做项目经理。然而,我在Stack Overflow却恰恰扮演的是这个角色。
我并不是说软件项目管理方面的所有图书都“狗屎不如”,但它们中的大多数就是这样。一些我认为很值得读一读的书中,有一本叫《门后的秘密:卓越管理的故事》,它是由Johanna Rothman和Esther Derby合著的。
读过这本书之后,你一定会觉得它是每个初涉软件项目管理的人必读的。你还会感觉非常沮丧,因为你一定没有和同样读过这本书的软件项目经理合作过。
我最早知道Johanna Rothman,是因为Joel Spolsky在他的《Joel谈优秀软件开发方法》这本书里引用了她的一些观点。她还写过一篇关于团队报酬的文章,读过之后让人如沐春风,并促使我重新审视了自己关于工作报酬的看法。你也应该读一读这篇文章。如果你是一位管理人员,你还应该让你的员工读一读。
这篇文章的网址是:http://www.poppendieck.com/pdfs/Compensation.pdf。实际上,这篇文章的作者是Mary Poppendieck。——译者注
在那之后,我还在另外两篇文章里(“Schedule Games”和“Egoless Programming: You Are Not Your Job”)简短地讨论过她的观点。但是,我更倾向于阅读我不太擅长的项目管理方面的文章。曾经有个播客的访客让我去回顾四月底我对于Stack Overflow开发的计划时间表,结果我发现,当时计划6~8周完成的事情实际上用了3个多月……
我碰到的麻烦是,我几乎没办法把东西写出来,除非我是在写博客。我前进的节奏很快,因此我更喜欢在脑子里盘算我正在做的事情,顶多再想一下我打算接着做的下一件事。对于下面的这个场景,我感觉有些折磨人:
“你看,Mike。”Tomas说,“我可以今天提交代码,并且可以说功能已经完成了。但是,以后我可能还需要3周的时间来进行一些扫尾工作。”Mike问Tomas扫尾工作是指什么。“我还没有拿到公司商标,所以现在每页都是缺商标的;并且我也没有拿到代理人的名字和电话号码,所以每页的底部现在也没有这些信息。但这些基本都是小事情,其他重要的功能都已经完成了。我已经完成了99%。”
看出这里的问题了吗?我知道,会有很多关于无法把所有事情罗列出来的借口,但这里最最根本的问题是什么呢?
这个软件工程师并没有一个清单,把自己要做的所有事情都列出来。这就意味着,即使他坚信自己已经完成了99%,他还是不知道这个项目什么时候可以做完!他的时间表是没有真实依据的。
一个好的软件项目经理的任务就是,要在项目出问题之前及时发现并且找出问题之所在。怎么做到呢?鼓励并且强制要求程序员创建一张他们所要做的全部事情的列表。然后再为其中的每一项列出子项,并且尽可能把所有的子项都加进来。程序员们总是会遗漏一些什么,因为他们有时候想不到那么长远。一旦你拥有了这么一个包含所有事项的列表,你就可以开始估算这个任务需要花费多少时间了。
在你开始去创建这个任务列表之前,所有的时间表都是白日梦——一个彻头彻尾的白日梦!但是在现实世界里,这种白日梦是不可原谅的。
Johanna Rothman在她最近的邮件简报中阐述了类似的观点,并且提出了几点建议用以避免“只能完成90%”问题的发生:
1. 把你在一个大项目中要做的所有事情全部罗列出来,包括那些基础设施工作,比如配置源代码管理系统的分支。
2. 估计这个列表中每一项所要花费的时间。这种最初的估计可以帮助你看到整个项目大致将会花费多少时间。
3. 现在,再看看你列表中的每一项要花多少时间。如果有一项的时间超过一天,则把这项拆分成若干小项。这种将大任务拆分成小任务的方式是解决“只能完成90%”问题的关键步骤。
4. 找出一种呈现任务状态的方式,以便那些感兴趣的人可以了解。如果你是一名员工,你打算怎样给你的经理看你的项目状态呢?或许你是经理,你想要看到哪些内容呢?你大概想要看到一个测试用例列表、一个演示或者是某种能够给你看到项目进度的形式。
5. 既然你已经拥有很多小的任务,并且这些任务所消耗的时间都在一天以内,你就可以每天追踪自己的任务完成情况。我喜欢把每个小任务的原定计划和实际完成时间放在一张表上,这对于管理人员来说是非常重要的,他可以从这张表上看出某个人是不是被打断了,抑或是在同时进行多个任务。
我不太热衷于计划时间表或者任务列表。但是,如果没有任务列表,就不可能有靠谱的计划时间表。这有点像挑战万有引力定律。因此,我们在项目中总是只能完成90%。如果你想要让你的软件项目摆脱这样的困境,别像我一样费劲千辛万苦才找到方法。如果有人过问你的时间表,你应该要能拿出一张你要做的所有事情的列表。如果你拿不出来,你所要做的第一件事情,就是要做出来这么一张列表。