从关键任务推导出业务场景

在“关键任务”被找到以后，我们还需要进一步去识别围绕这个任务都有哪些业务场景。

“场景”这个词源于电影业，被互联网迅速带火。逻辑思维的联合创始人吴声先生出版的《场景化革命》一书非常经典，在开篇就提出：场景就是“特定的时间、特定的地点、特定的任务、特定的事件构成的一个画面”。就像一个电影突然定格成一张图片，你可以指出这个“场景”里人物是谁、在什么时间、什么地点、在和谁、在做什么事情。

一个任务的描述是抽象的，如果找到任务在实际工作中的场景，那么它就是具体的、是员工每天面临的活生生的工作内容。同样一个任务，不同的公司、不同的人员，所面临的场景是不一样的。

在2013年，我同时接到了两家客户的课程开发需求，要开发的课程主题都跟“影响他人”有关。客户希望我能针对他们企业的目标学员，萃取提炼出“影响他人”的工作经验，并开发成面授课程。

第一家企业是医药企业，目标学员是“医药代表”。通过访谈和分析，我们得出结论，对于医药代表来说，“影响他人”的业务场景是这个代表会持续拜访某一个医院的科室主任、医生、护士长等人员，他们需要能够通过自己的沟通、呈现、服务等各种手段，有效地改变这些人的处方理念和处方行为。

第二家企业是互联网企业，目标学员是“技术专家”。通过访谈和分析，我们得出结论，对于这些技术专家来讲，“影响他人”有两个业务场景。一是他们在公司里经常会成为一个虚拟项目团队的项目经理，需要他们能够在项目管理中有效地影响和驱动他人进行配合，激发团队成员的活力，更好完成工作。第二个场景是公司期待他们能够经常在各种公司内外的技术社区保持活跃，对某一个特定的技术领域人员具有一定的影响力。

从上述的举例，我们可以看出，关键工作任务还有可能是抽象的，但是到了业务场景就非常具体，而最佳实践一定是基于这些具体场景的。

找到业务场景的方法并不难，请专家多多描述一下日常工作的具体情况，场景就会浮现出来。

就像互联网的产品经理一样，他们会追踪用户的一天在做什么、在想什么，把用户使用自己产品的场景都识别清楚，以便让自己的产品功能更加用户导向，让用户使用得更加方便。

举例来说，我曾经访谈过一个手机输入法的产品经理，他会检测用户在启动自己的输入法时，是在哪个城市，在使用哪个手机软件，以此来决定给用户推送什么词库。假如这个用户在上海，并且正在使用某个导航软件，则上海的街道名称、主要建筑物名称都会被推送至他的输入法中，这样用户在使用的时候，就会发现自己想要的词组都有，感觉很棒；如果这个用户在云南，并且正在使用一个听音乐的软件，则歌曲、歌词、明星相关的词库就会被推送给她。

受这次访谈的启发，我在思考，也许我们也可以用一些维度来定义“关键工作任务”，这样一些业务场景就会浮现出来，之后我们再和业务部门进行沟通，明确哪些是有意义的业务场景。通过这个过程，我们需要的场景地图就可以描绘出来了。

我使用的维度有三个：“对象”、“渠道”和“活动”。

我们还拿晓杨的案例来说明。他找到的其中一条关键工作任务是“为客户提供满意的日常性、常规性的服务”。让我们来尝试一下用这三个维度来定义这个任务的场景都有哪些。

•从“对象”维度来划分。对象指的是任务的对象。例如，一个管理者辅导下属的任务，“下属”就是这个任务作用的对象，我们可以按照下属的类别进行分类，把辅导任务找出不同的辅导场景；一个维修技师维修内燃机的故障，“内燃机”和“内燃机的故障”都是这个任务作用的对象，我们可以按照内燃机的不同型号，或者故障的不同类型来为这个任务找到不同的场景。

那么，针对晓杨的案例，任务的对象是“客户”。公司曾经根据客户的采购规模，给客户划分不同的类别，这个任务可能出现以下两个场景：

•为公司的VIP级客户提供服务

•为公司的普通客户提供服务

•从“渠道”维度来划分。渠道可以理解成这个任务发生的场所、地点和渠道。在晓杨的案例中，我们发现为客户提供服务这个任务，基本都有以下几种渠道：

•在机房现场，面对面地为客户提供服务（有些特定的情况下，客户会来到机房现场，与技术人员直接面对面解决一些问题）

•通过电话，为客户提供服务（大部分情况下，客户会直接拨打客服中心电话，提出疑问和服务的要求。客服中心会把这些技术问题转移到技术部门，由IT技术人员给出解决方案。很多情况下，IT技术人员需要通过电话直接跟客户沟通方案，或者说明问题，得到客户同意后，再去执行解决的方案）

