信息系统工程项目中的硬件设备监理

我们知道三类信息系统工程项目--信息网络系统、信息资源系统与信息应用系统都需要硬件来支撑。硬件监理在系统集成项目中占有很大比重。简单谈谈我对几个项目中和硬件有关的几点监理体会，想到哪点就写写哪点吧，总不能让人看了直接来抢了我饭碗。

　　1、到货计划的审查要点。重点最晚供货的设备到货时间和设备供货的时间优先级别，深入了解各设备是否需要从国外进口。通常从国外进口货物在供货时间上更难把握，应预留足够的时间提前量。必要时需要提供相关订单号和查询电话(或者网址)进行跟踪。

2、到货验收的审查要点。检查货物存放场地的空间和安全保卫措施;检查货物外观包装情况，并用DV或者相机逐一取证。重点检查装箱单与实物的一致性、设备的序列号。

3、设备的验证，关注出厂日期和保修条款，如果发现出厂日期与到货日期相关太远(每家产品会有差异)，有可能是存货甚至是返修产品，应责成集成商提供足够理由和佐证材料。大部分厂商的设备目前都可以在官方网站是查询，通过查询可以确认原厂部件。特别要验证原厂服务是否与合同要求吻合。

　　4、设备的安装监理，着重安装人员及设备的安全措施，电源插座检查、电压检查。安装过程是否规范，理线规范性和标签标识情况。

5、设备的配置与联调，要求先确定调试配置参数及相应的图纸，配置策略等。先确认的呢单一设备的工作状态，再系统联调。

6、设备的测试与预验收。先确定测试方案包括技术方案和测试计划，再按此方案中的步骤检查，确保一个同等知识要求的运维人员可以按此方案完成测试操作。验证测试结果与预期的一致性。

　　7、设备的试运行跟踪，使用跟踪情况表，特别是问题产生原因和解决途径,要求这些内容写入运维手册的QA项.

8、使用与管理培训，先出培训教材和培训计划，最后要有培训效果检查表确认每个受训对象合格通过，培训演员对教师和环境等培训过程的反馈表。

　　9、正式验收。。。。重要是移交材料的完备性，明确售后服务详细流程。。。。。

小技巧：网页自动转向代码

自动转向，也叫自动重定向。自动跳转，指当访问用户登陆到某网站时，自动将用户转向其它网页地址的一种技术。转向的网页地址可以是网站内的其它网页，也可以是其它网站。通常情况下，浏览器会收到一个网页，该页面含有自动加载一其它网页的代码。该页面有可能在服务器端被转换，这样的话，浏览器只收到一个页面，而自动转向往往意味着浏览器收到的页面具有自动将访问用户送至其它页面的功能。

对自动转向技术的合理应用包括：将用户转向到指定浏览器的网页版本；当网站的域名变更或删除后将人们转向到新域名下，等等。但现在这种技术却往往被搜索引擎优化人士用来作为提高网站的搜索引擎排名的一种手段。例如，先专门针对搜索引擎做一个高度优化的网页，也就是我们通常所说的“桥页”，然后把这个网页提交给搜索引擎来获得好的排名。但是，当搜索用户通过搜索引擎的搜索结果列表点击该网页列表进入后，将被自动转向到一个用户本来无意去访问的网站地址。搜索引擎常常认为自动转向的网页是对读者的误导，所以它会对这种网页或网站施以惩戒，不过对一些自动转向方法它目前还无法自动检测出来。

　　Meta Refresh Tag自动转向法

由于搜索引擎能够读取HTML，而Meta tags也是HTML，所以对于这种自动转向法，搜索引擎能够自动检测出来。因而无论网站的转向出于什么目的，都很容易被搜索引擎视做对读者的误导而受到惩罚。不过，如果跳转延迟时间设置合适，搜索引擎就不会视之为作弊。

　　页面定时刷新元标识(Meta Refresh Tag)只能放在HTML代码的区里。如下所示：    
　　代码
　　以下是代码片段：
　　     

　　其中的“5”是告诉浏览器在页面加载5秒钟后自动跳转到page.htm这个页面。这种方法常可以在论坛中见到。如果在论坛上发信息，先会看到一个确认页面，几秒后会自动重新跳转回当前的论坛页面中。

从搜索引擎优化的角度出发，一般不希望自动转向有延迟。不过，如果是用Meta Refresh标识进行转向，一定要注意把延迟时间设定成至少10秒以上。

　　“javascript”自动转向法

由于不能解析javascript，所以搜索引擎无法察觉(自动检测到)用javascript脚本进行的自动转向。javascript自动重定向脚本可以放在网页的任何位置上，如果要求立即跳转，则可以将其放入网页源码的区内的最上面。用javascript实现跳转的范例如下：

　　方案1：
　　以下是代码片段：
　　    

　　方案2：
　　以下是代码片段：
　　    

其中的“ http://solidot.org " 和 " http://www.zz-word.com "指特定的重定向目标地址，用相对/绝对URL地址均可。

用javascript实现自动重定向的好处在于：用户所访问的目标URL不会保留在用户浏览器的历史记录中，如果用户按返回按钮返回，则将回到跳转前的网页，而不是包含javascript自动重定向脚本的跳转页面，所以不会出现当用户点击返回按钮后返回至重定向页，然后该页自动跳转到用户本来想离开的那个页面的尴尬情形。

如果需要，可以把javascript自动重定向脚本存在一个外部文件中，并通过下面的命令行来加载，其中“filename.js”是该外部文件的路径和文件名：    
　　代码
　　
    　注意：若需实现即刻转向，或不希望人们看到转向前的那个页面，一般常用javascript脚本实现。在这种情况下应将javascript脚本放入HTML源码的区中。

　　表单(FORM)自动转向法

搜索引擎的“爬行”程序是不会填写表单的，所以它们也不会注意到提交表单，因而可以利用表单来实现自动转向(重定向)而不让搜索引擎察觉。
　　对于表单，人们往往很少意识到：表单的Action参数中包含的URL地址其实正是浏览器向服务器所请求的URL。浏览器将会通过向请求的URL地址增加一些格式为name=value的参数给予它以特殊的对待。在什么都没有的情况下，浏览器仍旧会为该URL安排请求至服务器。

用javascript脚本可让页面开始加载时即提交表单。下面是一个用javascript实现表单自动提交，以及提交表单的范例：
　　以下是代码片段：
　　 
　　

　　小结

　　如果访问用户最终看到的是他们想看到的，那么在搜索引擎优化中使用自动转向技术并没有什么不对，也并不是什么不道德的行为。但有些人往往会在利用 “自动跳转”技术，利用“桥页”吸引访问者，然后把他们送到他们无意浏览的页面或网站，这种做法只会引起访问用户的反感，又怎么能够期望访问流量可以有效转化为最终客户呢?

项目经理如何学会管理自己的领导

　　好像所有的人都会赞同沟通能力最重要，可是什么是沟通能力的内涵呢?我觉得是：清楚地表达、传递，并引导人们的表现朝你的期望发展。这里的“人们”包括你的领导。

在一个项目开始前和进行中，跟你的领导始终沟通无碍，是项目成功的最大保障。怎么才能和领导沟通好呢?

　　管理你的领导

有朋友说PM有权利调配资源，不够就去要。现实中，基本上我们的项目最大的限制除了钱就是资源，资源很多情况都被领导掌握，PM哪有随便调资源的权利?但是领导们都常常觉得，够了啊，总之你给我搞定。

PM要学会说“不”，制定计划的时候就要否定老大们不切实际的想法，但绝对不是上去就狂喊，而是说法上要有技巧，说“目标——步骤——难点——计划——资源”，领导们会容易接受一些。

就是说：我们的目标，是要达到什么效果，还有范围是什么;步骤是1、2、3、4，先做什么再做什么;难点是什么，哪个地方容易出错，不管是技术难点还是管理难点，PM都要考虑在内。

比如技术上大家都没有做过，就是难点，比如管理上没有某个规则等等。因为有了这些难点和目标，我们觉得时间计划是什么(保留适当的储备)——因为要实现这个计划，我们需要什么资源。

领导们听到最后，嗯，很有道理，他就要权衡了，给你资源么，不给?不给重新讨价还价，目标要不要改?时间要不要延长?范围要不要缩小?给，给当然好了，PM要到自己的东西了。

无论是制定目标还是过程中，你需要资源的时候都可以尝试用这种方法。虽然很多时候资源是被领导掌握，但是身为PM要记着，领导也是我们的资源，你用他的思维方式，引导他去思考。你要学会管理你的领导。

　　向领导暴露问题

就算这些资源都要到手了，我们就是承诺项目没问题吗?当然不是啦。领导们还是聪明而有经验的，他们都知道项目一定会有问题，他们不期望不出问题(他们基本都认为，不出问题的项目一定是有虚假信息，项目不可能不出问题)，他们只是希望可控(问题可以被解决，知道对现有质量、进度、资源、预算的影响)。

　　所以PM千万不要心虚说，因为前面我要了这个那个，后面我就不可以出问题了，有问题就隐瞒。恰恰相反，PM就是要在过程中暴露问题。你说出来了，领导就是再不开心也知道解决问题最重要，所以他就会帮你解决问题，你就多了一个强有力的资源了。

暴露问题是要说：问题是什么——为什么会出——如果不解决，对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么?——各自对上面6个维度的影响是什么，各自都有什么局限和好处?——领导决策。

　　如果你也没解决方案(这样不算好的PM，但是没辙的时候也是会有的)，你就做前面两步好了。问老板，怎么办啊?

但无论是谁给的解决方案，也无论这个方案是什么，你最后都要向你的领导(当然包括你的所有利益相关者)说清楚，这样一个变更对目标、范围、进度、质量、客户满意度、预算的影响是什么。

让你的领导感觉，虽然会出问题，但是你至少让问题的影响可控了。他在下一个问题出来前可以睡觉了。

　　什么时候汇报?

　　虽然我认为很少有PM会犯这个错误，但觉得还是说一说比较好。周报是干嘛的?其实很多时候虽然是一份常规的记录资料或文档，但最大的作用，我认为是保持所有人对项目的关注度。

让一些更大的老板、边缘的团队成员、边缘的利益相关者保持对项目的关注度;让核心团队成员有成就感：我们做了那么多，还报告领导了。我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

　　一旦有了问题要马上汇报!当然还要考虑上级领导的风格(他是事无巨细关注型还是抓大放小型)和PM的权利(什么样的问题有决策权)。但一旦有了PM搞不定的问题，要马上汇报。

　　出了问题要随时解决、即时解决。你想周期性报告一周一次?一月一次?那时候黄花菜都凉了。所以马上汇报。不要怕你的领导，因为耽误了时间更可怕。

项目经理如何处理好与不同类型客户之间的关系

　　作为项目经理，如何处理好与客户之间的关系非常重要。但是究竟如何处理客户关系呢?客户的人员都有哪些类型?不同类型的客户的应对是否都一样呢?下面我们来看看在日常工作中经常遇到的客户类型，应该如何处理跟他的关系。

权威决策型：这类客户往往具有权威的技术、业务和管理能力，对于事情本身具有决策权。

　　应对策略：正面应对，以技术服人。

　　典型决策者：具有商务上的决策权，但是不是业务和技术的专家。

应对策略：用通俗的语言表达技术和业务，尽量减缓正式的冲突，下面处理协调，效果会更好。

技术专家型：只关心技术实现、细节和技术可行性。

　　应对策略：直接正面应对，解释技术上的可行性和解决方案。

　　糊涂管理型：是甲方的管理者，具有一定的决策权和影响力，但是对项目管理不懂装懂，不时干预项目的事情，有时是麻烦的制造者。

应对策略：客气地拒绝，一定掌握主动权，一旦他掌握主动权，他会引导你项目的失败。

　　和稀泥型：不承担责任，但也不得罪任何一方，不解决问题，但也不制造麻烦，属于老好人型。

　　应对策略：别指望解决你的问题，可以利用大事化小，保持和气。

虚伪专家型：技术和业务有一定了解但是都不是很深；多为新提拨的业务和技术骨干或多年被“埋没”的人才，喜欢卖弄点技术能力，缺少大局观。

应对策略：或者成为利用的对象，或者让其远离你的项目，敬而远之。从大局考虑，使其空，从技术的纵深考虑，使其服。

　　小人型：阴奉阳维，表面一套背后一套，报复。得志小人更是难缠。

　　应对策略：不让其染指项目是最好的办法。

项目经理人与项目成员的实战指南

　　在一个团队中，作为一名团队领导，将：

　　1) 避免团队目标向政治问题妥协

　　2) 向团队目标显示个人承诺

　　3) 不用太多优先级的事物冲淡团队的工作

　　4) 公正、公平的对待团队成员

　　5) 愿意面对和解决与团队成员不良表现有关的问题

6) 对来自员工的新思维和新信息采取开放的态度

　　作为团队成员，要将：

　　1) 展示对个人角色和责任的真正理解

　　2) 展示目标和以事实为基础的判断

　　3) 和其他团队成员有效地合作

4) 使团队目标优先个人目标

　　5) 展示投身于任何项目成功所需的努力的愿望

　　6) 愿意分享信息、感受和产生适当的反馈

　　7) 当其他成员需要时给予适当的帮助

8) 展示对自己的高标准要求

　　9) 支持团队决策

　　10) 以为团队的成功而奋斗的方式体现带头作用

　　11) 对别人的反馈做出积极的反应

项目接近尾声时不能忽视的10件事

对于你的组织规模，你可以把项目管理视为一项偶尔的实践或者可以拥有一个复杂的PMO。不论那种情况，你可能通过典型的项目初始、精化和构建过程。但是到了项目终结的时候，很多项目经理只讨论短期的终点线。最后的步骤处理不好会给行动增加混乱并且可能导致客户不满、员工不悦，并把项目拖得比所需时间更长。

　　这里是一些你需要在达到你下一个项目的终点时要考虑的事情。其中有些项目是纯管理的，但其中很多能帮助你进一步保证你的项目能够成功。
　　一、最终测试
　　测试会耗费人员，而我们很多人都不愿意去做——特别是做过几轮之后。我见过大量的四到六个月的项目有一两天的计划去测试。没有安排适当数量测试的项目通常在实施的最初几周内因问题而结束。这里不要走捷径和将测试的重要性减至最小；否则，你会为痛苦的进展过程而承担额外的风险。

　　二、最终培训
　　用户？谁关心用户？好了，很多项目都为了他们的利益而做，所以确信把你所有的测试资料完成并移交。这个不做好最有可能体现在发怒的客户半夜三更打来的愤怒的电话上。

　　三、确认交付物
　　你检查了所有的箱子并清理了收件箱，而且你想真地结束了。但你的客户怎么想？安排时间和你的客户检查所有的交付物并且确认他们已经得到满足了。有些情况下，可能有一些特殊问题到你计划终止日期时尚未解决。在你项目的早些时候，应该有一份协议来决定如果发生这样的情况会如何影响你的结束日期。

　　四、获得项目签字
　　当你获得所有交付物都已满足的认可以后，请求在项目文档上做一个正式的签字。这样做帮助确保所有人都认可项目状态。因为这个签字通常标志着项目的正式结束，注意不要让你的客户感觉签字的压力。如果他们在不明所以的情况下做了，你可能会在日后出现问题的时候最终得到一个不满意的客户。

　　五、解散团队
　　现在项目完成了，你的团队何去何从？基于你的组织，他们可能被送回一个开发池或者去做业务。或者他们需要在企业内部为自己发起一些工作。不管是什么，你要保证花点时间和他们在一起，并且设置一个明确的不再需要他们的服务的最后日期。同时不要忘了你可能需要完成一些需要加入他们档案的业绩审核文档。

　　六、分析实际与计划的对比
　　资源——你是否真正摆脱了10周只有一个开发者/测试员，或者你需要去争夺并得到更多的人员？你为你的商业伙伴安排的时间量怎么样？明白你有多接近这些目标能帮助你为下一个项目更好地分配资源，并且在下一个项目来临时为它设定更切实的预期。
　　预算——项目要花费多少？你是达到预算、未达到预算、超出预算？坐下来弄明白这些基本问题的答案会给你一些对任何项目临界区域的洞察力。

　　七、存档文档
　　任何项目期间，好像我们都创建大量的文档。其范围可能从范围文档和项目计划到合同和会议纪要。不管是什么，在你结束时根据企业的保留策略应该有地方保存它们。当两年后你的电话铃响起来并且有人要你解释项目期间你所做的一个决定的背后原理时，你将会很高兴。

　　八、确保合同终止
　　一个项目不常有自己的预算。你可能还有硬件、软件或专业服务的合同。在你完成以后，确认检查合同的所有项目都满足了，向供应商索要发票并把它们提交给 AP，并且关闭任何相关的财务帐目，如果需要的话。

　　九、举行一个验尸会议
　　什么类型的风险你识别并减轻了？你想用以确保下次再做的什么真的变好了？和所有的项目利益相关者和有关参与者开个会，向他们提供了一个论坛来表述所学到的教训。

　　十、执行一个自我评估
　　终于结束了。在所有的艰苦工作都完成以后，你已经确认所有的 i 都被加了点而且所有的 t 都加了横。现在做什么？从和你在项目中互动的人员那里得到一些关于你绩效的反馈是重要的。如果你有机会发一份360度反馈调查给尽可能多的个人，我建议你这样去做。这会帮助你评估你进步了多少并且能给你一些极大地提示来决定你该着眼于哪些个人成长的机会。

这个清单并不是对每个人都一样，并且根据你的组织和它如何部署项目会有不同。但如果你能够去做，它会永远使到下一个项目的过渡更顺畅。

项目核心体制的角色和任务.

软件项目在开发过程中，拥有一个稳定的核心人员体制是非常重要的，这个核心体制中至少应该包含管理者、技术专家、业务专家三种角色。当然如果条件允许，再配以配置管理员、品质管理员就更加完善了。

　　做为核心体制中的管理者，通常情况需要肩负以下责任：
　　1、做为窗口，与客户进行沟通交流，既要保证把项目的状况及时地反映给客户，也要把客户的需要及时准确的反映给开发团队；
　　2、决策。对于项目中的一些重大事项进行决策，如开发平台和技术的选型、任务的分配以及人员的安排调度等；

