今天是愚人节，对这愚蠢的节日一向很反感，没有任何意义，只是一味的靠耍人找乐，手机上也偶尔收到一幽默短信，简单一笑置之。愚人节对我没有什么影响，也没有什么值得记忆的深刻愚人事件发生，但是这个日子还是让我进入2007年的春天有了个释放情怀，拥抱大自然的难忘的机会。
  因为这天我和一些伙伴去了济南南部山区－－梯子山。
他们几个都已反复去梯子山n次了，路已经熟悉的不能再熟悉了，而我每次都是擦肩而过，不是出差就是有其他事情错过去游玩。其实，当初我不是一个喜欢到处玩的人，因为踢球对我来说才有着无比的吸引力，自从认识了老婆，一个不能称之为真正驴友的驴友，才算是真正融入了大自然，感受大自然的清新和静谧了。
  周日一早6点我就起来了，虽然周六踢了一早上足球，浑身酸痛，但还是早早的起来，老婆还是习惯性的懒睡一会。简单的洗漱、收拾一下东西就出发了，一向总是迟到的我们居然是第一个早到的，等了半小时左右人员到齐。
  说是人员，其实就只有我们六人，三对夫妇。
  65路车向来人多拥挤，周末就更不用说。人少好控制，六人轻松挤上车，坐就不要想了，能有个地方站就是万幸。
  一个半小时的路程到达西营，15元租一面的，轻松到达梯子山下一村庄。
  梯子山海拔估为993米，从山下看还是仰起脖子眯着眼，当天雾大，看不到山顶，对我初次来者说，还是深不可测。当然本人是不会被此小山吓倒，还是很相信自己的体能的。
  上山了。。。
  山谷、山脊、山顶，到处传来强人的喊山声，像对梯子山的挑战，阵阵呐喊，足以振奋人心，没有理由退却和害怕。
  根据以往的经验，登山开始，是体力耗费最大的时候，此时身体和生理机能都没有舒展开，是对人的考验最残酷的时刻，爬了没几十米，汗水，可以说是虚汗，便浸透了衣服。看着老婆，累得脸儿红润有加，汗珠滚滴，虽然心疼，但也不能对她说什么，不然乱了她的方寸，影响登山的士气，慢慢调整吧，还是很相信老婆的体能的，毕竟近两千米的泰山后山她也能轻松翻越，只是偶尔给她拍一照片来鼓励她一下。
  登山路，其实根本就不是路，是前者踏出来的一痕迹，没有一合适的踏足点，全靠身体的平衡来调节登山的节奏和路线，山壁很陡峭，足以有75度的倾斜（后遇一强人所说），山越陡峭，我们的身体倾斜弯躬就越低，全身就像贴附着山路上一样往上慢慢蠕动。
  六人互相吆喝，互相鼓励着攀登，看出脸上汗水映衬的累态，没有一个人说累，更没有一个人想放弃。
  右手遮阳，抬头看山，“还有多高？”，但是每次的回答都是“快到山顶了”，也许这是一个非常合适而且非常乐观的回答，明知还有一段距离，但是‘快到山顶’还是给自己足够的信心和力量。
  爬了200米左右，体能已经不是那么重要了，此时的爬山者已经不再依靠体力，而是完全依靠自己的意志力，机械的抬起自己的左腿、右腿，汗水也不再有开始那么多，累了，寻找有利地形，就地而坐，稍息片刻。
  转身看望山下，才发现经过的村庄已经变成了售楼中心的小区模型了，一览无余，偶尔传来经过村庄看到一栓着黑狗的无奈的鸣叫，像是控诉残暴的主人打乱了这个大自然的和谐。对面山腰，蠕蠕而动的身影隐形可见，大吼几声，算是对对面知己的友好招呼，也算是互相鼓励一番。
  爬、继续爬。。。
  此时的我们已经不再感觉累，路型变得愈是复杂，而且也愈陡峭，开始手足并用，路上的断石经过无数英雄的次次踩踏已是相当牢固，不用担心滑坡或者人足踏空。
  转弯、拨开松树枝，排除障碍，大家的攀爬已经很是娴熟，互相提醒路况，当心脚下，本是对体能和技能要求很高的登山活动，让我们诠释的成为一休闲娱乐。
  偶遇。。。。
  我们登山途中，见一老兄在一有利地形，算是一片空草地，躺在草坪上，翘着二郎腿，户外遮阳帽盖在脸上休憩，嘴里哼着小曲，很是享受这大自然的滋润，此君算真是把登山的乐趣解释的淋漓尽致了。
  经过大家近两个小时的战斗，终于到达山头。
  站在山顶，身开双臂，面向阳光，紧闭双眼，享受阳光和山风的的沐浴和洗涤。此时的我们可以把所有生活的不快、工作的不顺完全的抛向脑后、山下，什么也不去想，尽情感受站在山顶上那种居高临下，身居大自然，陶醉于大自然的惬意，释放自己郁闷、疲惫、不堪各种矛盾折磨的情怀。
  睁开眼，身边多出的两位算是让自己又重新认识了人的意志和力量。一对夫妇居然从后面赶上我们，看到男的，不仅让我佩服折叹，此君有1.9米的身高，100多KG的体重，特别醒目而且就是让我佩服的就是此君腆着的将军肚，残酷一点形容就是一个水桶，感到他运动裤的松紧带能撑托起他这变形的肚子，真是不可思议，但是就是这么个不可思议，轻松的登上这近1000米的高山。
  登上山顶，算是任务完成一半，找地腐败，补充能量。
  拿出准备丰盛午餐，大家尽情享受，水果、牛肉、鸡蛋、烧饼、已是美味可口。
  腐败结束，天南地北忽侃一番，鼓足干劲，力争上游，继续出发，寻找下山出路。山顶上没有什么障碍，清晰的蜿蜒小路足以让我们恢复精力，尽情享受山风拂面。
  走不多时，遇到一长龙队伍，看队形应该是一有组织有纪律的驴友团，里面不仅有30好几的妈妈级的女士，而且还有两个不到10岁的小女孩，看到他们爬上来，居然还是那么轻松惬意。大自然的魅力，真是无穷啊。互相问候，互相鼓励一番，回去路线不一，便分开。
  我们走向山谷，经过一滩乱石坡，对我们来说这就是路，硬是扫除一切障碍，下到谷底。
  谷底居然有了碎石路，有了路，便有出口，顺着路走吧。
  此时的季节，干旱少雨，据他们说，多雨季节来此地，到处是溪水潺潺，积水成洼，看来，我此次来只能遗憾山水不能融为一体。
  到一平地，可以说是平台，上面立着不知是唐朝的诗人还是宋朝的词人三尊塑像，也许这是近处水涟峪景点的一观景台吧，在此处拍照、模仿秀，摄影师们疯狂了一把。
  继续出发。。。
  女人就是女人，路两边冒出青草，便说是山韭菜，可是闻起来怎么有种蒜的清香，便躬身拔起来，回去炒个鸡蛋就又能省上几毛钱，看着老婆那么辛苦的摘，于心不忍，上前帮忙，顷刻间，一片绿油油的韭菜还是蒜苗便只剩下弱细的摇曳了，大自然就这样慢慢的被破坏，人还真是坏啊。
  不知不觉进入收费景点，应该是水涟峪吧，当前算是淡季，而且正在整修，也没有什么游人在此休闲，往日泉水，缺少雨水也失去了精彩的溪水长流的壮观景象。水库也在整修，也许此景色便会失去大自然的固有魅力。人工造景，不知是破坏大自然还是给大自然做嫁衣。
  出来水涟峪，便是返城了，整个登山驴行在身体疲劳、心情愉畅中结束了。
  事业、爱情都可以造就生活，但是缺少大自然的滋润，生活就不会如此的精彩。

