③关于主要约束，我主要写了进度约束。 ·需求分析：2003.2.17-2003.3.7 ·总体设计：2003.3.10-2003.3.31 ·详细设计：2003.4.1-2003.4.30 ·编码：2003.5.7-2003.5.31 ·测试：2003.6.1-2003.6.30 ·初验：2003.7.1 ·终艟。：2003.9.20
本项目不存在成本和资源约束。 ④本项目与公司其他项目和部门没有依赖关系。 (2)项目组织和报告渠道 ①我分了两个组：软件组和网络组。软件组由李鹏负责，网络组由我负责。 ⑦我把以下各角色的责任都描述出来了。 ·项目总监（张廷） ·项目经理（我） ·软件组长（李鹏） ·网络组长（王东） ·项目支持（李克明，主要负责质量保证） ③报告渠道。 ·项目组周例会，项目组内每周召开。 ·给客户的双周报，向客户即甲方汇报项目情况。 ·项目报告，每双周向公司江报项目情况。 (3)项目过程和方法 ①在软件方面，我们按常规的软件瀑布型过程进行开发，其他没有特殊的技术 方法。 ②因为开发工作时间有限而且看起来不复杂，我裁剪了代码走查、弱化了总体设计、 详细设计、单元测试和配置管理的工作。 (4)工作交付物及WBS ①项目的最终交付物是可正常运行的南方省级网管系统及相关文档，包括如下
内容。 ·网络系统软件的可执珩印洒。 ·系统技术手册。 ·合同规定由我方提供的设备。 ·达到氍技术规范》要求的网络系统。
@按项目的时问顺序，按照想象中的一件件工作我基本上分解出项目的工作分解结 构。每件工作我都标注上其输出，走部分工作都在三五天以内，少数是10天左右．软件 部分的工作基本土是接软件开发生命周期进行分解的，接入部分的工作基本上按各地区 工作的时序进行分解。 (5)项目工作量估计
有了WBS估算项目舰麒和工作量就比较方便了。先为每一项子任务估算一个工期和 占用的资源，然后可以很容易地累加出总工作量。不过，既然总工期已经定死了是4个 月，那我定义的各任务的时间都是从速一最大的约束出发凑出来的。 (6)进度计划
按第一项的进度约束我定叉了几个里程碑。 (7)其他
因为还有风险日志，所以我不需要在项目计划中针对风险作什幺计划，等项目启动 后，接风险日志的格式再处理也不迟．
有了计划棋板，项目计划确实好做多了，不过对这个项目而言有不少地方我还不太 有把握，例如WBS、任务工期及进度安排、资源安排、项目工作量等。但因为有横叛的
格式，我还是按大致的估计填上了些内容，总不能空着。 王东把项目计划提交给都门经理张廷和公司项目管理部。
张廷拿到这份计划，他最关心的是能不能按公司领导的时间要求完成这个项目。从 进度安排方面看，蜃后的完工日期是符合合同要求的，这份计划没问题。另外，从组织、 责任、沟通渠道、工作交付物和WBS等方面基本上都是常规的一些内容，每个项目大 体上都是写这些内容，也都看不出有什么问题。他问了一下王东：“做好这个项目没什么 问题吧？公司高层领导可是很重视的啊。”
王东也想不出有什么重要的问题，就说：“现在项目还没开始，也没什么问题。时间 方面现在心里没底，我努力争取吧。人员方面以后要是有什么需要还请老总您老人家多 支持l\
张廷说：“您千万别}现在每个项目都很紧张，能给你抽出8个人已经很不容易了， 你知足吧！”
公司项目管理部小林问了张廷对这个计划有什么意见，张廷说没有。小林看看项目 计划的格式、内容基本符合要求，而且部门经理也没意见，就批准了这份项目计划。 按项目计划，项目软件部分的第一大项工作是进行需求分析。这方面工作王东让软 件组长李鹏全权负责。甲方这边的负责人郭处让他手底下的小凌负责跟李鹏来谈软件需 求。小凌和另外两位甲方的人员针对未来的网管系统各个功能分别提出他们的想法，李 鹏他们就逐一跟他们谈逐一作记录。虽然谈需求进行得不是很有规律，但是最后需求分 析还是按时完成了，得到了一份关于该项目网管系统的需求说明书。该说明书对系统的 各个功能、使用方法都提出了要求，有些要求非常具体。
李鹏告诉王东说这份需求文档的内容虽然有些方面提得比较细，但有不少地方跟《技 术规范》不一致，想商量商量怎么处理。最后他们觉得这份需求有些地方是对《技术规 范》的发展，有些地方是细化，体现了甲方现在对网管系统的实现要求，与其到测试或 验收时再处理，还不如现在就考虑。王东把需求文档提交给了甲方请他们审阅。 设计、编码工作基本是以需求文档为基础而进行的。
项目工作铺开后，大家才发现项目的工作没有原来计划的那么简单，有些工作在原 WBS中是没有的，还有不少工作是计划外的，这都占用了项目成员的很多精力。王东习 惯性地感叹：“意外太多了！怎么我们做的每一个项目都有这么多意外，原来做出来的计 划就没有办法顺利地执行下去，计划没有变化快啷】”这样，项目计划就没办法按原来的 进度要求走下去了，原来每个人的正常工作节奏全都被打乱了，每个人都很忙。
关于接入部分的工作，王东去了南方某省需要接入的好几个地方才发现甲方各地准 备工作根本没准备好，这将会严重地影响整个项目的进度，而这些准备工作原本是新兴 公司希望甲方在接入工作开始前就做好的，甲方也曾说他们将负责把各地所有的接入准 备工作都做好。王东问各地的相关负责人这个项目的工作怎么安排，负责人的回答大同 小异，基本上都说省局为这个项目召集他们开过会，具体的工作也都考虑过或做过一些 工作，不过现在工作特别忙，有部分工作也没顾上，有些人还说曾想好好完整地规划好 要做的所有准备工作，但也不清楚准备工作具体都需要做哪些。王东又打电话问负责这 个合同的销售代表老杨：“关于接入的准备工作当初跟甲方是怎么定的、怎么交待的？” 老杨说：“哎呀小李，你不找我我还想找你呢，签完合同就不知道这个项目怎么样了。你 说各地市的接入准备工作吗？他们说是他们负责的呀，我就没多管，你是不是该督促他 们一下啊？”
接入工作的进展也影响到了软件开发的工作，按原计划到5月中旬应该可以进行软 件调试的网络环境没按时就绪。
按王东的项目计划研发部虚该在4月初额外派3个人来三、四天帮他们解决一个技 术问题。时间到了4月初研发部却没动静，王东急了，打电话问人怎么还不过来，研发 部经理诧异地问：“你什么时候跟我说过这事？”王东说：“我都写在计划里了！计划也 发给过你了！”研发部经理说：“每天文件这么多，我怎么可能把你的每一个字都细看 呢？”
还有一件更麻烦的事：公司为甲方所订购的一批网络设备到货时间将会耽误项目的 进度，国内供货部分还好一点，国外供货最晚的要到7月中旬左右才会到货。王东又感
叹：“天不助我啊！”
王东每两周都会跟郭处沟通一次项目的情况，郭处知道了设备到货时间的问题后问 王东：“你们公司没有去考虑过这个问题吗？”
5月22日，甲方高层领导来到开发现场听项目组的汇报并观看系统演示，为了表示 重视，公司领导和张廷也来了。当时系统并没有完全开发完毕，大家只看到了主要的功 能模块。
看完后，甲方领导表达了意见。 (1)对项目的进度极不满意。
(2)系统演示出的功能与《技术规范》不一致，母后的验收将以《技术规范》为 标准。
(3)从项目前阶段的工作过程可以看出新兴公司投入到项目中的资源不足，希望新 兴公司领导充分重视该项目。
(4)为对项目的沟通和监督，从当天开始甲方将每8个工作日来现场听取项目汇报 并观看演示。
公司领导对甲方的意见非常意外，立即让王东汇报项目情况。王东的汇报中提到了 资源不足。领导问项目组的8个人他是怎么使用的，王东说从项目开始到现在他们都很 忙。领导无话可说，又问王东要增加多少人，王东说估计4人左右。领导说虽然公司很 重视这个项目，但现在公司资源非常紧张，需要王东详细规划出这4个人怎么使用的一 个计划然后再审批。王东觉得这样很麻烦，本来项目工作就很多，还要把耐间浪费在这 种形式化的表面文章中，但俗话说胳膊不能跟大腿拧、好汉不要跟领导顶，还是简单写 了这4个人各分配哪个方向的工作作为计划交了上去。
在随后的几次汇报中，甲方领导在观看软件演示时多次提出了修改意见。对于这些 意见李鹏提出这属于项目范围变更，要求按变更来处理。但郭处说这不是范围变更，软 件功能本来就该做成这样子，是开发组理解错了，不存在变更不变更的问题。为了能够 说服郭处，李鹏和王东详细查阅了《技术规范》，结粜悲观地发现在很多地方《技术规范》 并没有清楚描述要做成什么样，所以报难判定甲方的意见是不是属于变更。既然是这样， 就只有满足甲方的要求了。
项目的麻烦开了头就刹不住，估计项目的时间目标是不可能实现的了，不知道客户 的高层领导和公司的高层领导要怎么着急呢，唉……
现在回过头来看项目的计划，王东觉得这项目计划其实真的没什么用，项目是活的 计划是死的能有用吗．}还不如不做！只不过公司有制度，不做不行罢了。 2．项目执行保障部分
客户领导的意见让公司领导对这项目异常重视，几个人陆续派来了。
关于设备到赞的问题，公司领导责成公司商务营运部门抓紧催货。没到货之前怎么 办昵？张廷召集相关的人开会，大家出谋划策，决定从公词和客户两边先凑或借部分可 用的设备，在佛山先建一个示范点，把示范点的做法制定为规范，等设备到货后再COPY 到其余20个点，这样能大大地节省后期接入工作的时间。经与甲方商量，甲方很赞成， 之后示范点设备的筹集很顺利，随后的示范点接入和调试工作也都很顺利。
王东又感叹了：“还是客户的力量是无穷的呀！以前关于这些问题我也给张廷写过周 报，我写过可能会有设备到货时间的问题，会有资源不足的问题，会有需求变更的问题， 但都是石沉大海，现在客户领导一发话问题解决得真快！” 王东的回忆：
项目的气氛紧张了很多，由于巨大的进度压力，我规定全体人员每天都加班到晚上 9点半以后，周末也不休息。连续加班一段时期之后大家好像非常疲惫，全组人员一起 吃饭时话也不太多了，情绪变得不高了，积极性、工作效率等各方面都明显下降了。 以前项目组开周例会大家还挺积极，七嘴八舌地提出不少建议，而现在大家无精打 采没什么话，除了王耕田偶尔发发牢骚或讲个段子。真是无可奈何：既然大家都这样， 干脆以后周例会也别开了，我每周大致问一下大家的工作情况就算了，反正大家都忙， 顶多是我一个人多辛苦点，辛苦我不怕。
我发现如果以各项目成员为节点画一张项目信息流劫的示意图，有些人好像会成为
信息的“梗阻”，个别人居然趋向于成为“孤岛”。不过，我觉得人的性格是很难说的， 强求大家都像王耕田那样特爱说话也不可能。
管人真是麻烦！这些问题让我作为项目经理很难做工作，公司对项目的支持还是不 够，公司应该把人管理好，这些人才能为项目服务好。 李鹏的回忆：
详细设计、编码和单元测试工作的结果让我不满意，客户也不太满意，项目进度也 被拖延不少。王东和我一分析原因，觉得其中很大一部分原因是项目组里有几个成员不 太熟项目所用到的开发技术，无论是测试还是编码问题都比较多，工作的反复比较多， 表现也不专业，设计写出来五花八门、各有各路，编码更是天女散花，要多花有多花， 急得我恨不能上去自己把所有工作全都做究。王东安慰我说公司派来的人也不可能所有 的都是高手，这也是正常的，我们自己不能急，习惯了就好了。
来自公司研发部的人让王东觉得不好管理，他们中的部分人是身兼数职的，我们都 能看到，有时候他们会回公司忙他们别的工作，有时候他们人在项目现场但不停地为了 别的事情打电话。都是为了忙公司的事情，大家都能体谅。但有一次我觉得心里不舒服： 软件的总体设计是请研发部的肖大跃做的，大跃是“大拿”，那段时间同祥是特别忙，匆 匆忙忙花两天时间做出总体设计来，文档中以前项目的“痕迹”都没删干净。本来我觉 得在设计评审时QA和大家可能会找出不少问题来，但这个QA没经验，评审前没让大 家认真阅读，我觉得参加评审的人员里阅读了一小时的都算不错的了。评审时因为有人 马上要出差所以很快就过了一遍，两小时都不到！除了改了改笔误、删掉原来的一些不 该出现的“痕迹”外没谈出什么大问题来。另外，大家有一个心态觉得这是大跃的东西 应该没什么问题，大跃可是多大多复杂的系统都做过的“大拿”！但我怀疑这次大跃可能 连伐技术规范>都没细看。后来事实还真证明我的怀疑是对的，客户在测试的时候发现 我们的功能跟程技术规范》不一致，我们追根溯源一查，原来是大跃的设计照着旧系统 做的，没考虑这个项目的要求．唉，耽旌我们一个多星期的时间啊。
说到这个QA，我还觉得有点不明白，设了QA他就应该把项目质量方面的事情全 都管理起来对吧？但他全都管得了吗？他还是要我采负一些责任，还说我没尽到责任！ 但我到现在也没整明白在质量方面有哪些责任是该我负的，我也不清楚我具体负责的需 求，设计、编码、测试这些过程里质量该怎么管。他说他的项目质量计划里写到了，我 怎么就觉得那玩意儿是个形式呢？没有用！
甲方的小凌对小周所做的模块不满意，王东本来就对小周不满意，于是详细了解了 小周的工作情况，感觉小周虽然聪明但不踏实，有些工作该做但没做得很好，有些工作 虽然不起眼但他该做没做。王东直截了当地对小同提出批评了。小周报不服，说：“说我 该干没干？可我头到尾没有清楚地得到过指示要我去做哪几件事情，跟我交待过我要负 责这一块，可是领导，这一‘块’到底多大谁知道啊?您认为我该做什么最好跟我明确 出来，要不然我根难猜。说我没干好？‘好’到什么程度能不能也一起告诉我？再说了， 那些做得慢的您怎么不去考核一下？要是大家都考核，我应该还算好的呢！”
小周还提到了让王东和李鹏不太好回应的一件事：正是因为他们俩决定把单元测试 和系统测试的部分工作简化了才导致了后来出现的一些莫名其妙的问题。当时他们也是 想赶进度，没想到现在省不了时间反而为了查找和排除这些问题费了几倍的时间。什么 叫偷鸡不着蚀把米？嘿嘿【王东从小周的眼神里看出了这个意思。 对小周的批评屉后也只能不了了之了。
让王东觉得比较麻烦的还有客户。客户是上帝，上帝是给钱的人，上帝随便咳嗽一 声也绝对要注意听着；客户．还是合作者，没有他们配合项目的工作不可能完成。不想不 知道，一想就发现项目里有很多事情需要客户（或协调第三方厂家）去做而且他们能做 得好的，例如： ①提供各地的设备类型、数量、监控状况和监控协议。 @对不符合统一协议的c网设备进行整改和升级。 @提供整改后的各地区需接入的站点信息。 ④提供可联调的实际站点。提供联调配合计划。 ⑤对被接入的设备进行接入联调，并提交联调报告。
@外挂监控站点的接入实施工作。
让王东头疼的是客户经带不做好他们该完成的工作。下面这些是郭处、小凌或客户 的其他人让王东经常头疼的话。
(1)“最近太忙，上周说的事还没顾上。哎你们这边差不多了吧，培我看看！”
(2)“下周一要三个人配合测试？你怎么不早说？今天都周四了，我们怎么来得及安 排人手出来啊？往后推一周吧？”
(3)“这种事也要我们做？你们这么熟，人又这么多，顺手一弄就完了，啊，就这么 定了吧。”
(4)“这事我这种小兵管不了，我负不起这责任，你们还是找我们领导去吧！” (5)“那是使用部门的事，跟我没关系，你找他们吧……” 对这些话，王东都不知道怎么对付才好。
项目的压力超乎寻常地大，客户每8个工作日的检查对项目组来说是个很大的负担， 而不是能解决问题的帮助，部门经理张廷和公司项目管理部经常追着问项目进度。 每天都有新的问题涌来、每天都有新的压力，来自客户的、来自公司的、来自项目 组成员的，进度方面的、资源方面的、技术方面的、乱七八糟方面的l面对这些铺天盖 地而来的信息、问题、压力，王东觉得再下去就要崩溃了！
王东感叹的是为什么每一个项目都不顺、都这么麻烦，是自己运气不好？公司的问 题？还是行业、客户的问题？ 3．项目控制部分
项目一开始公司领导和部门领导就一直希望这个项目能按目标完成，目标显然不可 能达到时又寄希望于修订后的目标能够达到。项目经理被要求努力地去控制好项目以达 到各方面的目标。 王东的回忆：
一个事先没有预料到的情况严重地干扰了项目的进展：甲方颔导每8个工作日的视 察有时满意有时很不满意，但不管怎么样都会提出一堆意见和要求，这样好那样不好， 要这样下次别让我看到那样等等。项目有项目原来的进度计划，每天干什么都有安排， 而为了满足这些要求原来的安排全都被打乱了。甲方提出的这些意见有的跟《技术规范》 一致、有时不一致，一开始我和李鹏还想部分顶住，但因为甲方领导层次较高，我觉得 他要是震怒可能公司领导又会很紧张，同时也不希望因为我不同意满足甲方的要求让甲 方向高层领导投诉，这样会让我很被动。
这种对修改要求的满足一旦开始就很难停止，这样项目就陷入了很被动的循环，刚 把上次的要求改好了，想回复正常的开发节奏，新的一轮又开始了。这让我觉得就像转 轮里的小白鼠，自己永远不知道什么时候是尽头，直到累死为止，而外人觉得你在干你 该干的事情。
变化永远都在发生，这是极其讨厌的事情，说实话，我现在很怕听到这种坏消息， 但这种消息从项目一开始到后来还是很多。 (1)网络设备到货比预期晚。 (2)甲方的接入准备工作没做好。
(3)甲方的开发配合工作没按计划做好。 (4)项目资源的可用性发生变化。 (5)技术难题的难度超乎意料。
这些变化只要一出现就让我们没办法按计置|j走下去。
公司要求我控制的两个最重要的方面是项目进度和项目成本。
美于项目成本，我也想控制，但我实在不知道除了控制项目赧艄费用外还有什么措 施可用，反正项目费用预算的总额现在还没超，除了这一点其他的情况都无法判断，所 以也就没办法控制。
关于项目进度控制，我现在觉得是一个很虚无缥渺的事情，讲得实在一点就是：如 果项目没有意外，项目的进度你就能控制得住，有了意外你就控制不住，就这么回事！ 另外，公司让我们每个月都要进,f带-值分析，累死人又没有用，唉…… 关于项目周例会：项目组一开始还开周倒会，例会内容有如下两项。
(1)每人汇报上周的工作情况，有没有完成任务。 (2)确定下周工作的任务安排。
后来周例会也不开了，基本上都由王东依次问大家的工作情况再安排一下下周的 工作。
张廷觉得这个项目各方面似乎都处于失控状态，问王东他对项目都有哪些控制措 施，王东说了一堆，张廷觉得都没到点子上。他问王东：“你觉得项目怎么样才能控制得 住？”
王东觉得不好回答，想了一想说：“第一要防止意外发生，第二要靠运气!” 这个项目确实基本处于失控状态。
在进度方面，原计划是7月1日初验，后来改成8月10日，然后再改成10月8日， 然后……里程碑目标一拖再拖，眼看目标显然不可能达到就又把进度目标修改一次，每 次都有客观原因（公司项目管理部事后总结发现，要求进度目标延期或项目预算增加的 每一个项目都有绝对充分的理由、都有一大堆客观原因）。
在项目费用方面，报销的费用倒是不多，但整个公司里谁也没概念：这个项目现在 已经花了多少钱，还允许项目可以再花多少钱。
在项目质量方面，一句话就可以概括：时间和资源换质量。各个环节都出了不少问 题，大部分问题是用人和时间去换的，小部分问题就算了，以后再说了，顾不上了。 最后，项目在12月5日终于通过初验了。涉及到这个项目的所有人好像都舒了一 口气，但没有人有多少笑容。本来所有人对这个项目的期望值都挺高的，但现在落差太 大了。项目的成本远远超出了预算，无法不超，因为拖延了这么长时间、增加了这么多 人。王东知道的只停留在超出预算的数字上，但公司领导考虑的是：这个项目我们赚到 钱了吗？我们赔了多少钱？以后这种项目还能做吗？
各位项目成员也不开心，辛苦了这么长时间，项目没有一个值得大家高兴的结果。