超越对手——软件项目经理的18种实用技能（精编版）

1、介绍公司有三点一定要讲到：业务讲到 ：要让客户清楚我们能为您提供什么，做什么，如何合作。实力谈到 ：要让客户明白和我们合作为什么可以放心。案例说到 ：要让客户知道我们不是在说大话，有很多用户和我们一起取得了成功，并有案可查。只有和客户建立长期屡次接触时机才能创造时机了解客户需求，拥有可能让客户逐渐认可公司的实力和能力的时机。越是要做大工程，越是要让别人觉得你是一个值得交的朋友，而不是一个销售经理，所以未必要急于马上或者长篇大论介绍公司，要巧妙用自己推销公司，用公司推销自己。案例小李好不容易争取到一个潜在客户同意见面的时机，客户在谈话过程中想请小李介绍一下了解他们公司是做什么软件的，能解决什么问

2、题。小李觉得这是一个激发客户购置兴趣的时机，就请允许客户给他10分钟时间，他借机把公司和产品做了全面介绍，结果滔滔不绝讲了 20 分钟，最后留下一份精美公司数据给客户。请问小李这样做对吗？点评：象上例的小李可以在客户提出介绍要求时先感谢客户的关注，再用很简短时间23 分钟介绍公司和产品，主要是说明企业有哪方面的业务问题是可以考虑上我们的软件系统，这个过程中最重要的是判断客户这里是否存在工程时机预算，如果有工程那么应该考虑建议客户安排时间做更长的交流或者业务沟通的时机，在客户不愿意配合的情况下必须制造再次接触的理由。 例如这次成心送一份简单的数据，下次再送一份更精美的公司资料上门创造更多接触时机

3、。如果没有工程就和客户约定保持良性沟通方式，确保客户想上工程的时候想起通知我们的公司就可以了，不应该耽误客户太多时间，更没必要发送精美公司介绍材料浪费本钱；除非客户真有兴趣，业务人员恰好也有多余时间，那可以多谈一谈，更深入了解情况。案例小李开始一个正式介绍时，才讲了五分钟，客户有人打断他的发言，说我们想看一些实际的内容， 公司介绍还有一些虚的概念理念就不要讲了，你演示下软件让我们看看怎样解决我们实际问题。请问小李这时该怎样做？点评：如果事先有产品演示的准备，此时小李可马上表示： “我接受企业的意见，但与会还有人好象从来没有见过，因此请企业给我们五分钟用最短时间让我们介绍完公司，然后马上进入技术

4、交流，好吗？，这样企业一般不会反对。在这段介绍公司时间内注意讲要点和一些案例应用，同时快速根据大家对一些应用案例反响重新再组织一次自己产品演示思路。经过一个简短精练、着重强化公司专业地位的介绍后，配合的技术人员也可以很顺利地进入演示状态，效果自然很不错。如果介绍前完全没有意识到客户会要求演示，并做好相应的预案准备，这次演示效果很难做到有效， 只能尽量要求安排专门时间演示，强调这次约定的公司交流，不过可以先把产品简单沟通一下，留下转圜的伏笔。此外也可以说管理软件是个系统，很难简单通过操作来演示，一般管理软件也是重点谈解决问题思路， 而不进行具体接口操作，不过我们可以结合一些企业问题和案例介绍我们

5、是如何做的，解决问题过程和方法是什么，大家觉得这样可以吗？整个过程重在不慌不忙，沉着有序应对，给客户一个专业沉稳的印象。一般客户对软件公司是很好奇的，又不生产物质产品，很难和其产品线比拟，因此没有什么考察经验可以参照。要通过介绍让用户留下深刻印象并不容易，在总部介绍公司有“三讲 窍门。讲故事不要呆板的介绍公司，而是要讲故创业事。例如我们谈公司人数可以请用户看老照片，结合老照片讲公司创业艰辛到开展壮大历程，边讲边和客户互动，看着老照片， 听着软件人创业的故事，客户就容易从心理上接受这个朴实认真的公司了。讲特色特色主要指软件管理和业务上的特点。一般管理上特色是结合组织机构介绍进行的，要给客户生动介

6、绍公司的组织机构，介绍人可以和企业采用比方的方法，讲软件研发部就和客户比方成企业的生产车间，到测试组就和客户比方成企业的质检车间，这样企业就很快明白组织结构的作用和价值了。业务特点是请客户看软件研发工具，例如请他们看源代码管理工具，看平安保密工具，请他们看软件自动测试工具，这些是客户很少见到，但见到后又很容易认可软件公司标准可靠的细节管理，而且有新鲜感。讲文化在给客户在公司做介绍，不仅仅要介绍公司经历和管理特色，还要通过这些内容突出我们公司文化价值观，形成和客户的共鸣。售前调研的目的让客户认为调研者有足够能力了解企业业务流程问题所在和设计解决之道。要随时给竞争对手制造门坎，了解竞争对手给我们设

7、计的门坎。调研获得的信息足够让后续工作开展。售前调研和售后调研的不同售前调研一般是为产品演示，技术交流做准备，同时在调研过程要注意突出自己强项，给竞争对手制造门坎。售后调研一般是为解决方案，工程实施做准备，同时调研过程中要注意寻求工程价值点，利用价值点置换工程边界，尽量把工程边界最小化，工程才容易受控和成功。售前调研一般没有确定正式合作伙伴，客户不太愿意配合，也不愿意投入太多时间精力。售后调研有合同和目标约束，企业一般会花大力气配合启动。售前调研一般由商务和客户协商时机，商务人员根据实际情况和客户协商确定是否需要调研，是先交流再调研还是先调研再交流，是在竞争对手之前调研还是之后调研。售后调研在

