中国一句古话，麻雀虽小，五脏俱全。

但是小项目也能有大娱乐，google、37sigal，都是以"精小而美"著称。虽然还要面对软件时间，但是不用去面对布鲁克斯法则、不用烦心长长的bug list，不用强打精神奋战在动则几小时的沟通协调会议等等，小项目无疑更幸福^_^。

若让我描述项目管理，我会以站在地狱想天堂来总结之。

一次不开心的敏捷体验。

2年前开始带项目，严格来说是开发leader，如果武功是以毫无杂念为最佳天资，对项目管理却是天生残缺。与其说敏捷让我吃尽苦头，事实最多只是我作茧自缚。像所有人一样，我期望找到银弹解决所有的问题。失败以后，我信奉带人要带心的信条，完全站在开发人员一边。至此，你应该猜到，项目被我推向了失败的边缘。项目关系人对项目团队失去了信心，要求更多特性，更快的交付时期，开发人员越加痛苦。

辛苦却看不到结果，这是程序员最大的痛，也是项目最大的痛。

软件时间

程序员不擅长估算时间，估算剩余时间却是例外。

估算会议上所有人估算出软件的完成时间，但是这个时间不是精确的，这点我知道，一开始其他人也知道。前提是项目关系人没有失去耐心。现在的我会将任务的剩余时间即时更新，并且定出优先级，与客户沟通下次发布的任务。但是那时的我昏了头，一味替团队开脱，可笑却说不出什么时候可以交付新的版本。因为我也是开发人员。

不知道什么时候完成任务？即使完成了也不一定是用户可用的。 --这是项目管理最难的部分。

出现这个问题的时候，你或许正让几个人来完成一个功能。看起来7人的团队，却交付不出两个人的成果。即使存在优秀的程序员胜于10个烂程序员的事实，壹加壹难以等于二却是不争的事实。如果我有两个优秀的程序员，现在我更愿让他们各自完成的自己的工作。因为我再也不想听他们抱怨会议占用太多的时间，我没有时间编写代码了。

布鲁克斯法则

“只有一个月了，还有两个月的任务，你让我如何帮助你。”

“给我加一倍的人。”

如果你这样做了，你一定会失信于人。这个有悖常理的法则把我从最后一根稻草上拉下来。

我不是答复机，现在我宁愿顶着头皮让客户选择最高优先级的任务，然后让程序员更早的demo产品，安抚程序员”脆肉”的心灵。

提防磨刀时间

“手动导数据太麻烦了，我准备些个脚本来完成”

“脚本还有点小问题如果别人希望把关联的其他数据也要导入呢？我要修改一下”

“。。。”

研究新技术，或者编写新工具确实能改善生产率，但不是现在，而是未来，如果未来你还会遇到相同的问题。将来最大的问题是，问题总是以面目出现在你的眼前，即使抛却这个不计，它也是牺牲现在的时间，在将来获得回报。如果项目本来很紧，我宁愿用最笨的方法，也不情愿将另一个软件时间引进我的项目。

总结

人多力量大，对于项目管理而言是艺术，对于现在的我或者其他人都是很难的。如果一个人可以完成的事情，10个人未必会更好、更快。