“你的培.需求我都知道”“不!你不知道!”

文 | 李宏兵 《..》杂志融媒体特约作者

来源 | ..杂志（ID：trainingmagazine）

..需求分析是被动支持还是主动出击、是简单归纳还是找出事实，这既是态度问题也是专业问题。

企业内部有相当数量..无效的原因是需求分析错了，导致..在错的方向上勤奋努力，结果就是..做了，但问题依然存在。

我认为需求分析有五个认知鸿沟要跨越，只有跨越低层次认知水平，才能让..“柳暗花明、对症下药”。

👇👇👇

一定要区分支持和咨询，..需求分析不是事务性工作，而是咨询性工作。要跨越“机械式”的支持，迈向友好协商的地带。

“业务要什么我们就给什么”是一种问题思考上的懈怠，引用一句资深..人的话“业务部门应该提业务需求，..部门应该提..需求”。遗憾的是，..经理往往接收的是业务部门直接提的..需求。

而我们一错再错的做法是直接给予课程、讲师、资源的支持，仅把..作为一项支持性事务，不对需求的合理性加以分析，结果注定无效，久而久之，..不再被看好。

为什么会出现这种情况？这和两个不成立的假设分不开。

第一个假设：业务经理认为“需求是合理的”且..经理认为“业务部门是想清楚了的，否则怎么会提出来呢，况且我也很难拒绝。”

事实上在业务部门面前，我们是..问题的专家，有义务帮助其纠偏..需求，要大胆设想“是否..做了问题就解决了”，若不是这样，那就要回到解决问题的初心。

第二个假设：“既然业务经理已经提出明确需求了，我负责支持就好。将来没有效果，也不是我的错。”

这种想法多出于自我保护的心理，不敢承担更大的责任。其实“借助..解决问题”是..部门和业务部门是责任共担的，..若无效，..经理至少有50%的责任。

所以，需求分析阶段，..经理应与业务经理共同协商要解决的问题是什么、基于什么判断要开展这样的..、训后学员做什么、要解决问题是否仅有..就够了。

问题和方案不同，..需求分析不是推荐..，而是找出有效方案。要跨越“..领域”的专业，迈向解决问题的专业。

我们常说“不要拿自己的专业跟业务死磕”，的确不必与业务部门大谈“成人学习理论”“心理学”“行动学习”这些专业术语。但很多..经理总想回到擅长领域，一旦获取有关“知识技能”的词汇，就立刻与业务经理确认，紧接着对号入座安排..，大谈熟知的课程和讲师。这种做法是在颠倒因果，当未搞..正的问题是什么时，就直接跳到解决方案做决策，这样做是极其不可取的，切忌一上来就横加判断给方案。

..经理无论面对谁，都应先定义问题、找出根因，最后找寻方案，之所以这样做有两个理由。

一是，业务经理未必真正知道自己的问题根因，或者他们总想避重就轻，通常会采用那些容易想到的而非更有效的手段。

二是，..经理应该找出解决方案和问题之间的逻辑关系，找出解决问题的充分且必要条件，“知识技能态度”或许只是一个部分，故而..可能是有效手段、可能是“组合拳”之一、也可能是无效手段。

需要注意的是，要区分不同角度的“专业”的概念，..经理多认为是“..相关理论”，而业务经理多认为“是否帮助他们解决问题”。

现象和本质有根本的不同，..不能人云亦云，而应透过现象看本质。跨越先入为主的武断，迈向严密推理的逻辑思考。

在任何情况下都保持冷静理性的头脑，这是..经理很难得的素养，可靠的结论不是那种折中的或更为人所接受的结论，而是有事实和数据依据、令人无法辩驳的结论。现象是问题的表现，本质是问题根源。

..经理应做两个方面的工作，一方面倾听了解业务部门的需求和问题表象，另一方面需要寻根究底、追本溯源、找出表面问题背后的根源。

有句名言“没有调查就没有发言权”，一个结论可靠与否不是听谁说了什么，而是经过实地调查研究后可以通过“因果关系”链条推导出来的。

主观判断和客观事实一定不能划等号，..需求分析不是简单的信息概括总结，而是尊重以事实为依据。要跨越“表面信息”，迈向对事实的阐述。

多数..经理擅于把接收到的需求信息进行提炼归纳总结，却往往忽略事实的部分。

第一，切忌凭主观判断做决策。

与..需求有关的问题只是问题的一种，通常在大量的信息内容中，一部分是事实的演绎和主观判断的内容，另一部分是事实本身。所有“凭感觉出来的主观判断和结论”都应该被悬挂、查证后再办，我们应该首先做的是还原事实本身、找出问题发生的上下文场景，再去验证最初的结论是否客观理性、是否遵循事实为依据。

第二，用事实佐证结论。

比如像“员工绩效差，需要提升技术能力”这样的阐述，员工绩效差可能是事实，因为有数据佐证。

但需要提升技术能力的结论是怎么来的，要达成高绩效，那么提升技术能力是否为关键因素？

我们知道提升绩效有很多因素，且在以往团队中高能力、低绩效者大有人在。如果没有事实佐证，很多的假设是不成立的，应从事实出发，具体问题具体调查和分析。

事实和逻辑是不同领域专家沟通的“桥梁”，..经理应先实事求是、保持逻辑，再基于这种原则与业务经理一起“寻根究底”。

课程不是结果，..交付物不是精品课程或项目，而是干系人期待的结果。要跨越对“课程交付”的承诺，迈向“满意结果”的交付。

..经理交付结果的过程包含课程和讲师，但最终要对预期结果负责。

第一，课程和讲师是过程，它必须能促进期待结果发生。

不能用课程满意度代替期待结果，因为课程满意度仅限于课堂的评价，若无法在训后会带来期待的结果，那么课程是无效的，况且这个结果不是由学员来评判的，而是由需求提出方来评判的。

试想纵然我为销售经理们安排了方法论..，学员掌握的很好且评分很高，但实际工作中不具备应用的环境，改变不会发生，期待结果亦不会出现。

第二，知识技能必须成为满意结果的必要条件。

试想我给消防员安排了一次厨艺知识的讲座，就课程内容而言学员都能熟练烧菜，但这个技能对于消防员而言是需求方期待的结果吗？！这就如同“南辕北辙”所讲的马车很好、马夫很熟练、盘缠很多，跑得很快，但方向错了。

..经理应扪心自问“假如把课程比作产品，产品自身质量固然重要，但更重要的是，使用产品后用户会做什么，会带来什么结果”。

第三，..经理要对“ROI”负责。

一次..或一个项目，它既花了时间又投入了人力和成本，却没有带来干系人期待的结果，试想干系人会怎么想？

从商业角度看，任何企业投入都要有回报的，若不能带来价值，那是..经理的失职。

所以，我们承诺的不只是课程交付，更是期待的结果，先以终为始，再以始为终，找出期待结果应在需求分析阶段完成。

最后，送给大家一张《课程需求定义表》，旨在建立..与要解决问题之间的逻辑关系、澄清业务期望结果，确保未来的..以解决问题为中心而不是以知识为中心，确保课程开发的方向。