【项目体验】客户的需求确认

[size=medium]

最近几次的客户需求确认，发现这样一件事。
正常的需求分析和设计工作，是建立在甲方已有现成的业务流程、产品的基础上，需求分析人员的职责是在客户专家的帮助下，对该业务流程进行分析和整理，在客户确认之后，转化为开发人员可以理解的方式，送入开发流程。
但目前几次的需求分析过程中，都发现客户本身是没有业务流程的，也根本没考虑的过业务开展的方式，产品都是不存在的。客户只是像一个财大气粗的老板，看到这件事有利可图，就急冲冲地跳进来，对技术、对业务、对合作各方都没有经过过多的考虑。这其实是一个很好的机会，乙方依据原有的经验可以引导客户，并取得客户的信任，非常有利用这个项目今后的发展，也可以很好的控制其走向。糟糕的是，作为乙方，对该业务的熟悉度同样为0，考虑是在甲方提出概念之后才启动的，很有可能对该业务的了解程度还不及甲方。
在需求分析阶段，需求分析人员仍习惯性地向客户进行各种业务流程和部分细节的确认，以开发人员出身的部分人员已经开始考虑技术的实现方案。可想而知，一无所知的客户被问到全角度各方位的问题时，是多么的恼羞成怒，尤其在连续几次问题都无法回答的情况下。客户将这一过程认为是一种攻击，准备了更多的业务问题向需求分析人员提出，于是战场双方你来我往，没有谁能给出真正的结果。需求分析人员认为客户自己的业务都不清楚，让“我们”怎么设计。客户认为我花了银子请你们来，居然什么问题都解决不了，我要你们做什么。

遇到这样的项目，需求分析人员应当怎么做。

1、 了解甲方的组织机构。哪个部门是项目的组织者，哪个又是项目的决策者。各自的职责是什么，都向谁负责。由此 知道各个部门关心的关键点是什么，及时提供相关的内容给适当的角色。减轻甲方的工作，就是提高乙方的工作效率。如果不幸甲方的两个部门是竞争者，就更要小心避免被卷入泥潭，设计到决策的会议最好竞争双方都在场。

2、 当乙方需要向甲方内多个部门进行需求确认时，尽量避免以一对多的形式进行，不是每个人都可以舌战群儒的。而且，各部门关注点不同，处于自身利益的考虑，每个议题都会被无限制的拓展，偏离原始的方向，导致会议结果迟迟无法得出。所以，如果时间允许，客户配合度又高，可以考虑一对一的方式，针对一个利益体进行确认。在各方意见已基本明确的前提下，再进行最终的全体会议，这个会议上需要倾听各方的意见，协调各方对最终目标和阶段性没目标达成一致，对于过于细节化和无需讨论的问题应在会议前确定。 更高级的方式，请甲方提供接口人，由固定人员进行协调处理。

3、 提供完整的业务方案供甲方参考和确认。 不要向甲方提问题，要提供完整的业务方案让客户针对方案向乙方提问题。 在问题的说明当中，让甲方自己发现自己的问题并配合解决。当甲方感到自己有所收获时，就会设法解决随之而来的问题。 对于比较大的项目，需要预先做好相关业务的积累和准备，临时抱佛脚未必会有好效果。

4、 需求跟踪列表文档。 建议项：需求标题、需求细则、需求参考文档、需求提出方（部门、人）、需求提出时间、需求分析结果、需求确认人、确认时间、开发确认、确认进度。依据项目的大小和特点作相应的调整。

客户需求在双方配合度高的情况下，是最有利于的项目推动的，不论甲方本身是否有实际的业务。一旦出现甲方不能很好配合，扯皮等各种感到不可理喻的情况，不可情绪化，被对方牵着走。保持淡定，与自己公司其他职能人士进行沟通，比如销售、项目经理、自己的领导等人，确定是否有商务上的原因造成。若领导层有最新的动态，最好及时把握。[/size]