　　3、服务。做为项目的管理者，不能深入到项目的每一个开发细节中，但是一定要做好服务者，及时的了解和掌握项目进行过程中的各种需求，并适当给与解决和满足；
　　4、监控。全面掌握项目的状况，保证作业过程中各种品质活动的必要性的完整性；
　　5、协调。合理分配任务，协调各种作业间依赖关系，保证作业过程合理有序。

　　业务专家的核心任务是根据项目面向的应用领域，构建业务模型，业务模型中应该包含以下内容：
　　1、系统应用场景（这里用场景而不用环境，主要想与系统的运行环境进行区别）。应用场景中应该包含系统所面向用户和用户数量、系统用户的工作环境和地点分布以及系统应用时间和频率等；

　　2、业务流程模型。面向用户，构建完整的能够反映用户工作实际情况的工作流程，对于项目是否能够正常如期的交付并正确的放映客户的需求非常重要。业务流程中对于不同环节中的依赖和约束一定要有清晰完整的描述；

　　3、业务数据模型。数据做为软件系统的生产对象和消费对象，它会在系统中的不同功能模块间，甚至是不同系统间流动，在数据流动的过程中必须保证它的完整性、一致性和唯一性。因此我们在构建数据流程时要充分考虑这些要素；

　　4、UI接口模型。UI接口是用户使用系统的第一门户，因此一定要让这些接口尽早反映给客户，通过给客户演示或试用，收集用户的操作习惯，视觉反映等信息，不断的完善UI接口设计。

　　技术专家需要依赖业务专家的作业成果完成以下任务。
　　1、项目技术实现方案的设计。这里包括开发平台、部署环境、开发技术的选择等等，做为技术责任者不但要了解系统的应用场景，还要了解开发团队的技术特点；
　　2、系统整体功能结构的设计。我们需要根据业务流程，完成业务处理过程向计算机环境的合理转化，使系统的功能特点能够有效的反映业务流程的要求；

　　3、数据存储的设计。我们需要根据业务数据模型，完成物力业务数据向逻辑存储结构的转化，保证数据能够在相关功能处理中正常的流动和存储。
　　4、功能接口规范的设计和制定。功能接口是各相关功能模块间进行交互的门户，同时也是屏蔽模块内部细节门户。接口规范不但能够保证模块间协调工作，同时还为各模块的并行开发提供出口和入口约束。良好的接口规范应该具有清晰、简洁、易学、易用等特点；

　　4、作业任务分解。在设计方案确认后，需要对方案中的各项作业内容进行合理有效分解，这样便于选择合适的团队或个人来完成对应的作业，以便降低作业难度和作业人员能力不匹配的风险；
　　5、基础核心模块的开发和审查。条件允许的情况下，基础核心模块一定要由核心的团队或个人来开发完成，这样便于保证上层功能能够顺利实现，降低共通内容的重复开发，减少功能间的重叠。

项目管理新解:项目管理图形学

在各种项目管理知识体系中，将项目管理进行了诸多的知识领域划分，总让人有种“雾里看花”的感觉。长期从事某种项目管理知识体系的研究人员或许能够对知识领域、管理过程细细数落，但是对于非研究人员来说，比如项目管理工程实践的老手、项目管理的新手来说，如何快速上手、结合实践工程运用只怕比记忆一个知识管理体系要现实得多。

管理的精髓就是“把复杂的事简单化了”。那么能否用图形化的方式来表达项目管理的方方面面呢？就象软件需求建模用UML图形一样，如果项目管理的某个方面能用一两张图形来描述，稍作解说，那将特别有利于项目组内外人员的一致沟通。笔者（编者注：CSAI顾问团高级顾问邓子云）将研究如何用图形化的方式来描述项目管理的领域称为项目管理图形学。

一谈到图形描述的问题，让人马上联想到什么样的图元表示什么样的含义，能不能有所扩展，分为哪些图形种类。目前，在各种工程领域应用的图形种类已非常之多，有流程图、网络图、IDEF图等，不一而足，有的应用于特定的行业领域，有的有严格的约束。

项目管理需要体现很强的实践特性，用一两种图形似乎难以描述，也很难有严格的语义定义所需要表达的内容，项目管理工作的复杂性和多变性用工程技术领域中的图形描述又似乎不太合适。不过，简单的总是好的，甚至会对项目管理工作带来极大的帮助，这就够了。毕竟实用是这里坚持的首要原则。

　　下面概括出项目管理图形学研究的几个前提性的原则：

　　（1）实用性原则。偏向于项目管理实践工作应用，而不能偏向于学术研究。主要用于使用图形可以方便地应用起来。

（2）易读性原则。不追求严格的图元元素表述及语义要求，但要求图形容易被人所理解和沟通。主要用于客户交流与优化阶段。

　　（3）简单化原则。尽量用图来表达，而且少用文字，图形又要尽量简化。主要用于简化图形阶段。

（4）正确性原则。正确地表达出项目管理者所想的内容，虽然在元素的形状表述上可能因人而有异，但通过配合适度的口头语言和文字描述后，即可无误地在相关人员之间沟通。主要用于作图阶段。

　　根据以上原则，即可变幻出各种不同的图形，只要适合于项目管理的实践工作，都可以列为项目管理图形学的研究领域。

　　那么项目管理的各项工作用哪种图形更合适呢？又如何来作图呢？图因心生，图随心变。心里如何想的，先自己画出来，再需要作些变化。作为项目管理人员，不仅要勤于思考，也要善于表达，将表达付诸于图形中这也是一种不错的选择。为抛砖引玉，笔者下篇文章（编者注：CSAI顾问团高级顾问邓子云）《项目管理图形学之“九九归一”》将和读者一起来作第一个项目管理图形学实践。

项目管理师知识点（局域网协议）

　　信息系统项目管理师资料整理局域网协议

局域网协议 局域网技术由于具有规模小、组网灵活和结构规整的特点，所以极易形成标准。事实上，局域网技术也是所有计算机网络技术中标准化程序最高的一部分。国际电子电气工程师协议IEEE早在20世纪70 年代就制定了三个局域网标准：IEEE 802.3(CSMA/CD，以太网)、802.4 (Token 174 Bus,令牌总线)、802.5 (Token Ring,令牌环)。由于它已被市场广泛接受，所以IEEE 802系列标准已被ISO采纳为国际标准。而且随着网络技术的发展，又出现了像802.7 (FDDI ), 802.3u(快速以太网)、802.11(无线局域网)、802.12(100VG-AnyLAN ), 802.32(千兆以太网)等新一代网络标准。局域网协议是工作在数据链路层上的。

　　1.以太网(IEEE 802.3) 以太网采用的是“存取方法”，是带冲突检测的载波监听多路访问协议(CSMA/CD )技术。 现在以太网主要包括以下三种类型，而且现在还在继续向前发展。 ·IEEE 802.3中所定义的标准局域网，速度为10Mb/s,传输介质为细同轴电缆; ·IEEE 802.3u中所定义的快速以太网，速度为l 00Mb/s ,传输介质为双绞线; ·IEEE 802.32中所定义的千兆以太网，速度为1000Mb/s，传输介质为光纤或双绞线。

　　(1)存取方法。虽然以太网技术已有了很大的发展，但是它们所采用的“存取方法”都是基于CSMA/CD发展而来的。CSMA /CD(Carrier-Sense Multiple Access with Collision Detection)，载波侦听多路传送碰撞检测技术。它让整个网络上的设备都以竞争的方式来抢夺传送数据的权力，它的工作原理如下所述。

每当网络上的设备将数据送上传输线路时，都事先监听传输线路上是否有数据正在传输，如果没有，就将数据包送出去; 如果侦测到线路上正好有数据在传输，则继续监听网络，直到数据传输结束，再将自已在传送的数据传送出去; 还有一种情况是网络上有两台电脑同时要开始传输数据，而同时开始监听，这时线路恰好是空闲的，两台机器同时通过传输线路传输数据，这时就发生了“碰撞”。当遇到这种情况的时候，两台电脑同时终止传送，然后继续监听线路。

(2)802.3 10Mb/s以太网。这个标准是由IEEE 802.3委员会根据以太网技术总结出来的一个标准。它定义了一系列面向不同的传输媒介的、传输速率为10Mb/s的以太网规范。用以下表示法来区别： <用Mb/s计的传输速率><信号发式><用百米计的最大段的长度/线缆类型> 其中定义过10BASE5, 10BASE2, 10BASE-T, IOBASE-F等几种(需要注明的是，其中10BASE-T与 10BASE-F的最后一项就是以线缆类型进行命名的，其中T代表双绞线，F代表光纤)。表10-4是对它们进行的简单介绍。

(3) 802.3u 100Mb/s快速以太网。随着计算机技术的不断发展，10Mb/s的网络传输速度实在无法满足日益增大的网络的需求。人们就开始寻求更高的网络传输速度。但是由于 802.3 已被广泛应用于实际中，所以为了能够在它的基础上进行轻松升级，802.3u 充分考虑到了向下兼容性：它采用了非屏蔽双绞线(或屏蔽双绞线、光纤)作为传输媒介，采用与 802.3 一样的介质访问控制层CSMA/CD 。802.3u常称为快速以太网。 根据实现的介质不同，快速以太网可以分为100BaseTX, 100BaseFX和100E aseT4三种，如表10-5所示。

(4)802.3z 1000Mb/s 千兆以太网。20 世纪 90 年代中期，随着各种新的网络技术的推出，仅有100Mb/s传输速度的以太网似乎已经发展到了极限，“以太网被淘汰了”的说法让以太网技术一度低迷。许多对网络速度要求更高的计算机网络不得不采用一些新的网络技术(如ATM技术)来解决他们的问题。然而，1000Mb/s 的千兆以太网的推出，如同给以太网技术注入一剂“强心针”，使以太网技术迅速重新崛起。

它在780nm光纤上或超5类非屏蔽双绞线上运行。值得一提的是，为了给千兆以太网提供更好的传输媒介，非屏蔽双绞线也推陈出新，不断地发展。首先是在 5 类双绞线的基础上进行改进，以 175 适应千兆以太网的需要，接着又发展到了超5类、6类线。 IEEE 802.3z的出现向世人证明了以太网的“青春仍在”，而研究以太网技术的科学家们并没有因此而停止进一步研究，而是大胆地推进了万兆以太网的研究工作，我们拭目以待，相信以太网的奇迹仍然会出现。

2.令牌环网/IEEE 802.5 令牌环网是业界老大 IBM(国际商用机器)公司于20 世纪 70年代开发出来的，至今仍然沿用于IBM内部局域网的一种局域网技术。它在局域网中的流行性仅次于以太网。它还有一种变形，就是令牌总线/IEEE 802.4. 它的传输介质虽然没有明确定义，但主要基于屏蔽双绞线、非屏蔽双绞线两种。它的拓扑结构可以有多种：环型(最典型，是原意)、星型(实际上采用得最多)、总线型(一种变形)。

　　(1)存取方法—令牌环控制。首先，令牌环网在网络中传递一个很小的帧，称为“令牌”，只有拥有令牌环的工作站才有权力发送信息。 令牌在网络上依次按顺序传递。 当工作站要发送数据时，等待捕获一个空令牌，然后将要发送的信息附加到后边，发往下一站，如此直到目标站，将令牌释放。 如果工作站要发送数据时，经过的令牌不是空的，则等待令牌释放。

(2)与以太网的比较。Examda提示: 我们明显感觉到令牌环网的缺点，那就是协议过于复杂，所以造成了不必要的带宽开支，使令牌环网的速度比以太网慢得多。 当然，令牌环网也有它的优点，它可以定制每个站持有令牌的时间，使整个网络是“确定性”的。表10-6所示的是对以太网、令牌环网及它的变形令牌总线进行的综合比较。

　　3. FDDI/光纤分布式数据接口 FDDI(Fiber Destributed Data Interface),光纤分布式数据接口。它是由美国国家标准协会X3T9.5委员会制定的光纤环网标准。FDDI采用了类似令牌环网的协议，用光纤作为传输介质，数据传输率可达到100Mb/s,环路长度可扩展到200km,连接的站点数可以达到1000个。 FDDI网络在过去的10年中有了迅速的发展，主要的网络产品制造商有DEC, AT&T等，绝大部分的FDDI都是用于LAN的骨干网。

项目管理师知识点（广域网协议）

信息系统项目管理师资料整理广域网协议
　　广域网协议 在地域分布很远、很分散，以致无法用直接连接来接入局域网的场合，广域网(WAN)通过专用的或交换式的连接把计算机连接起来。这种广域连接可以是通过公众网建立的，也可以是通过服务于某个专门部门的专用网建立起来的。相对来说，广域网显得比较错综复杂，主要是用于广域传输的协议比较多：PPP(点对点协议)、DDN, ISDN(综合业务数字网)、X.25, FR(帧中继)、ATM(异步传输模式)等。

　　1.PPP点对点协议 
　　PPP 点对点协议主要用于“拨号上网”这种广域连接模式。一般来说，一些无法使用专门的网络线连接的双方(比如说家庭用户、移动用户)需要广域相连接的时候，就可以借助分布最广的公用交换电话网来实现。 当我们要浏览互联网上的网页的时候，首先通过调制解调器连接到电话线上，然后将在远方服务器的内容通过电话线传送到自、已的计算机中。或者当大家要发送电子邮件的时候，就可以将写好的电子邮件从电话线中传送出去。 176 另外，两个不同城市的两台计算机要互相传送数据，也可以通过装在两台计算机上调制解调器，让其中一台呼叫另一台(拨打它的电话号码)，而建立点对点的连接来实现的。 迄今为止，拨号上网还是绝大多数的家庭用户和小型办公室用户广域连接的一种最常用的手段。但是因为传输线路是模拟线路，所以传输速度较慢。 补充： 用户接入 Internet，在传送数据时都需要有数据链路层协议，其中最为广泛的是串行线路网际协议(SLIP)和点对点协议(PPP)。由于SLIP具有仅支持IP等缺点，主要用于低速(不超过19.2kbit/s)的交互性业务，它并未成为Internet的标准协议。为了改进SLIP，人们制订了点对点PPP(Point-to-Point Protocol)。RFC1661、RFC1662、RFC1663。

　　PPP三大成就： 
　　1.明确地划分出一帧的尾部和下一帧的头部的成帧方式。这种帧格式也处理错误检测工作。
　　2.当线路不再需要时，挑出这些线路，测试它们，商议选择，并仔细地再次释放链路控制协议。这个协议被称为链路控制协议LCP(link control protocol)。
　　3.用独立于所使用的网络层协议的方法来商议使用网络层的哪些选项。对于每个所支持的网络层来说，所选择的方法有不同的网络控制协议 NCP(network control protocol)。 PPP帧不仅能通过拨号电话线发送出去，而且还能通过SONET或真正面向位的HDLC线路(即路由器与路由器相连)发送出去。

　　一、PPP协议组成 PPP协议有三个组成部分：
　　(1)一个将IP数据报封到串行链路的方法。PPP既支持异步链路(无奇偶校验的8比特数据)，也支持面向比特的同步链路。
　　(2)一个用来建立、配置和测试数据链路的链路控制协议LCP(Link Control Protocol)。通信的双方可协商一些选项。在[RFC 1661]中定义了11种类型的LCP分组。
　　(3)一套网络控制协议NCP(Network Control Protocol)，支持不同的网络层协议，如IP、OSI的网络层、DECnet、AppleTalk等。

　　二、PPP帧格式 PPP帧格式和HDLC帧格式相似。

二者主要区别：PPP是面向字符的，而HDLC是面向位的。 7E 7E EF 03IP数据报 信息 F A C 协议FCS F字节 1 1 1 2 不超过1500字节 2 1
　　 PPP帧格式 可以看出，PPP 帧的前 3 个字段和最后两个字段与 HDLC的格式是一样的。
　　标志字段
　　F 为 0x7E(0x表示7E)，但地址字段A和控制字段C都是固定不变的，分别为0xFF、0x03。PPP协议不是面向比特的，因而所有的PPP帧长度都是整数个字节。 与HDLC不同的是多了2个字节的协议字段。协议字段不同，后面的信息字段类型就不同。

　　如：
　　0x0021——信息字段是IP数据报
　　0xC021——信息字段是链路控制数据LCP
　　0x8021——信息字段是网络控制数据NCP 177
　　0xC023——信息字段是安全性认证PAP 
　　0xC025——信息字段是LQR
　　0xC223——信息字段是安全性认证CHAP 当信息字段中出现和标志字段一样的比特0x7E时，就必须采取一些措施。因PPP协议是面向字符型的，所以它不能采用 HDLC 所使用的零比特插入法，而是使用一种特殊的字符填充。具体的做法是将信息字段中出现的每一个 0x7E 字节转变成 2 字节序列(0x7D，0x5E)。若信息字段中出现一个0x7D的字节，则将其转变成2字节序列(0x7D，0x5D)。若信息字段中出现ASCII码的控制字符，则在该字符前面要加入一个0x7D字节。这样做的目的是防止这些表面上的ASCII码控制字符被错误地解释为控制字符。

　　三、PPP链路工作过程
　　当用户拨号接入ISP时，路由器的调制解调器对拨号做出应答，并建立一条物理连接。这时PC机向路由器发送一系列的LCP分组(封装成多个PPP帧)。这些分组及其响应选择了将要使用的一些PPP参数，接着就进行网络层培植，NCP给新接入的PC机分配一个临时的IP地址，这样PC机就成为 Internet上一个主机了。当用户通信完毕时，NCP释放网络层连接，收回原来分配出去的IP地址。接着LCP释放数据链路层连接，最后释放的是物理层的连接。 对方协商一些选项鉴别成功 NCP 配置通信结束载波停止失败失败检测到载波鉴别终止打开静止

　　网络建立
　　PPP协议过程状态图当线路处于静止状态时，并不存在物理层的连接。当检测到调制解调器的载波信号，并建立物理层连接后，线路就进入建立状态，这时LCP开始协商一些选项。协商结束后就进入鉴别状态。若通信的双方鉴别身份成功，则进入网络状态。NCP配置网络蹭，分配IP地址，然后就进入可进行数据通信的打开状态。数据传输结束后就转到终止状态。载波停止后则回到静止状态。

