现场管理-如何做现场推广.docx

8如何做现场推广?
8.1现场推广工作可进行条件？
如何通过现场推广让用户项目快速上线，是很多实施工程时关注的问题。如果一个项目非常简单，和以往工程基本类似，那么辅导上线就非常轻松，根据企业业务和产品特点做好业务手册和应用规范，直接安装调试，验证无误就可以大面积推广，实施周期可以大大缩短。但对于很多大型项目，有很多不确定性或个性的内容，要进入现场推广阶段需要做很艰苦的工作。
　　在一个项目实施过程中，如果要想让现场推广工作快速有效进行，其实是需要做大量高质量的前期工作，现场辅导系统上线应用不过是一个很自然的结果。
　　现场推广工作可以进行在具备四个条件情况将非常顺利：
　　1)经过充分现场功能验证，确定产品功能基本能连串起一个或几个基本业务流，并得到用户项目组书面认可；
　　2)产品的稳定性和性能在可预见并发环境下性能能达到可使用要求；
　　3)针对基本业务流的业务操作手册全部编制完成，并对相关用户完成培训；
　　4)用户和公司都可以投入一定资源，主要是用户方有可独立推广资源。
　　功能能不能支撑一个业务是进行现场推广的最必要条件，很多人为了项目交差或者应付用户，匆忙装机、配置和辅导，最终用户发现用起来不是很顺利，经常出现BUG，或者对业务支持并不能达到要求，对就失去信心，再来推广，阻力就大，非常困难。
　　功能可以支持的情况产品稳定性和性能也很重要，如果产品稳定性和性能不足，项目往往也容易陷入停滞。
　　至于业务手册和用户推广资源也是顺利进行现场推广的必要条件。
　　实际项目实施过程中，往往是这些条件都不能满足的情况必须进行现场推广，否则无法将项目推进到一个阶段，得到用户认可，以便验收回款，但实际上效果并不见得容易达到。
　　我个人体会现场推广顺利不顺利，其实不在现场时间长短，而是你为现场推广准备工作细致程度关联性更强。要想出差少也能控制项目，就必须寻求合理的项目控制策略。
8.2现场推广工作为什么进展慢？
　　很多项目在快速完成业务调研和基本配置之后，就好象进入了一个平淡期，业务已经似乎清楚了，配置也按要求完成了，但用户好象就是没有什么用，大部分人也没有积极性，项目进入了一个僵持期，为了推动项目企业项目组或信息化负责人不断催促我们实施人员进入现场，推动项目。
　　而我们的实施人员也非常努力地在现场推动，推动，再推动，直到推不动，项目成为一个胡子工程或者是拉面工程。
　　项目现场推广时间无限延长对用户，对软件商，对实施人员都是一种极大的伤害和折磨，我们认为项目推广时间无法确定或者确定后无法结束恰恰是一个项目失控的症状。
　　泡现场其实是典型的项目失控特征之一。
　　我们可以分析为什么经常出现用户要求实施人员来泡现场？
　　从实施的角度来看，无非是以下几种原因或原因的综合。
8.2.1软件总是出问题
　　很多项目从一开始到现场推广是一段痛苦的经历，在推广过程中简直就是软件捉虫记。不断往前进一步，不断发现新的严重影响使用的BUG，导致项目停滞，去解决BUG，往往要耗费大量时间，然后再费尽力气再进一步，再发现BUG，再暂停，再去解决BUG，如此形成一个恶性循环，项目走走停停，周期不断延长，用户失去信心，而且觉得我们工作质量太低，慢慢不相信我们，对我们充满抱怨。
　　软件存在问题是客观的，没有不存在BUG的软件，无非是多少严重程度的问题。这应该是一个理智实施人员开始工作的限定条件：用可能存在BUG的系统解决问题。
　　但是我们往往犯的一个错误，人总是有意识无意识假定软件就应该是没有问题的。无论是用户还是实施人员都有这样的心态。
　　如果软件总是存在BUG，规划在干什么？开发在干什么？测试在干什么？那么多管理流程和制度为什么不能保障？在我们的宣传往往又是稳定可靠的情况下很多人对这些事情就有了一种反感和抵触的情绪，进而认为自己现场工作不顺利，都是公司的错，都是软件的问题，我是无能为力的，出现这样的心态才是最大的问题。
　　其实我们现在已经明确了，软件发现BUG是肯定，这是我们可以预见的项目风险。我们作为一个实际项目控制者，必须采取主动的项目控制对策，才能有效管理项目。
　　这个时候最有效的方法就是加强对软件的验证，根据自己项目业务过程，不断测试，发现是否存在严重问题，并采取相应的对策解决。
　　如果不是严重问题，可以先寻求替代方案(寻求替代方案可以是群策群力的过程)，不影响项目实施进度，然后让公司规划部门将其纳入可接受的版本规划时间，如果公司响应能力不足，我们将要把其作为项目风险提前和用户沟通，寻求支持和理解。
　　如果存在严重问题，肯定影响项目进展，就应该全力在公司推动解决BUG，然后再去现场更合适。
　　否则到了现场问题响应不及时，被用户指责之下非常容易被动，失去对项目的控制权。这个时候实施人员要么只好无原则承诺我们开发会解决来转移自己的压力，然后让公司承担大量开发响应申请，要么只好表示我们一定来解决问题，大量时间在现场推动一些无关重要的细节。
　　真正明智的实施人员一定会自觉花费大量时间做业务流验证，确保项目功能可用够用，能够支撑一个或几个完整业务流，没有重大程序隐患才会去现场推广。
　　在软件某些业务存在极大问题的时候项目团队不应该去现场，而是推动这些问题解决完成才能去现场，去现场时间多少不会成为用户是否认同我们的标准，去了能否解决问题才是用户是否认同我们的最后标准。
　　可以少去不去，但是每次去之前一定很清楚自己能解决什么问题，哪怕是很小的一个问题，解决问题完成培训，落实用户自我计划就可以回来。
　　如果软件发现还有问题却一定要去现场，前提就是你还有其它可选择的业务方案或管理行为要去解决，这些问题可以和发现的问题独立存在，无关紧要。
　　有的实施人员可能抱怨，为什么一定要我在公司推动这些事情，其实这倒未必，一个好的实施人员发现一个项目存在问题，可以及时反应到公司，通过软件配置管理和开发流程解决，但一定要按照配置管理要求把项目情况反映到位，如果反映不清楚才需要到公司协助，多出来的时间就可以多响应一些项目，这样一个实施人员同时响应两到三个项目是很容易做到的。
8.2.2要推广的业务流不完整
很多项目也做了一些验证工作，到了现场随着业务的展开，还是不断发现BUG。这就说明我们并没有建立一套可独立推广的完整的业务流，只能说在项目实施过程中我们只就部分业务流进行了验证，到了现场才发现实际业务情况并非如此，因而又陷入困局。
　　而能否拿出完整的可操作业务流推广方案是项目调研质量紧密结合在一起的，项目调研完成后，一定要可以拿出完整实现的业务流实施思路和方案，这也是自我评判实施调研工作是否完成的一个尺度。如果调研完成了，只有一堆细节信息，却没有完整的业务流框架，这个调研对实施而言就不能算成功，这个阶段工作也就不能算结束，还要花时间搞清楚为止。
　　但我们在调研过程中未必一定要搞清楚所有业务流和实现方案才能往下走，我们可以先解决完一个业务环节再往下走，把企业复杂的业务流程化整为零，形成相对完整的部分，用一个清晰效益目标牵引或做为愿景，促成企业一个业务流程一个业务流程不断前进。
　　但对于单个业务流程而言，配置一定要完整，一定可以看到用这个系统把企业实际中哪一件事情真正走完了，然后还比较方便，甚至是前期不方便，但可以完整实现。
　　如果实施不能得到这样的几个业务流方案，并反复站在用户的角度推想可能存在哪些问题，验证的质量就不会高，也不可能在现场顺利推广。
　　如果每个项目都能做成一个完整业务流，只要有10个成功的项目，软件在很多方面就会达到非常优化好用的状态，再进行推广经验的移植效益将极大发挥。
8.2.3和用户就推广实施方案没有达成一致
　　有的时候，实施工程师也拿出来一些业务实施方案，但一进入推广，用户并不认可，要求按自己的思路来，这样经常是边推广，边争论，然后不断调整推广目标，下面的人就等待观望，我们不得不调整部署，重新开始实施过程，甚至是软件配置和功能验证过程。
　　这样看来有清晰的业务实施方案也未必就能顺利推广，业务推广还必须和用户项目组达成一致意见。要和用户达成一致，并非是某个业务可用不可用，而是我们是否可以找准用户也可以认可的价值点。
　　举一个例子，我们很多项目要求用户入库数据，以方便今后图档的管理和查询。很多用户一实施就不认同，反而要我们上工作流或项目管理。这样就项目推广目标没有达成一致，结果就容易反复，反复后用户可能发现没有基础数据工作流和项目管理也跑不好，最后还是搞基础数据录入，但一上一下的折腾过程中，大部分用户可能已经不看好项目实施。
　　为了让用户认可推广目标对应的业务流，我们往往要想好关于业务价值的说辞，这个说辞推导要有力，而且有数据事实证明，而且有可清晰看到的价值，这样的业务才可能有人跟着走。
　　换句话说，你想让别人做什么事情，一定要有一个可以看得到或者想象得到的效益可期待，否则业务推广目标很难达成一致，即使用户同意按你的思路去做，最终也一定反悔。
　　就以我们说图纸是否可以方便查询是很重要价值点为例，如果仅仅强调这一点用户开始可能还不觉得，一旦录入数据开始就觉得怎么信息化尽是干苦力活？积极性很快就会演变成阻力。
　　所以要推广自己的业务流一定要和用户项目组就推广目标达成一致，达成一致才能快速推广。
　　事实上我们要先和用户分析如果图纸不好找有什么后果？能举几个真实的事例吗？如果好找真的有效益吗？为了这些效益值得我们投入这么大成本去做吗？如果遇到阻力领导会支持我们吗？
　　这些效益和目标经过反复设身处地的换位思考，和用户项目组达成一致了，才能成为项目推广顺利进行创造条件。
　　目标明确了只能说是大方向的事情落实了，和用户项目组要达成一致的事情还包括具体的策略，如何做才能保障这个目标实现？这个思路也要达成一致。
　　还以图档管理为例子，原来的图纸不好找，需要解决，这个目标认同了，不等于事情可以启动了，还要和用户组就如何管理的方案达成一致。
　　那么在系统如何管理图纸呢？我们可以以产品结构建立树状视图，我们可以根据各种特征建立分类视图，我们可以根据阶段建立项目阶段输入输出视图，我们可以根据文件类型建立关联视图等等，这些思路也要先和用户项目组达成一致，让他们觉得这些思路和方案不但能够解决问题，而且以往管理上的一些优点也可以被继承，这样的方案才比较有推动力。
　　管理的思路明确了，如何去做也要考虑清楚，而不是走一步看一步。
　　我们是安排专人录入数据，大家去利用，还是安排每个人都录入一些数据，逐步积累，我们是从新产品开始积累，还是把老产品数据也立即录入系统，我们每个人每天可分配工作时间大概是多少，这个时间段经过培训可以录入的数据量是多少，这样按一周数据录入量计算全部图纸录入完成大概需要多长时间，能否在系统实施可接受周期内，如何保障每个人的数据录入时间，如何组织培训，确保每个人都可以掌握操作。
　　这些工作细节都需要沟通确认，而且计划分解得越详细，执行力越强。因为所有最复杂的事情都变成了很简单很小的独立工作，每个工作完成需要的技能都很单纯、时间很小，在落实时阻力就小。
　　如果思路得到确认，我们就可以和用户项目组一起建立一个计划，落实我们的设想，再发动大家按计划运行。
　　一旦计划确定，要立即行动，我们应按计划高质量完成工作，然后就是催促用户项目组按照计划完成他们的任务，并提供技术支持，这个阶段我们要明确技术支持阶段我们就不需要大面积现场工作，除非有系统不能解决的问题
　　如果用户按计划在执行，我们还需要不断主动了解进度，形成一种进度反馈，根据进度快慢采取适当措施保障项目目标在实施周期内实现。
　　实际上通过和用户就实施方案达成一致，我们也就传授了一个很重要的项目管理套路：认同目标，明确策略，建立计划，立即行动，不断反馈。可以说任何事情只要这样做，就很难失败。
8.2.4没有激发用户的主动性
一般情况下现场推广很多用户认为主要是靠软件公司来落实，的确在很多企业由于体制观念的原因，在这些方面需要软件公司多做很多工作。
　　但实际上一个项目大量依赖软件公司人员推动，这个项目失败概率会比较高，越是成功的项目，用户主动性越强，用户才应该是项目实施的主体。用户自己的项目不是用户自己实施，却要依赖我们实施，这样的项目我们如何成功？
　　我们之所以推广失败往往是我们把自己思路给用户一描述，甚至没有什么描述，就闷头大干，用户不知道如何参与我们工作，只好去监督我们，成为项目的监工，而他们又不清楚系统的思路和实施套路，只能按照领导意图来给我们施加压力，而不是和软件公司一起分担压力，这样进行的项目自然难以受控。所以我们这样做的都是事倍功半的工作。
　　把用户，至少是用户项目组变成可实施的力量，并帮助他们推广实施项目，而不是依赖个人力量推动实施，把他们由项目监工变成项目执行者，我们成为监工和顾问，这样的实施才轻松有趣。
　　让用户真正参与项目实施工作，虽然用户累一些，但大家有了团队的感觉，心情反而更愉快，说个套话：往往在这个阶段和用户建立了战斗的情谊，为今后验收回款参观都奠定了牢固的基础。
　　所以我们在项目推广方案中要反复强调和贯彻这一思路，并得到用户认可，在实际工作中落实，而且用户掌握的技能要清晰写进备忘录，这样就可以请他们中具有相关技能的人去解决问题。
　　例如软件安装，我们可以和用户约定，我只示范装3台，然后安排用户方面的人装3台，我们在旁边看，如果连续三次都成功，我们认为基本上问题不大，其它的都可以交给用户处理，我们只需要处理意外问题。
　　又例如进行某个业务操作培训，我们先要经过讲解示范，确定用户项目组明白，立即请用户项目组操作，确定他们掌握了操作，那么后面的培训可以主动邀请用户项目组成员讲解，我们提供技术咨询，今后培训工作策划组织都可以逐步传授给用户项目成员负责，最后一般问题基本不需要我们出马，大面积基层用户都习惯和自己人交流解决问题，我们只负责解决软件的疑难杂症，而且某个业务被大部分人熟练掌握后，我们的工作主要就是新的业务流推广方案验证设计规划，还有保障项目进度的相关管理活动。
　　这样一轮轮循环，就可以让用户项目组慢慢成为实施的主体，而且在这个过程中用户项目组成员可以得到极大能力成长和进步，他们也会感谢我们的帮助。
　　一到现场工作，任何时候都要确定这个游戏规则：
　　实施推广以项目组为主，我们负责技术支持，负责推广实施能力的传帮带；
　　一旦实施能力转移了，我们并不需要经常来现场工作，因为我们来现场工作成本极高；
　　一般情况下我们只需要在现场解决问题，培训技能，达成后续工作计划，完成本次业务目标就必须返回。
　　我们不能解决问题的时候，我们会全力促成问题解决，一旦解决我们第一时间安排现场响应，但如果我们解决不及时不顺利我们会第一时间通报，也请用户理解支持。
　　不过坦率的说，很多实施工程师本身也不知道如何做这件事情，思路也是乱的，也不会做计划，这样的话去激发用户就缺少个人魅力和行动能力，就只好亲力亲为，被动响应，这个时候为自己能力不足付出代价也是没有办法的事情。
8.2.5光打雷不下雨，缺少高管支持
　　很多时候仅仅和用户项目组达成一致意见还不够，还要和用户高管达成一致。否则在项目遇到阻力的时候，得不到更多资源响应。
　　达成一致的实施方案要给用户高管汇报，汇报要点不在软件功能实现和配置细节，而在于目标是否认同，资源投入计划是否可行，可能会有哪些风险，采取了哪些措施保障，如果出现一些项目阻力，需要提前得到领导哪些授权或政策支持。
　　特别是要向领导汇报取得认同的工作就是，将和信息化相关的基础工作(例如数据录入，业务执行)变成有制度保证的岗位要求和流程要求，这样信息化工作推进才有制度保障。
　　取得高管支持最有效手段是建立和高管的汇报机制，这样才能够让高管清楚知道项目进展和需要给予的支持，项目组成员也会因为可以经常得到高管授权和肯定而努力推动项目。
　　给高管汇报要注意的是，每次汇报应该准备一些积极的内容，值得肯定的内容，的确有进步的内容为好，否则仅仅是诉苦汇报，是不用指望高管对一个无能的团队给予更多的支持的。
8.2.6边界总在变更
有的项目实施过程中，用户不断提出一些新的要求，希望我们能够给予解决。
　　这个时候我们有的实施人员顶不住用户的压力，被迫承诺答应解决，结果就导致项目的边界总在变更，项目目标在一次次变更中不断变形偏离游离，最终模糊不清，项目也就陷入不断开发，不断提出新问题的循环之中。
　　用户提出需求要进行分析，一般用户需求有三种情况：
　　第一种的确是软件规划没有合理解决的问题，而且无法绕过去，或者绕过去对用户项目就没有什么合理的价值了。
　　这类需求在业务调研阶段就要主动思考和确认，在功能内部验证配置业务流时就要发现，并向公司反馈，强力推动解决，不要等到现场推广时让用户去发现，然后再去改，这样可能浪费了好几个月宝贵的时间。
　　第二种是软件易用性和稳定性或者性能方面的问题，但的确有替代方案或者暂时可以接受。
　　对于这些需求我们应该给予解决，但要和用户解释这些需求必须纳入统一版本规划实现，不可能今天提出要求，明天就改好，这样开发管理快是快，但长远可维护性一定很差，所以在功能验证阶段要主动和用户项目组提出项目推广过程中哪些功能可能会产生问题，需要大家提前做好沟通工作和说辞，一旦出现应用者不满意的情况，我们还可以想办法提前打预防针，心里有数的处理疑问，不至于被动响应，甚至自己都没有发现用户提出的缺陷或者种种问题。
　　如果处理得好，在一个长周期项目内(例如半年或者一年)，如果能够提前识别这些需求，纳入规划开发响应，那么最终项目验收的时候这些问题也就比较顺利地得到解决。
　　第三种是用户应用后产生一些新的业务思想，希望也通过计算机加以解决，这些业务需求可能包含很有预见的需求，也可能是灵光一现，也可能是将其它系统需求要求我们系统也加以实现。
　　这类需求对内我们可以反馈给公司相关规划人员去合理讨论，但坚决不能给用户任何承诺，超出合同边界的需求在一个项目中是绝对不可以轻易响应的，否则开个一个口子，就无法拒绝用户各种合理不合理，但都不在本项目边界内的需求，项目也就越做越长，无法收场。
　　这种需求最简单的方法是以合同为准，按合同办事。
　　比较好的处理流程如下：
　　a)先要详细搞清楚用户业务需求到底是什么，核心要解决的问题是什么？很多用户表达的问题和要解决的手段往往是分离的，我们不要把解决问题的手段和问题混淆在一起，另外有时候要解决的问题是因为另一个问题不方便造成的，要先分析清楚；
　　b)和用户项目组沟通协调，确定问题的确存在，且需要解决，且能确定解决的需求；
　　c)和项目经理沟通，判断该问题是否在方案价值点覆盖范围内，而且影响主导业务正常运行，如果是提交需求建议和缺陷报告给公司规划评审；如果不是先要和用户沟通，看其是否愿意作为后续合作内容，或者另外追加费用解决，不和本项目目标混淆在一起；
　　d)如果用户坚持要开发，要及时向公司汇报，并坚决执行公司意志。
8.2.7做人不好
　　有的项目存在严重人员沟通问题，用户对我们不放心，宁可把我们关在现场不回来，生怕我们走了不再来了。
　　这种原因就是实施人员没有建立足够诚信，往往是一个阶段工作没有做完，没有确定到应完成的里程碑点，就不得不做其它工作，甚至就是不够认真负责，敷衍了事。
　　用户听信实施人员下次来解决问题的承诺回家，结果实施人员在多个项目现场奔波中并没有投入精力解决软件问题，或者促进公司解决问题，下次不得不被迫过来又没有真正解决问题，用户并不满意。
　　有的时候调度周转不灵，版本发布推迟，用户不能看到我们按计划兑现承诺，也会不相信我们的工作，采取要求派人现场长期遵点解决的要求。
　　其实如果问题不能解决，遵点是没有用的，如果问题能够解决，往往是双方沟通协调后在软件公司先解决然后再到现场解决的，软件公司资源一般都很紧张，将人压在现场，几乎让自己问题陷入无人催动的境地。
　　所以我们一定要做好最坏的打算，和用户慎重承诺，说到做到，有问题全力保障问题及时解决，给用户两个印象，第一我们很认真守信，第二我们时间珍贵，我们每次只能解决关键问题，实施还是靠用户自己解决。
8.3现场推广工作如何才能做好？
作好现场推广工作关键在于前期各项工作质量。
8.3.1第一要组织高质量的业务调研
　　业务调研阶段在产品比较熟悉的情况下，可以边调研边建立原型测试，这样在现场调研时对可推广业务设计和验证，构思业务流程操作手册，数据规范手册和各种样例，到了真正推广的时候思路早就经过反复推敲，非常可靠；
8.3.2第二要对关键用户组织成功的培训
　　培训就是让用户自我进行推广，我们软件公司协助配合，要相信用户的积极性，主动性和能力，要不断激发他们在这些方面的潜力。
　　a)从一开始到现场工作就要反复安排大量精心组织的培训活动，让用户理解我们的思路；
　　b)项目解决方案或思路一定要组织各种类型会议在现场反复讲解，达成一致，非常关键问题不要回避或模糊化，例如产品管理的思路。但一些技术细节可以淡化，例如表格格式或者汇总时一些小要求，不要纠缠这些细节；
　　c)培训的时候在操作上应该准备实例化的内容，应该让主导用户操作后自我评价掌握程度，直到熟悉为止；
　　d)培训思路站在业务流的高度规划，让用户相信你对他们业务理解和描述非常准确到位，打消用户顾虑忧。
8.3.3第三要提前做充分的内部业务验证
　　内部业务验证一定要自己亲手测试，而不是等测试部门结论。
　　因为我们通过业务验证推导我们业务流程实施思路是否可行的过程，这个工作别人是无法取代的。
　　测试部门只能按照功能验证，不能按照业务验证，可能有一些业务上操作瓶颈无法覆盖，但我们到现场用户一定会发现，因此造成用户满意度下降，进而要返工开发，导致公司管理成本上升。
　　而且验证过程中我们要发现软件是否有易用性，性能和功能上问题，要尽快提供给公司相关部门，直到寻求到替代解决方案或者列入可接受的版本实现计划中，这样才能保证在现场出现任何我们心中有数，即使是承诺可实现周期也比较有底，不会乱跳水。
　　此外作为项目经理和实施工程师必须对自己拿到现场实施产品功能了如指掌才能说是在业务上合格，不可能想象一个对新功能，新版本不熟悉的人去现场指导用户实施；这个只能通过内部验证来保证操作熟练程度，以及准备新功能培训教材和升级数据等相关指导教材。
　　在内部验证不是要让产品没有缺陷才能去现场，而是通过自己验证充分评估产品对主要业务线的支持程度，有多少是可以通过沟通克服的，有多少是无法克服的，必须解决后才能去现场的，有多少是必须解决但可以暂时忍受的。并及时和规划开发沟通，达成一致的解决意见，才有面对用户的智慧。
　　最终做到在现场用户发现缺陷之前，我们心中有底，有对策，有替代方案，可以承诺用户我们大致解决时间，并按时间兑现，进而建立用户对我们来现场工作的期待感和信任感，而不是抱怨我们拿着有问题的版本来，只会引发新的麻烦，进而导致项目失控。
8.3.4第四要做现场验证。
　　现场验证就是让用户项目组充分评估新版本的好处和不足之处，确定是否升级，一旦升级出现用户不满就可以事先采取对策克服，而不是到处救火；
　　如果验证结论是不能满足要求，就千万别到处装机推广，那是自寻死路，宁可回去改好再来，也不能强行压。
　　现场验证过程也就完成对用户的培训，让用户项目组承担起实施责任，软件功能是否满足要求是软件商的责任，通过验证实施就是用户的责任，这个工作要做得好还需要建立和用户项目组充分信任的关系。
　　所以现场验证要做好推广风险评估，提前采取对策，此外要找到用户实施推动人，协助他们推广项目，最后验证通过给领导汇报，取得支持，召开项目推广启动会，这个时候再进行推广工作就很容易了。
8.3.5选择适当的推广边界
　　一般情况下推广应用要考虑解决完一个业务环节再往下走，把繁复的企业业务化整为零，设计为相对完整的几个部分，一个部分一个部分实现。
　　而且每个部分一定要有一个清晰效益牵引或做愿景，这样大家才有跟随实施的信心和热情，并在一个台阶达到以后，再上一个台阶，逐步扩大应用范围，每个阶段实施难度实际上就降低了。
　　记住：只要某个业务流用起来了，往往就可以验收了，此时项目推广内容和合同边界未必等同。
8.3.6建立和用户的个人友情
　　为了推广顺利实施人员也可以和用户一起吃饭娱乐，增进感情，也是有效的团队建立策略。
　　当然建立友情未必就是靠请客吃饭造就的，请客吃饭一般不会建立深厚的友情，友情是项目中同甘共苦中建立的。