8、合同签定后必须尽快启动，而且应该在工程启动大会前后趁热打铁展开调研。售前调研一般由于时机难以把握，不可控制因素太多，往往突发性强， 客户也无法有足够精力和供货商沟通，因此对工作方案性要求不高，即使有方案安排更多也是形式上意义。售后调研用户比拟关注过程标准性，对工作方案性要求比拟严格。售前调研一般要协助商务攻关，所以不能轻易在现场不慎重地发表对业务或技术问题倾向性看法，要深入了解事实，策略性表达对问题的认识。售后调研可以相对直接提出问题，摆事实， 陈厉害，争取最大范围重视，进而获得管理支持。售前调研一般很难见到企业高层，接触形式有限， 时间有限， 也不可能获得管理层明示支持。售后调研前一般要和企

9、业高管紧密接触，取得支持， 可利用企业管理层力量要求企业人员配合进行。售前调研结束后不一定需要给企业留下调研记录，往往是通过其它方式 交流，演示，方案来验证调研质量。售后调研每个阶段结束应有标准文文件记录每天调研工作，通过过程文文件来审核工作质量。案例客户经理小李向公司申请咨询参谋来一个重要客户现场调研，但公司比拟好的参谋近期都有任务不能响应，但可以派一个经验不太丰富的参谋来配合小李，小李申请这个调研时机很不容易， 而且客户工程快接近选型确认，不立即进行调研很可能导致后面工作被动，这个时候他该什么办？点评：越是重要客户，时间压力大的售前调研越要想方法争取有足够经验的人去现场工作，不能用经验缺乏

10、的人去完成所谓这项工作。没有经验的人在现场呆得越久越耽误在现场做工作的时机。如果难以协调到适宜的人，安排一个水平缺乏的人员先去调研，这种人往往只能按照公司提供的模板找一些人，问一些问题， 不可能在很短时间内抓住企业的关注点，提出的问题都很概念化和范本化，这样的调研质量很难让客户建立我们和竞争对手差异化区分。因此小李应该和客户沟通，说明申请一个好的参谋调研对工程成功是非常重要也是负责任的表达， 争取客户理解并调整调研时间，如果客户时间实在不能调整，就必须根据工程重要性确保公司安排高水平参谋到现场工作，哪怕时间短一点或牺牲其它不重要的工程。此外小李下次和客户约定调研时间时，一定要在内部先和参谋沟通

11、时间行程安排，这样才能从根本上提前预防这类工作冲突。售前阶段不要轻易提供解决方案。解决方案难写在哪里？没有体系没有个性没有素材没有时间不好的解决方案十个特点只有厚度，没有质量只有论点，没有论证结构不清晰业务解决方案成为功能列表口语书面语混杂，遣词造句不严谨。没有认真检查，存在大量硬伤。过于突出自我没有表达公司产品最新进展文字太多，图表很少没有评审方案检查清单共61项序号检查项审查人整改意见1.是否用企业 logo 和产品设计有冲击力的封面和封底？可填写无整改项让步通过项 1、2、需整改项1、2、2.封面方案提交日期是否正确？3.封面提供的公司位址、联系方式、邮件是否正确合理？4.offices

12、文文件属性是否填写正确？5.目录是否超过5层？是否存在排版不清晰？6.目录是否未刷新？是否有“未定义标签页的错误？7.页眉是否和正文内容及单位一致？8.是否存在正文和首页页眉不一致？9.页脚的页码是否存在封面，目录，正文排序不一致？10.是否存在不连续页码？文档分多份时是否页码要衔接一致？11.标题是否采用自动编号方式产生？编号是否和章节对应一致？12.同级标题是否格式一致字体， 字体大小，段前段后行距，行间距且符合公司标准要求？13.正文中是否有无意义空行，孤行？14.正文段落是否是否格式一致字体，字体大小，段前段后行距，行间距且符合公司标准要求？15.正文字符字体、数字字体设置是否和汉字字

13、体不协调，前后不统一？二零零年的零字是否格式正确？16.正文标点，特别是逗号是否全半角一致？17.正文中图片排列位置是否合理？18.文文件图片是否有标题，且标题采用自动编号方式产生？是否在图片下方？19.接口图片是否把桌面任务栏也抓屏，或者带拼音输入法等和接口无关内容？20.图片格式是否全部统一？21.图片大小是否存在不合理的裁减？例如大面积空白区域的软件接口应加以裁减保存主要内容？22.图片中文字描述局部是否出现和企业方案内容不一致的地方？23.文文件图片是否大量存在绘制风格不统一的地方？例如word 、visio 、图片、接口混合24.正文中表格是否出现一个表格分页断开格式？25.表格格式

14、是否统一或协调？26.文文件表格是否有标题，且标题采用自动编号方式产生？是否在表格上方？27.正文中是否有错别字？28.正文中是否存在过于口语化内容？29.企业称呼在文档中是否一致？30.企业称呼是否和其正式资料一致正确无误？31.从模板复制的企业名称是否替换完毕，且正确无误？今后制作范本文文件可替换局部应用域管理32.正文对工程产品描述是否局部用软件名称称呼，局部用企业工程名称称呼等不协调的地方？高 级 功能审查33.正文中是否大量出现软件公司，软件公司产品等无意义自我宣传的词语？高 级 功能审查34.正文中是否出现说客户存在严重的问题，业务失控等一类暗示企业管理水平缺乏的表达方式？高 级

15、功能审查35.客户关注的核心问题在正文中是否专门列醒目章节给予答复？高 级 功能审查36.业务解决方案是否只是软件功能和思路的列表，没有表达出对企业业务特色的支持？高 级 功能审查37.是否出现类似表达文字描述在局部章节反复出现的问题？高 级 功能审查38.是否列入一些企业根本不关注的功能，或者过多描述一些企业不关注的功能？高 级 功能审查39.方案中功能描述是否只是简单复制历史方案模板，复制软件界面？高 级 功能审查40.软件架构局部技术方案内容是否感觉过于抽象，没有清晰图表配合说明？术语过多，和正文解决方案没有逻辑关系？高 级 功能审查41.软件设计思想、架构等内容和公司标准文档不一致？高

