唐僧师徒赴西天取经，不畏艰险，锲而不舍，历经八十一难最终修成正果。这是一段伟大的旅程，敢问路在何方——路在脚下!世上没有不能到达的目标，最远的路途就在脚下，这是西游记让我们深深感动的地方。西游记绚丽多彩的魔幻世界其实是现实社会的投影，平凡的人们为了生存和发展都会历经磨难。作为一名IT业的项目经理，我深刻地体会到：这是一个充满挑战和艰辛的职业，但也是一个自我发展和提升的途径。一帆风顺的经历不会增长才干，帮助个人成长的其实是困难和障碍以及克服它们的过程，只有经历风雨，才能迎来彩虹。

　　本文以我负责的某大型教育培训网站(简称教育网系统)建设项目为背景，结合项目实战经验谈一些体会。这个项目是我初任项目经理时经历的，现在回顾起来，当时所遇到的问题以及解决过程还历历在目。

　　甲方不提供硬件测试环境，争取提前试运行发现问题

　　该项目要建设一个在线学习和教育管理网站，提供在线学习和考核的平台，实现培训工作的信息发布和组织管理。平台所使用的课件由其他系统制作，本系统需提供课件上传管理功能。系统采用Oracle数据库、WebLogic应用服务器，通过F5实现负载均衡，使用基于J2EE技术的B/S架构，要求能够运行在Unix平台上。

　　接手这个项目后，我首先对系统的运行环境做了初步了解。客户方的机房有多台IBM AIX小型机和PC机。WebLogic应用服务器将部署在AIX小型机上，在一台AIX小型机上会同时部署多家公司的应用系统，每个应用系统在WebLogic中都通过建立独立的域(Domain)来进行管理。

　　任何应用系统在上线前都应进行严格的测试，而且测试环境要与实际运行环境一致，因为应用系统的功能、性能在不同操作系统环境下的表现是不一样的，因此为了保证系统的稳定运行，需要准备AIX小型机作为测试环境。但是我们以前承接的项目使用的基本都是HP和SUN的服务器，没有AIX服务器。

　　我意识到这是一个重要风险，必须妥善应对。客户的机房有一些测试设备可供使用，我与销售经理沟通，看有无可能得到客户许可使用机房的测试设备。这个项目当时还处于售前阶段，正在签署合同。销售经理反馈回来的结果是，客户不负责提供测试环境，并且在合同中对此增加了明确的条款：甲方不负责提供任何测试设备和环境。我在客户这边碰了壁，只好另外想办法，首先想到的是从公司获得支持。

　　项目启动后，我在项目计划中上报了这个风险，希望公司帮助调配一台测试用机，或者采购一台AIX小型机，在各个项目之间共享，解决多个项目可能会遇到的同样问题。项目管理部很快打来电话，询问了详细情况，表示公司调配有一定困难，其他项目并没有闲置的小型机，目前也没有采购机器的预算，希望项目组尽力设法解决，并强调一定要妥善处理，不能因此发生问题。

　　回想我当时的心情真不好受，感觉孤立无援，但是我从这个过程中也学到了重要的一课：项目经理的作用不只是发现问题、提出问题，更重要的是解决问题。系统测试的硬件环境不具备，客户和公司都不能提供支持，这是一个必须解决的难题。

　　这个问题放在现在是很好解决的，可以花少量费用短期租赁，但当时IT租赁业还没有发展起来，可以提供设备的大公司价格很高，而价格较低的小公司设备又不全。我询问了两个关系不错的合作伙伴公司能否借用，对方当下没有正好闲置的机器。看来这个风险不能避免，那就要从如何减小风险的影响程度上寻找对策。我一方面继续寻找机器，一方面积极与客户沟通，最终得到客户的支持，允许我们提前到正式环境下部署，在系统大范围试运行前先小范围试运行一段时间，这样就为解决可能面临的问题赢得了时间。

　　排查问题定位原因，但遭咨询方质疑

　　在我的推进下，系统得以提前部署到正式环境中，但不久就发现了一个严重的问题：课件的视频文件通常在几百兆左右，在上传到AIX平台时，速度非常慢，只有40KB/s，以至于浏览器页面失去响应，只有十几兆的小课件可以上传成功，稍微大一点的课件就传不上去了。