•通过电子邮件，为客户提供服务（技术部门需要定期给客户发送一些更新的信息、技术报告等。对一些故障的解决方案和结果，有时也需要用电子邮件反馈给客户）

以上三个渠道，基本上概括了IT工程师为客户提供服务时的所有方式。

•从“活动”维度来划分。活动是任务的下一层级，完成这个任务主要包括哪些内容，要做的事情就是里面的活动。在上面“影响他人”的举例中，互联网的技术经理有两件事要做：内部影响他人，吸引人加入项目，完成项目的任务；外部影响他人，在行业内部通过活跃的表现来吸引他人，顺利推进各种合作。这两类活动就是“影响他人”从活动维度区分出的两个场景。

现在，让我们来看一下晓杨的案例，如果从活动的维度来区分，也就是到底这些技术人员都在为客户做什么服务，都包括哪些具体的、不同类别的活动。我们找到了如下四类活动，也就是四个场景：

•在潜在客户参观时，提供介绍性的服务（销售会带着一些潜在客户来参观机房，需要技术人员出来陪同，给予专业的介绍。这个场景下的服务要高度体现IT技术工程师的专业性）

•客户的服务器安装上线时的服务（客户一旦签约，就会把自己的服务器运送过来，机房的IT技术工程师要协助上架安装，这个时候很多客户的诉求是又快又好，但因为机房技术人员人手少、工作任务多等原因，容易与客户需求发生矛盾，导致客户服务满意度下降）

•客户定期来机房检查自己的机器时，提供的协助服务。（有的客户会定期来检查，或者针对自己机器进行一些操作，机房IT技术工程师不需要全程陪同，但是服务技巧好的技术人员会时刻关注客户的行为，一旦客户有需要就会马上提供帮助，这点对客户的感受和体验非常重要）

•客户的机器发生故障时，现场抢修服务。（客户的机器出现宕机或者其他问题的时候，他们会火速赶到现场，要求机房的IT技术工程师解决，这是最容易发生问题的环节。同样是在为客户解决问题，有的技术人员会收到表扬信，可很多人收到的是投诉信。除了技术水平有差距外，服务的水平是最重要的原因）

在看了具体的例子后，现在我们回过头再来看一下，为什么要给任务找场景呢？具体来讲，有两个理由：

1.围绕场景的最佳实践技巧是具体的、丰富的、接地气的。

如果仅是围绕关键任务寻找最佳实践，访谈到的、整理出的内容还是比较偏通用，例如单纯围绕“为客户提供满意的日常性、常规性的服务”来找技巧，恐怕找到的还是倾听、同理等基本的技能。

但是一旦找准了具体的场景，我们一下子就能挖到很多非常具体的、接地气的工作思路和方法。例如，在上面的案例中，其中一个场景是“客户来定期检查自己的机器时，提供协助服务”，我们就可以找到其中的一个专家，详细去询问客户在定期检查的时候，都有哪些诉求，最希望机房的IT技术工程师们提供什么信息；工程师们在提供协助服务的时候，都有什么注意事项、具体的话术可以是什么？可以制造哪些惊喜，让客户有超出预期的感受？这样萃取出来的经验，非常鲜活，“接地气”。

2.围绕场景的最佳实践最容易被复制到岗位上。

场景都是目标受众每天在具体工作的时候做的事儿，他们很容易把所学习的内容和自己的工作实际做关联。

例如，一个IT技术工程师每个月都会有2~3次陪同客户检查的机会，每次与客户预约好后，他就可以回顾一下这个场景下的最佳实践，马上就可以在客户来的时候去使用。

在识别工作任务的具体场景这个问题上，以下几点是需要注意的：

1.并不是所有的任务都一定要分场景，有的时候从一个关键工作任务出发去萃取经验也是可以的。例如，“一名管理者如何为员工提供改进型反馈”这种任务，就已经比较具体，也许不一定需要再细分场景。

可能你会提到，我可以根据任务的对象的维度来区分场景呀，比如员工分为“绩优型员工”、“动机不足型员工”等等。你说的或许是有道理的，一个最实用的检验办法是：根据你的思路先分好场景，然后看看每个场景下的工作方法是否有差别。如果你发现针对任何类型的员工，管理者给予反馈的技巧都差不多，那就说明这种场景区分的必要性就不大了。但是，如果你发现给不同类别员工做反馈的方法技巧差别很大，那就证明值得区分场景。

2.本书提供的“对象”、“渠道”和“活动”这三个划分任务场景的维度，只是最为常见的三个，可以帮助大家解决大部分的问题。但是，这三个并不是划分场景全部的维度，具体如何划分，还要和业务专家们进行沟通，找到他们划分场景的方法。

