在项目推进过程中与客户沟通过程中的技巧

在交付过程中,演示过后,除了收集用户对前一阶段演示的意见以外,通常需要沟通下一阶段的需求。

获取下一阶段的需求可以分为几个关键点:

界定下一阶段任务范围

比如在面试系统中,我们第一阶段做的是单个“考场”的完整面试过程。演示过后,用户觉得基本问题不大了。这个时候,应该向用户提问:“下一步你们想要看到什么内容”。这一点很重要,这里就是在界定下一阶段的任务范围,这样的问题能够保证下一阶段做的内容不会和用户的期望跑偏。

这里还需要注意的是,应该引导用户描述我们想要的答案,“我想要看到XXX(流程),从而可以XXXX(业务价值)”。作为面试系统,我们这次得到的信息是“我想要看到设置考试功能,这样就可以创建考试,让一次“考试”中所有“考场”都可以进行面试”,这样也能一定程度上避免用户在细节上纠缠不休导致项目节奏缓慢。

业务建模

一次好的沟通不仅仅需要获取信息,应该是互动式的沟通。在知道用户需要什么的同时,应该帮助用户强化业务模型的概念。在将来的沟通中达成协议,增加沟通效率。

简单的例子,对于面试系统我们设计的模型为:

考场(物理上存在,可以进行面试的地点)

考场次(某一时间段某一考场所形成的特定供面试的环境)

对于考场,一般来说用户都能够很容易的理解,因为在日常中他们经常使用这一模型。但是对于考场次,用户一般来说在潜意识中可能有这个模型,但是在沟通过程中并不会用语言单个的词汇来描述。这里我们就需要针对其描述对其业务进行建模,并且和用户一起推敲这个模型的命名,这样才能保证后期的沟通中对某个业务模型的讨论有明确的指向性。

这里需要注意一个问题,我们并不是在凭空创造业务,业务是客观存在的,只是我们应该把它提到明面上进行讨论命名,形成模型。

引导用户假设操作流程

在交付过程的沟通中,当让用户假设操作流程,对于业务建模也是有很大帮助的。

举个例子,我们设计的流程是需要向每个考场次导入考生。因为我们设想的业务模型是每个考生的编号是特定的,并且唯一的。而后来客户坚持考生只需要在创建考场次的同时加入“考生数量”字段,然后根据这个数量自动生成考生。

从上面的讨论中我们发现用户的描述和我们的设想有矛盾的地方。根据之后的沟通,才明白这里其实有两个业务模型:“面试者”、“考生”。

我们说的“考生”是指的特定的人,有姓名身份证等等具体信息。而用户所说的考生,在面试过程中,可以叫做“面试者”。“面试者”对于面试过程而言,仅仅是一个从1开始的编号。在整个面试过程中,不需要,也不应该对应到特定的“考生”。所以,用户所说的“面试者”是可以自动生成的。

另一个重要的问题,我们应该防止用户做数据结构设计,这与上面说的过程并不矛盾。如果让用户直接做数据结构设计,我们往往无法捕获到流程上的业务。

比如在沟通中,用户可能会告诉我们“我要考试名称”“我要设置考场日期”“我要设置考场名称”。从用户的描述中,我们得到的是“考试名称”“日期”“考场名称”这三个数据项,而这三个数据项的业务意义并不明确

比较好的描述方法是“首先有一个考试,在这个考试下,有若干天的面试,每一天有若干个考场可供考试”。类似这样用自然语言描述出的流程,经过我们的分析,能够得出三个重要的要素:“模型,模型之间的关系,用户期望操作的顺序”

当然,这样的过程不可能每个客户都能够一开始就顺利的表述,这里就需要沟通人员对用户进行正确的引导

( 本文版权属于© 2015 卓逸天成 | 转载请注明作者和出处:卓逸知识文库 http://kb.skight.com )