　　我组织项目团队深入分析了这个问题，通过比较测试环境与正式环境的不同之处，定位问题的原因可能来自“网络环境”或者“操作系统”，此外应用程序上传组件在正式环境下能否正常运行也有待验证，根据初步分析，我们制定并实施了以下问题排查措施：

　　在客户方环境下使用FTP工具上传大视频文件，并使用网络监测工具观察上传过程是否正常，结果上传速度很快，网络监测也完全正常，基本排除了网络因素;

　　在客户方Windows环境下搭建WebLogic应用服务器进行测试，在上传代码中增加日志输出功能，打印分段传输文件过程中每段的用时和传输速度，结果上传速度很快，可以确定上传组件正常运行;

　　对操作系统的问题，为进一步缩小问题范围，我们在公司搭建了HP Unix测试环境，上传速度仍然很快，这样基本确定问题是由AIX操作系统带来的。

　　我组织项目团队成员继续奋战，查阅了AIX操作系统的大量资料，在团队技术骨干的分析和论证下，最后定位问题原因在于一个AIX操作系统的网络传输参数。于是我们写了一份分析报告提交给用户，说明了排查的过程和结论，请求客户方允许我们调整AIX操作系统的一个参数，问题就可以迎刃而解。

　　但是事情并不像预期的那样顺利，客户方请的咨询公司认为我们的报告证据不足，认为问题是应用系统的错误造成的，应修改应用系统，不应调整参数，而且由于AIX系统上运行着多家公司的多个应用系统，调整参数可能对其他系统产生影响，因此咨询公司坚持在没有得到权威结论前不同意调整参数。

　　我们一时找不到AIX系统验证我们的结论，但是客户方要求我们尽快解决问题，迫于时间压力，我们只好采用了权宜之计，修改了技术方案，从系统设计上做了调整，增加了一种课件上传管理的方式，避开了直接通过应用系统上传，这样做会增加一些操作步骤，但能够满足课件后台维护的要求，客户也认可这种修改方案，这个问题基本得到了解决。

　　用事实回应质疑，赢得甲方肯定

　　问题虽然得到解决，但我的心里却很不踏实：我们的排查结论是否正确还没能在AIX系统上进行验证，这次绕开陷阱的做法只是权宜之计，对系统今后的推广和产品化等工作会带来隐患，也许我们在未来还会再次遇到这个陷阱。此外，由于咨询公司多年服务于客户方，有重要的地位，他们的意见会左右客户方对我们的评价。这是我必须彻底解决的又一个重要问题：如何用事实证明我们的实力和价值。

　　我一直没有放弃多方寻找问题的解决方法，也一直保持和合作伙伴的联系。当时我还负责另一个项目，需要第三方测试，为此请了专业的第三方测试机构。他们拥有各种品牌、型号和配置的服务器，这让我看到了转机。在第三方测试工作开展的过程中，我与测试机构的负责人建立了良好的关系，在我提出需要免费借用设备时，对方很爽快地答应了。

　　我们很快在AIX操作系统上搭建了应用系统，进行了期待已久的测试。选定几个不同大小的视频文件样本，在网络传输参数tcp_nodelayack为缺省值0的情况下进行测试，结果与在客户方现场的表现一样，文件上传速度为40KB/s左右，50MB以上的文件就不能成功上传。当把该参数改为1，再用样本文件测试，结果上传速度显著提高，达到4MB/s。我们详细记录了验证过程，写了一份报告发送给客户方和咨询公司，用事实证明了应用系统没有问题，排查结论是正确的，赢得了客户方对我们工作的肯定。

　　软件供应商中断业务，拒绝提供支持

　　教育网系统正式上线运行取得了很好的效果，客户方决定在其20个分支机构推广，经过方案论证，确定以建成的教育网系统为中心，在20个机构采用分布式结构部署系统。客户方很快召开了全体会议，要求分支机构尽快完成硬件准备工作。我们了解到，分支机构的设备很多是以前客户方总部统一采购的，AIX小型机占主导，有些分支机构的业务量较大，资源比较紧张，就为此又购置了AIX小型机。

