你好，我是华仔。
上一讲我介绍了5W根因分析法，教你通过追问5个为什么来找到问题的根本原因。不过，找到原因不等于解决问题。
这就好比大夫看病，光是看出来患者的病根在心脏还不够，还要明确心脏到底出了什么毛病，是只用服药还是需要做手术，如果要安排手术，具体要怎么操刀。
处理问题也是这样，它是一个复杂的系统工程，既能够反映你的专业能力，又能够反映出你的综合能力。所以问题既有可能成为拖垮你绩效的陷阱，也有可能成为你晋升的机遇，关键在于你如何有效地去处理。
那么问题到底要怎么处理呢？我总结了一个5S问题处理法，也就是把处理问题的过程分为5个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。
接下来，我会为你逐一讲解这5个步骤。
第一个步骤是，明确问题。
我有个朋友曾经遇到过这样的情况：
领导跟他说，最近团队士气好像不高。他立刻分析了8点原因，并提出了针对性的改进意见，还觉得自己反应很快，能力很强。
然后领导就让他负责提升士气，于是他组织培训和团队活动，搞各种评奖，推出各种新制度……干了一大堆事儿。
结果半年后，老板说，感觉士气还是没什么变化。
这其实是很多人都会犯的第一个错误：问题本身都没有明确定义，就直接开始采取行动。结果很可能就是，你做了很多事情，但无法衡量。
所以你一定要提醒自己，在解决问题之前，先要明确问题。（这本来是不言而喻的道理，但是在实际工作中我们往往容易忘记。）
怎么明确呢？根据问题有没有用数据量化，可以分为两种情况。
首先，对于已经用数据量化的问题，关键在于确认数据是否准确。
通过数据来展现问题是比较直观的，而且很多人认为“数据不会撒谎”，所以他们看到数据之后就直接开始处理。
但其实这种情况也是需要明确问题的。因为数据可能出错，出错的原因有很多种，可能是源数据出错，也可能是计算时出错。
我就多次遇到过报表系统出问题导致业务数据异常的情况；也遇到过统计部门调整算法但是引入bug，从而导致数据错误的情况。
怎么确认数据是否准确呢？最方便的方法当然是让数据部门去核对，但是可能耗时比较长；而最快速的方法则是通过多个关联数据互相验证。
以互联网电商业务为例，如果月销售收入下降了20%，但是月订单量和月活用户（MAU，Monthly Active User）都在增长，那么很可能是销售收入的数据统计出了问题。
其次，对于没有用数据量化的问题，又可以分为两类。
一类是可以量化但是还没量化的，比如“业务增长放缓”，其中的“放缓”到底是什么意思，是增长速度从100%下降到60%，还是增长速度从10%下降到6%？不同的人理解可能千差万别。
对于这一类问题，你把量化的环节补上就行了。比如老板说：“我对当前的利润增长速度不满意，希望更快一点。”你就要明确，老板关注的指标是季度增长率还是月增长率？更快一些具体是多快，20%还是50%还是200%？
另一类是无法简单量化的，比如“团队士气不高”，其中的“士气”只是一种主观感受，很难量化。
所以这类问题是最棘手的，一是士气不高也许只是领导自己的感受有问题，并不是真的存在这个现象；二是就算真的士气不高，改善的效果也很难衡量。
你怎么证明你提高了士气，又怎么证明士气到底提高了多少呢？
直接用数据来衡量肯定是不现实的。经过实践摸索，我发现调查问卷是一种比较有效的方法。既然是主观感受，那我们就综合大多数人的主观感受来得到一个相对客观的评价。
这就像一部电影好不好，虽然不能用片长、投资金额或明星数量来衡量，但是如果看过的观众都来打分，最后综合算出一个分数，还是有一定参考意义的。而且评价的人越多，越能客观地反映影片的质量，这也是豆瓣等平台的价值。
调查问卷的设计技巧总结如下：
如果你的P8或P9级别的领导让你帮他分析一下团队的士气，那么你可以这样设计调查问卷：
注：仅为示例，实际的问卷内容要更多一些。
基于多份问卷的结果，就能在一定程度上分析出团队士气情况和整体成员的认知情况，从而避免个人主观判断的偏差。
不过，如果团队的人数很少，就不要用调查问卷了。比如你是P7的Team Leader，手底下带了5个人，现在你觉得团队士气不高，可以直接找他们一个一个聊，这样效果更好。
第二个步骤是，拆解问题。
明确问题之后，你是不是就准备急着去分析原因了呢？毕竟你是负责人，领导还等着你的答案呢。
这就是很多人都会犯的第二个错误：把自己当成拯救世界的超级英雄，以为可以一个人搞定所有的事情。
如果问题很简单，那么确实可以这样做。但大部分问题其实是比较复杂的，甚至有的问题看起来很简单，实际上可能涉及很多方面，如果你只靠自己一个人去分析，也许花了很长时间都搞不定。
所以为了能够更高效地分析问题和更快地给出解决方案，你要学会拆解问题。
具体的做法是，对问题进行初步的分析，将大问题拆解为几个独立的子问题，然后再根据子问题的数量和规模，看看是否需要申请更多人力资源来一起参与问题处理。
简单来说，就是不要单打独斗，要学会利用团队力量。
至于按照什么维度拆解，这就和问题本身有关了。业务类的问题，可以按照业务类型来拆解，也可以按照客户群体来拆解；管理类的问题可以按照流程来拆解，也可以按照事项分类来拆解。
拆解问题有几个常见的小技巧：
比如电商业务的“订单数下降30%”，你可以按照业务类型来拆解，看看不同品类各自下降了多少。
经过分析，你可能会发现，“男装下降了20%”、“鞋类下降了30%”、“食品下降了20%”，其它品类的数据还是增长的。
于是，“订单数下降30%”这个大问题拆解成了3个子问题，你可以分别协调对应的运营负责人来一起处理。
又比如“团队研发效率不高”，经过调研发现，团队反馈最多的前4个问题是“会议太多”“测试环境不足”“发布太麻烦了”和“需求变更太频繁”。
如果你一个人搞不定这4个子问题，你可以分别协调项目经理、测试负责人、运维负责人和产品负责人来一起处理。
第三个步骤是，定位问题。
我曾听过这样的案例：
半年的业务买量数据不升反降，老板让运营负责人赶紧想办法。于是他连夜构思解决方案，提出了几个大展拳脚的方案，比如SEO优化、增加更多渠道等。
老板大手一挥批准其中3个方案，半年后一看，投入多了几千万，买量的数据却没有多大起色，老板脸色很难看。
这就是很多人都会犯第三个错误：没有找到根本原因的情况下，就急于给出解决方案。
如果你只找到了表层原因，那么后续提出的方案就是无法从根本上解决问题，只能白白浪费时间和资源。
定位问题的技巧就是5W根因分析法，我在26讲已经介绍过了。需要注意的是，根本原因可能不止一个，不同的追问线索可能找到不同的根本原因。
比如“加班太多导致士气不高”，我们也许可以得到两个根本原因：“市面上的Go程序员较少” 和 “没有项目经理”。
问题1：为什么士气不高？
答：因为加班太多。
问题2：为什么加班太多？
答：因为人力不够。
问题3：为什么人力不够？
答：因为招聘困难。
问题4：为什么招聘困难？
答：因为市面上的Go程序员太少。
针对“市面上的Go程序员太少”这个根本原因，对应的解决方案可以是“招聘C/C++程序员然后培养成Go程序员”。
接下来是沿着另一条线索追问的情况：
问题1：为什么士气不高？
答：因为加班太多。
问题2：为什么加班太多？
答：因为项目执行混乱。
问题3：为什么项目执行混乱？
答：因为没有项目经理。
针对“没有项目经理”这个根本原因，对应的解决方案可以是“招聘专职项目经理”。
第四个步骤是，解决问题。
定位出问题的根本原因之后，你就需要提出问题的解决方案。
解决方案往往涉及资源的投入（增加广告投入预算）、组织的调整（成立专项小组）和系统的增强（增加配置检查功能防止运营配置出错）等，所以你需要得到上级的认可和支持。
这时很多人都会犯第四个错误：思维比较局限，只做了一个方案提交给上级。
你信心满满地把自己的解决方案提交上去，本来希望得到赞赏，结果却发现上级有更多的想法或不同的方案，反而认为你考虑得不够周全。
那么，怎么做才能很快得到上级的认可和支持呢？
你需要提供多个方案，并且给出你建议的方案和原因，最终让上级来挑选和拍板。这就是我在第24讲介绍的3C方案设计法。
第五个步骤是，落地行动。
方案得到批准后，你就要落地执行，真正解决问题。很多人在这一步容易犯问题处理的第五个错误：做事没有重点和优先级，眉毛胡子一把抓。
在前面的步骤中，你可能拆解出了3个子问题，然后每个子问题分析出2～3个根因，每个根因分别给出了对应的解决方案，接着每个解决方案又可以分成3～5件事情来做。最后你发现，可以做的事情有几十件。
你可能会认为这些事情都是有价值的，所以用一张Excel表格全部记录下来，然后从第一件开始一件一件地去做。
但是这样做的结果很可能是，你做了几个月，但是却看不到什么效果。
因为每件事情的价值有大有小，见效时间有快有慢，你的领导并不关心你做了多少件事，他们关心的是，问题有没有真正解决。如果看不到明显的效果，就算你做得很辛苦，也很难得到认可。
正确的做法就是先做优先级排序，然后挑选优先级TOP N的事情去做，尽快看到成效，让问题不断地改善。
优先级排序的技巧总结如下：
明确需要落地的TOP事项后，就可以用第25讲介绍的PDCA执行法来执行了。
现在，我们回顾一下这一讲的重点内容：
这就是今天的全部内容，最后留一道课后思考题给你吧。你职业生涯中处理过的最棘手的问题是什么？你在处理过程中是否犯过某些错误？如果是学完这一讲之后再交给你处理，你会怎么做？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
评论