3.5 设计课程形式

依据知识、技能、态度等不同性质的课程内容,以及知道、领会、掌握等不同的课程目标,应采用适合的课程形式将其呈现给学员。比如,对于需要学员记住的知识类内容,宜采用考试、竞赛或讲授等方式呈现;对于需要学员掌握动作技能、操作要点的技能类课程内容,宜采用示范、观摩、演练等形式呈现;对于需要学员理解并应用的能力类内容,宜采取案例分析、小组辩论等形式呈现。下面,本书介绍一些主要的、常用的课程呈现形式。

3.5.1 案例教学

案例教学(Case Method)是由美国哈佛法学院前院长朗代尔(C.C.Langdell)于1870年首创,后经哈佛企管研究所所长郑汉姆(W.B.Doham)推广,并迅速从美国传播到世界许多地方,被认为是代表未来教育方向的一种成功的教育方法。20世纪80年代,案例教学引入我国。当前,案例教学是国内企业培训的主流培训形式。

案例教学是一种高度开放与互动性强的教学方式。要开展案例教学,需做好以下工作:在课程研发阶段,要经过周密的策划和准备,要使用特定的案例;在课程实施阶段,要在课前指导学员提前阅读案例,在课上组织学员开展讨论,学员和培训师之间应多多互动与交流。需注意,案例教学一般要结合一定的理论,通过各种信息、知识、经验、观点的碰撞来达到启示理论和启迪思维的目的,即让学员“知其然,知其所以然”。

在案例教学中,所使用的案例既不是“杜撰”出来“讲道理”的故事,也不是写出来阐明事实的事例,而是为了达成明确的教学目的,基于一定的事实而编写的故事,将其用于课堂讨论和分析之后会使学员有所收获,从而提高学生分析问题和解决问题的能力。

在案例教学中,案例一般分为总结型案例、决策型案例,分别对应不同的教学设计结构,如表3-4所示。

表3-4 案例教学课程结构

表3-4介绍的案例教学模式,均是研发难度一般、培训师授课时驾驭难度一般的教学形式。讲师也可以采用逐一抛出问题、问题层层递进、引导学员分析、最终实现教学目的的方法,这种方法的课程研发与授课难度相对较高。

案例3-1 总结型案例(沟通案例节选)

(场景一)需技术经理入场

时间回到一个月前……

“项梅,其他两个厂商安排的15名开发人员至今都还留在现场,而你们只剩下9人,亏你们还承接了这个项目最关键、最难做的一块。这次我们要求技术经理一周后入场,你们可别出问题,一周后领导来视察,别说我没提醒你啊!”和项梅一起用餐的柯菊说。

客户的这个项目由三家厂商共同完成,客户要求每家厂商都派驻15名开发人员入场。让项梅倍感骄傲的是,在客户如此坚持的情况下,朗新仍旧可以撤出6名人员支持其他项目。客户虽然颇有微词,但每次工作考核,给朗新的评价都是优秀。项梅暗想,自己既要考虑客户需求,也要考虑朗新需求。

“必须入场吗?远程工作行吗?系统设计在哪里都能做好的。”项梅深知公司近期启动了好几个大型项目,不乏战略性项目,听说技术部门的同事都忙疯了,已经没日没夜地加班一个多月了。并且,和公司同期的其他项目相比,这个项目只有百余万元的合同额,这时让公司安排一个技术经理入场比较难,所以她才试探着问柯菊。

“你又和我讨价还价,技术经理入场这可是合同规定的,并且你看看最近的需求变更和工作量,不来现场还怎么工作?何况我们领导下周来视察,其他厂商的技术经理都在,就你们的不在,你觉得合适吗?”柯菊不悦地反问道。

“好,下周入场,我们朗新的工作质量是最好的,什么时候让你们操心过?”项梅自信满满地说。

项梅虽然做出保证,但心里一直在打鼓,真的不好协调啊!

季总是技术部总监,负责技术部所有工作和人员的安排,说服季总是关键。季总在朗新工作十余载,大家普遍认为季总拥有战略远见,说话直接,目标明确,做事情讲究效率。

思虑再三,项梅决定给季总写一封邮件……

(场景二)技术经理拒入场

邮件发出不久,项梅就收到了季总的回信:“季竹负责此事。”

季竹!这是让项梅又恨又爱的一位同事。项梅与季竹曾经打过交道,这个项目的初期设计就是季竹负责的。季竹专业知识丰富,业务能力强,工作效率高,敢说敢做,就是有些傲慢,大局观和全局意识稍微差些,和客户及同事的配合不那么密切,而且做事缺乏主动性,对自己觉得不重要的工作有些敷衍。项梅回忆起之前的合作经历,依然心存芥蒂。