君子之交淡若水，小人之交甘若醴
要有度，保持距离，不能太近，避免开过于亲昵或者过火的玩笑
多关心别人，同事遇到困难要热心主动的提供帮助，
工作之外，午餐、晚餐吃饭时经常一起吃，也可以增进感情
一起活动，经常参加大家都喜欢的集体活动，比如打球、打牌、卡拉OK等
最重要一点，互相尊重，
不打探别人隐私，不背后说别人坏话，
多赞赏别人，用心欣赏别人，赞扬要有度

有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。

4.3.1 客户说不清楚需求
有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。
有些客户心里非常清楚想要什么，但却说不明白。读者可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。
如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

4.3.2 需求自身经常变动
唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。”（《大话西游之大圣娶亲》）
连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。
软件的需求会变化吗？
答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]
让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。

4.3.3 分析人员或客户理解有误
有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”
软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。
由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”
为什么软件系统分析员的工资要比普通程序员高？就是因为需求分析困难嘛。

序言
目前，电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明，这类信息化建设项目在国内外成功的比例都不是很高。正因如此，
项目管理引起这个行业人士的普遍关注。同样，也有数据表明，西方国家的一些企业采用项目管理后，项目成功的比例有显著提高。
作者根据十多年项目管理实践经验，以及研究、培训和咨询的知识积累写就这篇文章，相信对信息化工程项目的建设者会有帮助。
本文涉及信息化建设项目管理的内容包括：项目经过的阶段；项目的计划、实施和控制；开发商对项目的管理；用户对项目的管理；项目的组织问题等。
一、信息化建设的几个阶段
信息化建设项目按时序划分，一般经过可行性研究、系统分析、系统设计、
开发和测试、安装调试、运行维护6个阶段。
1、可行性研究阶段
可行性研究阶段段的主要任务是：识别需求，对项目产品进行描述，确定分阶段实施的进度，从业务、技术、经济效益等方面进行可行性研究，形成可行性报告。
2、系统分析阶段
系统分析阶段的任务是：对现行系统进行详细调查，分析业务流程，分析数据与数据流程，分析功能与数据之间的关系。指出现行系统存在的问题和不足之处，确立新系统的基本目标和逻辑功能要求，最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统“做什么”的问题。因此，这个阶段是整个系统建设的关键阶段。
系统分析阶段的工作成果为“系统说明书”，这是系统建设的必备文件。系统说明书既要准确又要通俗易懂，用户根据系统说明书可以了解未来系统的功能，判断是不是他们所要求的系统。
“系统说明书”一经通过，就是系统设计的依据，也是将来评价和验收系统的依据。
3、系统设计阶段
系统分析阶段的任务概括地讲，已解决了系统“做什么”的问题，系统设计阶段要回答的问题则是系统“怎么做”。也就是说，根据系统说明书所规定的功能要求，考虑实际情况，具体设计实现逻辑模型的技术方案，即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。
这个阶段的技术文档为“系统设计说明书”
4、开发和测试阶段
开发和测试阶段是按物理设计方案付诸系统实现的具体工作，包括开发与调试程序，采购硬件。
这个阶段的工作量很大。在这个阶段，开发工作要重视文档的建设，测试工作需要写出测试分析报告，包括功能“测试分析报告”和“系统测试分析报告”。
5、安装调试阶段
本阶段的工作包括：硬件设备与软件平台的安装调试，用户培训，数据文件转换，系统调试与转换等。
安装调试阶段实现现有系统被新系统所替换，需要用户许多部门的参与或配合。为了使系统顺利转换，必须精心安排，合理组织，统筹调度和协调。
6、运行维护阶段
系统投入运行后，需要进行经常性维护和评价，记录系统运行的情况，根据一定的程序对系统进行必要的修改，评价系统的工作质量和经济效益。
上述6个阶段，构成信息化建设项目的全（整个）生命周期。
根据美国项目管理知识体系指南（PMBOK）的定义：项目生命周期开始于项目启动（例如签订承包合同），结束于项目收尾（例如按合同验收）。因此，信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。

