什么样的人适合看这篇文章？

　　1、项目经理
　　2、希望改进团队现状的技术人员
　　3、学习软件工程觉得是一纸空文的大学生

如果您并不觉得软件项目管理是一项管人的艺术，请阅读我刚无意收集到的一篇文章《一个敏捷教练中止越轨列车的故事》众所周知，软件的开发离不开技术，但是也同样离不开管理。虽然这只是简单的一句话，但是不同的人却对其有不同的理解，有的人将重点放在“技术”，有的人则将其放在“管理”。当然这样的判断都是全然无效的，首先二者都是必备的，再者由于不同项目的具体细节所导致的技术和管理的比例不尽相同，因此我们只能因地制宜地去创造我们的软件，缔造一个又一个的人月神话。

不知道您是通过什么途径了解软件项目管理的呢？以下列出几种我觉得可能的情况：

1、大学课本，很多大学计算机专业都必开软件工程一门课，其中就对软件项目管理大张旗鼓过。当然据我所知，同学们往往一无所知地完成了学业，因此这门课所给他们带来的意义远不及生产实践。

2、大学课本，（重复？NO）很多大学的管理学系同样也开设同样的课程，当然他们的重点是项目管理，但是也涉及到一些软件项目管理的项。

3、IT经理，也许你认识一些IT经理人，他们总告诉你他们的团队的种种故事，也许你不一定听得到“软件项目管理”几个字，但是你一定能将他与本条途径对上号。

4、程序员，也许你的朋友正在从事软件行业，因此他们对他们团队所发生的事也给出了种种说法。

5、图书，当然了，这一点很明显，因为软件行业是个巨大的市场，也有很多的学者投入其中。很可观的实际情况告诉我们这类图书通常依托于一些现实场景进行描述。
　……
　不再一一列举。

软件项目管理，究竟是一门什么样的学问？

软件项目管理，究其本质其实是一项管理，它应该被描述为一项管理软件人员协同工作的职责。

现代软件的特征表明，一个成功的软件的开发将不是或至少通常不是一个人所能够完成的，而是由软件团队协同完成的。如何组织协调软件团队有序有效地协同开发软件是软件项目管理的伟大职责。我们有理由相信没有良好的软件项目管理的团队是无法高效地适应现代软件行业竞争的。因此，软件项目管理的重要性一直被看作软件工程中的至关重要的成分而被列入项目经理的必修课。

经常听说，大公司/外企所拥有的是一个有效的管理团队，从大公司出来的人，之所以吃香，是因为他们所耳濡目染的管理经验能够带来对新公司生产力的一种提高，或者说，这层“管理能力”将成为他们梦寐以求所镀的金。

软件项目管理，不是管技术的技术，而是管人的艺术。

说说我得到的关于一些外企工作方式的一些例子。一个知名的外商独资跨国公司软件部，接受该公司在中国大陆的软件业务的承接，并完成70%以上的海内项目。他们的工作生活在明确的分工之下，从承接项目开始后，顺序完成软件项目的需求，设计，制作研发，测试等任务。期间包括从项目审核开始的各项流程，完成这些前期工作的时间占用了整个软件项目开发60%以上的时间，之后才开始代码的编写。当然设计肯定不是完美的，期间的修改也是围着主干道，八九不离十。再经过严格的测试才有最后的软件产品。这些和我们所得之的许多软件项目管理书中所提及的比例分配也不谋而合。

国内的情况呢？我们可以说现在软件公司的数量参差不齐，大小规模更是另人诧异。我不能一棒敲死所有人，但是我相信很多公司总是这样：项目经理得到项目之后就开始思量着怎么开始这个软件的设计，于是很快召集人马把数据库先架起来，然后也写了一份还算能用上滚动条的word文档，招来手下，开始给他们讲解这个项目的各个模块，之后的工作可想而知，就是进入coding。项目很快就落户VSS了，上面也能找到×××项目需求文档。