果然,季竹很快就回复了邮件:“电脑坏了,修好再去!”

看到这封邮件,项梅差点没背过气去,同时又觉得好笑。多年的工作经验告诉项梅,情绪是杀手,越是这样越要冷静。换个角度想,也许季竹真有难处呢?比如,也许他真的在修复电脑,很快就能修好;也许最近项目太多压得季竹喘不过气;也许……想着想着,项梅的心情平复了很多。

这时,邮件图标又在闪烁,季总回复邮件:“电脑修不好你就不去了吗?”字里行间,隐隐透着季总的怒气。

项梅深知依靠权力影响人是最不得已的策略,权利带来的只是服从,影响力造就的是合作。既然季总有了安排,自己该找季竹谈谈了。否则,带着情绪也难以开展工作,客户更不会满意。项梅拿起电话,随即又放下。常听人说“如果谁让你没面子,往往是你自己先让人家没面子”。项梅想:是不是自己的某些做事方式不妥?为什么季竹会这么抗拒入场?他有哪些难处?对于入场这件事,季竹有什么看法?他会提出哪些理由呢?我们怎么解决问题呢?我能接受的底线在哪里?自己和季竹不在一个部门,还是同级,怎样才能说服他呢?思考良久,项梅又拿起了电话。

“季竹,你看我正身处龙潭虎穴呢?电脑都快震坏了。”项梅打趣道,希望能消除季竹的“敌意”。

“有话直说,你是催我过去吧!你看我们这里现在的项目,哪个金额不比你那个项目高!这种情况都没有让我入场呢!资源是有限的,应该投入在重要项目上。”季竹将听筒夹在胳膊和脑袋之间,两只手还在快速地敲打键盘,冷冷地说。

“你说得很有道理,我在给季总的邮件中也解释了需要技术经理到场的原因,季总转给你了吗?并且你看,虽然这个项目金额小,但也是咱们公司实力的体现啊!如果这个你口中的小项目我们都无法让客户满意,客户怎么会想谈大项目呢?这会影响咱们公司和客户的关系。下次销售怎么拿项目?并且这个客户也是你负责的,这次入场也是你和客户建立关系的好契机啊!而且在这个项目之后,确实有一个大项目等着咱们挖掘。项目一期的设计客户特别满意,客户现在充满期待……”项梅解释道。

季竹没有言语,心里嘀咕:“你也不和客户争取一下,客户提什么要求你们都同意!也许远程支持就可以呢!”

项梅仿佛听见了季竹的腹诽,说道:“我已经努力说服客户了,看有没有其他办法……”

“好吧,你总有道理!可是我得晚一周去,我手里还有一些紧急方案要做,这周内必须出来。”季竹坚持说。

“据我了解,客户要求技术经理下周就进场,并且客户领导下周来视察,还要谈系统设计问题。你晚一周入场,我很难办啊!”项梅解释道。

“我手里的工作下周内必须做完,你请季总安排其他人去吧!”季竹将球踢了回来。

项梅强忍不快,说道:“我同意你的观点,我这里也有一个蛮好的主意,你看我们这样做行吗?你先按客户要求的时间进场,进场后兼顾你手里的工作,这样问题不就解决了嘛!再说,季总已经做出了决定,安排你来,你能不来吗?你了解季总的。”

“好吧,我过去,不过跟你干活太辛苦了,你总承接其他厂商不愿意做或者特别有难度的活。”季竹抱怨。

“太好了,那你下周就过来,记得给季总回个邮件!”项梅提醒季竹,接着说,“咱们也好久没见了,正好聚聚,这里附近开了一家你最喜欢的火锅店,有时间请你吃火锅!”

就这样,季竹接受了任务,如期入场。

请思考:项梅是如何说服季竹的?

案例3-2 决策型案例(沟通案例节选)

“项梅,其他两个厂商安排的15名开发人员至今都还留在现场,就你们只剩下9人,亏你们还承接了这个项目最关键、最难做的一块。这次要求技术经理一周后入场,你们可别出问题,一周后我们领导来视察,别说我没提醒你啊!”和项梅一起用餐的柯菊说。

这个项目由三家厂商共同完成,客户要求每家厂商都派驻15名开发人员入场。让项梅倍感骄傲的是,在客户如此坚持的情况下,项梅项目团队仍旧可以撤出6名人员支持公司的其他项目。客户虽然颇有微词,但每次工作考核,给项梅项目团队的评价都是优秀。项梅暗想,自己既要考虑客户需求,也要考虑自己公司的需求。