　　2. ISDN综合业务数字网
　　ISDN经历了一个极为漫长的“进化”过程。如果你常看一些网络界的时报，一定不会在10年之前就对它有所耳闻。在它出现的时候，远程通信界的专家们都声称它是未来的公共电话、电信接口。但是它的不够经济却严重地阻碍了它的广泛应用。 中国电信用了一个形象的名字“一线通”描述出它的特点：ISDN 将数据、声音、视频信号集成进一根数字电话线路，提供有效、经济的途径，将用户与高带宽数字服务相连。 ISDN可分为N-ISDN(窄带ISDN)和B-ISDN(宽带ISDN)两种。 其中常用于家庭及小型办公室的是N-ISDN,它提供的基本速率接口(BRI)服务由2个B信道和1个D信道组成(2B+D)，其中B信道为 64Kb/s，D信道为16Kb/s。 而B-ISDN提供的主要速率接口(PRI)则根据不同的国家而不尽相同。在北美、日本为23个速率64Kb/s的B信道和1个速率也为 64Kbls的D信道，总速率为1.544Mb/s,即23B+D。在欧洲、澳洲及其他国家，一般则是由30个速率64Kb/s的B信道和1个速率也为 64Kbls的D信道构成，总的接口速率可达到2.048Mb/s,也就是30B+D。

　　3 .xDSL
　　xDSL是DSL (Digital Subscriber Line)的统称，即数字用户线路，是以铜电话线为传输介质的传输技术组合。DSL技术主要分为对称和非对称两大类。
　　(1) HDSL(高速对称DSL)：是xDSL技术中最成熟的，它利用两对双绞线传输，支持Nx64Kb/s和多种速率，最高可达E1速率。
　　(2) SDSL(对称DSL)：利用单对双绞线传输，支持多种速率，最高到TI/El。
　　(3)MVL : Paradyne公司开发的低成本对称DSL传输技术，可以提供上下行768Kb/s，传输距离可达6km。
　　(4) ADSL(非对称DSL)：利用现有铜双绞线(即普通电话线)，提高到8Mb/s下行速度，1 Mb/s上行速度，传输距离3km到5km。

　　4.DDN数字专线
　　Examda提示:我国邮电部于1994年10月完成了全国数字数据骨干网的一期建设。这个网络是利用光纤、数字微波或卫星数字交驻连接设备组成的数字数据业务网。这些数字线路用于出租给最终用户。 由于在我们使用PPP协议拨号上网的时候，发送、接收数据所通过的电话线路是不明确的，速率根据当时线路的拥塞情况不同而不同，所以它的传输是低速且不稳定的。 对于某些需要更高的传输速度和质量的用户，就可以租用DDN线路来实现。租用了DDN线路，就等于在用户与电信局端直接用一条定制带宽的专用电话线路相连，显然这能大大提高整个数据传输的稳定性和速度。这项业务开通后，受到了用户的广泛好评，并且广泛被采用。 在DDN的客户端需要一个称为DDN MODEM的CSU/DSU设备，以及一个路由器，它的价格与DDN线路的带宽相关，一般来说，开通一个DDN客户端的费用在1.5万元左右。

　　5 .X.25
　　X.25是历史最悠久的广域数据传输协议。尽管它是所有广域数据传输协议的鼻祖， 而且也曾经为广域传输做出了很大的贡献，然而现在它似乎已经走到了尽头，X.25的应用越来越少了。

　　6. FR帧中继 
　　作为X.25网络协议的发展，Examda提示:帧中继是一种高性能的广域网协议。它是X.25的一个简化版本，省去了X.25的一些强制功能，如提供窗口技术和数据重发功能，这是因为帧中继的设计是以网络的传输环境已经有了很大的提高为前提的。

　　1990年，Cisco, Digital Equipment, Northern TeleCom和StartaCom等公司组成一个联合体，共同开发了帧中继技术。此后，帧中继技术有了迅猛发展。从整个连接上，帧中继与X.25相当类似。但它在数据分组确认和差错校验方法上有了很大的简化，而且分组的转发也有了改变。帧中继只要接到分组头，就开始转发，这样进一步提高了速度。但是，需要强调的是，帧中继在网络环境不好的情况下，将无法像X.25那样提供较好的传输质量，而且可能会使用传输质量急剧下降。

项目管理师知识点（测试相关内容）

　　软考项目管理 测试相关内容

　　1.黑盒测试 黑盒测试把测试对象看做一个空盒子，不考虑程序的内部逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明，又称为功能测试或数据驱动测试。 黑盒测试方法主要是在程序的接口上进行测试，主要是为了发现以下错误。 .是否有不正确或遗漏了的功能;在接口上，能否正确的接收输入，能否输出正确的结果; ·是否有数据结构错误或外部信息访问错误;性能上是否能够满足要求;是否有初始化或终止性错误; .黑盒测试需要在所有可能的输入条件和输出条件中确定测试数据，以检查程序是否都能产生正确的输出;有时测试数据量太大，是不现实的。 黑盒测试的测试用例设计方法主要有如下几种。

　　(1)等价类划分。等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。该方法把所有可能的输入数据即程序的输入域划分为若干个部分，然后从每一部分中选取少数有代表性的数据作为测试用例。

(2)边界值分析。边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值方法设计测试用例，应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。边界值分析方法选择测试用例的原则在很多方面与等价类划分方法类似。

(3)错误推测法。人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。其基本思想是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

　　(4)因果图。如果在测试时必须考虑输入条件的各种组合，可使用一种适于描述多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。这种方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

(5)功能图。它用功能图FD(Functional Diagram)形式化地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成，状态迁移图用于表示输入数据序列以及相应的输出数据，在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。逻辑功能模型用于表示在状态中输入条件与输出条件之间的对应关系。测试用例则是由测试中经过的一系列状态和在每个状态中必须输入/输出数据满足的一对条件组成。

2.白盒测试 白盒测试把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构和有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实 40 际的状态是否与预期的状态一致，又称为结构测试或逻辑驱动测试。 白盒测试主要对程序模块进行如下检查： 

·对程序模块的所有独立的执行路径至少测试一次; .对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次; .在循环的边界和运行界限内执行循环体; .测试内部数据结构的有效性等。

逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的设计用例的技术。它属白盒测试，包括语句覆盖、判定覆盖、条件覆盖、判定一条件覆盖、条件组合覆盖、路径覆盖等。 
　 ·语句覆盖：就是设计若干个测试用例，运行被测程序，使每一可执行语句至少执行一次。

·判定覆盖：设计若干个测试用例，运行被测程序，使程序中每个判断的取真分支和取假分支至少经历一次，又称为分支覆盖。 
　 ·条件覆盖：设计若干个测试用例，运行被测程序，使程序中每个判断的每个条件的可能取值至少执行一次。 

　　·判定一条件覆盖：设计足够的测试用例，使判断中每个条件的所有可能取值至少执行一次，每个判断中的每个条件的可能取值至少执行一次。 
　　·条件组合覆盖：设计足够的测试用例，运行被测程序，使每个判断的所有可能的条件取值组合至少执行一次。 
　　·路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。

　　3.α测试和β测试 在软件交付使用之后，用户将如何实际使用程序，对于开发者来说是不知道的。通常在软件发布上市之前需要进行α测试和β测试。 α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。 α测试可以从软件产品编码结束之时开始，或者在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。 β测试是由软件的多个用户在实际使用环境下进行的测试。

项目管理软件Project发展回顾

　 早80年代中期，微软公司就研究开发出了项目管理软件Project的DOS版本。

　　1990年，微软推出了世界上第一个基于WINDOWS环境下的Project 1.0 for Windows版本，开创了一个新篇章。此后，大约每两年就有一个新版本，功能逐版增强，操作越来越简化容易。

1992年4月，Project 3.0 for Windows问世，当年在美国PC Magazine杂志组织的评比内容多达280余项的8个项目管理软件评比中，被编辑部推荐为最佳软件。

1994年4月，微软推出Project 4.0 for Windows，世界上很多大公司(如波音公司)争先选用它做项目管理。这个版本当时没有中文版。为在我国广泛应用，中国科学院计算所开发了“中文伴侣”，使这个版本中文化，因此在建筑、航空、航天等领域有数百家单位应用，收到了很显著的效果。

　　在Windows 95问世后，适应这个操作系统的Project 4.1于1995年7月进入项目管理领域，该版本增强了在计算机网络通讯方面的功能，为大型工程的现代化管理奠定了基础。

1997年10月，微软推出了Project 98英文版，当年12月又推出了中文版。这个最新的版本为适应市场经济发展的形势，采用了许多新的项目管理思想，在机制上有重大的改进，特别增加了在Internet上交流的功能，使项目管理的水平能够提高到一个新的台阶。

2000年4月3日，微软公司宣布，Project 2000及其配套软件——基于WEB的Microsoft Project Central的零售开始。2000年7月19日，微软(中国)有限公司正式发布了面向项目管理的软件Project 2000中文版。它为知识性工作者提供更有弹性的协同计划与项目追踪的能力，并将项目的任何资讯自动、有效地传递给与项目有关的人员。Project 2000中的新功能----Microsoft Project Central是一个基于 Web的协同作业工具，它让每个与项目有关的使用者都可以进行多向沟通并存取项目资料，使得项目管理的环境更适合企业进行大型项目管理，满足多人环境下的使用。

2002年9月6日，Project 2002中文版正式上市。Project 2002包括了Microsoft Project Standard 2002、Microsoft Project Professional 2002以及Microsoft Project Server 2002三个版本。标准版和专业版适合所有的项目管理人员和项目成员使用，能协助企业经理人动态管理日程与资源、沟通项目状态，以及分析项目信息。服务器版特别为企业集中管理和分享项目的信息而设计，是第一次推出。可将企业內部标准化的项目与资源信息集中储存，以达到有效率的项目信息分享、分析与管理能力。

2003年10月21日，微软公司宣布Microsoft Office System大规模投放市场。微软(中国)有限公司同时宣布，简体中文版于2003年11月13日在北京正式发布。Project 2003 作为 Microsoft Office System 的集成组件出现，它包括面向单个管理人员的项目程序Project Standard 2003和Project Professional 2003以及Microsoft Office 企业项目管理(EPM)解决方案。Microsoft Office 企业项目管理 (EPM) 解决方案适用于具有以下需求的组织：在项目之间和项目经理之间需要有充分的协调和严格的标准化、需要集中管理资源或者需要对项目和资源情况进行更高级别的报告。

　　2006年11月30日，微软公司发布Office 2007 RTM版。2007年1月30日，Office 2007正式版的零售发布。Office Project 2007 家族包括 Office Project Standard 2007 以及 Enterprise Project Management (EPM) Solution 所必需的以下产品：Office Project Professional 2007、Office Project Server 2007、Office Project Web Access、Office Project Portfolio Server 2007 和 Office Project Portfolio Web Access。

项目管理感触：最难做的就是项目经理

从做项目开始，就知道项目管理是一件十分困难的事情，特别难做的就是项目经理。而我的理想就是成为一名成功的项目经理。因此抱着这种想法，只要有时间就会把google上搜索任何一篇有关项目管理的报道、介绍、经验谈等资料，一一浏览，仔细琢磨，希望能够从前人们的忠告中获取更多的经验，避免以后的工作中出现类似的问题。但是真的是应验了“计划不如变化的快”这句老话，无论花费多少时间在这个上面，终究还是没有办法使手中的项目能够全部完美的处理好。但是经过几个项目的训练也让我有颇多的感受，现总结以下几点，给大家做个参考吧。

　　一、项目目标

如果你在一家以项目作为生存手段的公司里，那么在接任何一个项目的同时，你就要去考虑该项目的目标是否明确，是否可以值得你花费这些时间去完成这个项目，即：所谓的项目可行性分析。当然这种分析与商家们那种市场的可行性分析还是有相当的区别的。商家们的分析是要讨论该项目是否给他们创建相应的利润，而项目经理除了分析做项目可得到的利润外;还要分析该商家对该项目的重视度，分析商家内部是否有人会对该项目产生阻碍;还要分析如果商家不能够及时支付该项目款项时，项目开发的内容与团队要如何处理;如果项目拖延时间过长，是否对公司有生存影响及公司以后的业务发展等。总之一句话，就是要考虑到项目的方方面面，将可能产生的问题与解决方案及未能解决的问题都要仔细的考虑到，这样在做项目的时候，风险才会小些，利润才会大些。

当然如果你是在处理公司内部的项目的时候，有很大一部分的项目是项目经理所不能左右的，只能是接受公司领导层的指派完成该项目。但是项目经理也必须要考虑该项目公司里的领导与各部门的重视程度等因素，将影响项目成功的各因素都要考虑在内，尽量避免产生项目的半途而废(当然有些项目的成败，项目经理是无法控制的)。这就是项目经理需要做的会影响到项目成败的重要工作――项目启动与风险识别。

　　二、项目计划

项目经理接受项目后，最首要的工作就是计划。为项目制定相应的时间表、功能表、人员表、配合部门表等一系统的计划安排。这个计划是相当重要的，首先是让项目有一个清晰的头绪，其次为项目的进行有一个目标，最后保证项目顺利完成。这个计划当然不是固定不变的，需要不断地进行相应调整。

　　三、项目团队

在承接一个项目后，项目经理必须要组建相应的项目团队。当然组建项目团队的方式有很多种，有的是通过临时的招聘，找到一些相应的技术人员来完成项目的开发 (这种现象在建筑业内较多见);还有的就是从公司各部门抽调相关的人员短期的组成一个团队完成项目;再有就是自身就已经是磨合过一段时间的项目团队。

当然任何一个项目经理都希望分到自己手中的资源是越高级越好，越优秀越好，但是这种情况的产生是十分的少的，因为越优秀的团队成员的加入说你在人力成本上需要花费更多的资金。因此项目经理在组建团队的同时，就要将项目的不同时段进行相应的划分，针对不同的时段选择不同水平的人员。

就IT业而言，一般是需求分析、系统设计与数据库设计这块的人员水平要求较高，而进入代码编写阶段后，则相应的人员水平就可以降低，只要求对代码编写熟练就可以，相应的测试人员也可以这时间加入进来，根据测试计划测试已经编写好的各模块。项目经理应该学会对资源的充分利用，有时候不是把握的越多越好，而是该放手的时候就应该放手。

项目的时间有长有短，对于短期项目而言，团队成员之间应该是越熟悉越好，因为受到时间的限制，熟悉的团队成员可以减少磨合期的时间，加快项目的进度。但不是说项目团队的挑选与项目团队成员的熟悉之间成正比。

如果项目时间长，那么项目经理必须为团队成员组织一定次数的沟通交流或者是外出游玩的活动，让大家可以通过团队的出游减缓工作的压力调节心情为项目的继续深入做相应的积极准备。

项目经理必须定期要求各小组或者是团队成员回馈项目的进展情况，将手中的问题积极的反馈到项目经理的手中，由项目经理去处他们所不能处理的问题。而不是等到问题被掩盖无法处理的同时才去处理，那将是一块十分烫手的山芋了，而且到那个时候的处理必须大大地影响整个项目。因此说句不客气的话就叫做“将任何问题扼杀在摇篮中”。而为了做好这点就项目经理必须做的一个主要工作―沟通。

　　四、项目资金

项目资金是是节制项目更多活动的主要手段，但是国内目前的许多项目，项目经理是无法接触到项目资金这块的，一般这块都是由财务部负责处理。因此虽然有许多项目经理都想为项目挣得更多的利润，但其实他们对资金的控制都相对羞涩的多了。其中大部分的原因是现在许多公司里的人员工资是相对保密的，公司不允许互相打听各自的报酬。当然这个作法可以维护相对稳定的公司团队，但是对项目经理而言，在定期的项目资金使用报表里就会缺少大量真实的凭据，而是大约估计一下，给出个大约量，但是这样做必然会引起项目资金的虚报。

以IT业为例，项目经理从来不知道任何一个团队成员的具体报酬，而是使用财务人员给予的相应的人员等级资金来估算项目成本。比如：将公司里的各技术人员划分成三个等级，每个级别按××元/人/次的计算。这样出台的成本表里的水份很大。而这个又是不可避免的。

　　五、项目验收

项目完成后，除了客户验收外，最好公司内部再做一次相应的内部验收，这样一方面可以保证项目的成功率，另一方面也可以起一个内部监督的效果。还可以从另一方面提高公司项目过程的不断改进，为以后其他的项目成功提供范本。

　　六、项目总结

每个项目验收后，项目经理都要做好项目总结;将项目过程发生各种事件及处理方法做好一个备案，提供给其他的项目经理参考。项目经理需完成对团队成员各个的评估，为项目成员提供相应的工作证明。

一个项目的产生一定有其相应的市场存在性的要求。在不断地接项目业务的同时，项目经理可以不断地为项目进行分门别类，将项目的要求总结归纳，形成自己的一套对待该行业项目的独有的解决方案，形成产品化。这个不仅可以为项目经理在以后的项目接单中找到以往的经验，还可以通过该产品化的产生，为公司及自己找到新的一条生存路径。

项目除了以上的这几点需要注意外，还需要项目经理能够灵活的变化，以及不断地提高自身的水平。项目经理除了需要具有相应的管理能力外，更多的是领导能力，他必须在规定的时间段内，领导项目团队走向成功。

项目经理可以是对业务十分熟悉的人员来担任也可以由一个具有很好领导力与管理能力的人来担任，因为项目的成功并不是靠项目经理一个人来决定的，他需要团队以及其他项目相关人员的配合，因此项目经理在项目开发过程中更多的是处理/控制突发性的事件以及与人的沟通。

　　综上所述，项目经理就是要做到：项目启动、计划、执行、控制、收尾的五项。将这五项的各个环节处理顺利，项目就会有60%的成功希望，而剩余的40%需要项目经理适时地改变。能够不断适应新需求的项目经理，就可以带领项目走向成功。

项目管理方法---基层项目经理如何激励自己的团队

激励在哪里都是需要的，对于基层员工来讲，他可能考虑不到公司长远的发展，比较难认同公司长远利益，而与公司共甘苦。这也很容易理解，他们一般都很年轻，个性强烈，做事不太考虑后果，喜欢新事物，没有家庭的压力等等，因此他们的决定往往比较随意。我有经历过的同事离职，包括我自己的几次换工作，都有一些随意。有些人，往往因为很小的事情就决定离开一个公司。

　　作为承担研发项目的基层项目经理，团队的士气和稳定非常重要，这里就探讨几条激励士气的方法：

　　一、工作任务的安排