例如，我曾经萃取过一家互联网企业“管理者如何做好离职挽留”的最佳实践。在最开始，我们认为可以按照“对象”这个维度，把场景划分为“挽留高绩效的员工”和“挽留普通员工”这两个维度。但后来在访谈中发现，业务部门的挽留技巧很大程度上和这个员工离职要去哪里有很大关系，去向不同，挽留的方法和话术就不同。于是我们把场景划分为“离职员工要去BAT等大公司”、“离职员工要加入创业公司”、“离职员工要去竞争对手公司”等几个维度来区分场景，总结出了特别多非常实用的技巧。因为这些场景和一线实际管理工作贴合得特别紧密，学员就觉得非常有用，获得了一线管理者的高度认可。

“对象”、“渠道”和“活动”这三个维度，是基于多个项目经验逐步形成的一个小模型。但是任何一个人才发展的项目设计都无法做到完全精准，上面三个维度更多的是参考，是根拐杖，在我们缺少头绪的时候，找到一个起点和支点。在具体拆分场景的时候，还要随着实际情况不断调整，尤其是要时时刻刻与业务专家们保持沟通，如果他们不理解、不认可，那就失去意义了。

3.划分任务的场景，通常只选取一到两个维度，并不是一定要选取前面介绍的全部三个维度。至于选取哪一个，需要找到对业务有价值的维度、有难度的维度。

在上面的案例中，我们和业务部门一起沟通和确认了区分场景的这些维度，得到了如下反馈：

•虽然公司的客户分为VIP和普通客户，但是从服务的角度来讲，针对这两类客户并没有不一样的流程，而且服务技巧上也没有本质的区别，公司同样重视对普通客户的服务。因此，这个维度的区分可以取消。

•从“渠道”维度找出来的三个场景，需要去掉第一个“面对面服务”，因为后面以“活动”维度区分出来的场景都是面对面的，这两个部分有重叠。但是，通过电话和通过邮件这两个场景需要保留，而且要重点萃取电话服务技巧和邮件服务的技巧。

•从“活动”维度找出来的四个场景，业务部门认为都需要保留，而且非常准确。

在晓杨的案例中，针对“为客户提供满意的日常性、常规性的服务”这个任务，我们找到了6个场景。

针对另一个任务“在客户发生抱怨的时候，为客户提供满意的服务”，我们根据客户抱怨的常见类型，分成了3个不同的场景。

以上两个任务一共识别出9个场景，构成了这次最佳实践萃取项目的场景地图。

从上图中的9个场景出发，我们就要进入到最佳实践萃取的正式流程了。这些场景是从业务目标推导和识别出来的，因此我们有理由做这样的假设：只要萃取项目把这些场景下的工作方法、技巧整理出来，并进行有效复制，就能帮助达成”IT工程师提供更好客户服务”这个业务结果。

后续的最佳经验萃取要紧密地围绕这些场景进行。具体来讲，场景地图对我们的指导意义有如下几项：

•我们在寻找业务专家的时候，要按图索骥，找到那些有这些场景化经验的人。例如，在晓杨的案例中，他会找到客户服务中心的人来作为服务技巧的专家接受访谈，哪些人在处理哪几类客户抱怨时有过成功的经验，他们就应该是重点的访谈对象。而对于现场服务的几类场景，客服中心并没有直接的经验，则不应该成为专家，而要从IT技术人员群体内部去寻找，哪些人经常受到客户的表扬，服务技巧比较成熟的，他们就应该成为重点接受访谈的对象。

•在访谈找到的业务专家时，要请他们分享自己的成功经验，这些经验一定要对标我们的目标场景。专家们在自己所负责的工作领域都做得很好，如果不明确访谈主题的界限，他们可能会泛泛而谈，虽然很重要，但并不是我们需要的。因此，在访谈专家时，我们要时刻对标场景地图，引导专家专注在我们想解决的问题上，分享他们的经验和做法。

•访谈的最佳实践要涵盖全部的场景，不能遗漏。要达到这个目的，需要对萃取多少个专家、需要多长时间等问题，事前做好规划。

•有些时候，场景地图中的各个业务场景有发生的顺序，后期在向学员推送这些学习资源时，就要遵循场景地图中显示的业务顺序。例如，在晓杨的案例中，如果你要把9个场景化的最佳实践设计成课程、微课、或者其他类型的学习资源让IT技术工程师学习的时候，最好先学习“日常服务”下的6个场景，再去学习“处理抱怨”时的3个场景。

当前，在学习资源开发领域里，微课始终是一个热点话题。我认为，在这方面场景化下的最佳实践是最适合做成微课内容的，运用上面介绍的规划场景地图的办法，可以很好地把企业内关键岗位上的业务场景微课题目规划出来。