16、 级 功能审查42.实施方案中实施团队图是否引用过期结构？高 级 功能审查43.实施方案中实施结构图和未来实施人员承诺是否得到商务和实施团队认可？高 级 功能审查44.实施方案中实施周期和里程碑是否得到商务认可？高 级 功能审查45.有无清晰明了针对性强的配合实施方案的实施部署过程介绍？高 级 功能审查好的方案应该设计一个好的封面，好封面的标准就是有视觉冲击力。建议书的要求是简短紧凑，内容详实，目标规划清楚，便于客户高层决策，可以在一份建议书中形成几个可选技术方案，推动客户高管决策。实施方案的要害是具不具备可操作性。这里面判断方法就是实施方案越是结合业务细化越具有可操作性。投标书一定要坚决按照

17、客户提供的招标书要求准备，客户如何要求就如何提供数据，不要任意发挥。演讲更侧重对某一个问题看法的陈述，主要是交换观点，允许争鸣，听众可以不同意你的观点， 但一定要保卫你发言的权利。除了常见的演讲比赛外，很多时候演讲者是受邀请，以一种被尊重状态出场， 是处于一种比拟沉着的心态下开始的。演讲的过程一般也是比拟连续，不会被随意打断的。辩论更侧重对话双方的交互，具有很强的考核目的，通过对辩论问题的反响，辩论主持方来主动判断他想获取的信息可靠程度。辩论的过程一般是不连续的，随时都可以中断响应不同的问题，辩论的节奏和压力也更为紧张，时间非常紧凑。培训更侧重于传授操作，此时被培训者已经认可培训者所在公司和产

18、品，在过程中更多的是教学相长，形式可以多种多样，根据不同培训层次灵活组织。演示不然，演示是有极强的目的性。演示往往是要求在有限的时间内但比辩论要舒展 ，面对一群不同心态或者不明心态的人，快速地把自己所在公司、公司产品和效劳，包括自己最大范围推销出去。演示过程中还要随时准备开始各种技术辩论，应付各种刁难。 演示是追求主动影响客户用户的过程， 售前演示也是主动和竞争对手竞争的过程，演示更是个人魅力展现的过程。整个演示就是一场复杂的脑力游戏，看看我们有什么方法在短短1到2个小时内更能抓住客户的心！售前演示的目的?介绍公司，通过自己的言行和产品介绍展示公司的形象；?强化自己的优势，给竞争对手设置一定的

19、进入门坎；?分析自己能为客户做什么，解决什么问题， 愈是客户关心的问题愈要主动沟通和交流，让客户对软件产品技术和实施能力放心；?进一步判断客户关注的工程重难点，了解我们前期准备的缺乏，采取针对性后续行动。售后演示的目的?详细介绍公司和产品，让广阔具体用户认可产品，取得最大范围业务认同，减少实施阻力；?宣讲对企业问题的认识，提出自己的业务解决思路，主动控制工程边界；?通过现场互动进一步判断客户关注的价值点是否在工程边界内，确认是否要调整工程边界，尽快回馈给实施团队或公司决策案例咨询参谋小李和客户经理一起首次拜访了一个客户，并应客户交流做了一个感觉不错的产品演示，企业也表示出很大兴趣。过了很久小李

20、听说客户后来选择了另一家产品和能力都不如自己公司的供货商，为什么会这样呢？点评：大局部客户一开始并不了解管理软件的全部概念内涵，并对自己的业务需求也没有清晰化认识， 往往在经过供货商多轮技术攻关后，客户才能比拟清楚一些理论概念和自己的业务需求之间的关系，才能逐渐看懂产品演示，此时的产品演示也能到达目的。过早的演示往往是对客户进行启蒙式教育。一个共同的经验是，企业对于自己完全不理解的事情， 无论演示者水平如何出色，总体效果不会太好；对自己有足够了解的事情，即使演示者水平一般，企业还是能听懂个七八分。很多客户经理其实缺乏销售管理软件的经验和沉着自信的心态。因此当发现一个工程需求信息后，他们要么被动

21、地随着客户要求走，要么就过于积极主动创造调研和演示的时机，期望通过一次良好的演示或者用户考察到达商务成功的目的。实际上一个周期很长的管理软件工程匆匆忙忙去调研演示，效果往往不好，反而造成工作被动。 在需要长期跟踪的工程上，往往是早起的鸟儿没虫吃。因此演示最好在充分了解客户关注点的情况下开始，而且要充分考虑如何应对竞争对手的效果最正确。过早演示往往是一个无用的商务活动，还会为后续工作制造麻烦。在大工程上是不会有太多的演示时机的，特别是在多竞争对手的情况下，宁可等到演示筹划确定和准备就绪后，才和客户预约， 哪怕耽误一些时间也不用担忧，只要给客户解释清楚，客户一般都会理解的。不要怕耽误一个月两个月时

22、间，管理软件工程不在于跟进时间长短，而在于能否准确定位客户心理需求并给予良好解释。当然那些客户经理自己都没有跟踪，主动找上门来的紧急客户工程例外。充分利用信息不对称为什么存在技术交流呢？就是因为在it管理系统和应用企业之间存在着严重的信息不对称。技术交流的诀窍就是如何有效利用信息不对称的空间去交流。信息不对称就是利用大家对全力配合和目标定义的理解不同，让工程可以先进行下去，如果直接告诉客户需求不合理，可能会导致很严重后果直接出局的情况下，可以考虑先策略性进行回复，以期获得再次沟通或合作的时机。但在取得时机后，一定要在后续沟通中逐步引导客户意识到这些目标的不合理性，逐步把工程往客观的方向靠近。利