时间上呢？海外公司可能在项目到手的一个月内一直在写文档，导致程序员都不知道自己是不是应该换位叫文员，大陆团队，程序员怀着为软件牺牲的热情，开始了没日没夜的代码生活，写的是他们最喜欢的代码，而不是文档。

一个月过去了，海外公司终于启动了编码进程，而大陆团队可能已经写完了大部分模块了。（国内很多项目经理本身也就参与编码工作，并且还是不可或缺的人物）项目经理开始逐一查阅成果了，项目经理还是资格比较老一点嘛，就开始和手下沟通了，

这个页面怎么这么难看啊？你不觉得这样很难看吗？你就不会……于是，改。

这个功能好像不对啊，我上次应该是跟你说的很清楚了，你怎么忘了？……于是，改。

这个做的倒是还可以，不过，这里、这里、这里，你不觉得用得很不舒服么？于是，改。

这个，你参考一下我做的×××，我们现在都尽量不用图片了，你不能跟上一个项目一样啊，我们可以变得嘛，我都已经改了，你也改成这样吧，（反驳：不是以前说要做成这样么），那是领导的意思，换用文字不是更直接么？（反驳：可是以前做成这样就被说过不行的呀），你还是听我的，改成这样吧！于是，改。

这个，这样做不太好，你不觉得不方便么，而且技术上做的这么复杂，分开，为什么还沿用以前的××风格，现在这个**风格的做法不是很好用么？为什么不用？于是，改。
　……

程序员一直纳闷，这我也是想了好久的呀，要是换我当customer，这样感觉很好，至少比××样好，嗨，不过也只得改，反正按时间算钱……

根据要修改的数量，可能这样修改的时间可长可短。但是新的问题又来了，当程序员拿着改好的程序去交差的时候，项目经理又开始指点江山了，当然了期间居然还有遗留忘记的问题未修复，当然，还经常由于修改而引入了新的问题。于是：你这个东西你自己都不用一下么？怎么会这样！这样要返工的啊！（反驳：我刚才没改这里…￥……%&#）当然了，还是得改，再深究，还有好多的问题，被项目经理“追求完美”的眼光所识破，于是，整个程序又经历了长达大半个月的施工大功告成了，但处处有着未知引入的种种问题。

也许你会说改项目的时候用重构，再用测试去保证自动验证，再……，但是现有的框架或许根本不是那块种菜的沃土，现有的团队，压根就没有所谓的测试技术予以保证。

从以上的示例中我大致抽检成以下几种：

用户体验

项目也许正朝着“良好用户体验”的广告上靠拢，并高谈阔论之，但实际上这些“用户体验”又仅仅只是某些人的主观判断，当然在美上，人人都有发表意见的权利，但却不是每个人都能做出最后的决定的。

规范规格

没有明文规定的内容大有死无对证的隐患，造成的冤假错案，更是诸多其他问题的根源。因为一直在强调是管人的艺术，而人是有思想有主观能动性的行为体。被“冤假错案”搞得一头雾水的人，可能会上产生恐惧或排斥的心理，这种心理对于管人的艺术是不和谐的，但饮水思源，问题是谁造成的呢？都归结为那个项目经理么？不尽然，更具体地说是管理策略上的不严谨造成的。

技术变革

有效地团队沟通是团队管理中必不可少的组成部分，而以上案例明显没有做到有效地沟通，或者也可以理解成规范规格的非标准化所导致的。

事情发展到这里，海外团队已经开始进入年度旅游计划了，而国内的团队，如果没有新项目，则在接受用户的意见，当然可想而知，改是必然的，当然海外团队返工的可能性也不是没有，但问题是他们的产品已经事先和用户达成了“一致”（由于用户可能在需求阶段也是被软件团队搞得一头雾水导致也不知道定夺的方案是不是产品的效果，但这样的成功率相对于后者，则普遍高多了……）大陆团队呢，如果需求做得业余，则问题将会大量出现在业务逻辑和用户体验环节，这方面所带来的影响对整个项目都是致命的。项目成本变得不可估计，很有哪天用户不满意了，一切就得从头开始，而所有的错误都发生在一开始的“假设”上。大陆团队总是假设自己的需求以及实现对用户来说是如此地easy，大陆的用户又经常是逆来顺受的类型（见不多识不广，再加上可能是长期合作伙伴的关系，因此更能“适应”那种糟糕的体验），而大陆的团队则认为他们的东西用户都是“没有意见”的，因此愈发他们的自大和自狂……，当然这绝不是大多数软件公司，但起码我相信是一部分。