　　硬件准备好后，客户与我方签署了“软件开发服务”合同，要求分别根据分支机构的个性需求对教育网系统进行改造和完善。在系统推广的工作中，又出现了一个棘手的问题：系统需要使用R公司的视频服务器R Server用于播放课件，R公司在中国已经中断了基于AIX的R4及以上版本的产品销售、服务和技术支持，即使是R4也仅在AIX 4及以下版本的操作系统上进行过严格测试，而分支机构购置的AIX小型机都是AIX 5以上版本，所以根本无法得到可靠的视频服务器。总部通过一段时间积累了很多课件资源，这些资源都是基于R公司独有的视频文件格式，并需要与分支机构共享，所以不可能转移到其他视频服务器。

　　针对以上问题，我组织项目团队进行了分析，根据我们对R公司视频服务器的技术积累和掌握程度，可以确定：在AIX 5版本上运行未经严格测试的R4并没有问题，我们可以考虑采购R4替代高版本产品用于AIX 5。下面的问题就是如何说服R公司破例出售给我们R4。

　　我为此与R公司进行了多次沟通，详细说明了我们遇到的问题，希望得到支持，R公司的负责人在与美国总部沟通多次后明确表示这是总部确定的销售政策，不能破例，而且R4缺少某些新特性，对项目开发、实施不利，强烈建议我们改用其他操作系统，采购最新版本。但这就意味着客户方花费几十万购买的小型机不能投入使用，这是客户绝对不能接受的，事情一时陷入僵局。

　　这个问题并不孤立，还连带一些潜在问题。根据用户数量的发展情况，系统总部及其分支机构以后很有可能需要做视频服务器的集群，因此并不是只解决目前的问题就可以了，一定要未雨绸缪，否则未来仍然会面临这个问题。

　　在这个项目中，我方按照“软件开发服务”合同的要求，只负责软件部分，并不负责软硬件系统集成，但这个问题不解决，就无法顺利推动项目进展。突破责任的界限与职责范围，站在项目整体利益的高度，我必须设法使软件供应商改变拒绝的态度，全力支持，破例出售足够数量的R4软件使用许可，并与我们共同面对、解决出现的问题，这是关系到系统是否能顺利推广的一个关键问题。

　　借助甲方力量，协调软件供应商共担风险

　　我仔细分析了现状，列出要解决的两个具体问题：第一是说服R公司出售R4低版本产品，第二是要保证不能因为采购了R4而造成未来有些业务需求不能实现。我仔细分析了高版本新增的功能特性：在分布式环境中实现课件共享和支持移动设备。前者可以通过应用系统实现，我们已经在这方面有了扎实的技术积累，而后者虽然目前客户没有需求，但是未来怎样没有把握。

　　这些未定因素需要尽早摆到桌面上，把风险提出来，引起相关各方的重视，最好能够促成客户方与R公司直接对话，这样在客户面前我们可以共担风险，而且也可以借助客户方的力量推动R公司按特例处理这个问题，避免我方独立面对客户，处于不利的地位，承担过重的责任和压力。

　　为此，我组织了由客户方相关分支机构(包括业务部门和信息中心)、项目监理方、R公司和我方参加的项目专题会议，在会议上我详细汇报了目前的问题、建议的解决方案以及我们和R公司已做的工作的进展情况，并听取客户方的指导意见。

　　客户方的业务部门明确表示：未来五年内不会考虑升级到更高版本，不会有移动设备视频服务的需求。这样，我顾虑的第二个问题就打消了。R公司在会议上也表示虽然很难，但通过努力能够向美国总部申请一定数量的许可满足客户需求，如果在实施过程中出现任何问题，也将协调国内、国外的技术人员给予解决，将大力支持系统的建设。

　　我安排专人对此次会议做了详细的会议纪要，与会各方都在纪要上签字并各自留存纪要副本，通过协调会，各相关方都充分意识到这个问题，并进行了深入的分析和探讨，最后明确了问题的解决方案并作出承诺，为项目的顺利进展扫清了障碍。

　　通过解决这个问题，我体会到：在项目实施过程中，项目经理一定要主动与客户方密切合作，加强沟通，客户方的充分参与能有效地协调供应商，增强项目经理对项目的控制能力。此外，对于己方不完全掌握的技术，不能单方面过度承诺。我们要有高度负责的敬业精神，但同时也要善于通过沟通、协调与合作伙伴分担责任。