23、用信息不对称并不是利用客户对行业和产品的不了解去欺骗客户，说服他们购置，然后让客户感觉到上当受骗。好的技术交流从理论上应该是针对客户的疑惑，依据业务现状和管理常识来解答，帮助客户得到一个合情合理，客观真实的解答。现在越来越多的用户趋于理性，只有用真诚的心态去交流，才能取得客户的信任和尊重。案例咨询参谋小李和客户经理一起参加一个客户技术交流，这个工程参加对手不少，小李他们是比拟晚才进来的，客户告诉好几家供货商表示能够实现某功能和在三个月内完成实施，询问小李他们是否也能做到？小李认为这个工程实施难度很大，在三个月完成非常困难，至少要六个月时间，这个时候他该怎样答复客户呢？点评：一个咨询参谋必须认识

24、到目前在中国大局部工程上还多少都存在过度承诺，或者滥用信息不对称进行目的性很强的商业暗示的做法。在工程中经常碰到客户要求供货商承诺做目前无法做到的功能，这种情况是非常难应对的局面，说能做好似是撒谎，说不能做好似是示弱，可能直接导致出局。有的工程对某些技术条件是硬性条款，拒绝就等于放弃。有一些客户提出的要求本身就不具备合理性，例如有的客户要求无论出现怎么情况工程实施必须保证百分之百成功，有的客户要求工程实施周期必须在三个月内搞定，这些都是典型的不合理需求。对不合理的技术要求，可以明白告诉客户“有所为，有所不为的原那么，争取深入沟通、了解这些不合理的技术要求到底是为了解决什么问题，这些问题是由哪些

25、更根本的原因造成的，是否存在其它合理的解决手段。如果是涉及实施周期问题，一般按实际需要理想周期介绍，如果客户对周期非常敏感，可以讲只要企业全力配合，合理定义工程目标，是可以在三个月内做到出成绩的。其实大局部客户经过一段时间合作后都会趋于理性，可以接受工程边界和软件功能的调整，特别是真正进入合作后，谁也不愿意做一个没有成效但到处过度承诺的系统。如果大家都是追求成功，就一定能找到合理的妥协之道。针对客户中不同性格的人，交流也要注意策略：表现型的人要多让其发挥，我们只要因势利导即可，争取他认同我们的理念，并宣传他认同的观点；对于控制型的人，我们要想一切方法让他认同我们专业性和灵活性，用比拟恭敬的态度

26、让其觉得利益上不会受到伤害；对于友善型的人，我们一开始就要敢于宣讲，让其觉得我们的气势是建立在充分自信之上的；对于分析型的人，这种人在技术交流时是最危险的，注意谨慎小心，言多必失的道理，话不在多，在于精确可验证。针对感情上倾向支持自己的人，技术交流的目标是巧妙为其提供说法和炮弹以从内部打击对手；对于感情上中立的人，技术交流的目标是说服其成为支持我们的人，至少是无偏向的人；对于倾向于支持对手的人，技术交流的目标是让其在心理上对对手的技术难点和实施能力患得患失，最后可能在压力下成为骑墙派。对于想法特别多，思维跳跃的人，要冷静分析其想法的合理性，对客户想法和自己想法的矛盾之处做出合理解释，并提出自己

27、的处理意见，否那么很容易陷入一种被动响应的局面，成为客户引导软件供货商的局面。对于没有需求的人，技术交流不要谈功能细节，要更多帮助其建立业务能力信任，甚至是个人魅力信任，有了信任，自然能判断出有什么需求可以帮助其解决。对关注细节的人，要主动谈理念，让他感觉到高度；对关注理念的人，要主动谈操作，让他感觉到理念在细节层面上已经落实。对关注技术的人，要主动谈实施，让他意识到管理系统并非是一个技术决定的系统；对关注实施的人，要主动谈技术，让他意识到没有良好技术根底保障，仅仅空谈实施方法也是无用的。公司考察接待往往注意大的安排，但对细节落实关注不够，给客户留下不好的印象。常见的考察细节错误举例：1、没有

28、通盘考虑每个行程的时间开销，及时通知每个活动负责人提前准备，按时启动，导致很多行程因为节奏拖沓被拉长，很多方案内重要交流内容被迫缩短，或者难以到达质量。在接待时， 有经验的人应该预见到可能哪些环节要留足够时间余量，哪些环节可以挤出一些弹性时间，保证整体方案按进度来。2、只注意安排有车接，没有注意告诉司机有几个人和多少行李安排车过小，没有落实到具体司机， 没有留司机联系方式，没有确认司机是否按时发车特别是接早班火车或晚班晚点飞机时 ；3、住宿安排没有考虑客户报销要求，安排宾馆过贵或者票据不符合报销标准，客户住宿标准过低时没有想方法申请预算解决住宿问题；4、早上或很晚接到客户时没有想好早餐或晚茶地

29、点，临时又找不到适宜地点；5、接待所持的欢送标语牌上企业名称不正确或者用简写称呼；6、只注意落实每个接待环节负责人，没有和负责人沟通关于客户各方面的情况，导致各个配合接待的人心中无数；7、没有亲自检查公司介绍材料中是否有和自己前期说法不一致的地方，并做好对策；8、接待客户过程中在下车，交换名片，称谓，递水，入座等细节不注意商务礼仪；9、没有提前规划餐饮，点菜时间长，菜样不好；10、游玩安排不考虑天气因素，没有给客户准备好饮料食品和相机、伞具；11、购置礼品没有考虑是否便于客户携带；12、送客户走没有亲自送到站台，仅仅是到车站就走。如何确认典型用户？首先要将对公司市场工作最有利的典型用户筛选出来

30、，这些用户其实在售前跟踪时就可以通过客户 abc 分类加以明确，这样即使某些用户在第一次合作时工程金额并不大，也可以在在工程实施过程重点保障，重点投入。一般选择典型用户名单考虑以下七个因素：1 应用效果。有三类用户可以做典型用户。第一是成功进行了大量应用的用户，最好的典型用户应该是每天都有大量人员利用系统进行工作， 而且在实施过程中有很好的参考作用。这样有实际应用效果的用户最能让其它客户相信软件公司的能力；第二是一些应用面还不够大，但根底资料都根本录入，典型业务流都可以实现的用户；第三是应用很一般，但在技术上有特点的用户也可以考虑作为典型用户。2 商务关系。所谓典型用户，就是能够替公司提供宣传

