超越对手之十--如何做实施调研精彩观点摘要

案例

  项目经理小李和一个客户项目负责人约定要启动调研了，他写了份计划，说明调研派出团队人数和计划天数，还说明了调研要了解的大概内容，请企业确认能否按计划时间启动和开始。小李在得到企业肯定答复后来到现场，这才发现企业这边根本没有配合好，无论是要求准备的数据还是要求约的被调研对象，都没有准备。小李不得不调整计划，在现场重新落实计划的工作内容。

请问怎样避免出现这样的情况呢？

  点评：

  企业客观上都希望项目团队在现场的工作紧凑合理，不浪费彼此的时间。但用户并不清楚如何做这种调研，他们能做的就是按照软件公司意见尽量安排合适人员配合。

  如果调研计划只是含糊说明某几天要来现场调研的话，实际上用户领导可能会回答，那你们先来，来了再说。结果到了现场发现准备不足，把大量时间都无价值的浪费在协调调研资源和等待上。

  有的人把调研计划做好，告诉用户行程，就准备按计划去现场了，这样的调研者不及格。

  有的人会提前发邮件或传真给用户，然后电话确认收到，然后和用户确认时间无问题，然后再去，这样的调研者60分。

  有的人不但会确认计划时间，还会认真了解企业是否认同计划内容和是否有相关业务人员配合，得到肯定承诺后再去，这样的人80分。

  有的人还会准备一些前期调研文卷和数据准备清单，让客户经理配合落实后再去调研，这样的人100分。

  调研计划至少要做到80分！计划发给中国用户后，大部分用户一般是不会认真看和落实的，这是中国人做事的习惯，特别是一些地位不高的联系人，可能连为这个事找领导的协调能力都没有。所以打电话确认的时候一定要请用户确认是否可以按计划进行，得到肯定答复后再出发，这样计划执行保障性会高一些，也给别人留下一个认真的印象。

  案例

  项目经理小李在调研过程发现一个客户项目中非常关注编码的问题，而企业的编码想实现编码规则，软件公司现有的产品肯定无法满足，小李花了很多时间说服企业项目负责人，指出企业现有的编码也是够用的，没有必要在启动阶段花费如此大力气折腾编码，项目负责人最后接受他的意见。小李用这种办法婉拒了很多客户需求，也就不投入精力进行这些方面的调研了，这样操作对吗？

  点评：

  控制用户的需求是合理的项目边界管理方法，只要和用户进行过充分沟通，达成共识，小李的做法是无可厚非的。

  但如果在调研阶段发现用户认为是很有价值的问题是公司目前不能解决的问题，并不等于说服用户后调研工作中就可以回避。现在可以回避的问题不等于以后可以一直回避，更不等于在未来实施过程中永远不面对。合理的需求总是要冒出来，与其回避，不如先主动搞清楚，汇报给公司后群策群力，看看到底有什么办法可以解决。

  如果有选择性问问题，就会遗漏一些关键性业务，这样对调研整体质量有影响，在后续制定解决方案工作中容易遗失业务环节。

  如果确实不想引发用户一些天马行空的问题，或者的确不想引发他们高度兴趣的问题也有合理的回避方法，不过不是通过不调研达到，而是以单独认真记录，但不提供在正式文档的方式规避。很多用户的很多需求都是一时灵感，没有经过认真思考，呈口舌之快，过了也就过了，不形成文字记录，用户自己也不记得自己说过什么了。

  如果真是关键问题，会不断在后续阶段再提出来的，这个时候再确定写入正式档也不迟。

  此外越是有公司产品明显不能解决的问题，越要调研清楚，搞清楚来龙去脉，为公司今后产品发展提供完整的需求建议。作为一家负责任的软件公司，首先要承认自己的软件不可能解决所有的问题，但一定要在发展过程中逐步解决更多的问题，调研时都回避问题，不就使公司产品失去了发展机会了吗？

  真正的问题都是回避不了，绕不过去的。
 

超越对手之十一--如何处理用户需求精彩观点摘要

处理用户需求需要知道的三件事
    用户提出的需求很少有不合理的，往往是用户提出的实现办法并不能真正解决问题而已。
    用户提出的需求很少有不能解决的，往往是公司在现有资源情况下无法快速响应和服务而已。
    用户提出的需求往往有简单的解决方法，如果答案很复杂，往往不是正解而已。