　　安排工作任务也是可以激励士气?是的，合理分配任务可以让组员工作在愉快中。

工作任务的安排，要根据组员的能力，性格，以往经验，个人意愿，并结合项目进度综合考虑。

　　1、不要让一个人永远做同一件事，这样的安排违背效率原则，因为熟能生巧，大多数日本企业采取这样的风格。比如，日企里，一个专门负责文档工作的人，可能把word,excel使用的淋漓尽致，而且文档经过他的手之后，会非常漂亮，专业。 人不是机器，因此我不赞成这种做法，采取适当的频率调整组员的工作内容，会让他们更乐于接受工作。

　　2、工作的适当划分，这也是项目经理要重点考虑的，工作任务分解到多大为合理，这也是一门学问。

　　3、把那些有挑战性的工作交给那些熟练员工，让他们做重复，技术含量低的工作会让他们觉得没趣。

4、新员工同样需要工作压力，否则他们不会成长，所以虽然相对简单的工作被分配给了后进员工，但是工作负荷要得到保证。

　　二、与组员同甘共苦

作为基层项目经理，不要把自己定位在领导的角色上，要学会与组员同甘共苦。并多参与一些技术上的工作，比如参与需求分析，高层设计，文档/代码的review, 甚至在项目进度紧，人员缺的情况下，参与一些详细设计，coding等工作。 和组员摸爬滚打在一起，可以很好地激励组员。因为在你的组员眼中，你始终是一个领导。你能和他们一起辛苦，他们会比较能认同你。

再说加班， 工作任务紧的时候，加班在所难免，不能让你的组员天天劳作，而你每天很早就回家了。我的切身体会就是，当你和你的组员一起加班到很晚，结束后，大家一起去吃一个简单的夜宵，大家会感觉很好。(当然不能每次都去吃，否则大家会认为是个负担，因为大多数时候，大家还是希望，工作完马上回家休息)。

　　三、为组员争取合理的利益

　　1. 争取公司奖励：公司必然有很多比如“优秀员工” ,“进步奖”等等奖项，要为合适的组员争取这些奖励，在公司范围内表彰，将大大促进该员工的成长。

　　2. 工资，奖金调整

3. 加班补助的争取

　　四、沟通并了解组员的情况

做你的组员的朋友，而不是领导，虽然你在他们眼中，永远都是领导，他们也会刻意与你保持距离。但是你还是积极地和他们沟通，去了解他们的情况，如果需要时，帮助他们。对于一些后进员工，基层项目经理要肩负起导师的角色。

　　五、考评杠杆作用

考评是一把双刃剑，但是可以说没有一个单位不实行考评。作为项目经理，如果你有考评权(或者考评建议权)，则你要充分利用这一杠杆，因为没有人比你更了解组员的情况，用的好，考评可以为你的团队带来积极的因素。

　　请注意把握以下几个原则：

　　1)考评永远是鼓励进步者，而不是优秀者。只要你的组员取得了进步，不管他水平多差(除非你开除他出去)，你就要在考评上体现出来。那些一直表现优秀的组员，你要考虑在奖金(考虑一个人的贡献)给他倾斜，或者赋予他更有挑战性的任务。

　　2)对于考评比较差的员工，你一定要帮助他一起分析原因。

3)轮流坐庄，对于多个组员都表现出进步，你无法取舍时(考评比例的限制)，采取轮流坐庄的方式，这虽然有大锅饭的嫌疑，但是也是必须要采用的。除非一个人特别出色，大家都心悦诚服，否则不要再项目组设定一个高高在上的标兵。

　　六、和组员一起设定目标

包括个人的绩效目标设定，让组员明确你们团队的目标，以及明确你们团队所在的部门(或者产品)的目标。不管怎么说， 明确的短期/中长期目标是需要的。

　　七、团队活动

包括体育类，聚餐，唱歌，旅游，串门等等，营造组员间融洽的气氛，对于团队战斗力的提高大有裨益。同时通过这些活动，让大家身心也得到一定程度的放松。注意的事是，作为项目经理你要制定一个比较活泼，外向的组员作为组织者，你不要亲自组织。 如果这个组织者是一个美女(你们的团队宝贝)，则更佳。

团队活动也要把握一个度，不能太密，不能太过强制，这样也可能让组员有压力。

　　八、团队文化

　　这一点放在最后讲，不是因为不重要。而是因为它最重要，而又最难做。你要努力去形成你们团队文化，形成一些大家都认同，有没有形成规范的规则。这个很难，还在研究中。

项目管理:软件项目管理的特点

软件项目管理的解决，涉及到系统工程学、统计学、心理学、社会学、经济学，乃至法律等方面的问题。需要用到多方面的综合知识，特别是要涉及到社会的因素、精神的因素、人的因素，比技术问题复杂得多。仅靠技术、工程或科研项目的效率、质量、成本和进度等问题很难得到较好的解决。必须结合工作条件、人员和社会环境等多种因素。因此，简单地照搬国外的管理技术往往不一定奏效。此外，管理技术的基础是实践，为取得管理技术的成果必须反复实践。很显然，管理能够带来效率，能够赢得时间，最终将在技术前进的道路上取得领先地位。在知识爆炸、高技术迅速发展的今天，必须在战略级上对待技术管理问题。

　　(1)软件项目的特点
　　软件产品与其他任何产业的产品不同，它是无形的，完全没有物理属性。对于这样看不见，摸不着的产品，难以理解，难于架驭。但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。因此，要开发这样的产品，在许多情况下，用户一开始给不出明确的想法，提不出确切的要求。他说不清究竟他需要的是什么。在开发的过程中，程序与其相关的文档常常需要修改。在修改的过程中又可能产生新的问题，并且这些问题很可能在过了相当长的时间以后才会发现。文档编制的工作量在整个项目研制过程中占有很大的比重。但从实践中看出，人们对它不感兴趣、认为是不得不做的苦差事，不愿认真地去做。因而直接影响了软件的质量。软件开发工作技术性很强，要求参加工作的人员具有一定的技术水平和实际工作的经验。但事实上，人员的流动对工作的影响很大。离去的人员不但带走了重要的信息，还带走了工作经验。

　　(2)软件项目管理的困难
　　1)智力密集，可见性差：软件工程过程充满了大量高强度的脑力劳动。软件开发的成果是不可见的逻辑实体，软件产品的质量难以用简单的尺度加以度量。对于不深入掌握软件知识或缺乏软件开发实践经验的人员，是不可能领导做好软件管理工作的。软件开发任务完成得好也看不见，完成得不好有时也能制造假象，欺骗外行的领导。

　　2)单件生产：在特定机型上，利用特定硬件配置，由特定的系统软件或支撑软件的支持，形成了特定的开发环境。再加上软件项目特定的目标，采用特定的开发方法、工具和语言，使得软件具有独一无二的特色，几乎找不到与之完全相同的软件产品。这种建立在内容、形式各异的基础上的研制或生产方式，与其他领域中大规模现代化生产有着很大的差别，也自然会给管理工作造成许多实际困难。

　　3)劳动密集，自动化程度低：软件项目经历的各个阶段都渗透J，大量的手工劳动，这些劳动十分细致、复杂和容易出错。尽管近年来开展了软件工具和cAsE的研究，但总体来说，仍远未达到自动化的程度。软件产业所处的这一状态，加上软件的复杂性，使得软件的开发和维护难以避免出错，软件的正确性难于保证，软件产品质量的提高自然受到了很大的影响。

　　4)使用方法繁琐，维护困难：用户使用软件需要掌握计算机的基本知识，或者接受专门的培训，否则面对多种使用手册、说明和繁琐的操作步骤，学会使用要花费很大力气。另一方面，如果遇到软件运行出了问题，且没有配备专职维护人员，又得不到开发部门及时的售后服务，软件的使用者更是徒唤奈何。

　　5)软件工作渗透了人的因素：为高质量地完成软件项目，充分发掘人员的智力才能和创造精神，不仅要求软件人员具有一定的技术水平和工作经验，而且还要求他们具有良好的心理素质。软件人员的情绪和他们的工作环境，对他们工作有很大的影响。与其他行业相比，它的这一特点十分突出，必须给予足够的重视。

　　(3)造成软件失误的原因
　　在总结和分析足够数量失误的软件项目之后，看出其原因大多与管理工作有关。
　　在软件项目开始执行时，遇到的问题往往是可供利用的资料太少、项目负责人的责任不明确、项目的定义模糊、没有计划或计划过分粗糙、资源要求未按时作出安排而落空、没有明确规定子项目完成的标准、缺乏使用工具的知识、项目已有更动，但预算未随之改变。

　　在软件项目执行的过程中可能会发生的问题是项目审查只注意琐事而走过场、人员变动造成对工作的干扰、项目进行情况未能定期汇报、对阶段评审和评审中发现的问题如何处置未作出明确规定、资源要求并不像原来预计的那样大、未能做到严格遵循需求说明书、项目管理人员不足。

　　项目进行到最后阶段可能会发生的问题是未做质量评价、取得的知识和经验很少交流、未对人员工作情况做出评定、未做严格的移交、扩充性建议未写入文档资料。
　　总之，问题涉及到软件项目研制中的计划制定、进度估计、资源使用、人员配备、组织机构和管理方法等软件管理的许多侧面。

　　(4)软件管理的主要职能
　　软件管理的主要职能包括：
　　1)制定计划：规定待完成的任务、要求、资源、人力和进度等。
　　2)建立组织：为实施计划，保证任务的完成，需要建立分工明确的责任制机构。
　　3)配备人员：任用各种层次的技术人员和管理人员。

4)指导：鼓励和动员软件人员完成所分配的工作。
　　5)检验：对照计划或标准，监督和检查实施的情况。

以下将针对软件项目管理的主要问题进行讨论。

项目管理:软件配置管理最佳实践

现在大家都已经认识到了有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置管理实施方面的一些研究，市场上我们也可以看到一些软件配置管理工具厂商针对具体配置管理工具提供的实施服务;但是，实施软件配置管理到底应该做哪些东西?团队的配置管理现状怎么评估?在哪些方面还可以进行改进?我们相信，这些问题可能正困扰着大多数研发主管和项目经理。

　　国外软件产业界在软件配置管理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”(Best Practices)，我们可以使用这些“最佳实践”来作为评估一个组织软件配置管理能力的标尺，也可以作为我们实施软件配置管理的指南。这些“最佳实践”包括：

　　1、 标识需要进行存储的工件(Artifact)并保障安全存储;
　　2、 控制并且审计(Audit)对于工件的修改;
　　3、 设立并管理基线(Baseline);
　　4、 记录并跟踪变更请求;
　　5、 维护稳定、一致的工作空间;
　　6、 支持对于工件和控件的并发修改;
　　7、 尽早集成、持续集成;
　　8、 保证软件构建的重现能力;
　　9、 以控件(Component)为单位实施版本控制;
　　10、 使用“活动”(Activity)来组织和整合版本集。

　　下文将介绍前5条最佳实践。
　　1、标识需要进行存储的工件(Artifact)并保障安全存储
　　在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件(Artifact)。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，好好地保存;对于软件资产，我们也需要相似的措施。所以，软件配置管理工作的第一步就是建立一个安全、可靠的存储库(Repository)，用于保存组织的核心软件资产。

　　这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。

　　对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。
　　在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项(Configuration Item)。

　　2、控制并且审计(Audit)对于工件的修改
　　在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。
　　库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方(Who、When、Why、What)。

　　审计机制通常通过“检出/检入”(Check out/Check in)模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读(read only)，如果要对该工件进行修改，则需要通过“检出”这个步骤;在修改结束以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”(Version Control)。在版本控制过程中，如果利用一些配置管理工具(或者版本控制工具)的支持，则可以自动地记录审计工作所需的四个“W”(Who、When、Why、What)。

项目管理:将Webservice解读到底

分布式应用程序和浏览器
　　研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

　　传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信?问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

　　关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

　　许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

　　什么是Web Service
　　对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：

http://host.company.com/weather.asp?zipcode=20171

　　返回的数据就应该是这样：
　　这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
　　下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

　　Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

　　新平台
　　Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数(译注：如COM和COBAR中的IDL语言)。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。

　　XML和XSD
　　可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

　　XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么?16位，32位，还是64位?这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。

　　SOAP
　　Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。

　　WSDL
　　你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢?你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。

　　解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

项目管理:OpenKM开源文档管理系统(DMS)

OpenKM简介
　　OpenKM是一个文档管理系统,用于组织和共享文档。可以通过名称，内容，关键字等来搜索文档。基于Jboss+J2EE+Ajax web (GWT)+Jackrabbit (lucene)等技术开发。
　　相关技术
　　OpenKM开发过程中运用到了如下几个技术:
　　JBoss 4.0.3SP1 ( version basis for the development ) Java企业级服务器 
　　Java J2EE ( JDK 1,5 ) Java企业级开发环境 
　　Jackrabbit 内容管理库 
　　GWT ( Google Web Toolkit - Ajax ) 用户界面设计 

　　功能介绍
　　1.支持多语言功能
　　2.网站多样式
　　3.上传,下载(把修改后的文件上传或下载后修改;只可以上传MIME在配置文件里有写明)
　　4.版本控制
　　5.垃圾桶 (删除文件后具有恢复功能)
　　6.文档分类管理
　　7.用户权限管理
　　8.搜索引擎(可提供查找功能)
　　9.每个用户一个session

　　开发用的功能
　　1.工作流(workflow)
　　2.Email通知机制
　　3.用LDAP存储用户的信息
　　4.web spider一种搜索引擎
　　5.用户空间控制
　　6.收藏夹
　　7.文件修改后通知机制
　　8.我的文档(存个人的文件)

　　系统运行截图

　　源程序下载
　　http://www.openkm.com/index.pl/download
　　系统演示
　　http://www.openkm.com:8080/OpenKM/
　　用户名和密码可以用以下几个:
　　user1, pass1 
　　user2, pass2 
　　user3, pass3 
　　user4, pass4 
　　user5, pass5

项目感悟1-清楚的了解自己的能力和效率

项目管理既是科学也是艺术，从组建项目团队开始到带领项目团队完成项目目标而取得成功绝非易事。组织环境和文化，人员组成和特点，团队，方法工具技术，风险，范围，进度，成本和质量诸多项目经理要考虑的问题。即使有科学的项目管理方法论，有组织级的过程做保证，但项目经理的经验往往仍然是最重要的内容。

确实，没有必要把项目和人生挂到一起，但从多年的项目管理和过程改进中确实获取到不少的生活领悟，从少年到中年再到老年，人生有何尝不是一个项目，人一生的所有活动都是按照目标把这个大项目经营好。

　　1.清楚的了解自己的能力和效率

这是做项目和最近实施量化项目管理的一个重要体会，每个人都应该对直接的生产率和效率有充分的认识和了解，要做到这个自然就应该做好时间记录，学习记录时间和分析时间。了解自己的效能目的仍然是为直接赚取最大的效益和价值，比如你是一个作手工瓷器的工匠，则你必须清楚的了解直接做瓷器活的生产率和速度，你通过经验的积累和历史工作情况就会形成一些量化的数据，比如一个月做的瓷器量在100-120件。

这就是一个量化的数据，对你最有用的数据。如果你没有这种量化的数据，则你个人的最大价值就无法发挥出来，无法赚钱最大的利润。接单小于100件了自己太空闲把时间浪费了，接单大于120件了则按期无法交货造成违约赔偿。因此只有在这个区间内你每个月才能够创造最大的效益，因此量化自己的生产率是对自己有利的事情。

我们平时讲每个人应该信守承诺，但这往往又不只是态度确定的。你给客户承诺一月交200件，你态度再好也完成不了，因此要信守承诺不仅仅是态度问题，不仅仅是时间管理问题，更多是需要通过时间记录，历史数据分析清楚的了解到自己效能和生产率。我们很多时候不敢承诺往往就是历史数据积累不够，对自己生产率不清楚，在客户给定的期限交付200件自己心里也没有数。

工匠有了100-120件的生产率的历史数据后。那是否就有100%的把握交付呢?当然不是，因为我们在做任何事情过程中都会遇到各种风险和不确定性因素，不确定性有多大，仍然需要看历史数据，看历史月份自己的生产率是否稳定?如果过去的一年12个月自己有11个月都达到了这个区间，则说明你的效能基本是稳定的，你的估计有11/12=90%左右的把握能够完成。如果过去一年有5,6都偏离这个区间，要么高或者要么低，则说明你做事情不稳定，你可能是一个感性或情绪化的人，高兴的时候生产率很高，不高兴的时候又可能很低。如果这样的话就麻烦了，你最高兴时候产能可能是200件，如果你按这个产能去接单，但做单的一个月刚好又遇到了自己最情绪低落的时候，那可能就会导致你大量的延误的损失。

在有了这种自我的生产率数据，并且自我又能够保持这种数据比较平稳的时候，你就可以更有信心的知道如何去充分发挥自己的能量，赚钱最大的价值。但这仅仅是第一步，你的生产率数据是仅仅针对0.5升容积以下，雕刻工艺的简单瓷器制作的效率。而客户和市场又时候千变万化的，当客户需要的是100升上的瓷器或者是需要复杂的美工雕刻的瓷器的时候，自己可能又不知所措了，因为原来没有做过类似的瓷器而导致你没有可以类别的经验数据。

这就引入了第二个层次的问题，我们平时的效率和估算是基于我们的工作是可重复的，基于我们做的产品是类似的思路进行的。一旦市场和产品变化我们已经积累的效率数据就失灵的。这个时候就需要考虑根据历史数据去建立参数化的估算和预测模型，还是刚才的例子我们可以分析出来彩瓷的制作工期跟瓷器的容积，形状，加工工艺，雕刻的图像的数量，上色的层次等多个因素相关，而且你可能还会观察到当需要制作的瓷器容积不断增大的时候，工期往往是曾现指数级别的非线性增长。这样你就清楚了为了适应变化，必须改进自己对数据收集的粒度，并且有意识的去分析工期目标和各个影响参数之间的关系。你积累的历史数据越多，你就越容易建立起一种参数化的预测模型。注意了这种模型并不是说一定要体现为一种数学公式，也可以体现在你自己的经验思维中。