31、的用户。这些用户论高管还是中层干部或者基层操作人员应该认同软件公司产品，愿意推荐软件公司的产品。如果没有好的商务关系，用户甚至对软件公司还存在意见，即使应用情况不错，也要考虑是否适合做典型用户。典型用户的商务关系应该一直有专人负责跟踪和维护，仅仅靠客户经理和实施经理要考虑客户经理和实施经理的稳定性问题维护是不够可靠的。3 行业影响力。影响力越大越好，一般情况下行业影响力大的用户公司应在商务和实施时区别对待，重点投入，而不要简单受工程金额大小左右，否那么可能造成效劳资源不够，做坏一个， 丢掉一片。4 业务应用丰富。不是一个用户实施比拟成功，参观就一定有好的效果，要选择一个业务应用尽量丰富的企业，

32、 这样的考察效果才能到达全面完整。一般随生产模式 单件， 多品种小批量， 大批量不同，业务应用丰富的企业也要选择几种类型才能适应不同生产类型用户考察需要。5 地域辐射力。典型用户的地理位置应该交通方便，不然会增加客户交通本钱，也增加公司接待本钱，而且无法起到长期辐射作用。一个全国性公司一定要考虑在全国建立可参观考察的典型用户网络，仅仅只有几个典型用户参观考察对用户本身也是一种巨大的骚扰，而且对很多不方便出省考察的地域性客户，没有当地典型用户是很难做到有效辐射。地域还应考虑到周边游玩餐饮等因素，这也是客户接待考察环节中可以充分利用的资源。6 效劳资源。典型用户并非一定是所有问题都解决了的用户，往

33、往是经常性需要效劳的用户。因为应用深入， 反而新的需求比拟多，合作时机比拟多。但很多时候典型用户在协助软件公司做一些参观考察工作， 往往提出软件公司帮助免费解决一些软件应用问题，这样典型用户如果完全没有效劳资源往往会出问题，难以让典型用户长期保持一个良好的考察状态。7 介绍资源。典型用户接待效果在一定程度上取决于用户有无能将把业务和信息化实施相关问题介绍清楚的人员， 如果有一个这样业务能力比拟突出，信息化理念清晰，又全程参与工程实施过程的企业人员能介绍工程实际情况是最好不过。典型用户确认条件未必一定要以现在是否可以立即考察做依据，而是应该综合以上因素后确定名单，然后通过一系列工作努力让这些适宜

34、的用户成为可以参观考察的用户。选择典型用户的最关键因素就是这个企业本身业务典型不典型，行业辐射力大不大，其次是综合考察本钱是否最经济。案例客户经理小李的一个客户要求看一看他们的成功典型用户，正好小李公司有一个做得不错的用户， 经公司同意后就推荐客户去这家用户去考察，这家用户和小李的客户业务不完全相同，但没有更方便的考察用户了。在陪同客户去用户路上，他一直在担忧用户考察效果。最后考察完成了， 小李感到尽管用户实施效果不错，但好象客户感觉和他们企业关心问题不相同，要求小李再安排一家已解决他们关心问题的用户去考察。小李在这个考察过程中到底该如何做才能更好呢？点评：很多软件公司感到困惑的一个问题就是管

35、理软件工程实施效果往往和预期有一定差距，能全面应用软件全部功能的用户非常之少这需要产品功能、性能、实施力量，业务客观需求，用户配合多方面因素成全，而很多项选择型客户总是希望看到一个自己需求类似、全面应用的用户，以放心选择合作伙伴。实际上不存在完美的典型用户。我们知道大局部情况下我们很难依据客户要求提供类似的考察用户。客户经理总是把工程考察成功的希望寄托在让用户看到一个真实全面和类似应用的标杆上，对典型用户的考察效果全面寄托于样板客户的实施和应用水平。按没有同行业典型用户无法成交工程的逻辑，那么任何行业供货商都应该没方法做新领域的第一个工程，因为他们都没有样板用户。事实上，客户经理可以选择一个有

36、影响力的用户，最好与客户的生产类型比拟接近。在考察之前，客户经理最好是和用户介绍人面对面交流一次，听听他对一些关键问题的说辞，确保符合公司要求， 防止说漏口或介绍自己认为是很得意的工作但恰恰是别的客户的忌讳的工作。现场交流时客户经理可以安排用户主动问客户关心的问题，等客户说出自己的问题时可以根据情况要求用户立即强调这些问题在我们企业也存在，但通过上软件工程已经比拟好的解决了难题，以此引发两家企业产生业务共鸣，让企业觉得确实考察的是类似行业性问题。客户前来考察是提供脱离自己企业环境，可独立思考的时机，也是最容易接受别人思想的时机，整个考察工作如果精心准备和规划，自然能给客户留下深刻的印象，对工程

37、成功起到关键的作用。在管理良好的企业一般是通过自下而上的流程去驱动根底业务，高管更多关注战略业务层面工作， 然后安排执行。 在管理不佳的企业一般是通过自上而下的流程去驱动根底业务，高管不得不投入精力在业务部门调停争论，使大家投入精力到解决问题中去。因此需要高管来推动业务有两种，第一种是非常紧急和重要的业务，按照常规的业务流程评审过程将使事情复杂化，失去敏捷的回应能力； 第二种是牵扯到多个部门利益的新问题，暂时无法通过流程达成一致处理方式，也就是中层无法决策或达成一致的事情，请高管决策。大凡领导都喜欢处理正式的文档。有四类报告高管是不注意或不能有精力真正重视的：过长的文档 ：给高管写的文字一定要