“必须入场吗?远程工作行吗?系统设计在哪里都能做好的。”项梅深知公司近期启动了好几个大型项目,不乏战略性项目,听说技术部门的同事都要忙疯了,已经没日没夜地加班一个多月了。此外,和公司同期的其他项目相比,客户的这个项目合同额较小,只有百余万元。这时让公司安排一个技术经理入场比较难,所以她才试探着问柯菊。

“你又和我讨价还价,技术经理入场可是合同规定的,你再看看最近的需求变更和工作量,不来现场怎么工作?更何况我们领导下周来视察,其他厂商技术经理都在,就你们不在,你觉得合适吗?”柯菊不悦地反问道。

“好,下周入场,我们的工作质量是最好的,什么时候让你们操心过?”项梅自信满满地说。

项梅虽然做出保证,但心里一直在打鼓,真的不好协调啊!项目一期的设计是季竹负责的,客户对项目一期的设计很满意。若协调技术经理入场,季竹是最适合的人。可提起季竹,不禁让项梅又恨又爱。

季竹专业知识丰富,业务能力强,工作效率高,敢说敢做,就是有些傲慢,大局观和全局意识稍微差些,和客户及同事的配合不那么密切,而且做事缺乏主动性,对自己觉得不重要的工作有些敷衍。项梅回忆起之前的合作经历,依然心存芥蒂。

季竹的直接领导—季总,负责技术部所有的工作和人员安排。季总在公司工作十余载,大家普遍认为季总拥有战略远见,说话直接,目标明确,做事情讲究效率。

该如何协调季竹入场呢?季总的意见很关键!那么,是自己直接找季总,还是请项总支持呢?还是尽量不麻烦领导,自己先扛下来,再想办法协调解决吧。

项梅计划给季总写一封邮件……

邮件发出不久,项梅就收到了季总转发给季竹、抄送给自己的回复:“季竹负责此工作。”

“电脑坏了,修好再去!”季竹很快就回复了邮件。

“电脑修不好你就不去了吗?”季总回复了邮件,语气中隐隐透着不快。

看到季竹的回复邮件,项梅差点没背过气去,同时又觉得好笑。不过,项梅也听说季竹近期疯狂加班,几个技术方案的交付时间和自己客户的入场时间重合,季竹也很难将这几个技术方案交给其他同事接手。

项梅深知依靠权力影响人是最不得已的策略,权力带来的只是服从,影响力造就的是合作。既然季总有了安排,自己也该找季竹谈谈了。否则,季竹若带着情绪开展工作,客户不会满意的。

请思考:如果你是项梅,你会如何说服季竹呢?

3.5.2 结构化研讨

当前,企业培训课程越来越重视学员的参与,即注重学员群策群力发现问题、解决问题的能力。因此,结构化研讨日益成为主流的课程教学形式。

结构化方法是一种传统的软件开发方法,它是由结构化分析、结构化设计和结构化程序设计三部分有机组合而成的。它的基本思想是:把一个复杂问题的求解过程分阶段进行,而且这种分解是自顶向下、逐层分解,使得每个阶段处理的问题都控制在人们容易理解和处理的范围内。

在引导技术中,结构化研讨是团队分阶段、分层次地针对某一个问题展开深入对话,并就成果达成共识的过程。几乎所有有效的结构化研讨均要经过发散、收敛两个阶段。所谓发散,即从一到多的过程,也就是说,学员对某一主题或问题充分发表自己的观点的过程;所谓收敛,即从多到一的过程,也就是说,学员对某一主题发表众多观点,根据一定的标准与程序,形成小组共同观点。从发散阶段到收敛阶段,中间往往要经历一定的震荡,即学员不同观点的充分碰撞。结构化研讨过程如图3-6所示。常用的结构化研讨工具如表3-5所示。

图3-6 结构化研讨过程

表3-5 常用的结构化研讨工具

3.5.3 角色扮演

角色扮演(Role-playing)伴随的是情景模拟,即学员在模拟的“环境”或“场景”中扮演角色,并应对可能出现的问题,体验某种行为的具体实践,以帮助他们了解自己,改进提高。角色扮演情景模拟如图3-7所示。角色扮演任务卡如图3-8所示。

图3-7 角色扮演情景模拟

图3-8 角色扮演任务卡

3.5.4 课程概要设计

完成课程需求分析、课程目标编写、课程内容设计、课程形式设计之后,就要进入正式的课程资料开发阶段,即研发讲师手册等。为了保证所开发的课程能够满足学员需求,符合课程开发需求提出方的期待,在正式开发课程资料之前,往往要先进行课程概要设计,即概要呈现课程内容的分析结果、课程形式的设计结果,并与课程培训需求提出方就课程概要设计内容沟通确认后,再进入正式的课程资料开发阶段。课程概要设计表如表3-6所示。

表3-6 课程概要设计表