第一个层次在可重复，第二个层次在预测。而我们往往不会刻意去做这些事情，我们为自己预留太多的缓冲时间，让我们形成一种假象，这种假象让我们无法真正了解自己的能力和获取最优化的价值回报。同样，这种态度也往往是跟组织的绩效考核相关的事情，我们不需要太了解自己的生产率，企业或雇主仍然会按月给我应得的报酬。在一些企业或工厂实行的计件工资制正好打破了这一个规则，更好的去促发每个员工了解自己的生产率和提高自我效率。

　　你在为谁工作?我们往往很难回答这个问题。当无论这个问题答案如何，我们都应该有意识的去了解自己的能力和生产效率，你对自我能力了解的越清楚，你越能够信守承诺创造最大价值。你和竞争对手间的差距不是一天两天造成的，更多的是一种日积月累的差距，你只要能够认识到这点，不断持续改进，并保持适当的加速度，则对手往往就很难超越。再回来看刚才例子，如果你的生产率是500件/月，而你对手是100件/月。在这个时候你对手绞尽脑汁提高一倍效率得到的利润只相当于你提高20%效率的回报。

项目感悟2-风险意识和目标驱动

项目目标和风险管理都是项目管理中最重要的内容。这两个搞清楚了不能说项目就一定成功，但却能够回答项目究竟有几层把握能成功。项目在朝项目目标不断迈进的过程就是我们逐步的消除风险的过程，如果一个项目没有风险了则项目就一定能够成功的完成项目目标，否则就是前期没有识别出项目潜在的风险和危机。我们现在讲问题管理，但这已经是亡羊补牢，更多的应该讲危机意识和风险管理。

　　1.风险意识

古人是一直就有高度的危机意识，在《易经》中谈君子安而不忘危,存而不忘亡,治而不忘乱。《道德经》谈为之于未有，始之于未然。《论语》里面也讲如临深渊,如履薄冰指导我们做事情应该谨慎多思。我们要按目标完成一件事情，那么在整个过程中影响到这个事情正常完成的不确定因素，或者在整个过程中我们没有 100%的把握确定的任何潜在影响和不确定性都是风险，你对风险分析的越清楚你越能做到心中有数。日常生活中我们购买保险，看着阴天出门带伞，提前给自己充电等等行为都是我们具有风险意识的表现，只是我们已经将风险转换为了我们的风险应对。

在树立风险意识前首先应该是有目标意识，风险是指如果这些不确定性的事情发生了会影响到我们目标的实现，如果我们的目标都不清晰如何谈得上风险?在日常生活中我们经常不关注目标，风险，而直接看到了风险的应对。还是举保险的例子，比如张三为何要买保险，可能是因为他看到李四得大病了没钱医治，或者是更简单看到王五买了所以自己也买。但真正的目标却是你需要将你每年的医疗费用控制到多少钱以内，或者说99%的把握控制在多少钱以内。有了这个目标你才能真正有意识的去驱动你是否该买保险，如果该买应该买多少?

风险意识跟目标本身的重要性关系紧密。如果目标本身允许的偏差大，则我们的风险意识可能就会弱。比如你和朋友一起聚会，大家公认的在偏差30分钟范围内都是容许的范围，在这种情况下你可能并不会刻意的采取风险应对，按正常情况出门就可以了。但如果你是去拜访一个重要的客户，迟到5分钟以上就会对自己的品牌和公司声誉造成影响，那你可能会做最坏的打算。虽然按正常只要20分钟就能达到目的地，但等出租没等到，中间堵车，电梯出故障都是可能出现的异常情况，如果恰好这些倒霉事情都凑到一起了，你达到目的地需要1个小时。那么你做的最坏打算就是要提前1个小时出发。只有这样才能满足你的目标。

风险意识会体现到我们的应对上面，如进度储备和资金储备，以及提前的知识技能储备都是常用的风险减轻措施。前面已经讲到目标直接影响到风险应对和具体的时间和资金储备，我们定的目标一定是一种对我们最有利的目标，而不是盲目的目标。举个例，张三为了严格遵守开会不迟到的目标，往往每次都需要提前15分钟出发。而李四定的目标是95%情况下能准时达到，因此李四只提前5分钟出发。95%的目标已经可以为李四树立守时的个人品牌，而张三可能为了100%的目标每次都要在会议地点多等待10分钟。一次10分钟往往我们并看不对实际的价值，但多个事件，多次的行为我们往往就可以节约和获取更多的时间来做更重要的事情。

　　2.风险和目标驱动

首先是有了项目目标，有了风险意识我们就会针对项目目标来识别我们可能遇到的各种风险，有了风险我们才可能去考虑风险的分析和应对。或者说在有了足够多的经验数据后可以考虑风险的量化。一个项目之所以复杂，就在于这个项目受到太多的不确定性因素影响，不确定性越多你越没有把握，越没有把握越容易失控和失败。如果一个项目不存在风险，那任何人都能将项目做成功，自然也体现不出项目经理应有的价值，风险驱动的含义就是需要项目经理在整个项目执行过程中不断的变不确定为确定，消除各种潜在的隐患发生的可能。

模仿始终是外在的，关键是理解一种思想和思维的模式。做同样一个项目，甲可能在前期花更多的时间来减少各种风险发生的概率;而乙可能在前期没有任何动作，后期投入爆发的一大堆问题的跟踪，协调和解决中。结果是甲投入了30%的时间就保证了项目成功完成，而乙可能投入了80%的时间最终也只能是项目延期或失败。乙可能也在前期发现了甲经常找成员单独沟通，组织团队活动，进行项目内培训和学习，共同研讨项目应该执行的规范或者还让组员单独去研究一项新技术，但乙往往并不清楚为何存在了这些任务或活动，在乙的WBS工作任务分解里面找不到这些任务的踪迹，这些任务也不是有明确产出和交付的东西。而这些恰好是通过风险识别->风险分析后驱动出来的为了减轻风险发生的任务，对项目影响最大的恰恰是这些任务的完成效果，这些任务如果完成的不好将直接影响到主体任务的完成效果。

对于项目经理而言，风险意识和分析越早越好。项目没有开始前就分析有利于你决策是否接受项目和评估应该的资源，项目正式启动后分析风险有利于随时了解你成功的把握，达到目标的把握，也使你知道在项目执行中你的重要跟踪和关注点。只要风险不发生，你的项目就应该成功，你需要做的就是不断的去采取各种积极的行为去影响风险，去减轻风险发生的概率。

　　3.风险的量化

首先不应该认为风险量化就一定需要经过周密和复杂的统计分析和数字计算，确实风险量化需要借助历史数据和计算机模拟工具，但是我们更多的时候是形成风险量化的意识，风险量化的目的也是让我们对达成目标的一个总体风险情况有清醒的认识。

还是拿上面的例子，当我们要参加一个会议的时候，等不到车，堵车，电梯坏了等等都是风险，这些不确定性都会影响到我们按时达到的目标。当我们在应对的时候我们会关注每一个风险，但我们更关注风险的总体影响，也就是说我原计划的30分钟达到的概率究竟有多大?这才是我们关注的重点问题，前面已经讲过了当要达到100%的时候我们会付出成倍的时间储备。因此一般情况下我们会设定一个目标，比如我要做到95%把握都能够按时参加每次会议。

　　好了这个时候我们就需要分析下前面二十次参加会议的情况，只有通过历史数据分析我们才能得出比较准确的结论，根据分析得到的达到时间分别为 25,28,34,33,29,30,29,34,28,27,28,25,24,24,25,36,29,30,28,27.这些应该是符合正态分布的数据，通过分析如果都是提前30分钟走，则有三次迟到准时的概率只有85%,为了达到95%准时的概率你需要提前35分钟走。你往往并没有做详细的数字分析和模拟统计，当通过自己的不断的经验积累就得出了这种重要的结论。风险储备留的太多浪费，太少又无法达到目标，量化的好处就是我们留刚好够的风险储备来达到我们预定的目标。

项目感悟3-基于平衡的系统观

天之道，损有余而补不足。这句话最适合来概括平衡和系统思考。项目经理在整个项目中最关键的事情就是不断的动态平衡项目目标中各个要素和干系人，并且基于这种新平衡采取相关的决策和行动。项目经理就像是拿着一跟长长的竹竿走在钢丝上，平衡稍微掌握不好就可能无法成功的完成项目的目标，最终导致项目的失败。

前面讲过项目经理具有强烈的目标驱动和风险意识是必须的，但目标和风险意识最终会转换到我们的行动和决策，诸如是否接收新的变更，是否增加人手，是否调整项目周期，是否组织培训，是否缩减范围，是否调整质量要求等等。任何一次决策往往都会对诸多的项目因素和干系人造成影响，各个要素相互之间都可能存在正反两方面的相互作用，因此决策的过程需要考虑整体的最优化，要追求整体的最优化自然就需要平衡好受影响的各个要素。项目的目标往往就是这样，没有最优解，只有满意解，各干系人在项目收尾都满意了项目就是成功的。

在我们日常生活中，工作和生活，事业和家庭，学习和娱乐，知识和金钱等都是我们需要平衡的方方面面。平衡无所谓对错，关键是根据自己的目标和原则进行。世间没有绝对的公平，因此任何平衡都是相对的，是可能存在偏差的，只要在偏差内就应该算做合理的。在这里，狐狸分饼的故事给我们最好的启示，为了追求绝对的公平最好饼被狐狸东一口西一口全吃光了，所以如果我们追求绝对的100%平衡，往往最后造成一种恶性循环，导致最终各方都无法满意。

　　1.为什么要进行平衡

　　对于一个执行中的项目团队，根据系统思维方法来看，是一个动态的平衡系统，而且由于项目各因素的变化平衡有可能被打破，必须向上或向下去找寻新的平衡支撑点。

项目中最重要的是团队，项目成功需要整个团队付出共同的努力。因此平衡的原因很简单，就是要创造一种一致，协调的项目环境，这样整个项目团队才可能形成合力，共同完成项目目标。

平衡的目的仍然是为了项目目标的达成，这是一个最重要的关注点，我们在找寻新的平衡点中的所有决策都是为了这个目标。因此比如项目执行中期有获取到一部分奖金，均分是一种简单无用的平衡行为，这种看似平衡往往却对团队产生了负激励。

当平衡被打破的时候，项目经理必须介入并采取相关的决策，因此根据经验在没有人工干预的情况下混乱会朝下寻求支撑和新的平衡。项目经理要做的就是在出现不稳定后通过科学，合理的行动和决策以维持平衡的层次或朝更高的平衡发展。只有这样项目目标才能够达成。

　　2.平衡的维度

走钢丝的杂技演员，只要关注左右两个维度就能够保持很好的平衡。而在项目中，项目成员，高层领导，赞助人，客户，项目的质量，进度，成本，范围，远期和近期利益都可能成为平衡要素，而且各个要素之间还发生着错综复杂的相互影响，牵一发而动全身。

我们生活在一个二元对立的世界里面，是非，黑白，对错，输赢分的是如此的清楚。但很多地方我们有强烈的二元对立认识正在于我们没有客观的看待事物，无法看到事物的本性，太自我的原因。对于项目管理中的多维平衡更多需要的是客观，需要的是系统思维。

事物的二元分析和平衡由于可变量少，函数关系也可行是简单的线性，很容易找到新的支点寻求平衡。而对于多维情况下,可变量和受影响的因素很多，我们往往也只有凭借我们的经验去找寻平衡点。但是在无法通过科学计算获取最优解的时候，我们应该根据经验假设和组合得到各种场景，通过模拟和试验来寻找一种满意的解。因此诸如iThink系统建模，DOE试验设计仍然是值得关注的辅助分析工具。

　　3.系统的思考和决策

　　在我们进行平衡的过程中，首先要进行系统思考，在进行了系统思考后才能够谈得上科学的决策，自然决策的目的就是动态的建立新的平衡以保证项目目标的达成。

系统思考简单步骤仍然是首先要确定系统的目标，任何平衡和决策的过程都是目标驱动的;然后是确定各个影响要素，确定影响要素中的可变量和不可变量;最后是确定各个要素间的正反相互作用力和大小。有了这些步骤后就是做假设和做尝试，看看各种不同的调整情况下哪种模式可以达到新的平衡，哪种模式可以保证在调整后仍然能够满足项目或系统的目标。

在《卓有成效的管理者》里面讲到的科学决策，首先要进行问题的定义和问题边界的确定，刚好对应了系统思维中目标的确定。确定最优方案的过程就是要不断的假设和尝试，需要为达到目标各相关要素的一个新平衡点。另外决策的过程中要重视反馈和形成闭环，我们在系统思考过程中同样也要关注在我们决策后整个系统是否沿着我们预想的方式去寻求新的平衡，而不是导致了恶性循环。

确定项目的目标，时刻关注项目的风险和危机，系统思考项目中存在的各个要素，为实现项目目标使各要素间平衡而达到最大化利用，在环境和事物变化中通过系统思考果断科学的决策以达到新的平衡。这些不仅仅是在项目中，也是我们在日常生活中可以借鉴的思维模式。

先项目经理，后CIO

　　信息化项目不同于一般的项目，因此信息化项目的负责人也不同于一般项目的负责人。

　　项目是我们耳熟能详的一个词汇，只要有清晰目标和起讫时间，并且不是重复性的工作任务，我们一般都可以称之为项目。事实上，还可以找到很多版本的更经典的定义。

如果从企业的发展历程来看，企业信息化似乎是一个有始无终的项目，它被分解成许多阶段，承载着许多阶段性的目标。但它还不能算真正意义上的项目——因为不管如何预计，事实上我们对目标的认识仍有严重的偏差，这与我们的工业化和信息化都不很成熟有深层的关系。

那么，信息化到底算不算项目呢?笔者认为可以从狭义和广义两个角度来理解：从狭义角度，信息化是单一的有明确目标的阶段性项目，诸如财务软件一期工程就属这类;而广义角度的项目，则指与企业如影相随的信息化事业。也正因为如此，企业CIO作为企业信息化事业的直接使命者，他必须首先是一个合格的项目负责人，甚至是一个优秀的项目负责人。

信息化项目不同于一般的项目，因此信息化项目的负责人也不同于一般项目的负责人。到底有何不同呢?首先要明确信息化项目与其他项目的区别。根据与一些CIO的交流和个人体验，笔者认为信息化项目具有下述几个显著特点。

　　信息化项目的特点

　　■有始无终

企业产品有其寿命周期，基建工程有其明确的起讫时间和验收标准，市场开拓也可以非常清晰地对其阶段目标进行描述，唯有信息化项目是有始无终的。在企业管理中，只要有一项工作通过一套软件系统来运作(事实上从这个系统的立项开始)我们就宣布企业信息化开始了，然后就是永无止境的升级、维护、扩展和渗透等等。有时我们说一期工程、二期工程，实际上除非企业停止运转，否则信息化就要一直进行下去。信息化事业是一个没有终点的高速之旅。你可以从任何一个入口进入，但进入以后的方向就只有一个——向前，向前，再向前。你可以张望，但不可以停顿;你可以适当调整速度，但是绝对不可以掉头，甚至根本没有可以安静地加油和休息的服务区。

这一特性使信息化项目只能分成一个个相对集中的任务段，而不能分为若干泾渭分明的孤立项目。如果哪个企业真的以为信息化项目是一个“交钥匙”工程，那它就“死”定了——因为从本质上看，信息化的过程就是企业经济活动数字化的过程，这一过程应该是连续而有秩序的。在一个较长的时间跨度上，如果我们回溯信息化的历程，将会发现一个个分布得很有节律的里程碑。

　　■高度继承

这一特性是由第一个特性决定的。数据是企业的宝贵财富，信息化工程启动之后，数据将一直累积。这就像人的经验一样，不可否定也不可割裂，信息化的不可逆转也体现在这里。当然这种继承不仅仅体现在数据上，还体现在系统的应用将越来越简单和高效。在持续继承的基础上，系统将引进、复制新的更贴近并且能更便利地满足需求的方式，让我们能更清晰地做好规划，以便于后续系统更好地与之前的系统进行继承与集成。

　　■目标迁移

企业的产品虽然是相对范式的一个结构，但是与之相关的运营(表现为内部交易和外部交易的各种经济活动)却在不断变化。经济规律作用于日常经济活动是通过多种“变形”方式来体现的。许多时候，由商业智慧赋予其实际的融合与运作的规则。同时，信息化系统必须实时反映现实运行的活动。不管你进行了怎样的规划与设计，如果不支持这种适应，系统就肯定是不成功的。

在这种情况下，不管是狭义的还是广义的信息化项目，必然会遇到不可回避的目标迁移现象，而这种迁移大部分是由业务流程的变化引起的，当然也有一部分源于人事变动、机构变化。需求的变化便引起了信息化阶段目标的变化。目标受制于现实还是超越现实，是很多项目经理深感困扰的原因所在。同时，目标不清晰的工作不算项目，只能算试验活动，而这恰恰也是与企业价值观相背离的。

　　■多线程并行

企业管理是复式的经济活动，不可能简单到只要按部就班就能进行。企业是有机体，依靠的是多部门、多岗位的细致协同，信息化需要将这些协同用一种相对固化的方式表现出来。在具体的项目运行过程中，管理人员、业务人员在过渡期往往要在两个系统中行进，这通常是项目的危险期。如果企业组织处于复杂的多线程并行状态，如果控制点不便掌握，项目的进展将会异常缓慢或者失控，甚至危及企业组织。

此外，信息化项目还包括以下特性：蜕变特性，对原有的数据式系统进行改进和否定，同时也伴随着鲜明的权力结构调整;自成长特性，信息化有一套自主的规律，当然有许多并不为我们所认知;信息化项目许多时候还有一种“革命运动式”的特性，这种特性往往使其具有不可抑制的破坏性。

　　获取项目的主动权

　　如何取得项目的真正主动权?笔者认为CIO应该在以下几个方面有所作为：

首先是信息资源的规划。信息资源拥有特殊的虚拟特性、流转特性、经济特性，使其具备了自然资源与社会资源融合的一种新特性，构成了在企业经济工作中的实际应用基础，成为企业一切资源中最具有支配地位、最“廉价”的创新资源。按照国内资深IRP(信息资源规划)专家高复先教授的观点，“IRP是在管理咨询之后，软件开发之前的一项工作”。