38、在三四页纸甚至更短的页数内解决问题；只提出问题， 却没有清晰解决思路的报告：除了给高管带来烦心感外还有什么大的价值呢？组织条理不清，逻辑结构混乱的文件：也是无法获得高管认同的。只从自己角度思考问题，没有站在全局角度思考问题的文档：高管会觉得信息量太小而无法决策，报告也就不了了之。切记：理性、客观的汇报工作是任何一个明智高管欢送的作风。不开启动大会的几种情况。弱势软件公司签下了严重过度承诺的合同国内软件公司绝大局部都是弱势公司，即使是一些产值很高的公司都不见得比一个国外小公司产品有影响力。弱势公司为了击败强势公司，往往会用较低工程金额承诺一些定制开发。而强势公司完全可以要求企业按照其产品进行业务

39、流程重组，尽管很多时候依据国内外咨询公司建立的新流程也未必高明和实用，实施效果也未必好。这种过度承诺的工程从实施角度来看风险很大，很可能在工程启动后很长一段时间内软件供货商都很难拿出适宜的产品到现场实施。此时， 必须低调处理工程启动大会，甚至暂时不召开启动大会，在工程找到可实施路径的时候再召开启动大会更合理。金额很小的工程可不召开启动大会有的企业虽然签订了一个复杂的合同，但投入的费用其实很不合理，供货商出于种种原因还是签订了合同，此时指望供货商提供强大的后续支持不太现实，因此工程经理尽可能不扩大工程影响， 这样可以在合理条件下尽量调整工程边界，使之可以到达可承受的本钱范围内。如果召开一个高调的

40、启动大会，企业主管领导可能又号召大家动脑筋、提建议， 发动面越广， 工程需求越可能控制不住，此时高调的启动大会不但不能帮助工程顺利启动，反而很可能造成工程走不下去，企业的投入全部报废的后果。在这种情况下工程经理完全可以和企业沟通，低调起步， 取得一些成绩， 得到企业各方面认同工程目标后，通过企业适当追加费用，把工程顺利完成。在这种情况下，低调反而是对工程的一种自我保护，会屏蔽掉很多不必要的干扰。工具化，产品化的工程可不召开启动大会现在上三维设计软件的企业很多，花费到达几十万的也不少，很多时候远远超过管理系统的投入， 这里不讨论这种投入比例是否适宜，但一个奇怪的现象就是，很多企业并不为这些花费不

41、小的工程开启动大会。原因很简单， 工具型培训掌握的软件是没有实施风险的，业务部门很清楚掌握这些工具对业务和个人的好处，会比拟自觉按领导要求去接受培训，在截止日期之前掌握软件，根本就没有召开启动大会发动全员重视的必要。同样如果我们应用的是非常成熟的业务和系统模块，也可以快速调研、快速安装、 快速培训、快速见效，那么也不需要召开启动大会，最多只需要召开一个推广阔会，业务部门强化培训一段时间即可。具备良好信息化实施经验和管理标准的企业不需要启动大会如果企业的信息化工作已经成为一项日常工作，已经具备大量信息化工程实施经验，有良好的实施团队，信息化已经成为每个部门标准工具和日常流程中一局部的时候，再上一

42、个新工程就不需要启动大会这种形式了。经过充分磨合的用户可不召开启动大会有的工程是老用户追加，再增加比拟大的投入合作新工程，和软件供货商队伍磨合已经完成， 新工程只是扩大应用深度，可以看做是历史工程不断的深入，此时也可不召开启动大会。不过在新工程业务流程验证完成后可以召开一个新工程上线发动大会。无法摆平内部关系的工程可暂不召开启动大会有的工程商务阶段过于复杂，选型结束后企业内部仍然存在矛盾，此时如果立即召开启动大会， 很难快速化解矛盾各方，启动大会必然就流于形式了。这种情况下工程启动大会可以稍为缓一缓，创造出一些条件后再召开效果更好。工程启动大会既约束企业，也约束软件供货商。 企业对供给商专案组

43、有合同约束手段，反过来软件工程组也一定要让企业工程组受到内部考核机制的约束，这样双方才能在启动阶段认识一致， 同心同德完成工程实施。如果从启动阶段开始，企业工程组就变成软件供货商的监工， 大局部时间用于检查软件供货商的工作，指责他们进度的拖延，而不配合软件供货商调度资源、推动进度的话，那么这个工程失败风险就增加了。案例工程经理小李和一个客户工程负责人约定要启动调研了，他写了份方案，说明调研派出团队人数和方案天数，还说明了调研要了解的大概内容，请企业确认能否按方案时间启动和开始。 小李在得到企业肯定答复后来到现场，这才发现企业这边根本没有配合好，无论是要求准备的数据还是要求约的被调研对象，都没有

44、准备。 小李不得不调整方案，在现场重新落实方案的工作内容。请问怎样防止出现这样的情况呢？点评：企业客观上都希望工程团队在现场的工作紧凑合理，不浪费彼此的时间。但用户并不清楚如何做这种调研，他们能做的就是按照软件公司意见尽量安排适宜人员配合。如果调研方案只是模糊说明某几天要来现场调研的话，实际上用户领导可能会答复，那你们先来， 来了再说。 结果到了现场发现准备缺乏，把大量时间都无价值的浪费在协调调研资源和等待上。有的人把调研方案做好，告诉用户行程， 就准备按方案去现场了，这样的调研者不及格。有的人会提前发邮件或给用户，然后确认收到，然后和用户确认时间无问题，然后再去，这样的调研者60分。有的人不

45、但会确认方案时间，还会认真了解企业是否认同方案内容和是否有相关业务人员配合，得到肯定承诺后再去，这样的人80分。有的人还会准备一些前期调研文卷和数据准备清单，让客户经理配合落实后再去调研，这样的人 100分。调研方案至少要做到80分！方案发给中国用户后，大局部用户一般是不会认真看和落实的，这是中国人做事的习惯，特别是一些地位不高的联系人，可能连为这个事找领导的协调能力都没有。所以打确认的时候一定要请用户确认是否可以按方案进行，得到肯定答复后再出发，这样方案执行保障性会高一些，也给别人留下一个认真的印象。案例工程经理小李在调研过程发现一个客户工程中非常关注编码的问题，而企业的编码想实现编码规那么