大陆团队

现在的团队已经疲惫不堪，项目经理认为手下都是废物，一点小事办不好（相反，自己做的东西则如此地美好，沾沾自喜中……）

手下：嗨，做的又都改了，高傲型的，则愤愤不平，你做的那也叫用户体验，落后；逆来顺受型，嗨，下次多注意（开始扭曲自己的主观判断，并开始谨慎行事于未来的项目）

关系：本来和谐的办公室出现了隔膜。

这也难怪人家说外国人思想比较简单，而中国人，思路太复杂，这样看来，社会因素是导致这一复杂关系的根源，这种不利的沟通则成为团队中的不和谐音。而管人的艺术遇到这样的音符将显得死气沉沉。

外国团队

由于文档化做的很好，因此在出现问题的时候，打开文档，心服口服者了然于胸。责任不会被推卸。（记得卡耐基说过，通常的人是不会或者没有人愿意承认自己是错的，即使承认了，也并不是100%地这么认为……那我们又何必引入这样一种环境去滋养这样的细菌生长呢？既然可以让白字黑字来撇清这种无聊的人际因素……）

文档化也利于项目验收，当用户对自己拿到的产品不满意的话，他们需要为改进而付费，而大陆团队在这方面则没有任何优势，只能被告知，你做错了。

因此在软件项目管理中，文档化可以作为解决软件团队沟通、规范等重要因素的解决方案。

这时或许能听到大陆团队的项目经理传来的声音，现在我们的团队哪里有这么多时间去做这些功夫啊，那些文档能当按钮点出效果么？不能？我们要的是程序，不是文档！再者，你这些所谓的文档谁来写？了解需求的就我一人，你想累死我啊？还有，就这么点大的系统一点难度都没有，写那些干嘛？

这些问题既然被提出，就一定有它存在的道理，的确小团队要完成这样的任务是需要付出风险的。

首先项目经理不愿意写是一方面，因为很多急性子不耐于写那些他们称之为形式化的东西，但事实上他们是形式上的吗？事实上它们正在潜移默化地改变我们的工作方式，并从一个侧面改善程序的构造过程，使之不是被扭曲地成长起来的。或许之前的关于时间分配的规律不适合您的团队，但文档化总是或多或少能解决您当前的问题。

再者，要解决文档粒度问题。曾听朋友说他们公司的文档细致到100px×200px这样的粒度，对各个可见部分的长宽高都做了严格的设计，另外，在代码设计上更是细化到方法体。当然这并不是我所推荐的，并且我也没什么可推荐给您，因为这个问题从来就没有也不应该有答案，您得根据您的团队制定出符合您粒度的项目，细化到方法体的做法，可能会导致很多现有的软件团队直接疯掉。

最后，强调文档在改善人际关系方面的作用。这方面问题最危险也最可怕，小则影响心情，再者影响工作，甚至危害到您的身心健康（别自己气死了或者把别人给气死了……）。人的心理是整个软件项目管理中最复杂的部分，良好的团队不是强调有队员要有团队精神的团队，而是创造能激发人自身最强团队精神的团队，因为发自内心的和刻意伪造的是没有可比性的。

如果您的团队还在口头传达，如果您的团队还在为除了业务领域逻辑以外的纯规范问题而争执，如果您的团队还在忙碌于修改代码的痛楚之中，请尝试本文所提及的方法，不敢保证它一定有效，但不烦一试。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号