本文第二部分内容——项目计划、实施和控制，是基于项目生命周期来考虑的。由于项目管理其实是一种方法论，因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。

二、项目计划、实施和控制
1、整体计划
整体计划的核心内容包括：范围计划、时间计划、成本计划和组织计划。
1）范围计划
项目范围由工作分解结构（WBS）界定。工作分解是一种以结果为导向的分析方法，用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件，因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为，没有包含在WBS中的工作是不应该做的。
信息系统建设项目的工作分解结构，第一层通常是由前面所述的项目生命周期的4个阶段组成，第二层则包括每个阶段需要完成的可交付成果，第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果，…。
工作分解结构层次的多少，以便于管理为划分标准。相同的项目，不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。
2）时间计划
时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法，可用来优化时间计划安排。由于有项目管理软件的支持，生成时间计划图表，以及用网络计划技术优化时间安排都变得十分地容易。
3）成本计划
① 制订资源计划
资源计划确定了为完成项目中各活动所需要的资源（人、设备、材料）。WBS
是项目资源计划最基本的输入。
② 成本估算
成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素，通过有关算法与工具（项目管理软件或电子表格）算出完成项目所需各种资源的成本估计值。
③ 成本预算
成本预算是为了确定测量项目实际绩效的基准计划，而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。
④ 成本基准计划
成本基准计划是一种按时间分段的预算，可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。
4）组织计划
组织计划是，利用责任矩阵确定WBS中各工作项的责任单位；利用组织图确定报告关系。但是，组织计划结果的具体形式受企事业单位的组织结构制约。（关于项目的组织问题，在本文第五部分解析）。
2、项目实施
项目实施总是一个阶段接一个阶段地进行的，前一个阶段的结果为下一阶段提供输入。信息化建设项目中，第一阶段的结果“系统说明书”，为第二阶段系统设计提供输入；第二阶段的结果“系统设计说明书”，为第三阶段的开发工作提供输入…。
每个阶段实施工作也都要首先做个计划，这个计划是为完成WBS工作包而采取的行动计划，包括：基于各项活动的基准进度计划，角色、职责分配计划。类似于前面讲到的组织计划，角色、职责分配也利用了责任矩阵这种方法，只不过在这里是把职责分配到个人。
项目子产品、产品实际上产生于项目实施过程中。
3、项目控制
项目控制包括绩效控制和变更控制
1）绩效控制
绩效控制目的是使工作结果与计划保持一致。
上面讲到，项目子产品、产品产生于项目实施过程，因此在这个过程中必须持续测量相对于项目基准计划的绩效，以便将实际绩效和基准计划进行比较，并以此为基础采取相应的纠正措施。
测量绩效的方法主要有两种，一是挣值测量，一是进度跟踪。而且，这两种方法通常是结合起来使用。
① 挣值测量
挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量，帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值：
l 计划值（PV）：在规定时间内花费的获得批准的成本预算部分
l 实际成本（AC）：在规定时间内完成工作发生的实际成本
l 挣值（EV）：在规定时间内实际完成工作的价值
不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状，所以通常称之为S曲线图。
这三个值提供了评价工作绩效的测量尺度。包括
l 进度偏差（SV）：SV=EV-PV
l 成本偏差（CV）：CV=EV-AC
l 进度绩效指数（SPI）：SPI=EV/PV
l 成本绩效指数（CPI）：CPI=EV/AC
② 进度跟踪
进度跟踪是输入实际工作进度，然后与基准进度计划比较，找出各项活动进
度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。
有了绩效测量结果，接着便是对偏差原因进行分析，进而根据分析结果决定纠正措施。纠正措施没有什么新东西，都是平时习以为常的一些方法，比如对进度偏差有赶工、快速跟进（有些书上叫做并行工程）等措施。理论著作上对这些方法的外延问题讲得很多，原因是在采取这些措施时，要考虑可能带来的许多问题，但这些都不是本文所要描述的内容了。
2）变更控制
变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。
基准计划变更包括：范围基准计划变更，时间基准计划变更和成本基准计划变更。一般说来，只有项目范围变更才会影响测量基准。但是，在某些情况下，进度延误或成本偏差非常严重，需要“重新确定基准计划”才能提供
测量进度或成本执行情况的切合实际的数据。
基准计划变更是很慎重的事，应该：
l 建立正式的变更程序
l 由变更控制领导小组负责批准或否决变更申请
l 定义正式文档变更的步骤
前面已经讲了，一般情况下只有范围变更才会影响测量基准。而在信息化建
设这样的高科技项目中，范围变更往往是因技术（功能、性能）要求的变化而起。项目管理中讲到的配置管理，讲的是项目过程中的技术管理问题。
配置管理内容包括：
l 识别工作项或系统的物理特征和功能特征
l 控制这些特征的任何变更
l 记录和报告这些变更
l 审计这些工作项和系统以证实其与需求相一致。
进行配置管理的目的是，项目过程中任何技术上的变更都要在范围变更中反
映出来，并要得到有关各方的一致认可。
三、开发商对项目的管理
无疑，开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作，开发商都需要重视。
计划方面
信息化建设项目往往带有较多的创新成份和不确定性，项目成果在出来之前，并不确切知道它会是什么样子。因此，用户的需求和任务目标在整体计划中都不容易表述得十分具体，特别是对要实现的功能的规定往往有相当程度的灵活余地。
由于这些原因，整体计划中的工作范围、完成各项工作（由WBS定义）所需的时间和费用都较难以准确估计，所以整体计划工作必定是一个反复修改的过程。实际工作中，人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为，项目管理的首要任务是计划！计划！还是计划！先哲说：“凡事预则立，不预则废”。因此，尽管信息化建设项目中存在诸多变数，但细致的整体计划工作是必须要做的。

