评人月神话-兼谈项目管理

    我是在 03年春节回家在火车上看这本书的，其实书早买了，我当时还只是一个普通的程序员，因此，觉得看这本书还不是很必要。后来我做了项目经理，很多工程以及管理方面的理念都是来自于这本书，很长了，我只能凭借我的记忆基于我的理解来谈谈。
　　软件的现状是什么样的？文中认为做软件就像是在“焦油坑”中，苦苦挣扎，却越陷越深，焦油坑中是累累白骨。对于管理混乱的项目，这个比喻很形象。
　　这里我还需要多说几句，好像是《代码大全》还是哪本书，提到过一个问题，软件的隐喻是什么？大体上有：流水线，建房子，种树，艺术创作，其实都很贴切，只是都是针对特定类型的项目而言的。项目一般分为，研究类，研发类，开发类，实施类（名字是我随便取的）。研发类，指的是产品研发，既有研究又有开发，因为通用，所以需求很复杂，深度和广度都很大。开发类，就是做项目，根据需求定制开发即可。实施类，一般是有产品，但是需要二次开发。
　　项目的组织结构，人月神话中有“外科手术式”的团队模式，就是一个主治大夫，其他的如助理大夫，护士等，都是配合主治大夫来进行手术。想要建立这样的团队，你的团队中得有这样的牛人，如果你看错了一个看起来说起来都很牛但是做起来不牛的人，你这个项目算是毁了。如果你团队中没有这样的人，那么你可以建立一个议会制，拉几个资深一点的，大家一起讨论，共同决策。如果大家都很平均，对所做的内容都不熟悉，最好全民公决了，大家一起研究，一起讨论。建立怎样的组织架构是项目成功的关键。
　　在谈谈人月关系，就是人力和时间的关系，人月神话这本书的书名是来自其中的一节，1个人 6个月，和6个人1个月是否等同？肯定不是这么简单的算法。我认为，一项时间比较长的工作，控制在2-3人是比较合适的。项目是否要加人，需要考虑到如下几点。首先是加人融入团队熟悉工作的时间，其次是加人后的沟通成本，三是工作是否可以进一步细分，四是工作的备份。临时加人，算是项目经理的失职，好的项目经理在项目开始或者初期就应该估算到需要的人员，中后期要加人，则要求有经验，能很快上手，当然，如果为了以后培养，则没有这个要求。另外，人越多，沟通起来就越困难，老人可能需要花很长的时间才能跟新进的人员交流清楚工作内容，另外，每个人的理解是有差异的。根据我的经验，人员越多，花在开会和讨论上的时间就越多。还有一点也很重要，工作是否可以细分为两人同时做，如果细分不了，加人也白搭。最后一点，老人合同到期后的去向，如果准备走人，肯定得加人，做为一个备份，免得人走了，活没人可以接手。
　　《黑夜传说》大家估计都看过了，人狼必须用银弹来杀死。书中说，软件开发没有银弹，我觉得这个观点是有些悲观。用发展的眼光来看，其实银弹是有的，只是人狼进化太快了。另外，开发软件，比如管理软件之类的，还是有很多成熟的框架可以用的，对于提高开发效率，提高软件质量的帮助还是很大的，另外某些公司，也正在研究开发平台软件，用开发平台来开发软件，这个方向也许是软件开发的银弹。但是要看到，你给了最好的给客户，客户还要更好的，从这个角度上来说，永远没有最好，也永远没有银弹。
　　这本书，不是讲“鱼”的书，而是讲“渔”的书，你应当学习软件工程的思维方式，以及项目经理的视角。