9如何做项目验收?
9.1验收工作应如何组织？
实施项目最快乐的事情就是项目验收，可是经常是没完没了的信息化，不见不散的项目组，验收之路何其漫漫。
　　我在整个项目经理技巧中都反复强调任何工作达到成效，并不在一时一地事情做到位，而是在平时工作积累中将事情细节做完善，做到位，很多想要的结果就自然达到了。
　　项目验收就是我们最想要达到的结果，一旦项目验收对很多人还意味着一件现实的事情就是，我们可以回款了，可以获得项目提成收入了，同样项目验收也是一系列细致工作完成到位的结果，而不是某个点的成功或者个人能力就可以促成的事情。一个项目的验收，未必是一次性活动，而是由一系列验收准备工作组成的，在最终验收之前，我们已经将很多阶段工作细化并得到认可执行，项目验收就是一个水到渠成的事情。
　　下面我们就一起讨论一下如何进行项目验收。
9.1.1项目验收的条件
　　很多人会奇怪，这个问题还需要谈吗，肯定是按照合同和技术协议验收。
　　其实在业内目前项目合同和技术协议现状是一个项目，不管金额大小，个性化开发多少，软件功能模块，几乎是一个不少，用户要求我们承诺的服务内容也是一个不少，供应商在竞争压力下的营销过渡承诺很难完全避免杜绝，如果要以完成合同和技术协议为标准进行验收，业内的大部分项目个人以为达到预期要求的可能非常之少。
　　当然这和技术协议架构方式有关，一般最开始技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。
　　这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多的体现了软件商的自我保护。
　　实际运做时无论技术协议多细致，对用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在运做，并以此作为检验我们项目是否可以验收的标准，当然有的项目可以通过商务运做，在业务实现不太好的情况下也能验收。
　　所以现在一般的模式管理软件项目是按照服务内容分几个业务目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。
　　所以项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。
　　这些基本业务面是不是很简单，或者是不是很稳定，或者人员是不是一定全部都上线，或者业务面上功能是否存在可改进功能都不一定，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以了。
9.1.2确定里程碑
　　我们现在知道如果要真做好一个项目，完成项目验收条件，是以业务是否可用为考量角度。不是一定得实现所有用户的需求，也不是只有将一些所谓的技术难点解决用户就可以用起来并验收，而是我们可以完成一定的阶段应用业务目标。
　　所以要想成功验收，不是我们什么都承诺，什么技术问题都实现项目才能做好，而是和用户沟通，代表公司和用户就项目业务实施目标达成一致。
　　因此我们从进行业务调研的时候就要主动控制项目的业务边界，将一个一个业务流根据企业实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。
　　在中国管理软件售前工作和用户还无法建立长期合作关系，面对不是很成熟的用户和疯狂的竞争对手，我们在生存压力下可以先和用户建立合作关系，一旦能合作，就相对容易和用户建立信任关系，有了信任就可以慢慢教育用户，用户一旦理解很多事情的复杂性不是软件单方面可以控制的，反而会理性地和我们一起解决问题。
　　因此我们要相信用户是理性的，他一定会坐下来和我们一起谈：那到底怎样解决问题呢？最终可以达成合理的结果，然后我们全力去冲刺每个里程碑。
　　里程碑的好处第一是将复杂的业务目标分解为一系列简单的目标，即降低了难度，又使每个阶段实施重点突出，精力集中在一点上，自然可以更有效解决问题。第二里程碑界定目标包含了一个一个相对独立应用台阶，可以促进用户项目一个台阶一个台阶往上走，用户只要达到了一个里程碑，项目在这个业务实现台阶上就可以进入不可逆转的状态，不会走走停停，经常从头开始。
　　在具体项目中，这些里程碑内容都可以设计，在每个项目中成功设计里程碑的关键就是最小化项目边界，然后和用户高管和中层干部，甚至在某些项目上还要和基层达成一致。
　　我们控制边界的前提是我们自己要有可置换的因素，这就是用价值换边界。
　　我们必须在深刻了解用户业务基础上提出我们的业务目标，阐明项目价值所在，让用户接受业务目标，并按照这个业务目标去实施，而不是纠缠在有什么功能没有什么功能。
　　功能很重要，但考虑用功能如何支撑业务流程更重要。
　　所以一个人在项目中最大的力量往往源自对业务深刻而理性的把握。
　　成功项目验收的核心就是边界的确定。
　　没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。
　　很多人希望通过详细解决方案来定义项目要实现的内容和业务目标，这是很有必要的，但解决方案得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与解决方案思路思考，变成用户自己推导出来的业务实施目标，未来才不容易变形。
　　因此我们建议在确定里程碑的时候和不同层面人员大量沟通目标，确定达成一致，在产品比较成熟的情况下，能否就项目边界达成一致是最关键的工作，一旦这个目标达成，就很容易制定计划执行和落实。
　　确定每个里程碑后续工作可以参考下面的标准流程。
9.1.3主动沟通
一般项目业务目标清晰后，就可以按照业务目标分解相应工作，逐步落实，在落实过程中有一个很重要的工作是很多实施人员会忽视的，就是主动沟通。
　　项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持？和中层如何就业务目标不断确认，逐步清晰？和基层如何就项目应用操作模式达成一致，持续改进？都需要通过沟通反馈完成。
　　沟通的作用对于高管是让他们清楚我们一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的话，第一个好处高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备象我们所说进展，这样一旦认可了各个阶段目标后，最终要求高管签字结项也就顺理成章。
　　第二个会哭的孩子有奶吃，一把手工程核心就是高管支持项目运行，而做到这一点关键就是通过合理汇报让高管对一个逐步前进的工作进行业绩的承认，高管一旦认为某个事情比较容易成功了，反而容易追加资源保障完成，这就是信息化的：“马太效应”。
　　一个工作高管经常性不知道进展，怎么会支持呢？当然谁去汇报可以在项目中界定是企业还是我们软件实施商，但一定要和高管主动汇报。
　　给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。
　　中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。
　　要达到项目的目标没有中层的配合也是非常困难的，和中层的沟通往往是不断动态调整项目目标，逐步清晰化项目目标和细节的过程。
　　往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。
　　和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候我们往往发现很多用户真的是非常可爱，尽管软件还有很多值得改进的地方，但他们一旦认可我们团队，反而会尽心尽力帮助我们推动。
　　个人以为一般在项目中要坚持每个月到一个半月写一份详尽《情况简报》，分别通报企业项目负责人，部门负责人，项目组成员。
　　《情况简报》应先发邮件，然后一定电话落实收到并口头简要汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证企业各方面负责人对项目进展做到心中有数。
　　另外实施工程师无论是否在现场，保证每周至少和操作用户、系统管理员沟通一次，主动和用户接触，不要等到用户有问题再来找我们解决。
　　这样反而可以逐步释放用户一些火气，真要救火的时候我们反而有一些从容周转的时间，一回生，二回熟，到了验收的时候也好说话。
9.1.4写好备忘录
在一个漫长项目周期中，很多工作做了也就做了，认可了也就认可了，时间一长也就忘记了很多承诺和约定，到了验收的时候就翻出来重新要，这种事情很多人可能都经历过，明明说得可以先不做的内容最终验收的时候又成了必要条件。
　　所以在一个项目中要顺利验收，一定要写好备忘录，把平时项目过程中重要阶段点双方达成的共识详细记录下来，以备查询。
　　项目组在每次现场工作都必须要写备忘录，备忘录必须注明现场工作天数，按时间段写清楚工作内容，性质和时间长度。
　　例如培训工作要写清楚培训人员名称，培训内容，培训小时数，培训掌握效果；
　　例如装机工作要写清楚装机软件，装机台数，是否可正常使用等等细节。
　　每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行，保障项目在每次工作基础上不断前进，并用备忘录约束双方的行为。
　　备忘录标准的写法是先简要汇报阶段工作中内容，要用积极肯定性的文字给自己前一段工作或者一些提法给出正面结论，这样大家看了才有信心。
　　这个工作内容往往是上一阶段约定要解决的内容，而且在这次现场工作中得到解决的内容，要考虑和上一次备忘录约定工作内容的呼应，很多人写备忘录，纯粹是为了备忘而备忘，备忘录三大功能，第一是备忘，第二是缴功，第三是约定后续工作安排，推动事情继续前进。
　　所以写备忘录首先要讲上一次我们约定什么工作，这次是否完成，完成质量如何，没有完成是什么原因造成的，是否纳入下一次解决的内容，这样的文档才有体系，也能体现出一个人整个项目过程中的脉络，否则写这么多备忘有什么用？
　　结论出来后后备忘录要详细描述自己所做工作细节，细节越详细越好，让项目组彼此认可工作内容和质量，而且对服务工作量可以有一个客观的评估。
　　而且在写备忘录时发现自己大量时间并非在有效沟通或者在推动项目实施上，那么意味着项目已经是在失去控制路上，应该立即引起警觉并采取措施解决。
　　备忘录最后还要约定下一阶段双方工作安排，在后续工作中严格按照备忘录设计自己的工作计划，了解企业项目组进展，如果企业项目组方面配合出现问题，在下次备忘录中要明确指出责任承担方，给用户形成一定的压力，从而更好推动项目走向前进。
　　一些重要的项目目标约定或者验收意见可以单独写备忘录，在最终验收时可以作为依据。
　　这样一个备忘录一个脚印推动项目向目标前进，每个备忘录都在前一阶段工作上有一点点进步，最终项目验收就是水到渠成的事情。
　　除了实施备忘录外，实施人员最好给每天工作做详细记录，实施备忘录个人认为只是一个工作进度大概描述，而且可能会有水分，因而需要有一个每天工作的详细记录用于自己或者团队成员准确把握项目脉搏，及时发现问题，个人也能随时做项目回顾，用户的反复也能随时记录在案，如果出现项目延误，也能有理有节和用