如何分析用户的需求
    实施过程鲜有一帆风顺的，对于现有产品，用户提出不满，提出这样那样的问题是常有的事。用户提出需求的方式往往表现为强烈需要一个功能，这个时候很多实施人员可能开始考虑这个功能是否合理，是否容易实现，并以此为基础和用户展开谈判。
    一个有经验的实施人员这个时候首先应该思考用户为什么有这个需求，不要光看需求的功能描述。首先应该考虑的是：用户这个需求的本来面目是什么。有时用户的需求也是用户自己加工过的，比如用户认为在某个窗体加个字段就可以实现这样一种业务，但实际上可能不是那么简单。因此，我们必须从需求出发把用户要解决的业务还原，然后再站在全局业务的高度考虑我们到底要解决的是什么问题。
    还原了业务后我们可能会发现很多时候用户提出的需求往往是管理上的漏洞造成的，技术手段并不能解决业务问题，属于不合理的需求。
    这个时候我们并不能轻易拒绝用户的需求，而是要和用户一起推导直到他们发现自己提出的方案并不能从根本上解决问题，然后再和用户探讨真正解决问题的办法，这样用户不但会收回自己的想法，还会建立对你分析能力的认可。

  案例

  项目经理小李接到一个项目，项目在商务阶段为了争取合同做了大量承诺，但实际上很多是软件很难开发满足的，这个时候企业负责人要求软件公司兑现承诺，否则不可能验收项目。

  请问小李该怎么办？

  点评：

  管理系统销售为了争取合同很少有不过度承诺的，这是一种不可回避的现状。这种现状恰恰是造成实施人员的体现自身价值的机会，如何在最小化开发成本情况下有效解决业务问题，而不是指责销售团队，或者逼压开发团队。

  很多过度承诺的内容是用户心血来潮的产物，真正在做项目时经过深入思考，用户也会接受理性的目标，不会反复追究。因此在调研阶段提供好的解决方案（提供清晰的项目目标和完整的业务方案）和与用户建立良好私人感情是多么重要！

  此外由销售承诺的很多功能，其实未必是合理的需求实现方式，实施人员在业务调研过程中，往往有可能发现真正解决问题的办法。一旦和用户对某个需求功能实现方式形成僵局，实施人员首先要去了解业务，分析这个业务到底想解决什么问题，这个问题到底可以通过怎样办法来解决，可能能找到找到可替代的方案，甚至是更好更被用户接受的方案。

  有的功能可以和用户一起评估这些要求和我们的主要项目业务目标的符合程度，如果需求对我们主要目标实现没有帮助，我们就可以尽力去说服用户先将精力集中在主要目标上，一个项目是不允许有太多分支目标来发散精力的。

  如果个别用户还是非常固执要求实现自己的要求，一个有效的策略就是不主动激起用户讨论这些问题，淡化处理，拖一拖也就可能把问题拖掉了，这也是一种没有办法的办法。
 

超越对手之十二--如何编制实施解决方案精彩观点摘要

没有清楚定义未来的工作远景的系统，追随者会越来越少。

实施解决方案和售前解决方案的不同
    1、从售前到实施解决方案要经过一个主体从软件公司能力宣传到企业业务支撑描述的变化。

    售前阶段大部分项目不能提供详细业务调研的机会，所以售前解决方案以软件企业功能和实施经验为主，结合企业一些特色加以发挥，简单地说还是以软件公司为主，而售后解决方案是建立在详细业务调研基础之上，必须结合企业流程详细展开，以企业为主描述。

    2、从售前到实施解决方案要经过一个从虚到实的变化。

    售前阶段解决方案重在介绍一些理念和管理思路，总体上存在很多务虚的内容，比如项目目标主要从定性角度阐发，对价值主要从一般认识出发。

    但经过业务调研后实施解决方案中要明确提出一些定量的目标，例如产品数据管理怎样叫做管理了，不能说不出所以然。同时实施解决方案对项目价值点要能结合部门，岗位和业务描述出在不同业务环节的不同岗位责任人能从系统中得到哪些方面的效益，进而支持企业的何种价值点，而不能再是放之四海皆准的泛理论推导。

    同样在售前宣传的一些概念，要么在实施阶段找到落脚点，要么在实施阶段把这些天上的东西用地面的目标取代。

    3、从售前到实施解决方案要经过一个从功能排列到操作串联的变化。

    售前阶段对软件更多的是从功能列表角度去陈列，或者解释不同应用需要用到哪些功能，在实施方案就中就必须能够将这些功能真正串接成业务操作，让用户能看懂一个业务在系统支持下从原始输入到最终输出的全部流程，而不能含糊其辞。

    一份含糊的业务方案其实反映的是一个公司，一个项目经理对业务把握含糊不清的状态。这种没有业务串联的方案也难以指导项目团队成员有效完成配置和开发。

    没有目标定义的项目很难获得成功。

编制实施阶段解决方案常见问题
    第一、和售前方案几乎难以区别，都是价值点+功能手册的模式

    实施阶段解决方案很容易从售前范本中学习到“假，大，空”的毛病，对软件价值缺少足够的逻辑论证，关键价值实现业务路径缺少分析。

    实施解决方案很容易成为功能点的罗列，难以指导用户形成业务思路，也不能指导实施人员进行业务配置，也无法通过解决方案验证配置。

    实施解决方案过多罗列价值点必要性不大，用户更愿意看到实现哪些业务流程，在过程中改善了哪些环节工作，是如何改善的，要如何实施，最终操作模式是怎样的。

软件功能点在软件功能手册中有，实施解决方案要针对企业业务进行数据建模分析，然后形成新的业务流程框图和操作思路说明。

    第二解决方案对项目价值点关注很多，对项目目标关注过少，而且不细化，不量化，不提验证手段。

    第三解决方案抄用历史模板图片，没有用用户的实际数据做图片。

    第四在内容编排上和一些细节上不注意和售前方案呼应，基本不参考售前一些工作成果。