实施方面
项目实施过程中，项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口（界面）。对于信息化建设项目，在系统设计与开发、测试阶段，对各种技术接口的管理极为重要。而在系统分析与安装调试阶段，协调组织界面是项目管理队伍的重点工作。
实施过程中，项目队伍成员必须按计划做事！
比较我们与西方人做事的习惯不难发现，西方人总是按文档（当然首推计划）规定去做事，而我们做事主观随意性较大。应该学习和接受西方人的做事习惯！
控制方面
挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目
管理者粗放式管理惯了，不习惯于做较精细的管理工作。当然，在信息化建设这类高科技项目的管理工作中，对工作量完成百分比做比较准确的估计（这是使用挣值测量法的前提）有些困难，也是人们不愿使用这种工具的一个原因。但笔者的体会是：对工作量完成情况做个百分比估计，比不做要好；对于类似项目第二次做时，对许多工作完成情况的估计还是有较好的置信度的。
变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素，这里不一一讨论了。

四、用户对项目的管理
在项目生命周期内，用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商，因此对成本的控制不是用户主要考虑的问题（当然，非固定总价合同情况除外）。而对范围、进度、质量等方面的管理是基于同样的标准的，即是说项目所有的技术和管理文档以及任何变更后的版本，都是开发商和用户达成一致意见后形成的。
在项目生命周期内，用户项目队伍重在参与。在系统分析阶段，没有用户项目队伍的重要参与就不可能产生好的“系统说明书”，也就不可能有好的项目成果。在安装调试阶段，没有用户项目管理队伍的协调、调度，转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段，用户应着眼于未来的运行维护，派技术人员全程参与工作，其必要性有二：一是未来系统运行维护的重要责任，要求技术人员必须深度了解系统的技术情况；一是系统将来必然会不断升级，要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家，不可等同于一般维护人员，也不同于一般网管人员，这点应引起用户的重视。
有些情况下，用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段，用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的，可能并不很清楚，这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段，从职能上说，项目监理与项目管理是差不多的。
五、项目的组织问题
对于信息化建设项目，多数开发商、用户单位的内部组织都是传统型（职能型）的，即组织的结构是按职能划分的。在这种结构体系里，对项目的组织往往是非正式的（用户方面更是如此）。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是，当认为某个项目很重要时，就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中，我们都能看到有这样的说法：信息化很重要，信息化建设工作应该由一把手亲自抓。
对信息化建设的项目管理工作，由一个领头干活的人负责显然不行，但由一把手亲自抓的观点，也非常值得商榷。
本文开头提过，信息建设工作是很复杂的事情。“复杂”体现在两个方面：一是把业务流程、规范、标准等搞清楚，并据此确定要建一个什么样的系统很复杂；一是技术实现上复杂。负责信息化建设的项目经理，应有这两方面的知识与经验。从开发商方面看，该项目经理应有很好的技术背景，同时要熟悉所服务行业的业务情况；从用户方面看，这个项目经理应非常清楚本单位的业务流程，同时对技术有一定的掌握。
一把手是企业战略层面上的管理者，很难要求他管好信息化建设这样具体而复杂的项目。
保证信息化建设项目的顺利进行，应从组织结构上着手。
矩阵型组织（参见下图）是西方国家许多企业采用的一种项目组织类型。