46、， 软件公司现有的产品肯定无法满足，小李花了很多时间说服企业工程负责人，指出企业现有的编码也是够用的，没有必要在启动阶段花费如此大力气折腾编码，工程负责人最后接受他的意见。小李用这种方法婉拒了很多客户需求，也就不投入精力进行这些方面的调研了，这样操作对吗？点评：控制用户的需求是合理的工程边界管理方法，只要和用户进行过充分沟通，达成共识，小李的做法是无可厚非的。但如果在调研阶段发现用户认为是很有价值的问题是公司目前不能解决的问题，并不等于说服用户后调研工作中就可以回避。现在可以回避的问题不等于以后可以一直回避，更不等于在未来实施过程中永远不面对。合理的需求总是要冒出来，与其回避， 不如先主动搞清

47、楚，汇报给公司后群策群力，看看到底有什么方法可以解决。如果有选择性问问题，就会遗漏一些关键性业务，这样对调研整体质量有影响，在后续制定解决方案工作中容易遗失业务环节。如果确实不想引发用户一些天马行空的问题，或者确实不想引发他们高度兴趣的问题也有合理的回避方法，不过不是通过不调研到达，而是以单独认真记录，但不提供在正式文档的方式躲避。很多用户的很多需求都是一时灵感，没有经过认真思考，呈口舌之快，过了也就过了，不形成文字记录，用户自己也不记得自己说过什么了。如果真是关键问题，会不断在后续阶段再提出来的，这个时候再确定写入正式档也不迟。此外越是有公司产品明显不能解决的问题，越要调研清楚，搞清楚来龙去

48、脉，为公司今后产品开展提供完整的需求建议。作为一家负责任的软件公司，首先要成认自己的软件不可能解决所有的问题，但一定要在开展过程中逐步解决更多的问题，调研时都回避问题，不就使公司产品失去了开展时机了吗？真正的问题都是回避不了，绕不过去的。处理用户需求需要知道的三件事用户提出的需求很少有不合理的，往往是用户提出的实现方法并不能真正解决问题而已。用户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和效劳而已。用户提出的需求往往有简单的解决方法，如果答案很复杂，往往不是正解而已。如何分析用户的需求实施过程鲜有一帆风顺的，对于现有产品，用户提出不满，提出这样那样的问题是常有的事。 用

49、户提出需求的方式往往表现为强烈需要一个功能，这个时候很多实施人员可能开始考虑这个功能是否合理，是否容易实现，并以此为根底和用户展开谈判。一个有经验的实施人员这个时候首先应该思考用户为什么有这个需求，不要光看需求的功能描述。 首先应该考虑的是：用户这个需求的本来面目是什么。有时用户的需求也是用户自己加工过的，比方用户认为在某个窗体加个字段就可以实现这样一种业务，但实际上可能不是那么简单。因此， 我们必须从需求出发把用户要解决的业务复原，然后再站在全局业务的高度考虑我们到底要解决的是什么问题。复原了业务后我们可能会发现很多时候用户提出的需求往往是管理上的漏洞造成的，技术手段并不能解决业务问题，属于

50、不合理的需求。这个时候我们并不能轻易拒绝用户的需求，而是要和用户一起推导直到他们发现自己提出的方案并不能从根本上解决问题，然后再和用户探讨真正解决问题的方法，这样用户不但会收回自己的想法，还会建立对你分析能力的认可。案例工程经理小李接到一个工程，工程在商务阶段为了争取合同做了大量承诺，但实际上很多是软件很难开发满足的，这个时候企业负责人要求软件公司兑现承诺，否那么不可能验收工程。请问小李该怎么办？点评：管理系统销售为了争取合同很少有不过度承诺的，这是一种不可回避的现状。这种现状恰恰是造成实施人员的表达自身价值的时机，如何在最小化开发本钱情况下有效解决业务问题，而不是指责销售团队，或者逼压开发团

51、队。很多过度承诺的内容是用户心血来潮的产物，真正在做工程时经过深入思考，用户也会接受理性的目标，不会反复追究。 因此在调研阶段提供好的解决方案提供清晰的工程目标和完整的业务方案和与用户建立良好私人感情是多么重要！此外由销售承诺的很多功能，其实未必是合理的需求实现方式，实施人员在业务调研过程中，往往有可能发现真正解决问题的方法。一旦和用户对某个需求功能实现方式形成僵局，实施人员首先要去了解业务，分析这个业务到底想解决什么问题，这个问题到底可以通过怎样方法来解决，可能能找到找到可替代的方案，甚至是更好更被用户接受的方案。有的功能可以和用户一起评估这些要求和我们的主要工程业务目标的符合程度，如果需求

52、对我们主要目标实现没有帮助，我们就可以尽力去说服用户先将精力集中在主要目标上，一个工程是不允许有太多分支目标来发散精力的。如果个别用户还是非常固执要求实现自己的要求，一个有效的策略就是不主动激起用户讨论这些问题，淡化处理，拖一拖也就可能把问题拖掉了，这也是一种没有方法的方法。没有清楚定义未来的工作远景的系统，追随者会越来越少。实施解决方案和售前解决方案的不同1、从售前到实施解决方案要经过一个主体从软件公司能力宣传到企业业务支撑描述的变化。售前阶段大局部工程不能提供详细业务调研的时机，所以售前解决方案以软件企业功能和实施经验为主，结合企业一些特色加以发挥，简单地说还是以软件公司为主，而售后解决方

53、案是建立在详细业务调研根底之上，必须结合企业流程详细展开，以企业为主描述。2、从售前到实施解决方案要经过一个从虚到实的变化。售前阶段解决方案重在介绍一些理念和管理思路，总体上存在很多务虚的内容，比方工程目标主要从定性角度阐发，对价值主要从一般认识出发。但经过业务调研后实施解决方案中要明确提出一些定量的目标，例如产品数据管理怎样叫做管理了，不能说不出所以然。同时实施解决方案对工程价值点要能结合部门，岗位和业务描述出在不同业务环节的不同岗位责任人能从系统中得到哪些方面的效益，进而支持企业的何种价值点，而不能再是放之四海皆准的泛理论推导。同样在售前宣传的一些概念，要么在实施阶段找到落脚点，要么在实施