信息资源如果没有岗位串联和流程支持，是难以独立存在的，因此有必要仔细分析其中的依存关系，以及互动的甚至是网状的影响。实际上在复杂的业务流中，一个典型的数据流应该具备输入、处理、输出和贮存的过程。许多表面上并无二致的数据流事实上是为不同的业务流服务的，提取了其真正差别，也就基本上掌握了其运行规律，也必定为今后的维护、升级等工作提供有效的支持。

　　第二，业务流程的规划。关于业务流程规划的讨论比较多，并一度成为企业信息化工作的主体，这里不再赘述。

第三，权力系统的规划。信息化的主体是企业的权力系统，如何按照企业的意志协同业务流与权力部署的情况，是信息化项目实施之前必须切实考虑的问题，这与IRP同等重要。当然并不需要完全“屈从”于当前的权力系统，事实上，新流程将逐步产生对权力系统的深刻变革。由于领导者的权力意志与业务流程的科学性，我们可以很轻松地通过“边缘权力”实现业务流的畅通，然后再逐步向当前的“核心权力”逼近，使它们“就范”于统一的、科学的、以企业意志为主导的流程系统，从而建立一个新的权力体系。这是一个扁平、透明、自然生长的体系，当然也应该是自律、健康的体系。

如果对自己的企业没有充分的认识，肯定做不好这三个方面的规划，从而运筹的项目也将非常危险。

　　工夫在诗外

一在IT之外。对于信息化项目，我们经常会陷入“偏技术还是偏管理”的争论中，现实中显然是“依靠技术加强管理”的局面，二者并不是并列的。

二在管理之外。是不是重视管理，为管理服务就足够了呢?答案是否定的!对于管理系统，老板们怀念创业期的简单管理与极至效率，但管理的麻烦并不仅仅在于幅度，更在于深度。因此，对于这种灵动的东西，进行多层面的沟通是必不可少的，这不是一般的培训所能全部替代的。我们需要很好的沟通，追求高层、中层、基层的上下同欲。事实上，这是中国企业信息化的重大特色之一。笔者曾在一个杂志上就此专门写过一篇文章，认为应该同时做好做事、做人与做秀这三件事——在你准备充分的时候，做秀可能是最迫切的，甚至是最重要的。

另外，要建立一个科学的控制系统，即必须尊重狭义项目的基本规律。项目管理的终极就是时间管理——实际上并不存在任何可以一蹴而就的事情，何况信息化项目?如果能规避或者客观认识下述这些问题，一个科学的控制系统是容易建立的：

　　第一，项目开始时没有明确的目标，清晰的资源以及配置方式。

第二，选择了错误的人员。适合项目的不是那些时间最宽裕的人，而应该是最擅长完成这类任务的人。许多时候，我们在选择的时候，经常从计算机技术方面的能力和表现来取舍人力资源，并单纯地以为这样会更有效率。

　　第三，赋予项目参与成员的自由和时间过少。

　　第四，向来自其它领域的关键人物或决策者提供的信息不足。这些角色经常是企业里有实际支配能力的财务部门、销售部门的负责人。我们在工作中需要一个合适的沟通机制。

第五，对来自企业的阻力估计过低。想一想，哪些人可能反对你的项目?制定一个让这些人站到你这边来的策略，是CIO首先要考虑的问题，而那些专业的技术问题可以让其他人去认真考虑。

　　第六，由于太过注重细节，而失去对时间的总体把握。有些过分追求完美的人永远也无法实现他们的目标，因为在他们眼中总有一些地方还需要改进。你应该制定一个能够达到的质量标准，并确定好评判的标准。完成这些工作都必须严格遵照计划的时间，以保证你能够最终实现目标。很多CIO都非常渴望完美，很多时候技术人员会“创造性地、自作主张修改计划”，增加那些自己认为用户需要的功能，来获取狭隘的成就感，结果导致项目一拖再拖——许多时候，我们对项目的信心，就是因此而渐渐消失的。

编写高效率的HTML网页代码

　　提高HTML代码的效率

许多网站设计者最常犯的错误便是当其网页能够在IE下正常显示便认为其代码正确无误，甚至常看到有人在抱怨其网站排名不理想，到其网站简单看一下便可发现 HTML代码中充斥各种各样的错误，在那样的代码基础上无论付出多少努力去优化网站结果都可能是付诸流水的啊!事实上，IE是一款对HTML代码容错能力甚高的的浏览器，——说句题外话，尽管我们可以有各式各样的理由可以攻击微软，但微软对其产品操作的易手性及可用性方面所做的努力是不容抹杀的。—— Web页面能够在IE下正常显示绝不意味着页面的HTML代码没有问题，甚至可以推而广之，Web页面在多种浏览器下均可正常显示也不意味着HTML代码完全合法有效，毕竟哪个浏览器都要保证基本的容错的功能，不然，就会发生即使仅仅因为网络传输中的一点导致导致 HTML页面显示不正常了，而这在网络带宽仍然紧张的今天仍是频繁发生的。

　　什么是合法有效的HTML代码

简单说来，我们的Web页面是由HTML(Hypertext Markup Language :超文本链接标示语言)元素构成的，即使对于ASP、PHP之类的动态页面，其也是由SERVER将ASP或PHP语句渲染成相应的HTML元素并下传到客户机上;对于JavaScript之类则由客户端将其转换为HTML。

同其他语言一样，HTML也有自己的语法规则，无论是浏览器还是搜索引擎的Spider都在根据这些规则来分析网页代码中的内容。但很多时候，即使对熟练人员来说，在HTML页面构建时仍然难免出些HTML代码上的错误，更别提大部分所见即所得编辑器造成的HTML冗余臃肿问题了。

如果页面中不存在违背HTML标准语法规范的成分，即可被称为合法有效的HTML代码

　　合法有效的HTML代码对SEO的重要性

要使搜索引擎收录我们的网页，——在此基础上才能谈网站优化网站推广——其前提是要让搜索引擎的Spider能读懂我们的Web文件。搜索引擎 Spider阅读网页的根据便是HTML规范，通过对HTML代码的分析，Spider才能判断网页内容，在此基础上才能判断针对相应关键词的相关性。

需要明确的是，搜索引擎Spider不同于浏览器的一点便是其容错能力相对于浏览器要差不少，如果页面代码中存在其无法解释的HTML代码时，其便可能停止阅读该页面甚至可能停止在我们的网站内爬行，更严重的错误甚至会导致其同时也丢弃已经收集到的网站内其他页面的内容信息。

尽管如今如大主要搜索引擎也都在尽力提高Spider的容错能力，让其可以在HTML代码出现一般性错误时不至影响对内容的收集。但很多时候，仍然会发生如漏了一个关闭标签导致整个页面的内容被忽略的情况。

另一方面，合法有效的HTML也可以保证Web页面可以在多种浏览器下被正确解释，避免同一个页面在IE下显示正常在Mozilla下却严重变形的情况(当然，不能完全避免)，这对于提高网站的可用性方面也是有着极大好处的。

　　如何验证HTML代码的合法有效？

Internet有很多类似的免费服务可以帮我们验证网页代码是否合法有效，其中最著名的即是 W3C HTMLValidator，这是由W3C( World Wide WebConsortium：万维网联盟)官方推出的免费服务项目，在其页面上只需输入待验证的HTML地址或者上传一个在本地机上的HTML文件即可，其会很快返回校验结果，是否无误，如有错误分别为哪些及如何改进等。

同时，W3C HTML Validator也提供对CSS文件的验证服务。

　　一定要通过W3C的验证么？

对这个问题的答案则不那么绝对。

理论上说，合法的HTML代码能够使搜索引擎的Spider在更容易地收集网站页面的内容信息。但另一方面，并不是所有的HTML代码错误都会影响到 Spider的爬行，也即是说，HTML存在少量的错误对Spider来说也是可接受的，那么，一定要通过W3C认证么?

另一方面，如在Mark Daoust的测试中，甚至暗喻(未肯定地下结论)存在少量HTML代码错误在页面在Google排名中能更占优势，当然这存在很大争议，但至少证明了存在少量HTML代码错误并不影响网页在SERP中的排名。

个人观点，如果您对HTML相对不那么熟悉的话，倒也不必强求非得100%通过W3C的验证，毕竟把更多的时间与精力放到真正应该努力的方向如创建内容与链接才是根本，但要保证HTML代码中不存在大的严重性错误。当然，如果您对HTML语言较为精通，那么，何妨稍花点功夫以确保其完全无误呢?

因此，我们要做的倒不一定非得通过W3C认证，但至少要保证其在各种浏览器下显示正常，保证搜索引擎的Spider能够正常分析。

　　提高HTML代码的效率

前文我们提说过很多所见即所得编辑器造成的HTML冗余臃肿问题，这种情况在很多中文网站相当普遍。所见即所得编辑器如FrontPage、 Dreamweaver，尤其在其对一个网页进行修改的时候，往往会产生很多不必要的冗余代码。当页面的HTML文件在存在大量的冗余代码时，文件便会变得臃肿，这不但会降低网页的打开速度，损害到网页的效率，同时也会严重影响到相当网页的搜索引擎排名。

　　与其把精力投入到一定通过W3C认证上，个人认为，倒不如把更多的精力放到精减代码上，如引入CSS等，以实现代码的干净简洁。这样的优化效果会更明显。

案例：Ipedo企业项目管理解决方案

经历了轰轰烈烈信息化基础建设后，我们看到目前很多电力企业虽然已实施了各种信息管理系统，但这些系统通常构筑在不同的平台之上，系统间缺乏良好的信息沟通。导致虽然有许多系统和数据，但这些系统中的数据不能共享，无法达到IT技术真正有效地支持业务的发展，和领导层全局把握企业的运做。如何提高自身的竞争优势，使业务规范、持续运转?对市场变化做出敏捷的反应?人员变动知识流失，如何确保企业的可持续发展?这些问题日已成为电力企业关注的焦点，而信息技术的应用成为解决问题的关键所在。

　　面临问题

企业按照业务职能划分的制度将各个部门划分成独立的业务模块，各部门之间协调困难，电力企业同样如此。身处专业和职能分割中的中层管理者无法获取整体信息;部门间、分公司间以自身利益为中心影响到了电力集团整体战略的执行。最终出现“任务多人负责、最终无人负责、计划被拖延、执行成本增加”等现象。

　　归纳电力企业主要面临的问题：

　　1)缺乏以项目执行过程贯穿组织业务的项目管理，跟踪，报告，跨部门工作的系统;

　　2)项目多，无法有效的管理和监控;

　　3)企业和员工间知识经验无法共享、积累，项目经验的重用性不高;

　　4)业务和流程管理脱节，跨部门协调困难;

5)领导无法实时了解企业状况，决策缺乏基础支持;

　　需求特点

首先，企业项目管理已成为整个组织的管理理念。电力企业通过一系列同时进行的项目来实现，如企业战略项目、业务项目、组织改革项目、以及传统的开发项目，对项目采取系统的方法达到管理高度。企业可将营销计划、广告活动、大型宣传活动、新产品投放、产品开发、行政管理都看作是项目，并利用项目管理方法高效完成。通过项目化的理念和方法将运作转化为有具体目标、预算、进度和控制的项目，确保时间、技术、经费和性能指标的条件下，以尽可能高的效率完成预定目标。对快速发展和业务日益多元化的电力企业实施项目管理无疑是最佳的解决方案。

其次，针对每个电力项目中涉及产品技术、解决方案、情报、工程成败经验，项目组成员的技能、经验、智慧等知识应该是企业的核心，对这些知识进行开发利用，有效的积累、管理和共享是电力企业又一重要的需求。

电力企业往往是同时开展多个项目，各个项目经理关注单个项目目标的完成，而整个组织没有一个整体项目运作平台，实时监控项目群的情况，这样就不可避免发生各种冲突，结果可能是部分“单个项目”的目标虽然实现了，而整个组织的目标却未能实现。缺乏对整体项目的知识管理运作平台，结果无法有效实施项目管理。项目型企业需要在企业范围内提供项目知识管理的有效实施平台，建立一套与项目管理相适应的知识管理体系，使长期性组织能够提供项目管理所要求的“临时性”和“柔性”

　　解决之道

　　Ipedo 提出：在多项目环境下，基于项目管理的解决方案的运行机制。

以项目管理为主线，全面组织、全程贯穿地集成各个业务环节，协同各个部门的工作，以知识管理、实时监控为最终目标的系统平台解决项目型企业出现的上述问题。

　　项目管理、知识管理和实时监控是本系统平台的三个方面，以项目执行过程协调各个职能部门完成项目的跟踪，报告，管理，监控，着眼于管理整个企业范围内项目知识集中管理和分享，实现三类目标：

　　1)内部标准化的项目与资源知识集中储存，以实现高效的项目知识分享、分析与管理;

　　2)决策层可利用它获得关于全企业的活动及相应状态的宽广视图，从而进行项目组合的知识分析并做出合理的运营决策;

3)项目经理、成员以及合作伙伴可以通过基于Web的协作界面创建项目计划并对项目进行跟踪、报告、分析和控制。

　　业务架构

　　该平台是流程化管理平台，实现了领导的实时了解、知识的不断积累、项目的有效管理。

以项目管理过程将企业中的各种跨部门的管理活动转化为有具体目标，管理项目过程，集成人，财，物各方面的信息。这些信息来源于原有的各业务系统，如RDBMS的MIS系统，财务系统以及OA办公系统等，通过XML的专业集成技术实现对这些分散信息的集成。同时对单一项目和多个项目的执行跟踪，从而把握业务运作的状况，进行全面监控，提供与项目管理相适应的涉及企业范围内的知识管理体系的平台。

　　功能介绍

平台全程体现了协同的理念，当进行一个计划的审批时，相关人员的参考意见、领导的审批意见都将积累在其中，最后形成更好层次的知识积累，将协同办公和知识积累形成了完美的结合。

平台从功能上分为三大模块，分别是项目管理(PM)、知识管理(KM)和实时监控(RM)，实现对项目、知识等方面的完整管理。

　　1)项目管理(PM)

项目，是本系统的基本的且重要的主线，实现对各类项目的有效管理，包括项目前期管理、项目实施管理、项目结项管理和客户服务管理等，涉及项目有指令性项目、科技项目、外包项目等等。涉及内容有任务管理、物资管理、人力管理、资金的管理、风险管理等等。包括：

　　1、任务管理：进行任务进度的安排，工作的分配，资源的调配等等。并且 可以反映到项目的总体进度，人员成本等等管理。

2、人财物管理：系统将能够集成企业各类管理系统，实现资源的共享，例如可以和HR集成后，使HR信息直接在企业项目管理平台中使用，而无须再输入同样的信息。减少信息输入，充分利用各类信息。

　　3、风险管理：及时了解项目中面临的风险、难点，或项目的资金使用情况、进度状况，将可能影响到项目的各种风险及时进行处理，避免对项目的正常执行造成影响。

4、知识使用：平台的知识库将集中企业的经验、体系化标准、文档以及历史项目的知识。无疑这些知识将对当前的项目有很好的借鉴作用，因此在项目管理过程中将处处体现这一点，使知识管理将能够很好的为当前的项目提供帮助。

5、协同管理：项目管理是一个团队合作，该平台能够为团队的项目沟通提供很好的通道，无论即时通讯，在线交流等方面都能够很好的为团队方便快捷的交流提供帮助，甚至在项目过程中协同也在其中体现出来，如协同和任务的分发的结合就使协同得到了很好的应用。

　　2)知识管理(KM)

　　构建企业知识库，为知识的积累、共享和创新提供一个平台，实现企业内部各类型的知识整理、存储、发布、使用。包括：

　　1、分类管理：知识管理的分类无疑是最重要的，它将帮助用户快速的定位到所需知识的位置，平台提供了系统半自动化和手工结合的方式为用户的智能化分类提供帮助。

　　2、企业体系化管理：体系化管理贯穿于项目工作的全过程。内容共分为管理、上传、修改、维护、流程和评审等等。这一些都为项目管理的专业性提供知识的帮助。

3、快速定位：平台提供了各种角度的知识分类和各种排名(按点击、按重要程度、按时间等等)，为用户的快速获取和定位提供了帮助，并且用户可以按照自己的角度进行设计分类，这样获得知识点的效率将更高。

4、项目体系管理：项目结束后，相关的经验、文档、交流等等都将收入知识管理中，并且按照一定的类别进行分组分类，这样不同的项目人员可以根据自己项目特点找到类似的项目进行了解借鉴。

5、经典案例：在历史很多项目中，有些项目具有非常好的参考价值，因此企业将这类项目评为经典案例，而经典案例管理将从这些角度进行分类管理这些案例。项目人员将能够从这些经典案例中获得直接的帮助。

6、专家文献：企业专家的经验非常宝贵，能够为项目人员提供很好的支持。平台的知识管理对这些专家的宝贵经验和文献进行分类统一管理，并且可以从网站等多个渠道获取同行业专家的宝贵资料。这样完整的文献管理将能够为项目人员的专业性提供帮助。

　　3)实时监控(RM)

　　提供了对企业各类信息的实时监控，多角度观察以及分析等功能，信息的来源可以分散在不同系统的信息(异构信息)。包括：

　　1、横向监控：可以实现对项目群的监控。及时发现项目的问题，并且可以将一些隐蔽在下面的问题通过类似项目之间对比等方式发现，而无需等到问题暴露出来才进行处理。

2、纵向监控：通过对项目深度的监控，掌握项目各个可能发生问题的环节，将问题挖掘出来，而不是停留在事务的表面，简单的进行了解，这样从横向的对比分析监控到纵向的项目深度挖掘分析监控，实现了对项目的全面监控，从而确保了项目的有效执行。

3、实时预警：用户可以根据需要设置需要关注的角度，如从资金角度关注成本使用情况，如果用户设置使用成本达到设定值就需要通知，那么当该项目的成本达到预警的设置时，该用户将在第一时间收到“该项目成本使用已经达到预警阀”的消息通知，他就可以到项目管理中了解成本的详细使用情况或和财务、项目组成员进行沟通，确认资金的正常使用。通过平台用户就可以主动的获取到关注的信息，从而提高了信息的价值和效率。

　　4、智能化分析：能够按照一定的商业智能化模型进行分析，提供给用户更有价值的分析资料，为用户的决策提供帮助。

