gitbook/朱赟的技术管理课/docs/802.md

# 01 | 职场分身术：从给答案到做引导

    在学校读书的时候，偶尔作业不会做，我很可能会问同学，他很可能会把答案直接给我。但是，如果我去问老师，他很可能给我一些启发和引导。这正是我对不同帮助类型最初的感受。

进入职场之后，你我也经常会碰到需要别人帮助的情况。比如说，新入职时不知道怎么搭开发环境、不知道如何去写第一个代码块；或者是一个问题有两种处理方案，而你不知道应该选哪一个；又或者遇到了一个 Bug，不知道该从哪里下手。

记得我刚开始带新人的时候，对系统的各种设计和业务逻辑已经非常熟悉了，所以每次他们有问题找我，我基本上都能快速给出答案。即使我没有现成答案，也能很快地帮他们定位问题和找到答案。

当时我没有带人经验，因此也就没有想太多。当时我是小组中最资深的一个，所以每次有人问问题，我都会下意识地紧张，生怕不知道解决方案，没办法帮到对方。而我的注意力，便大量放在了“帮他找到答案”上。

但是，每次别人问问题，你都有现成的答案，或者能快速找到答案，就会渐渐导致两个问题：第一，在你这儿容易得到答案，愿意问你问题和各种琐事的人越来越多；第二，你给的是答案，下次有类似的问题，别人还可能来找你。

**这样一来，你每天都会花大把时间在“带新人”上，而其中很大一部分时间就是在回答各种随机的问题。**

**我变得越来越忙，看起来似乎越来越重要，有时我不在，问题就成了瓶颈，因此我本身也就成了瓶颈。当组里人慢慢多起来的时候，这种模式根本不可能扩展，而那些重要和紧急的事情，我却没有时间关注和解决。**

那时老板就和我说：“你不能每次都给答案，你应该试着用引导的方式，让对方学会自己找答案。”

这话听起来简单，但做起来却很吃力。直接把答案告诉对方可能只需要5分钟，但是和对方坐下来一起梳理问题，找到解决方案，帮助他自己想明白，可能要花费半小时。

时间上一对比，我更多地选择了前者。我越忙的时候，越会用最简洁的方式直截了当地给出答案。这样就造成了恶性循环：越来越多的问题找到我，我为了省时间以最快的速度给出答案，对方并没有学会自己解决，变得越来越依赖我。

当超过一个临界点时，我实在没办法处理各种随机的问题了，之前有问必答的系统崩塌了。既然没有时间去回答所有问题了，这时我就不会给出最直接的答案了，反而会选择“拖一拖”再处理，或者给出一些想法。

比如“如果是我，我会尝试去看某某文档” 这样的建议，或者是“你觉得这个线上错误可能是哪些地方引起的呢？”“你有没有试着用排除法，先把那些不可能的因素排除掉？”很多时候用不了太久，对方就会很高兴地跑过来告诉我，问题找到了，或是知道该怎么做了。

当然，我的转变其实是个漫长的过程，但是现在回过头来看，确实有一些心得可以分享。

**首先是：什么时候适合直接给答案，什么时候适合给线索，让对方自己找答案。**

我觉得，如果是一个新人，他刚进入全新的领域，或者所谓的答案就是某些知识点，此时不妨直接给答案或知识点。因为这些问题，即便他全然没有线索，我们也不可能让他自己去推导出业界多年发展才形成的规则和规律。

等对方已经有一定的积累和经验后，就可以让他自己去探求解决方案了。这时候我们需要给出一些提示，或者这样说：“对于问题本身，我也没有完整的答案，只有些直觉和想法。”给他方向和建议，让对方继续寻找，这样比把问题解出来，然后再直接告诉对方一个确切的答案更有意义。

**其次是：如何引导。**

这里最关键的一点是，问对方正确的问题，通过问题去引导对方进行深入思考，找到解决方案。当一个好问题摆在面前的时候，人们更容易主动思考，他们会跳出自己之前设定的方案和框架，换一个角度去看待问题；或者被带到一条之前没有发现的道路入口，然后自己走下去，直到找到答案。

**最后是：引导的好处。**

虽然最终的结果都是对方找到了想要的答案，但如果是通过别人的引导，自己摸索出来的，那么他解决类似问题的能力后续就会提升。这样的做法，还可以调动他工作的积极性，对方会产生一种自己解决了问题的成就感。

此外，更好的事情可能会发生。获得引导帮助，对方甚至会结合他的经验，经过持续的努力找到更好的答案或者解决方案，甚至引发对系统的改进。

我们常说“授人以鱼，不如授人以渔”，但在实际工作中什么时候直接给出答案，什么时候给出方法和引导呢？希望你可以参考我今天分享的内容进行实践。欢迎你给我留言，和我一起探讨。