54、阶段把这些天上的东西用地面的目标取代。3、从售前到实施解决方案要经过一个从功能排列到操作串联的变化。售前阶段对软件更多的是从功能列表角度去陈列，或者解释不同应用需要用到哪些功能，在实施方案就中就必须能够将这些功能真正串接成业务操作，让用户能看懂一个业务在系统支持下从原始输入到最终输出的全部流程，而不能模糊其辞。一份模糊的业务方案其实反映的是一个公司，一个工程经理对业务把握模糊不清的状态。这种没有业务串联的方案也难以指导工程团队成员有效完成配置和开发。没有目标定义的工程很难获得成功。编制实施阶段解决方案常见问题第一、和售前方案几乎难以区别，都是价值点+功能手册的模式实施阶段解决方案很容易从售前范

55、本中学习到“假，大，空的毛病，对软件价值缺少足够的逻辑论证，关键价值实现业务路径缺少分析。实施解决方案很容易成为功能点的罗列，难以指导用户形成业务思路，也不能指导实施人员进行业务配置，也无法通过解决方案验证配置。实施解决方案过多罗列价值点必要性不大，用户更愿意看到实现哪些业务流程，在过程中改善了哪些环节工作，是如何改善的，要如何实施，最终操作模式是怎样的。软件功能点在软件功能手册中有，实施解决方案要针对企业业务进行数据建模分析，然后形成新的业务流程框图和操作思路说明。第二解决方案对工程价值点关注很多，对工程目标关注过少，而且不细化，不量化，不提验证手段。第三解决方案抄用历史模板图片，没有用用户

56、的实际数据做图片。第四在内容编排上和一些细节上不注意和售前方案照应，根本不参考售前一些工作成果。很多工程经理编制方案的过程就是参考软件公司内部的管理要求，借鉴一个历史模板加以修改的过程。 甚至有不做方案，以为凭借自己的经验到现场一定就可以搞定。尽管机械地复制历史模版工程经理可以快速炮制出大量格式标准，内容丰富的实施方案，但是并没有技术含量，对实际工作也帮助甚微。有的工程经理会义正言辞地辩称，这个世界其实“ 方案不如变化快，整个工程实施过程就是踩着西瓜皮，走到哪里滑到哪里的过程，反正努力把它往前推动，尽心尽力就好。现在很多方案一看就没有表达筹划的过程，把软件公司业务方法论顺序当作工程过程分解依据

57、，千篇一律。事实上所有的人都成认工程和工程不一样，不存在简单复制的关系，为什么方案这里却又可以理所当然地套用呢？这些敷衍做法在实际工作中是大量存在的。我们可以将这一类人总结出一个共同的工作特性，那就是不做方案、消极地应付工作，处于受用户摆布的地位；而工程经理做方案的目的那么正是希望。设定里程碑容易出现两个问题，第一是把行动当作目标，第二是把完成重要关键事件和里程碑具体含义等同。案例工程经理小李一份工程方案目标中是这样写的：方案目标：和用户沟通工作方案解决现场遗留的问题完本钱次现场工作备忘录然后再具体描述各工程标的子活动和时间配合安排。这样编制方案有什么问题吗？点评：这样的方案目标看上去没有什么

58、错误，但是所有这些目标看做是本次现场工作的一些活动更适宜。 沟通，解决问题，签署备忘录是实施人员在现场工作必须完成的一些活动，这些活动完成质量上下可以决定工程目标是否被到达，并不能认为做了这三件事情工程现场工作质量就高，就完成了工程目标。本次现场工作目标和你整个工程的目标有什么关系？任何一个阶段工作都应该有利于工程总体目标或者某个分阶段目标实现，这个要实现的效果才是来现场工作的目标。具体方案大局部实施人员就习惯列工作活动流水帐，并把完成流水帐作业内容作为受控的目标， 而不关注本次现场工作要使工程到达怎样的状态。一个工程每个阶段每个人都这么流水帐写下去，工程到底要干什么，用不了多久大家都说不清楚

59、，工程延期也指日可待。这种流水帐方案还有一个巨大的负面作用，很容易将工程总目标一个个阶段中引入一些反复验证的技术细节，忘记了整个工程不是用于解决技术问题，而是要解决业务问题，使工程目标被转移到技术细节上。备忘录首先要用书面的形式使自己完成的工作成果得到认可，让用户肯定公司在工程上的进展和努力。 在工作成果得到确认根底上给工程的阶段工作做正面评价，为工程整体目标推进提前进行铺垫。 一些重要的工程目标约定或者验收意见还可以单独写备忘录，在最终验收时可以作为参考依据。备忘录要说明本次现场工作进行了哪些工作内容，到达了怎样的目的，和企业约定的下一步工作安排是什么，进度出现问题的原因是什么，哪些是企业的

60、原因，哪些是软件供货商的原因。备忘录最后要约定下一阶段双方工作安排，推动事情继续前进，尤其要注意约定的工作一定要在下次工作方案中表达。在后续工作中软件公司要尽量严格按照备忘录设计自己的工作方案，同时了解企业工程组约定的工作进展情况，如果企业工程组方面配合出现了问题，在下次备忘录中要明确指出责任承当方，给用户形成一定的压力，从而更好推动工程走向前进。工程经理要让用户通过备忘录看到一个软件公司做事的标准性、一个工程过程中方案的承接性。案例工程经理小李在一个工程的实施过程中进展很不顺利，阶段工作结束后根本无法到达任何预期工作目标，这个时候用户对是否写备忘录没有什么要求。在没有工作进展的时候是不是可以