5、流程优化：当企业根据业务设计流程时，由于受条件的限制，不可能把流程中各个环节的效率考虑的很充分。如主任是否经常出差，审批的流程是否经常停留在主任这个环节?这些在流程设计的时候不可能考虑的非常清楚，但流程优化将能够很好的监控这一切，它反映出来的是主任这里的各个流程效率都非常低，这样可以及时的将流程进行调整，采用主任替代或延时转发到其它人员那里审批，从而提高了流程的效率。

　技术架构

基于以上的业务要求和需要集成异构系统的特点，Ipedo EPM采用目前先进成熟的三层体系(Browse/Application Server/Database Server)架构，遵循J2EE企业平台规范，采用国际标准集成技术XML和Web Service，借助Ipedo的产品、技术和人员优势，实现这个平台。

　　1、Ipedo的XML Intelligence Platform(简称 XIP)可以集成各类业务系统(包括现存的系统和将来新加入的)，屏蔽各种数据源的纷繁芜杂。通过XML和WebService技术，统一将他们管理起来，为上层应用逻辑提供了单一开发界面。

　　2、Ipedo Project Base包含了大量成熟的应用组件，使得业务建模人员和开发人员非常方便的在其之上进行应用业务逻辑开发，为整个平台应用层的开发提供了强大支持。

3、企业的实际业务流程随着市场变化而变化，Ipedo Workflow将确保流程的信息化和实际的业务流程一致。自定义的工作方式将使流程时刻和业务结合在一起，随时可以调整流程的管理，而不会发生实际操作的业务规范和信息化的流程管理不一致。

　　4、企业对业务的分析角度经常在发生变化，如何方便的提供不同角度的报表非常重要，而Ipedo Dynamic Report能够让用户很方便的自定义需要的报表，这样结合Ipedo Integration Manager可以实现跨部门的综合性报表。

5、大量的信息汇总在一起，如何快速浏览自己关心的信息非常重要，Ipedo提供的Personal Portal能够提供个性化的服务，使其适应不同层次、不同人员的不同应用。

这些关键技术，提供给了电力企业项目管理平台有力的保障，统一为平台服务。保障了平台高效、稳定、开放和可扩展，并实现了重要的技术：异构系统集成、流程管理、动态报表、知识管理、单点登陆、个性化展现等。在Ipedo相关产品技术的支持下，企业项目管理平台实现稳定的性能，良好的扩展性，贴近客户的需求，成为符合企业需要的应用平台。

　　投资回报

市场千变万化，客户需求日益增长，要求企业各部门通力合作完成项目是企业获得长期发展的基础。在现实的企业信息化过程中，企业项目管理平台切合当前电力企业信息化建设的真正需求，通过完善项目计划和在项目中合理的分配资源、资产和知识，使电力企业获得更大的运作效率，在日益激烈市场竞争中立于不败之地!

　　通过Ipedo EPM为企业带来可视的益处：

　　异构信息的共享，集成和分析;

　　项目的有效管理和监控;

知识的共享、利用和创新;

　　业务流程实现自定义;

　　对企业信息的全面掌控。

安全、管理和监视成功实现SOA三大步骤

设想一下，如果你询问一位首席执行官是否知道他的全部企业应用程序在什么地方，安全状况如何以及是否正确地进行管理，结果会怎么样呢?他可能以为你是疯子。他很可能这样做。然而，令人惊奇的是许多不能准确回答这三个问题的销售人员却正在设法销售SOA服务。 

　　事实是，由于其承诺的全部好处，SOA作为一种环境很自然地比它的前身更难控制：
　　·通过把所有的逻辑和数据集中在一起，基于托管的计算很容易管理、保证安全和监视。
　　·通过把逻辑、数据和用户接口分开，客户机-服务器计算会产生一定水平的混乱和永远无法真正控制的失控成本。这里关键的因素是失去中心的控制。在过去的15年里，这个因素决定了计算。

　　·现在我们拥有了SOA。SOA为我们提供了敏捷性、灵活性、传统的延伸、投资回报和更多的东西。SOA的不利方面是SOA能够不确定地分布，从而使其成为最困难的东西，除非有现成的合适的基础设施。

　　随着企业日益增多地利用广泛分布的架构，并且一方面访问第三方的服务，另一方面把自己的应用程序作为Web服务提供，他们需要能够明确地回答这些问题：我知道我拥有什么吗?它安全吗?严酷的现实是许多企业在不能回答这些问题的时候就走上了SOA的道路。因此，他们使用老式的计算范例永远也不会实现SOA的目标。

　　没有保证安全、管理和监视服务的能力，企业就不应该考虑解决SOA的问题：
　　·安全：IT部门需要解决“中间人攻击”和“最后一英里”安全漏洞。除非恰当地治理，SOA才能允许让任何人在任何地方和任何时间启动、部署和编排一项Web服务。这项服务可能同数千个其它的服务在一起，显著增加安全风险。此外，这种情况也能够让虚假的服务伪装成合法的节点冒充真正的服务，破坏保证实现SOA功能的信任等式。通过采用运行时治理，IT能够通过服务发现和自动强制执行政策等方式减少风险。

　　·监视：除非你能够实时地看到你的服务和服务周围正在发生的事情，否则，你就不能放弃SOA治理的责任。理想的方法是商务流程的可见性，让你从商务流程的角度管理你的SOA。

　　·企业级管理：同所有其它形式的系统管理一样，在一个不同种类的SOA环境中实时地从一个控制台查看、管理和控制所有服务的能力是最基本的要求。SOA治理需要从规划到设计、从开发到应用、从运行到优化等全部过程的管理和工具能力。最后，这种能力允许用户根据业务或者IT标准定义、排列和优先安排事情以便管理服务级协议。

　　SOA承诺给企业带来巨大的好处。同以前的大多数IT范例一样，它一直被过分地宣传，甚至吹嘘到了预期超过现实的程度。
　　为了让事实纠正过分的宣传并且防止人们失望，早期的SOA应用者需要保证建立一个牢固的基础。这个基础能够让人们像10年前一样进行控制。其它任何表示能够实现SOA的东西都可以看作是又一个一时流行的IT狂热。

IT项目经理必备的三种能力

信息化项目对企业而言，无疑是一项系统工程，既要符合企业发展战略，又要各部门协同配合，还要把握技术方向，因此作为企业信息化项目负责人的项目经理(往往由CIO担当)，在项目实施过程中起着关键作用，正所谓“成也萧何、败也萧何”，项目经理的能力是项目成功实施的基础。

　　一、项目经理应具备组织能力。

项目经理的组织能力具体表现在组建高效的项目小组、规范组织的工作范畴、明确项目成员的分工、协调各项工作的进度。拥有较高组织能力的项目经理，能够建立科学规范、分工合理、协调一致、高效精干的项目组织机构，作为项目成功的组织保障。

　　① 组建高效的项目小组。组建项目小组是项目开始的第一步，由于信息化项目往往牵扯的部门较多，因此项目小组的组建应考虑多个部门的共同参与，同时将各参与部门的人员分为实施人员和决策人员，并分别组成项目“领导小组”和“实施小组”的两层管理结构。这样，一方面能够让参与部门的各个层面充分了解项目的情况，另一方面可分别让项目的“决策”与“执行”寻找到合适的落脚点。

② 规范组织的工作范围。规范项目小组的工作范围，同时确定项目的实施内容，不仅可以有效保证项目组的工作目标明确，而且也是有效控制项目在实施过程中不断被扩展的有效途径。一般来说，项目范围的定义是项目组根据内部需求提出来的框架，这个框架一般会涉及到企业的具体业务，是项目实施过程的指导，并需要在项目执行过程中不断细化，因此要求项目经理具备把控工作范围的能力，否则项目会像滚雪球一样，越滚越大，远远超出项目的时间、成本预算。

③ 明确项目成员的分工。责任清楚、分工明确是任何一项工作的基础，尤其是像信息化项目这种涉及部门多、业务流程复杂的项目，更需要项目经理对项目组的每一位成员进行明确分工。

④ 协调各项工作的进度信息化项目强调各部门之间的协调配合，每一个部门的项目进度出现问题，都会影响到项目的总体进度，因此项目经理除关注项目的总体进度外，仍需协调各部门的项目进度，这样才能使各部门工作衔接流畅，从而步调一致，协同发展。

　　其次，项目经理应具备决策能力。

项目经理不仅仅是IT部门的管理者，更是项目组的决策者，在错综复杂的信息化项目中，项目经理应探查项目相关的各种信息，对其进行筛选，并对各种解决方案进行优势分析，从相关技术、设备、服务、行情等信息出发，进行分析预测，优中选优，做出符合项目战略的项目决策。

　　第三，项目经理应具备沟通能力。

　　项目经理在信息化项目中承担了企业(甲方)、实施方(乙方)、第三方咨询机构之间联系和协调的任务：企业通过项目经理将项目需求传递给实施方;实施方通过项目经理将项目方案提供给企业;第三方咨询机构对项目的诊断和建议也往往通过项目经理来传达。因此项目经理实际上在信息化项目管理中扮演了“三方”之间桥梁的角色，其与任何一方的沟通出现问题都会影响到项目的进展。因此一个好的项目经理，一定是一个好的沟通者，通过与项目任何一方以及项目组成员的沟通，才能全面了解用户、决策者、实施方，乃至咨询机构对项目的真实评价，及时发现潜在问题，并通过征求各方意见，协调各方关系，找到能够保障项目顺利进行的办法。沟通可以是多方面的，口头的、书面的、甚至定期不定期的项目通风会、讨论会都会成为项目经理沟通的手段。

IT项目管理工具探讨之一------项目群管理

目前专门针对IT行业、软件行业的项目管理工具越来越多，但大多数产品目前还只是具有较通用功能，一些管理精细的要求难以在工具中得到支持。笔者根据实际应用，探讨一下项目管理中的工具支持功能，此为系列之一，欢迎从事项目管理工具研究或者感兴趣的人员 ，探讨研究。

一般有一定规模的软件开发组织，项目基本上都是项目群。一般规模的项目群可能分为两级，一个项目群下面包括若干项目组，大的项目，项目分级可能有3到4级。目前的管理工具对于项目群的支持都不够好，项目管理中对于项目群的描述，也是篇幅有限，认为管理好所有子项目，即可。对于项目群中各个项目之间关系一般很少阐述。一般的项目管理工具即使支持项目群的管理，也就是可以象树形展开那样，对项目群信息进行汇总查看，对于项目群的各个项目之间的关系、管理模模式等都不涉及，项目群就是若干项目的简单组合而已。

　　实际中，我以一个ERP软件公司为例，简单阐述下两种典型的组织架构下的两种项目管理模式，。

　　1、项目单独型：此种情况下，项目群中每个项目组是较为独立的，彼此间的任务基本没有太多联系。

　　这种模式下，每个项目组的项目经理，负责从需求、开发、测试整个的管理与跟踪，整个项目的项目计划跟踪由项目经理负责，这种管理模式下，项目群可以简单的看作是一系统子项目的集合，大部份能够支持项目群的项目管理工具都可以支持。

　　2、混合模式：

　　上述管理模式中，因为不利于资源的整合和利用，目前很多公司进行了改进，所以一般会将需求、测试从单个项目组中抽出来，组成需求组和测试组。

　　这样情况下，严格意义上讲，高级项目经理才是真正的项目经理，但在实际中，如果让高级项目经理(一般我们称为部门经理)负责项目任务的建立、跟踪，是完全不可能的。一般的部门，估计项目任务有好几百条任务，部门成员有20-30人，没有哪个部门经理能承担得了这个工作量。而且，在这种模式下，工作量估算也是分开的。

　　一般工具的解决方案就是，与上一种模式中的一样，将需求组、开发组、测试组也视为一个项目组，单独建任务。这样又产生两个问题：

　　1、 同一个功能点，被重复建了三个任务，并且之间没有任何关联，部门经理要跟踪功能点的完成情况，很麻烦;

2、 需求、开发、测试之间协作会较累，比如，我们在项目中，都要实时标记，是否提交开发、提交测试、测试完成，结果不知道要针对哪个任务进行标记。

　　所以我认为，现有的项目管理工具，即使是专门针对软件开发的项目管理工具，都没有考虑到这么细，这样的需求有一定个性化，但我认为在很多大型研发组织，还是有一定的代表性。说明管理工具的需求做得得还不够精细和深入，或者缺少。

我建议的解决方案是：对于项目群的管理，支持项目组的任务建立关联和继承关系，比如

　　上述混合模式中，开发组任务可以由需求组任务继承，测试组由开发组继承，需求组、开发组、测试组关注自己组的任务，对于部门经理，因为这些任务这间有继承关系，所以可以展现从需求、开发、测试的一体化跟踪表。

IT项目管理工具探讨之二_需求管理、项目管理

目前大部分的针对软件开发的项目管理工具，除了提供项目任务管理，有些已提供需求管理、变更管理等功能，但往往三者是独立功能，之间没有集成，造成在实际使用中的不便。

　　一、需求管理与项目管理的集成

　　对于做管理类软件的软件公司，一般都是业务驱动，由需求人员决定每版本的需求点，以此形成开发任务，至于非功能需求(如性能改进)，一般由开发组决定，一般占的比例较少。

需求管理功能，包括原始需求的收集，整理成业务需求，然后再细化为概要需求。往往是需求人员使用的，侧重于对需求的记录，不需要任务管理功能。

　　项目管理，主要侧重于任务的跟踪管理。

　　实际中大部分的任务都来源于需求管理的输出—概要需求点，概要需求点就是需求人员的需求任务，需求人员对每个需求点进行详细需求分析，再生成开发任务进行开发、测试。

从上述看，需求管理与项目任务管理，虽然侧重点不一样，但它们是密切相关，在软件开发中，需求点是任务的主要来源。

　　实际应用上，因为管理工具不支持两者集成，结果造成两方面使用不便：

　　1、项目任务往往来源于概要需求点，需要重复建立项目任务;

　　这点不是很关键，因为一般工具都提供导入功能;

2、最重要的是，需求人员，可以从需求库中，看出有哪些需求在哪个版本实现，哪些没有实现。每次项目结束，都需要需求人员逐个标记，非常麻烦。如果集成起来，则无此问题。

　　二、变更管理与项目管理的集成

　　如果说需求管理与项目任务管理不集成，还能勉强适应，但变更管理没有与项目任务管理结合，

我就觉得太不可思议了。目前大部分项目管理工具的变更管理，基本只是变更记录器，做得好的，可以支持变更流程审批。没有与项目任务管理集成起来，实际上，变更往往会取消任务，或者影响任务工作量，如果不与项目任务管理关联，则在变更生效后，要手工在项目任务管理中更改，一来麻烦，二来没有日志记录，既繁琐，而且不便于跟踪记录。

　　当然，完整的变更管理不止这些功能，还有文档变更、资源变更等，但是项目任务变更是最重要和关键的变更。对于较大规模的开发来说，变更管理是很重要的一部分。目前大部分管理工具对于变更管理的功能我认为需要加强。

Dreamweaver定义模板批量制作网页

做网站，麻烦在更新和改版，特别是大规模更新，如果不是用cms系统，手工工作量非常大。告诉你个秘密吧，其实只要用好模板工具，就能很好地“批发”网页。常见的网页制作工具如DreamWeaver中都有这项功能，使用模板就能减少大量的重复劳动。

　　一、建立模板

　　1、创建模板页面

最简单的办法是将一个网页另存为模板文件，通过执行命令：File→Save as Template，DreamWeaver会在网站根目录中建立一个模板文件夹——Templates来保存该模板。当然，也可以新建一个模板： Window→Templates，会出现的Templates面板，单击右下角的New Template按钮，输入文件名，就建立了一个空模板;再单击Open Template按钮打开该模板，保存后自动存放于网站模板文件夹Templates中。新建、打开的模板页面和普通的网页没什么两样，同样可以加入表格、层、图片、动画、脚本，设置页面属性等。

举例：这里以制作一个模板为例来说明。在该页面中，我们希望左侧的网站标识图和底部的导航图出现在每个页面中。其中标识图由两幅图片叠加而成，导航图上的文字“最近更新”、“在线阅读”、“打包下载”等划分成几个热区分别链接到不同的文件，它们在每个页面中都不变。右上部的主页面区和左下角弹出式选单按钮下面的页面说明则各不相同。为了保持页面整洁，我们用表格来布置这些元素。

准确地说它只是一个没有可编辑区域的“准模板”，下面再设定可编辑区域。

　　2、设定可编辑区域

　　设定模板可编辑区域，一般来说有两种方法。

新建可编辑区域：选择命令：Modify→Template→New Editable Region。在某一空白区域中单击后执行该命令即可将该区域变为可编辑区域。

　　标记某一区域为可编辑区域：选择命令：Modify→Template→Mark Selectin as Editable Region。如果某区域已经有一些文字，并且希望在以后新建的超文本文件中部分保留其内容，先选中该区域再执行标记命令即可。

取消可编辑状态：选择命令：Modify→Template→Unmark Editable Region。执行该命令后会弹出一个对话框，其中有当前已有的可编辑区域列表，选中要取消的区域名称，确认即可。

举例：在大片空白区中随便单击一下，执行Modify→Template→New Editable Region命令，在弹出对话框中输入名称：Main;选中左下角本页说明下面的文字，执行Modify→Template→Mark Selectin as Editable Region命令，输入名称：exp。可以看到可编辑区显示为浅蓝色，保存即完成模板制作。

　　二、使用模板批量制作网页

　　1、根据模板新建页面

命令： File→New From Template。弹出对话框，从模板列表中选取模板，出现的新页面中除可编辑区外均有淡黄色背景，是不能进行修改的部分。空白的Main编辑区可直接进行插入表格、文字、图片等操作，Exp编辑区保留有原来的文字，修改或重新编辑均可。

　　2、对一个已经有内容的页面应用模板

命令：Modify→Template→Apply Template to Page。选择模板后还会弹出一个对话框，让您选择现有的孤立内容保存到哪个可编辑区域(Choose Editable Region for Orphaned Content)。要是不想保留则可以选择“(none)”。

举例：我们先新建一个普通页面，输入：“CIW 电脑工作室”，执行Modify→Template→Apply Template to Page命令，选择模板test，现有内容保存区域选择Main，确认后可看到页面自动变成了模板页的形式，而“CIW电脑工作室”这一行字就出现在主编辑窗口中。

　　3、更新模板以全面更新站点

　　基于某一模板建立了一些页面后，对模板进行修改后保存时，就会自动弹出一个对话框，列出所有使用了该模板的页面，询问是否要更新。