　唐僧师徒赴西天取经，不畏艰险，锲而不舍，历经八十一难最终修成正果。这是一段伟大的旅程，敢问路在何方——路在脚下!世上没有不能到达的目标，最远的路途就在脚下，这是西游记让我们深深感动的地方。西游记绚丽多彩的魔幻世界其实是现实社会的投影，平凡的人们为了生存和发展都会历经磨难。作为一名IT业的项目经理，我深刻地体会到：这是一个充满挑战和艰辛的职业，但也是一个自我发展和提升的途径。一帆风顺的经历不会增长才干，帮助个人成长的其实是困难和障碍以及克服它们的过程，只有经历风雨，才能迎来彩虹。

　　本文以我负责的某大型教育培训网站(简称教育网系统)建设项目为背景，结合项目实战经验谈一些体会。这个项目是我初任项目经理时经历的，现在回顾起来，当时所遇到的问题以及解决过程还历历在目。

　　甲方不提供硬件测试环境，争取提前试运行发现问题

　　该项目要建设一个在线学习和教育管理网站，提供在线学习和考核的平台，实现培训工作的信息发布和组织管理。平台所使用的课件由其他系统制作，本系统需提供课件上传管理功能。系统采用Oracle数据库、WebLogic应用服务器，通过F5实现负载均衡，使用基于J2EE技术的B/S架构，要求能够运行在Unix平台上。

　　接手这个项目后，我首先对系统的运行环境做了初步了解。客户方的机房有多台IBM AIX小型机和PC机。WebLogic应用服务器将部署在AIX小型机上，在一台AIX小型机上会同时部署多家公司的应用系统，每个应用系统在WebLogic中都通过建立独立的域(Domain)来进行管理。

　　任何应用系统在上线前都应进行严格的测试，而且测试环境要与实际运行环境一致，因为应用系统的功能、性能在不同操作系统环境下的表现是不一样的，因此为了保证系统的稳定运行，需要准备AIX小型机作为测试环境。但是我们以前承接的项目使用的基本都是HP和SUN的服务器，没有AIX服务器。

　　我意识到这是一个重要风险，必须妥善应对。客户的机房有一些测试设备可供使用，我与销售经理沟通，看有无可能得到客户许可使用机房的测试设备。这个项目当时还处于售前阶段，正在签署合同。销售经理反馈回来的结果是，客户不负责提供测试环境，并且在合同中对此增加了明确的条款：甲方不负责提供任何测试设备和环境。我在客户这边碰了壁，只好另外想办法，首先想到的是从公司获得支持。

　　项目启动后，我在项目计划中上报了这个风险，希望公司帮助调配一台测试用机，或者采购一台AIX小型机，在各个项目之间共享，解决多个项目可能会遇到的同样问题。项目管理部很快打来电话，询问了详细情况，表示公司调配有一定困难，其他项目并没有闲置的小型机，目前也没有采购机器的预算，希望项目组尽力设法解决，并强调一定要妥善处理，不能因此发生问题。

　　回想我当时的心情真不好受，感觉孤立无援，但是我从这个过程中也学到了重要的一课：项目经理的作用不只是发现问题、提出问题，更重要的是解决问题。系统测试的硬件环境不具备，客户和公司都不能提供支持，这是一个必须解决的难题。

　　这个问题放在现在是很好解决的，可以花少量费用短期租赁，但当时IT租赁业还没有发展起来，可以提供设备的大公司价格很高，而价格较低的小公司设备又不全。我询问了两个关系不错的合作伙伴公司能否借用，对方当下没有正好闲置的机器。看来这个风险不能避免，那就要从如何减小风险的影响程度上寻找对策。我一方面继续寻找机器，一方面积极与客户沟通，最终得到客户的支持，允许我们提前到正式环境下部署，在系统大范围试运行前先小范围试运行一段时间，这样就为解决可能面临的问题赢得了时间。

　　排查问题定位原因，但遭咨询方质疑

　　在我的推进下，系统得以提前部署到正式环境中，但不久就发现了一个严重的问题：课件的视频文件通常在几百兆左右，在上传到AIX平台时，速度非常慢，只有40KB/s，以至于浏览器页面失去响应，只有十几兆的小课件可以上传成功，稍微大一点的课件就传不上去了。

