职场之锤
布置任务总被误解？向下沟通，关键不是讲明白，而是让人做得动
虎头锤 · Staff Engineer本文另有英文译文 · 阅读英文版 →
“这也太离谱了吧？明明讲过三遍，怎么还是没做对？”
很多管理者第一次带人，都会有类似的吐槽。
但后来慢慢会发现，这种沟通问题，不是因为对方理解力差，而是我们说话的方式不适合对方的状态。我们习惯了从自己的立场去表达，却忘了一句话落到对方耳朵里，到底是不是一个能直接动手执行的信号。
这篇文章，就来聊聊：面对向下沟通，怎么说，才能让对方听得懂、做得动、越做越清楚？
一开始就讲怎么做，比强调做得好更重要
我们经常会说：“这个文案太不打动人了”, “感觉逻辑有点乱”，“要不你再顺一顺这个流程”。
这些话虽然不是错的，但对新同事来说毫无参考价值。
他会想：“怎么才叫打动人？是加数据？加比喻？换一种语气？还是根本要重写？”
“流程不顺是哪个环节？交互问题还是信息架构问题？”
我们说的是感受，但他需要的是方向。
所以，布置任务的第一步，不是指出问题，而是先告诉他从哪儿下手。
比如别说这个流程不顺，而是说：
上个版本用户在第二步掉线率很高，这一版我们希望能把两个点击合并成一屏完成操作。你重点优化这一段的路径。
听起来差别不大，但执行结果天差地别。
我们说得太抽象，对方就只能靠猜
“顺一点”“，不要割裂”，这些词我们可能早就习惯了，但对新同事来说完全不知道该从哪儿开始。
他搞不清楚哪一步不顺，也不明白“割裂”到底是页面跳转的问题，还是用户行为的问题。
更常见的是这种场景：
我们说：“流程不够清晰。”
他改完后，我们说：“看起来变化不大。”
他又改，我们又说：“还是没抓住重点。”
改三轮还过不了，我们觉得他做得不行，他觉得你没说清楚。
问题根源不是工作内容，而是沟通方式没有帮助他搭建判断体系。
所以在布置任务时，如果能用5W2H把任务具体化，就能大大减少误解。
举个例子：
What： 优化A产品的注册流程 （具体要做什么？）
Why：当前掉线率超过20%，转化率低 （这个任务对结果或目标的价值是什么？）
Who：你和设计师B配合，开发由C支持 （是谁负责？是否涉及其他配合人）
When：预计下周二前出Demo （最晚什么时候交付？是否有中间检查点？）
Where：重点优化前两步的交互 （交付物是什么？有没有协作空间或文件？）
How：参考竞品X/Y，减少点击数 （建议用什么方式做？有参考模板或流程吗）
How much：成本控制在现有框架内，不新增开发人力 （标准/范围/预期工作量是多少？）
听完这个任务，大部分人心里就不会空了。
不要怕啰嗦，怕的是模糊
有些管理者担心讲太多像在手把手教，会不会让人觉得不信任。
但真正的问题不是讲太多，而是讲得太空。
一个实战建议是：把要做的事拆成两部分讲——
一部分是你希望最终达成什么（让对方知道你的期望是什么）
一部分是对方可以怎么开始动手（让他知道第一步怎么迈出去）
比如你想要一个更简洁的推广页文案。
可以说：
这版文案段落太多，容易让人跳出。我们希望这一屏能在10秒内说清主打功能。你可以试着用一句金句开场，直接点出产品价值，再配一个用户转化的数据。
不是直接给答案，而是给方向和起点。
听懂和听进去，是两回事
还有一种场景是，我们说了，对方也点头了，但最终交付的结果还是偏了。
这是因为他听懂了字面意思，但没能形成内在理解。
一个特别有用的做法是，在对方开始动手前，请他用自己的语言再说一遍他理解的任务重点。
这不是对对方不信任，而是确保彼此在同一个频道上。
比如说：
你刚听下来的意思是怎么理解的？你觉得这个页面的核心目标是什么？准备怎么动手？
这几句话，可以帮我们发现他有没有误解，也能让他自己捋清楚思路。
布置任务≠一次说清楚，而是持续建立互信
有经验的管理者，都会在任务过程中不断提供反馈。
而这种反馈，不是你错了，而是这里有个地方你可能没注意，或者我们可以试着换一种方法。
比如一个新同事写了一个用户分群的逻辑，但用了不稳定的字段。
我们可能一上来就想说：“这样写不太稳，重跑会挂。”
但更好的说法可能是：
这个字段我们以前也用过，但有个问题是它在极端情况下不稳定。你可以试着把字段X当作主键，对后续分析更稳。
这样既表达了期待，也保护了关系。
向下沟通的核心，不是你说了什么，而是他有没有感受到你在帮他做得更好。
一个小小结语
很多人觉得带人难，是因为对方太嫩或者不主动。
但真正的带人，是让一个人从看不懂你怎么想，变成知道自己该怎么做。
从我交付你要求的，变成我交付你真正想要的。
这不是天赋，而是沟通方式的问题。
如果我们愿意多想一句、多问一声，慢慢就会发现：
越清楚地讲清楚，我们带的人也就越清楚地在进步。