另外一种方法是执行Modify→Template→Update Pages命令。从Update Pages对话框中选择一个站点或站点的某一种模板(同一站点中可以使用多个模板)，单击右侧的Start按钮，软件会自动搜索与模板相关联的网页并进行更新。非常方便!

举例：Test模板左侧图形中的“读书破万站”图片是用一个图层叠加在另一幅图片之上的，现在不想要它，同时还想将所有页面中的该图片均删除。就可以打开模板test.dwt，删除该图层，保存模板，单击右侧的“Update”按钮即可。

　　注意：新建和使用模板前需定义站点。方法是，执行命令：Site→Define Sites;指定站点名称和本地根目录(Local Root)。模板使用的是相对路径，如果没有指定网站在本地的位置，软件就不能准确找到并保存模板文件;并且应用模板新建和更新页面时，页面中的超链接也不能随页面文件保存位置的不同而相应变化。

CMMI之需求管理和股票池管理

CMMI之需求管理和股票池管理
　　CMMI中需求管理过程域用于管理项目产品和产品组件的需求以识别需求与项目计划和工作产品之间不一致的地方。需求管理过程域只有一个特定目标：需求得到管理并且与项目计划和工作产品之间的不一致问题得到识别。

　　对于这个过程域，在证券操作中，相对应的过程是投资机会管理，而投资机会管理中最常见的手段就是股票池。在各大基金经理访谈节目中，我们常常能听到基金经理谈起基金建仓的范围是受基金公司股票池限制的，并不能完全自由的选择任何股票。因此直接将股票池管理与需求管理相对应。

　　需求管理的第一个特定实践：与需求提供者一起开发对需求含义的理解，工作产品一般是达成一致意见的需求集合。完成这个实践，有两个关键：1，合格的需求提供者；2，对需求进行评价，以保证来自于合格提供者的合适的需求得到收集。股票池管理其实就是股票列表的管理，较之于软件需求而言，软件需求的表述要长长的文字加图表等等，而股票要简单很多，一个代码就是说明绝大多数问题。对于个人炒股而言，一般由一个人完成，完全自己作主，不必考虑其他“需求提供者”，那么还有一个问题：如何评价股票？什么样的标准是股票入池的标准。这是股票池建设的一个核心问题。比如市盈率，比如走势，比如股评家推荐，等等，有很多标准，以后将专门来讲讲选股标准，这里就大家记得要有既定的标准来选股。最反对出现的极端情况是听到某某股神的推荐之后，直接加入自己的股票池，并且马上购买。

　　需求管理的第二个特定实践：从项目参与者处获得需求的承诺，工作产品一般是对需求和需求变更的书面承诺。对于股票池中股票而言，这也变得非常简单。法律和交易所的规则是最好的承诺，其次各上市公司各项公告也是满足这个实践要求的上好材料。

　　需求管理的第三个特定实践：管理在项目进行中变化的需求，工作产品一般是需求变化的记录。对于股票池的管理而言，变化就是股票的进池和出池，这可比软件简单多了，软件需求变化管理几乎是这个行业的噩梦。这里也与选股标准有关。对于基金公司而言，一般是既定的流程审批和记录，不是基金经理或研究员个人能快速决定的对于个人炒股而言，出现随心所欲的可能就很大。个人通常犯如下的毛病有股票池扩容过快，看看这只不错，那只也不错，都加到了股票池中，出现了长达50 支股票甚至更多的股票池。另外就是容易忘记当初为什么选那只股票入池，出入池没有记录，过一阵子就忘记为什么了。因此对于个人而言，简要的进行股票进出池记录，就能附合这个实践的要求。

　　需求管理的第四个特定实践：在需求与项目计划和工作产品之间维护双向的可追溯性，工作产品一般是需求矩阵或某种关联的命名规则。在软件开发中，通俗一点讲就是“通过这个已经实现功能对应的需求编号可以看到，这是某年某月某日某某会议上某某领导明确要求的，你现在怎么能说不要了呢？”。在股票池管理中，股票天生的代码就已经解决了这个追溯性的问题了，与这个代码相关的情况就是通过代码来追溯，当前前提是相关情况得到了记录，比如出入池。

　　需求管理的第五个特定实践：识别在项目计划和工作产品与需求之间的不一致问题，工作产品一般是记录不一致问题的来源、条件和原因之间的文档。对于股票池管理来说，不一致问题就在于操作股票池以外的股票。对于个人来说，在这个实践中不要操作股票池以外的股票就是很好了。对于投资机会管理而言，还有时间、价格等其它因素，投资机会管理涉及到买卖操作，不作为需求管理的范畴进行讨论，在下面的操作方法中进行讨论。

2010年下半年信息系统项目管理师考试试题分析

　　一、上午试题结构分析

从近几年信息系统项目管理师考试上午试题的考试题型来看，主要考查一些项目管理的知识，考试难度较大，对考生掌握知识的深度要求较高。从考试范围来看，着重考查信息化知识、专业技术知识、项目管理知识、高级项目管理知识、法律法规和英语等。从题目内容来看，主要以考察项目管理的知识为主。

　　在本次考试中，上午试题具有以下几个特点：

　　（1）难度较高，试题中分值尽管主要集中在项目管理知识，而专业知识、项目管理高级知识也占了不少的分值，但很多题型都是属于新题型，因此，很多同学在上午考试结束后都有一种模棱两可的感觉。但全部考题仍然在考点范围内。

（2）考试大纲中有的知识领域没有考题，如项目成本管理、项目人力资源管理和项目沟通管理等（而上半年是整体管理、人力资源管理、采购管理没有考题），仍然说明试题分数分布并不均匀。信息监理知识点连续3次没有考核。

　　（3）高级部分知识加强，所占分值达到10分。

从本次试题来看，灵活度较高，考生在今后的复习中对于上午知识仍然要全面掌握，对于概念性内容侧重理解。

　　二、下午试题I结构分析

　　下午的考试案例分析题3道题目全部是必答题，每题25分。从拿到试卷的一刻，笔者一阵喜悦，全部题目都在辅导过程中反复强调，尤其是在面授以及在线答疑中，笔者反复强调招投标法和采购法，要求考生记住关键数字，同时，对于久违多时的计算题，此次终于露面了，计算PV、EV、AC以及EAC，这类题型对于面授学员和参加过在线辅导的学员来说几乎属于送分题目。

　　试题一

　　试题一是考核《招投标法》的内容。问题1要求考生根据案例的内容分析项目招投标过程中存在的问题。问题2要求案例中的某些具体时间给出是否合理的判断。问题3属于知识型题目，要求考生说明招投标活动的主要流程有哪些。

　　（1）熟记3个数字，“15天、20天、30天”，本次考核到其中两个，即“距离投标截止日前20天发标书”、“中标通知书发出后30天内签合同”；

　　（2）同时，要求考生记住两个禁止事项“禁止串标”和“禁止低于成本价中标”。本次考核到后者。

　　（3）要求考生熟记招投标活动的流程：招、投、开、评、中六环节。

当然。对于此类题型，考生可以从模拟试题中和面授讲义中（《立项与招投标》章节）找到明确的解答。

　　试题二

试题二是关于变更控制的分析题，问题1要求考生通过对案例的分析，找出变更过程中存在的问题，问题2接着问可能产生的后果，问题3属于知识性题目，要求考生说明整体变更控制的流程。对于此类题目，仍然属于面授讲义命中范围，各位同学应该对面授过程中所提到的“反推法”印象深刻，本题恰恰就是面授过程中“反推法”案例的翻版。

对于问题1继续采用“原文法”找出问题所在，然后通过“问题”推导出得到问题2的答案。问题3属于知识型题目，考生可以从《信息系统项目管理师全程辅导》中找到具体的答案。当然，学习过“反推法”的同学完全可以按照授课过程中的方法进行解答。

　　试题三

试题三考核项目成本管理方面的知识。看到此类题目，仍然在命中范围，在面授和在线辅导答疑过程中，我们反复强调，对于计算题来说，要掌握的有三类，关键路径法、挣值分析和投资回收期计算，并告诫学员，此类题目属于送分的题目。对于计算题，一旦掌握的计算方法，确实是属于送分的题目。

　　此类题目无非是计算PV、EV、AC、CV、SV、EAC，而对于EAC分典型偏差和非典型偏差两种情形。对于解决方法可以参照面授讲义中所提到的方法。

问题1，2，均属于简单的计算，掌握公式即可，对于问题3，需要灵活理解BAC的概念，在本题中，EAC=AC+ETC，根据状态的不同，ETC分典型和非典型，典型情况下，ETC=（BAC-EV）/CPI，非典型状态下ETC=BAC-EV。

综合来看，本次下午I题目相当简单，其难度甚至无法与中级的案例分析题（5道）相比。同时，除了案例2需要一点“分析”外，其余都属于“计算”和“记忆”的范畴，尽管此处案例简单，但也让我们分为意识到高级考试的多变性，并不一定是以“分析”为主了，因此，对于后续的考生来说，难度反而更大，从以往的“经验”和“分析”能力取胜可能拓展到“计算”“记忆”，实际上是范围越来越广。

　　三、下午试题II结构分析

下午试题II要求在两道题中选择一道题，撰写论文，虽说是论文，其实是经验总结。两道题目分别为试题一《论大型信息系统项目的进度管理》和试题二《论多项目的资源管理》。

每道试题结构都是一样的，分为三个问题。第一个问题属于老生常谈，都是“概要叙述管理过的大型信息系统项目（项目的背景、项目的规模、目的、发起单位性质、项目内容、项目周期、交付产品等相关信息）。”

　　第二、三个问题则开始谈对所涉及知识领域的理解以及具体的项目经验。

2010年软考信息系统项目管理师考试重点与难点：沟通与变革管理

项目管理是一门复杂的科学，其成败取决于很多因素，项目管理中的沟通与变革管理是关系到项目成败的关键之一。大型的IT应用项目不仅仅是一个技术工作，而是一场管理变革。如果不能很好地管理和推动这些变革，人与组织固有的"惰性"将对变革产生消极的抵抗。

据国际著名咨询公司——德勤公司的一项调查表明，影响ERP系统成败的风险主要有十项，其中最大的因素就是"对变革的抵抗"，其他一些与变革相关的风险还包括"不实际的期望"、"变革原因说不清"以及"缺乏变革管理策划"等三项。由此可见，变革管理是项目管理中的重要内容，必须慎重对待。

　　变革管理的根本目的是取得项目实施成功所必需的利益相关者的支持与承诺，同时促使企业全体员工能接受并适应新的系统与业务流程。

具体而言，变革管理必须实现以下目标：项目组与业务部门领导、公司决策层之间能进行开诚布公、及时有效的沟通，从而获得他们的支持、参与与推动;项目组内部能进行清楚高效的沟通，以保证项目组成员的工作能协调一致，按时、保质、保量完成预期的交付成果，并得到认同和提升。

为使整个组织能清楚理解项目实施的目的、影响与进度，应做到所有员工都应理解项目实施的原因、意义及其对整个组织及组织内部每个功能、地域实体的影响;广大员工能看到公司高层领导通过实际行动所表现出来的对于项目实施的支持与承诺;保证组织合理安排员工的工作职责和角色转换，以及可能发生的组织结构调整。

对系统实施相关的终端用户进行教育与培训，使其以积极主动的心态迎接可能的变革，并具有相应的技能来适应这种变革;加强内外部的宣传与沟通，为项目顺利推进营造一种适宜的组织氛围。

变革管理工作的核心是沟通。沟通是取得那些会受到变革影响的人的支持的基础。这种支持只会在关键决策者认识到变革的作用并推动变革时才会取得。为了达到获得支持的目的，沟通必须：

　　培养客户对IT应用项目的价值与战略重要性的认同感;保持信息的一致性与重复性，因为在长期变革中最容易受到影响的就是信息的清晰性;通过行动的一致性培养信任;形成双向交流，就信息源所提出的问题及其回答给予回应;了解不同的对象会有不同的需求、兴趣及理解事物的倾向性;增强项目进度的透明度，并确保包括各相关业务部门在内的各方了解项目的进展。

“猴子与芒果园”的故事谈项目失败的原因

话说有一片美丽的芒果园，园中结满成熟的果实。一群猴子从果园经过，看见满园的芒果，就进入果园。它们摘下芒果，咬过几口便不耐烦地丢下，又去摘下一个。突然一只猴子尖叫起来，原来它被一块大石头打中了。猴子们回过头，发现园丁们正向它们扔石头。它们慌忙逃进附近的森林中，等园丁们离开，又立刻返回。但是它们刚刚开始吃芒果，石头便再次雨点般向它们打来。猴子们只得逃走。

　　这样的情景一次又一次地再现，最后大多数猴子都受了伤。这时猴王说：“我们应当拥有自己的芒果树，那样就能太太平平地吃果子。”于是猴王召集众猴开会，以寻求解决办法。最聪明的一只猴子说：

　　“我听说芒果树来自芒果中的种子，人类把种子埋到地里，芒果树就会长出来。我们可以偷一只芒果，把种子埋到地里，种出我们自己的树。”
　　猴子们一致认为这是个好主意，于是它们派出最灵活的一只猴子回到果园。它躲开园丁的几块石头，摘下一颗硕大的芒果，带着它奔回森林。猴子们挖了一个坑，放进一颗种子，盖上土。然后它们围坐在坑的周围，目不转睛地盯着树坑，期待着树长出来。10分钟过去了，芒果树并没长出来，一些小猴子们坐不住了，偷偷地溜走。10分钟又过去了，芒果树仍然没有长出来，一些大猴子也溜走了。最后猴王喝道：

　　“都回来!你们要去哪儿?”
　　“我们不想等下去了。果园里有那么多芒果可吃。”
　　“你们不明白吗?吃别人的果子是没有前途的，我们必须有自己的树。我确信它很快会长出来。”

　　众猴们在猴王的号召下又等了整整一天，但是芒果树还是没有长出来。第二天又过去了，芒果树还是没有长出来。“等这么长时间是不正常的!”一只猴子说，“把它挖出来，看看出了什么问题。”“耐心点。”猴王说。第三天过去了，芒果树依旧没有长出来。全体猴子一齐求猴王让它们把种子挖出来，看看发生了什么。最后猴王同意了，猴子们挖下去，种子露了出来，但是它们把刚刚萌发的细芽弄断了。

　　“你们看见了，孩子们!”猴王说，“愿望不会一夜成真。你们有拥有一棵树的梦想，也有了种子，却没有实现梦想的耐心。”
　　项目经理的错误管理，从软件工程的角度考虑，主要表现在以下几个方面：

　　1)需求分析没有做好：这里正确的需求应该是拥有自己的芒果园，而不是单单的一颗芒果树。
　　2)解决方案没有做好：猴王召集众猴开会，以寻求解决办法，这个可以认为是“头脑风暴”方式的问题办法，但风暴后的结果却是错误的，因为有只公认的聪明的猴子说“我听说芒果树来自芒果中的种子，人类把种子埋到地里，芒果树就会长出来。我们可以偷一只芒果，把种子埋到地里，种出我们自己的树。”并且猴子们一致认为这是个好主意，其实这是个错误的主意。其一：这个解决方案只是听说，并没有进行可行性研究；其二：偷一只芒果，显然是资源需求没有做好，一只芒果的种子的数量是远远不够的。

　　3)项目成本投入太少：最灵活的一只猴子回到果园。摘下一颗硕大的芒果，带着它奔回森林。猴子们挖了一个坑，放进一颗种子，盖上土。大家注意，这里整个项目组只挖了一个坑，并且只投入了一颗种子。显然成本投入太少。

　　4)资源管理混乱，没有进行科学的任务分配：种子种下之后，他应该只派一两只猴子看守种子的成长情况，以观察项目的进度；再派其它猴子偷学园丁的果园管理技术，以及芒果树的种植技术;还得加强一批猴子的技术训练如敏捷度，并将这只训练有素的队伍外派到人类的果园偷果子，以解决项目组其它成员的火食问题，使项目进行下去。

　　5)项目技术不成熟：种子种下之后，应该给予浇水、施肥、甚至给予适当的温度，以保证种子的合理的生长环境。
　　6)项目测试混乱：整个项目只经过一次现场测试，也就是Baita测试，但测试的结果是项目因为资源耗尽而导致失败，显然没有进行有效的备份。

　　7)推卸责任：项目总结时，猴王是这样总结的：“愿望不会一夜成真。你们有拥有一棵树的梦想，也有了种子，却没有实现梦想的耐心。”挖种子是在猴王的同意之下才进行的，而当萌芽被破坏后，猴王却将责任推向众猴，显然猴王是一个不敢于承担责任的项目经理。

　　8)没有进行合理的效益分析：一颗芒果树从生根、发芽再到开花、结果，大约需要三年的时间，整个猴群项目组花三年的时间，就为了培育一颗芒果树，那么项目的成本回收是何年何月，项目出业绩，又是何年何月。
　　9)风险意识太差：一颗芒果籽生根、发芽、结果需要多长时间他没想过，就算一颗树结了果实又能养活多少只猴子也没想过。 

　　　从辩证法的角度考虑，猴王主要违背了以下四个项目经理具备的辩证论法
　　1)既要计划，又要变化
　　有人说计划赶不上变化，但倘若没有变化,要计划还有何用；“芒果树种植”项目中，没有任何的计划，也没有应对变化的对策。

　　2)既要见林，又要见木
　　不要因一叶遮目，但也不能因为整片森林而忽略眼前参天大树；“芒果树种植”
　　项目应该树立远大的目标芒果园，而不是芒果树。

　　3)既要冷静分析，又要相信直觉
　　冷静也是一种直觉；猴王这个项目经理没有经过冷静的分析，而只是凭着他个人的感觉，相信“芒果树一定会长出来”，而没有任何依据，如果他能冷静的分析出芒果树的生长规律，相信就不会再犯这样的直觉错误。

　　4)既要有原则性，又要有灵活性
　　猴王有原则，但不够坚持。
　　总的来说，“芒果树种植”项目的失败，主要是项目经理没有合理的调度工期、质量、成本、人员、范围也就是T-Q-C-P-S这五大要素。

上学吧为您提供信息系统项目管理师（高级）考试资料下载：hhttp://www.shangxueba.com/share/e26.html

信息系统项目管理师（高级）