　　我组织项目团队深入分析了这个问题，通过比较测试环境与正式环境的不同之处，定位问题的原因可能来自“网络环境”或者“操作系统”，此外应用程序上传组件在正式环境下能否正常运行也有待验证，根据初步分析，我们制定并实施了以下问题排查措施：

　　在客户方环境下使用FTP工具上传大视频文件，并使用网络监测工具观察上传过程是否正常，结果上传速度很快，网络监测也完全正常，基本排除了网络因素;

　　在客户方Windows环境下搭建WebLogic应用服务器进行测试，在上传代码中增加日志输出功能，打印分段传输文件过程中每段的用时和传输速度，结果上传速度很快，可以确定上传组件正常运行;

　　对操作系统的问题，为进一步缩小问题范围，我们在公司搭建了HP Unix测试环境，上传速度仍然很快，这样基本确定问题是由AIX操作系统带来的。

　　我组织项目团队成员继续奋战，查阅了AIX操作系统的大量资料，在团队技术骨干的分析和论证下，最后定位问题原因在于一个AIX操作系统的网络传输参数。于是我们写了一份分析报告提交给用户，说明了排查的过程和结论，请求客户方允许我们调整AIX操作系统的一个参数，问题就可以迎刃而解。

　　但是事情并不像预期的那样顺利，客户方请的咨询公司认为我们的报告证据不足，认为问题是应用系统的错误造成的，应修改应用系统，不应调整参数，而且由于AIX系统上运行着多家公司的多个应用系统，调整参数可能对其他系统产生影响，因此咨询公司坚持在没有得到权威结论前不同意调整参数。

　　我们一时找不到AIX系统验证我们的结论，但是客户方要求我们尽快解决问题，迫于时间压力，我们只好采用了权宜之计，修改了技术方案，从系统设计上做了调整，增加了一种课件上传管理的方式，避开了直接通过应用系统上传，这样做会增加一些操作步骤，但能够满足课件后台维护的要求，客户也认可这种修改方案，这个问题基本得到了解决。

　　用事实回应质疑，赢得甲方肯定

　　问题虽然得到解决，但我的心里却很不踏实：我们的排查结论是否正确还没能在AIX系统上进行验证，这次绕开陷阱的做法只是权宜之计，对系统今后的推广和产品化等工作会带来隐患，也许我们在未来还会再次遇到这个陷阱。此外，由于咨询公司多年服务于客户方，有重要的地位，他们的意见会左右客户方对我们的评价。这是我必须彻底解决的又一个重要问题：如何用事实证明我们的实力和价值。

　　我一直没有放弃多方寻找问题的解决方法，也一直保持和合作伙伴的联系。当时我还负责另一个项目，需要第三方测试，为此请了专业的第三方测试机构。他们拥有各种品牌、型号和配置的服务器，这让我看到了转机。在第三方测试工作开展的过程中，我与测试机构的负责人建立了良好的关系，在我提出需要免费借用设备时，对方很爽快地答应了。

　　我们很快在AIX操作系统上搭建了应用系统，进行了期待已久的测试。选定几个不同大小的视频文件样本，在网络传输参数tcp_nodelayack为缺省值0的情况下进行测试，结果与在客户方现场的表现一样，文件上传速度为40KB/s左右，50MB以上的文件就不能成功上传。当把该参数改为1，再用样本文件测试，结果上传速度显著提高，达到4MB/s。我们详细记录了验证过程，写了一份报告发送给客户方和咨询公司，用事实证明了应用系统没有问题，排查结论是正确的，赢得了客户方对我们工作的肯定。

　　软件供应商中断业务，拒绝提供支持

　　教育网系统正式上线运行取得了很好的效果，客户方决定在其20个分支机构推广，经过方案论证，确定以建成的教育网系统为中心，在20个机构采用分布式结构部署系统。客户方很快召开了全体会议，要求分支机构尽快完成硬件准备工作。我们了解到，分支机构的设备很多是以前客户方总部统一采购的，AIX小型机占主导，有些分支机构的业务量较大，资源比较紧张，就为此又购置了AIX小型机。

