项目管理的怨念

    三十年前，领导了规模达到5000人年的项目（OS360）并且最终彻底失败了的那个项目经理布鲁克斯写了闻名软件业界的《人月神话》。 过了二十多年，《人月神话》传入中国，震撼了国内软件业。 那么，是不是表明我们在软件项目管理意识上落后别人至少二十年呢？
    很多人不屑我这个推论，认为是强词夺理。 可是好多事情都使我认为我这个推断不但没错，而且还有低估。 也许，落后三十年也不止。
    好吧，看些实际的例子：
怨念1：

    中午和朋友一起吃饭，一个有1x年项目经验，n年项目管理经验的人对我说：“你应该开始学习项目管理。”

    我说：“好，可是怎么学。”

    于是他给了我好多文档。 其中有148种表格，“这是一个完整的项目中应该有的东西。 要做项目管理就要学会写文档做表格。 ”

    “…………”

怨念2：

    “为什么每次项目结束，你们要把一个团队打散？”我不解地问道。

    “当然啦，每个项目特点都是不同的，所以我们需要不一样的人来完成。”
   
    “可是这样一来，辛苦组建起来的团队不是都没了吗？”
   
    “但是我们不可能让同一个团队去做所有的项目啊。”
   
    “是吗，那比如说到底需要哪些地方不一样？”
   
    “呃……这个……比如说一个项目在天津，一个项目在上海，……”
   
    “…………”
   

……………………（无数的怨念）

    模型、表格、甘特图、方法论、流程、CMM、……这些东西的目的到底是什么？ 看着那么多所谓的管理者舍本逐末，还认为自己深谙管理之道，实在是令一个员工痛心。
    老板问一个拿着所谓的需求规格说明书的技术人员问：“怎么样？”我们常会听到这样的回答：“呃，还行吧，就是有些地方写的不是特别清楚。”“好吧，我知道了，那你再和需求人员沟通一下，抓紧开始做吧。”真的是这样吗？ 当然不是。 只是没有一个人会说实话：“这个根本就不是什么需求规格说明书，这份文档一点用都没有！”
    详细设计就不谈了，为了一些所谓的流程，辛辛苦苦写了一叠详细设计文档。 然后开始编码了，详细设计文档就不知道被扔到哪里去了。 好了，编码结束。 “你看，我们的开发人员有个很好的习惯，叫做交换代码走读，你知道吗，这个是发现bug效率最高的方法。”是啊，我也知道。 可是你知道为什么吗？ 因为你根本没做详细设计，你那一大堆所谓的详细设计文档不但一点用都没，而且还浪费了所有人的时间，延迟了进度！ 没有一个编码人员是根据详细设计文档来编码的，所以才会在代码走读阶段很容易得发现那么多的缺陷！
    究竟哪些事情是管理者真正需要考虑的？ 其实只有四件事情：
        1 雇佣正确的人。
        2 分配给他们合适的事情去完成
        3 始终保持他们的积极性
        4 使你的团队拥有足够的凝聚力
    那么，管理者管理的一定是一个团队了。 可是什么是团队呢？
    一个团队如果有n个人，并且能得到超过n个独立个人的产出，这个就叫团队。
    团队的形成是需要时间的，而最好的方法莫过于让一群人在一个实际的项目中建立一种彼此之间的默契。 当这个项目结束以后，除了项目本身以外，最大的收获莫过于培养了一支有一定默契的团队。 可是，你居然就这么把一个团队解散了，还美其名曰适应不同项目需求，这纯粹是胡扯。 做开发的人根本无所谓一个东西是用java还是用.net来开发，对他来说区别只在于业务。 了解了业务，做好需求和设计，编码根本是没难度的事情。
    哎……我也明白，很多事情确实是需要时间的，我只希望这次的选择不会再次让自己郁闷到辞职摆地摊。