在这种组织结构里，职能部门经理承担职能性职责，项目经理承担项目职责。所谓扁平化管理指的也是这个意思。
从图中不难看出，项目经理需要在全公司内整合资源来完成项目工作。要做到这点，首先应赋予项目经理必要的权力。高层经理应充分认识到，负责=职责+职权。上图显示出，项目经理和职能经理的权力是平行的。要重视信息化项目建设工作，高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。
这里应该强调的是，矩阵型组织是一种现代型组织结构，重视这种组织结构
应用，其意义不仅仅局限在信息化建设过程中，对处在产品或服务转型期的各行业来说，都有重要的现实意义。
结束语
本文阐述了信息化建设中的项目管理。然而，在当今信息化社会里各行业都应重视项目管理。时代的变化已越来越快。产品生命周期短了，一种型号的产品推出后，很快就被功能更强、性能更好的产品所取代；对服务的要求更高了，与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项，服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此，我们不仅要在信息化建设中重视项目管理工作，还需要在广泛的社会领域中重视项目管理。

 

 

   七夕，这个浪漫的牛郎会织女的日子，被多情的少男少女丰定为中国情人节。

   其实，今天又是我的阴历生日！

   在认识老婆之前，很少给自己过生日，看到别人热热闹闹的过中国式情人节时，自己也悄悄的祈祷一下生日快乐，但是除了自己父母外再没有其他人知道这个多情的日子也是我的生日,所以在这个日子，我很少收到礼物，不是情人节而是生日礼物!

  自从认识了老婆，属于我的阴历生日才忽然变的热闹起来，老婆是个心细的人，她偷偷的查到我的阴历生日在七夕，于是，让我们的爱情在中国情人节中更加的甜蜜幸福，也因为中国的情人节让我的生日变的更加的浪漫。

  去年，在东北项目上，过生日没能和老婆一起，而是和项目上同甘共苦的同事一起过得，但是这个异地的生日让老婆一次偷袭性的鲜花把我给幸福的砸晕了。早上老婆也早早的打电话给我祝福了生日快乐，中午的时候，一个同事诡秘的让我和他一起拿件东西，到了客户公司门口，一个小伙子手捧一束鲜花来到我们面前，同事拿给我说生日快乐，这是你老婆送给你的生日礼物，那一刻，心里的幸福只有自己能体会的到，激动的眼泪没有流在同事的面前，原来老婆也早早的给我的项目经理打电话说帮她给我预定一束鲜花，经理也给我定了一个大大的蛋糕，闻着幽鼻的玫瑰花香，吃着甜甜的蛋糕，忽然觉得自己好感动，这是我有生以来过的最难忘最幸福的生日。

  去年在项目上刚过完浪漫的阳历生日没有几天，就是去年的今天－－七夕，那天我给老婆打电话祝福情人节快乐，老婆给我打电话说生日快乐，转眼又是一年，到了06年的今天，老婆已早早的等我回家一起过属于我们的情人节，而又属于我的生日！

  幸福就在不经意间属于了我们，浪漫也是不需要刻意的去追求，两个人在平凡中也可以创造出很多值得回忆的生活！

 

 

 

 

 

    以色列轰炸了联合国驻黎巴嫩维和部队位于黎巴嫩南部的一处观察站，造成4名联合国观察员死亡，其中包括中国籍观察员杜照宇。

    看到此消息，很是愤慨，感到震惊，为失去这样优秀的年轻人感到惋惜，又为他的英雄行为感到骄傲。

   这位英雄就是我曾经所在的山东省科学院自动化所一名老职工的儿子：杜照宇的爸爸杜战退休前是山东省科学院自动化研究所的一位副研究员。杜照宇的妈妈赵茂华在山东省科学院从事财务工作。两位和蔼可亲的老人培养了一位好儿子，真是不敢想象有病在身的两位老人得到儿子遇难的消息会给他们带来怎样的悲痛。

   我在山东省科学院自动化所工作的时候，也记不清是2002年的哪一天了，杜照宇的爸爸杜战老人走进我们办公室，让我帮他收一封邮件，里面有一附件让我给他打印出来，说是他国外的儿子给他发过来的，是一些英文的资料，因为是个人资料也没有详看，也没有问老人的儿子是做什么的，但那时能看出老人为有这样的儿子感到幸福自豪。

  当看到人民的好儿子杜照宇遇难的消息时，真是不敢相信，不敢相信国际战争的影响居然就发生在了我们身边。

  7月的济南骄阳似火，济南人的优秀儿子杜照宇却在这个炎热的夏日突然离去，给家乡人带来绵绵哀思。

  网上哀思如潮，同学、朋友、老师、邻居，认识的和不认识的数以万计的家乡人，纷纷表达对英雄的惋惜、留恋和景仰。

 

  --“两岁的孩子失去了自己的父亲！年轻的女人失去了自己的丈夫！年迈的父母失去了自己的儿子！多么英俊的小伙子啊.为国捐躯光荣！”

 --“老乡，你是济南人的骄傲！你是中国人的骄傲！”

 --“英勇的山东人，你为世界和平做出努力，我们向你致敬！”

 

 

 