　　硬件准备好后，客户与我方签署了“软件开发服务”合同，要求分别根据分支机构的个性需求对教育网系统进行改造和完善。在系统推广的工作中，又出现了一个棘手的问题：系统需要使用R公司的视频服务器R Server用于播放课件，R公司在中国已经中断了基于AIX的R4及以上版本的产品销售、服务和技术支持，即使是R4也仅在AIX 4及以下版本的操作系统上进行过严格测试，而分支机构购置的AIX小型机都是AIX 5以上版本，所以根本无法得到可靠的视频服务器。总部通过一段时间积累了很多课件资源，这些资源都是基于R公司独有的视频文件格式，并需要与分支机构共享，所以不可能转移到其他视频服务器。

　　针对以上问题，我组织项目团队进行了分析，根据我们对R公司视频服务器的技术积累和掌握程度，可以确定：在AIX 5版本上运行未经严格测试的R4并没有问题，我们可以考虑采购R4替代高版本产品用于AIX 5。下面的问题就是如何说服R公司破例出售给我们R4。

　　我为此与R公司进行了多次沟通，详细说明了我们遇到的问题，希望得到支持，R公司的负责人在与美国总部沟通多次后明确表示这是总部确定的销售政策，不能破例，而且R4缺少某些新特性，对项目开发、实施不利，强烈建议我们改用其他操作系统，采购最新版本。但这就意味着客户方花费几十万购买的小型机不能投入使用，这是客户绝对不能接受的，事情一时陷入僵局。

　　这个问题并不孤立，还连带一些潜在问题。根据用户数量的发展情况，系统总部及其分支机构以后很有可能需要做视频服务器的集群，因此并不是只解决目前的问题就可以了，一定要未雨绸缪，否则未来仍然会面临这个问题。

　　在这个项目中，我方按照“软件开发服务”合同的要求，只负责软件部分，并不负责软硬件系统集成，但这个问题不解决，就无法顺利推动项目进展。突破责任的界限与职责范围，站在项目整体利益的高度，我必须设法使软件供应商改变拒绝的态度，全力支持，破例出售足够数量的R4软件使用许可，并与我们共同面对、解决出现的问题，这是关系到系统是否能顺利推广的一个关键问题。

　　借助甲方力量，协调软件供应商共担风险

　　我仔细分析了现状，列出要解决的两个具体问题：第一是说服R公司出售R4低版本产品，第二是要保证不能因为采购了R4而造成未来有些业务需求不能实现。我仔细分析了高版本新增的功能特性：在分布式环境中实现课件共享和支持移动设备。前者可以通过应用系统实现，我们已经在这方面有了扎实的技术积累，而后者虽然目前客户没有需求，但是未来怎样没有把握。

　　这些未定因素需要尽早摆到桌面上，把风险提出来，引起相关各方的重视，最好能够促成客户方与R公司直接对话，这样在客户面前我们可以共担风险，而且也可以借助客户方的力量推动R公司按特例处理这个问题，避免我方独立面对客户，处于不利的地位，承担过重的责任和压力。

　　为此，我组织了由客户方相关分支机构(包括业务部门和信息中心)、项目监理方、R公司和我方参加的项目专题会议，在会议上我详细汇报了目前的问题、建议的解决方案以及我们和R公司已做的工作的进展情况，并听取客户方的指导意见。

　　客户方的业务部门明确表示：未来五年内不会考虑升级到更高版本，不会有移动设备视频服务的需求。这样，我顾虑的第二个问题就打消了。R公司在会议上也表示虽然很难，但通过努力能够向美国总部申请一定数量的许可满足客户需求，如果在实施过程中出现任何问题，也将协调国内、国外的技术人员给予解决，将大力支持系统的建设。

　　我安排专人对此次会议做了详细的会议纪要，与会各方都在纪要上签字并各自留存纪要副本，通过协调会，各相关方都充分意识到这个问题，并进行了深入的分析和探讨，最后明确了问题的解决方案并作出承诺，为项目的顺利进展扫清了障碍。

　　通过解决这个问题，我体会到：在项目实施过程中，项目经理一定要主动与客户方密切合作，加强沟通，客户方的充分参与能有效地协调供应商，增强项目经理对项目的控制能力。此外，对于己方不完全掌握的技术，不能单方面过度承诺。我们要有高度负责的敬业精神，但同时也要善于通过沟通、协调与合作伙伴分担责任。