做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
　　
1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。

2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的；

3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；
　　
4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；

5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
　　
6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。

7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。

对于这种需求天天变的客户，你就一定要事先做好规矩：
　　一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；
　　二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
　　*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
　　*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
　　*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；

8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。

9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做干特图的形式表现出来。你做完这个表以后会惊奇地发现，干特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。

好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：“(*&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
　　
　　 另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。

接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
　　
　　1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
　　
　　2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
　　
　　3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。
系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：
　　
　　一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正确是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。
　　
　　验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，这些在前面已经有所提及，这里就不再多说。
　　
　　我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了XP还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。

如何构建软件开发团队取决于可供选择的人员、项目的需求以及组织的需求。本文阐述了各种团队组织的策略。

有效的软件项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色；可能一个人专门负责项目管理，而另一些人则积极地参与系统的设计与实现。常见的一些项目角色包括：

分析师
策划师
数据库管理员
设计师
操作／支持工程师
程序员
项目经理
项目赞助者
质量保证工程师
需求分析师
主题专家（用户）
测试人员
您是如何组织项目团队的？是采用垂直方案、水平方案还是混合方案？以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括多面手，又包括专家。

一个重要的考虑因素是可供选择的人员的性质。如果大多数人员是多面手，则您往往需要采用垂直方案，同样，如果大多数人员是专家，则采用水平方案。如果您正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑您的项目和组织。本文描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。本次讨论的一个重要含意是您的团队组织和用于管理项目的手段之间应构成默契；任何方法上的失谐都很可能导致项目产生问题。

垂直团队组织
垂直团队由多面手组成。用例 分配给了个人或小组，然后由他们从头至尾地实现用例。

优点

以单个用例为基础实现平滑的端到端开发。
开发人员能够掌握更广泛的技能。

缺点

多面手通常是一些要价很高并且很难找到的顾问。
多面手通常不具备快速解决具体问题所需的特定技术专长。
主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
所有多面手水平各不相同。

成功因素

每个成员都按照一套共同的标准与准则工作。
开发人员之间需要进行良好的沟通，以避免公共功能由不同的组来实现。
公共和达成共识的体系结构需要尽早在项目中确立。

水平团队组织
水平团队由专家组成。此类团队同时处理多个用例，每个成员都从事用例中有关其自身的方面。

优点

能高质量地完成项目各个方面（需求、设计等）的工作。
一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。

缺点

专家们通常无法意识到其它专业的重要性，导致项目的各方面之间缺乏联系。
“后端”人员所需的信息可能无法由“前端”人员来收集。
由于专家们的优先权、看法和需求互不相同，所以项目管理更为困难。

成功因素

团队成员之间需要有良好的沟通，这样他们才能彼此了解各自的职责。
需要制定专家们必须遵循的工作流程和质量标准，从而提高移交给其他专家的效率。

混合团队组织
混合团队由专家和多面手共同组成。多面手继续操作一个用例的整个开发过程，支持并处理多个使用例中各部分的专家们一起工作。

优点

拥有前两种方案的优点。
外部小组只需要与一小部分专家进行交互。
专家们可集中精力从事他们所擅长的工作。
各个用例的实现都保持一致。

缺点

拥有前两种方案的缺点。
多面手仍然很难找到。
专家们仍然不能认识到其他专家的工作并且无法很好地协作，尽管这应该由多面手来调节。
项目管理仍然很困难。

成功因素

项目团队成员需要良好的沟通。
需要确定公共体系结构。
必须适当地定义公共流程、标准和准则。

项目团队士气是项目成功的一个因素
大部分项目成功的定义说的是项目如何按时完成、是否在预算内以及是否满足用户的需要。但是，在如今要找到好的软件专业人员都非常困难，更不用说留住他们的这种情况下，还需要将项目成功的定义扩展为包括项目团队的士气。可能在努力完成一个软件项目后，不料却因为压榨他们过度而失去了重要的开发人员，这样做可能会符合组织的短期需要，但它对构建一个高效的软件部门的长远利益来说肯定是有害的。衡量项目成功与否的一个重要手段是项目结束后团队的士气。在项目结束之际，项目团队的各个成员是否觉得他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。

需求陷阱：软件的功能的确越来越强大，虽然在开发前期制定了开发计划，但是开发过程中经常激发更多想象，从而试图不断增加新的功能，这种追求完美的心理可能导致的后果就是产品始终出不来，永远处于开发期；功能实现为首要任务，界面美化虽然重要，但一味强调界面，则产品不再美观。

解决办法：锁定需求，限制功能，需要的话，利用版本升级的原理，把功能分阶段实现，既保障产品的及时完成，又使小组产生成就感。

5月30日 领导好下属的四项修炼（转贴） 　   很多管理者都有这样的抱怨：为什么我的下属永远不能和我步调一致？其实，没有带不好的兵，只有带不好兵的将军。遇到这种情况，管理者应该首先反省一下自己的领导方式，看看自己的问题出在哪里。下面谈一谈一个成功管理者领导下属应做的四项工作，看你有没有做到。 　　 　　 1、让下属了解事情的全局 　　 　　安排工作时要讲清目的和全局，而不是只告诉他“你现在该做什么“。有些管理者认为“下属干好当前的工作就行了，没有必要了解事情的全局，因为我才是整体调度者“，这种观念是错误的。如果你的下属不了解事情的全局，他只能完全按照你的表面意图不工作，不敢越雷池一步。 　　 　　工作中遇到的任何问题，他都要向你汇报，因为他不知道如何处理是正确的。这样长此以往，你的下属会成为你的“跟屁虫“，工作能力不会有任何长进。 　　 　　让下属了解事情的全局，并且了解其他员工是如何配合的，这非常有利于工作效率的提高。了解了全局，下属就会明白这些事情的做事原因，在一些细节上就会灵活处理。久而久之，下属就会认真地去思考自己的工作，并且会将自己的一些建议和想法告诉你，你不但多了一个好参谋，他的工作劲头也会很足。 　　 　　 2、命令明确 　　 　　在给下属布置工作时，还要把你的工作命令讲的明确，比如“这件工作要求什么时候完成“，“完成的标准是什么“等等，都要讲清楚。 　　命令明确为分清职责提供了条件，当工作中出现了问题时，很容易分清是管理者的责任，还是下属的责任。这样可以防止相互推委，减少工作中的管理矛盾。另外，它为客观评价下属的工作提供了前提条件。 　　 　　 3、赞扬下属 　　 　　每个人都希望得到别人的重视，每个人都希望得到别人的赞扬。赞扬是最廉价、最神奇的激励方式。有些管理者认为：我已经为我下属的劳动付出了工资，没有必要去做这些事情。如果你这样对待下属，你的下属也会这样对待你：公司为我支付了工资，我为公司付出了劳动，所以我没有必要关心公司的前途。如果管理者和员工形成这样的局面，就很难有愉快合作的工作气氛了。 　　 　　 4、诚实和值得尊敬 　　 　　要想使下属心悦诚服地听从你的命令，你必须诚实并且值得下属尊敬。你的诚实首先表现在你要勇于承认自己的错误，承认错误不但不会降低你在下属心目中的威信，反而会增强下属对你的信赖。另外，对待下属应该实事求是，如果下属发现他受到了欺骗，则很难在恢复到原有的信任。 　　 　　你的言行必须为下属提供表率，“言必行，行必果“必须是你的做事宗旨。你要求下属做到的事情，必须自己首先做到，否则就不要有这方面的要求。受人尊敬不是一件容易做到的事情，它需要你坚持不懈地提高你的修养。