前言
工作中真正让人累的，并不只是上司严厉。
就算严厉，只要判断明确、有优先级、有目标、责任范围清楚，人还是能往前干的。
最累的，是上司这样做事：
- 不拍板
- 不同步信息
- 不把要求落成明确的需求
- 口头含糊带过
- 事后翻脸变卦
- 把局部的小毛病放大成整体的责任
- 最后把问题归结到下属的性格或特质上
在这样的上司手下，越是擅长需求梳理（把要做什么、为什么做、谁来定、在什么条件下做讲清楚）的人，越痛苦。
因为我们为了把事情推进下去，会去看目的、现状、原因、相关方、执行条件、风险和拍板的人。
而上司只看表面印象和一点点瑕疵，然后开始挑刺。
结果就是，双方说话不在同一个层面上。
我们在谈业务怎么设计。
上司在谈看起来怎么样、给人什么印象。
我们解决的是主要问题。
上司只捡一些次要的改进点来说。
这种错位越积越多，上司就不再是支持者，而成了纯粹的噪音。
1. 对上司的期待，只要“判断、优先级、担责”就够了
有些人自己就能把工作往前推进相当一段。
比如能做到下面这些：
- 能理清目的
- 能掌握现状
- 能找出瓶颈
- 能把方案分成 A 案、B 案、C 案
- 能提前预判风险
- 能和其他部门沟通
- 能把相关人员拉进来
- 能留下记录
- 眼看要出事就能叫停
- 需要时能在短时间内做出方案文档
对这样的人来说，对上司的期待其实很有限。
本来，希望上司做的只有这些：
- 做判断
- 定优先级
- 正式出面和其他部门打通
- 承担责任
- 负责向上说明，替下面挡一挡
- 不要多余地事后加码
反过来说，不做这些的上司，就相当碍事。
只会说“你去推进”，却不做判断。
只会说“你自己想想”，却不定优先级。
只会说“你去跟其他部门谈”，却不给正式的支持。
只会问“现在怎么样了？”，却不承担责任。
最后还追问“你为什么要做？”“你为什么没做？”。
这不是在给团队增加价值。
反而是在给工作添噪音。
2. “能和上面的人说上话”和“能把需求定义清楚”是两种不同的能力
管理者里，有人确实擅长和上面的人打交道。
和高管聊。
去开会。
听取意见。
带回一些像是方针的东西。
还能像模像样地说一句“我们会推进的”。
光看这些，外人会觉得很有管理者的样子。
但问题出在后面。
把从上面听来的模糊说法，转化成下面的人能动手的需求，他做得到吗？
按理说，会后应该整理成这样：
- 定了什么
- 还有什么没定
- 谁来拍板
- 谁来负责具体执行
- 要向谁同步什么
- 什么时候之前做什么
- 推进的条件是什么
- 叫停的条件是什么
- 风险是什么
- 是否已经到了可以交给下面的状态
整理到这一步，执行的人才动得了。
可是做不到这种转化的管理者，会把上面的一团模糊原封不动地丢给下面。
“好像从 7 月开始要动了。”
“你和 S 谈谈，把事情推进一下。”
“这个月内想办法安排个会。”
“总之先做起来。”
“现在怎么样了？”
“怎么还没进展？”
这只是参加了会议，并没有做需求梳理。
能和上面的人说上话，与把工作设计成下面的人能动起来，是两种不同的能力。
3. 擅长需求梳理的人，不妨把上司当成“审批关口”
擅长需求梳理的人，如果把上司当作商量对象，往往会很耗神。
因为一商量，要么模糊的话越来越多，要么被浅浅的几句指点带偏、离开主要问题，要么事后完成标准又变了。
这种情况下，把上司当成审批关口，而不是商量对象，会更好。
比如这样说：
这件事我打算按 A 案推进。担心的点是 B 和 C，已经处理好了。如果没有问题，就按 A 来。
或者这样说：
有 A 案、B 案、C 案。考虑到影响范围和工作量，我认为 A 案比较合适。请您决定采用哪个。
或者这样说：
这件事要在全公司范围推行，需要向其他部门发正式的协助请求。如果要推进，请您决定配合的部门、对接人和优先顺序。
这样一来，就能把需要上司思考的范围缩小。
不是让上司从零开始想。
而是让上司做选择。
让上司只负责拍板。
让上司把责任范围说清楚。
擅长需求梳理的人，自己先把事情整理好，再向上司要“批准”“选择”“正式委托”和“责任”，这样比较好。
4. 就算解决了主要问题，也会因为次要的改进点被全盘否定
浅层管理者最让人头疼的是：主要问题明明已经解决了，他却只盯着次要的瑕疵，把整件事都否定掉。
比如，寄给本人的文件被退回了 3 次。
为了解决“送不到”的问题，我们建立了这样一套做法：
- 明确标示这是给本人的
- 印出“培训学员本人收”
- 同时印上学员的部门名和姓名
- 用箭头标出应该看哪里
- 注明如果因收不到而困扰，请写明原因退回人事部门
- 注明如果一切顺利，这张纸可以直接丢掉
- 附在正式文件上一起寄出
结果，正式文件送到了本人手上。
也就是说，主要问题“送不到”已经解决了。
可是浅层的审阅会变成这样：
“附页上收件人的手写字太难看了。”
“这是投诉吧？”
“是不是太单方面了？”
“去跟本人谈谈，搞清楚真正的原因。”
“那真正的原因到底是什么？不知道。”
这样的审阅相当薄弱。
因为他根本没有看该看的主要问题。
该看的是下面这些：
- 被退回 3 次的原因是什么
- 有没有建立起能送到本人手上的路径
- 本人遇到困难时有没有回复的办法
- 正式文件有没有送达
- 以后能不能避免同样的送不到
附页手写字不好认，至多是下次的改进点。
它不能成为否定“主要问题已经解决”的理由。
5. 当“太单方面”的指责说偏了
对于书面发出的说明，有时会被说“太单方面”。
可是，如果那张纸上写着下面这些，就不能算单方面：
- 这是给本人的
- 文件一直没送到，让大家很困扰
- 如果有瓶颈或特殊情况，请告知
- 如果没有问题，可以丢掉
- 提供了回复的渠道
这不是单方面的命令。
而是请对方帮忙确认没送到的原因。
甚至比去找人当面谈，给对方的负担更小。
一说“你们去谈一谈”，乍一听好像很周到。
但落到实际流程里是这样：
- 找出是谁发的文件
- 找出那个人在哪个部门
- 去那个部门谈
- 向本人或相关人确认情况
- 人事这边把听到的内容整理出来
- 最后还是要留记录
工作量很大。
而且是口头的，之后还可能变成“你说过”“我没说过”的扯皮。
相反，如果做成本人看了这张纸、需要的话就回复的机制，那么只要本人确认就能了结。
记录也留下了。
也不用到处找相关人。
周到不一定等于当面交谈。
让对方不迷茫、花最少的功夫、并且留有记录，同样是一种周到。
6. 要说“查清真正的原因”，就得看这套设计是不是更接近真因
“要查清真正的原因”这句话本身没错。
但光是话说得对，没有意义。
要查真因，有该看的东西：
- 过去 3 次的收件地址
- 收件人姓名的写法
- 寄送方式
- 退回理由
- 本人那边的签收情况
- 地址、部门、内部邮寄路线
- 是谁在哪里卡住的
- 在哪个环节被退回的
这些都不看，只说“可能是字太难看”“去跟本人谈谈”，那不叫原因分析。
而且这次正式文件已经送到了。
那么至少这次的对策是改善了送达率的。
这里该看的，是把主要问题的解决和遗留问题区分开来。
- 主要问题：给本人的文件送不到
- 对策：明确标示是给本人的，并附上回复渠道后寄出
- 结果：正式文件送达
- 遗留问题：附页的手写部分，下次起改成打印比较好
这样整理就行了。
不这么做，只说“字难看”“像投诉”“太单方面”，只停留在表面，层次太浅。
7. “手写字难看”是下次的改进点，不是主要问题
说手写字不好认，并非完全没有意义。
下次起改成打印就行了。
做成固定格式就行了。
收件人也全部用电脑打字就行了。
但那只是次要的改进点。
这次的主要目的，是解决送不到的问题。
这个主要目的已经达成。
所以，应该这样说：
这次因为寄给本人的文件多次被退回，所以我们用纸面告知了这是给本人的，并请对方如有送不到的原因或瓶颈，回复给人事部门。结果正式文件已送到本人手上，最初的送不到问题已解决。附页上的手写部分，下次起改为打印。
这样整理，主要问题和改进点就分开了。
浅层管理者做不到这种区分。
所以他们会拿次要的改进点，去否定连主要成果。
8. 交了方案，不会拍板的上司也会从头开会
方案文档也会发生同样的事。
看部门的课题，思考瓶颈在哪里。
比如先发现需要保证人手或招聘。
排出优先级。
用 30 分钟左右搭出骨架。
用一天左右写成方案。
提交给上司。
按理，接下来该做的是下面几种之一：
- 采用
- 修改
- 暂缓
- 只试行一部分
- 决定由谁来推进
- 决定拉哪些部门进来
- 决定什么时候之前做什么
可是不会拍板的上司，用不好方案。
方案发过去，只是已读不回。
不拍板。
不定团队。
后来别人也开始说类似的话。
于是变成“大家一起从头想想吧”。
这相当浪费。
草案已经有了。
现在不是从头想的阶段。
而是决定已有的方案是采用还是修改、由谁来做的阶段。
这时需要的不是从零开始的会议，而是决策会议。
比如可以这样说：
方案已经提交，所以这次不是从零开始提点子的会，而是想用来决定是否实施、优先顺序和各自负责的范围。
这才是本来的推进方式。
9. 想得快的人，他的方案容易被看轻
能在短时间内做出方案的人，有时会吃亏。
30 分钟搭出骨架。
一天做成资料。
把课题、原因、优先级、措施方案都整理好。
这本来价值很高。
可是如果上司没有识别这种价值的眼光，就只会把它当成“不知道谁发来的一个方案”。
看上去没花多少时间。
所以被看轻。
但其实，是因为平时就在盯着课题、做了结构化，脑子里早就梳理过了，所以才快。
不是因为交得快才浅。
而是因为早就想过了，才快。
理解不了这一点的上司，事后会让大家把同样的话从头再说一遍。
然后花很长时间，重新发现一个和已经提交的方案差不多的结论。
对一个组织来说，这非常浪费。
10. “事后补课会”会占用已经想过的人的时间
事后补课会，指的是别人已经整理好并提交的内容，事后再由一群人从头重新想一遍的会议。
当然，多人讨论本身并没有错。
但既然已经有了草案，会议的目的就应该改变。
糟糕的会议是这样的：
“先大家从头想想吧。”
“课题是什么呢？”
“问题在哪里呢？”
“有什么方案吗？”
好的会议是这样的：
“先确认已经提出的方案。”
“哪些论点采用？”
“哪些论点需要修改？”
“哪些论点还需要进一步确认？”
“谁在什么时候之前推进？”
后者的推进效率高得多。
既然已经有人想过了，直接用他的草案就好。
没必要从头再想。
上司做不到这一点，越会思考的人就越疲惫。
“这点我早就想过了。”
“资料也交了。”
“都整理到只剩拍板的状态了。”
“结果还要从零开会？”
就会变成这样。
11. 擅长需求梳理的人需要的，不是善解人意的上司，而是不添乱的上司
对擅长需求梳理的人来说，理想的上司不必特别优秀。
最起码，别添乱就行。
比如，这样的上司就很好配合：
“按 A 案推进吧。”
“其他部门我来协调。”
“这里有风险，加一句话。”
“需要判断时再拿来。”
“这件事这次先搁置。”
“这是全公司推行的事，先把正式的组织架构定下来再推进。”
光是这样，就已经帮了很大的忙。
相反，下面这样的上司就是在添乱：
“为什么？”
“打算怎么办？”
“计划呢？”
“不过明天就要。”
“这个也明天要。”
“这是投诉吧？”
“字很难看吧？”
“真正原因我可不知道。”
“这就是你的特质问题吧。”
这样并没有推进工作。
只是把工作搅浑了。
擅长需求梳理的人想要的，不是过度的指导。
而是判断、责任，以及不添乱的态度。
12. 适不适合当管理者，看的不是头衔，而是“转化能力”
管理者需要的，不只是能和上面的人说话。
还需要把上面模糊的方针，转化成下面的人能动手的需求。
具体来说，是下面这些能力：
- 把目的讲清楚
- 把未决事项找出来
- 定好谁来拍板
- 定好谁来负责
- 定好优先级
- 定好期限
- 定好舍弃什么
- 向其他部门发出正式的委托
- 让执行的人处于可以动手的状态
- 留下记录，以免日后被推翻
做不到这种转化的管理者，与其说是上司，不如说是制造“未定义”的机器。
另一方面，没有头衔却能做这种转化的人，在实际工作中非常强。
“A、B、C 里，您看按哪个推进？”
“这个担心已经考虑进去了。”
“按这个条件的话，就走 A 案。”
“需要同步的范围是这些。”
“只需要您拍板。”
“具体工作我们这边推进。”
能说出这些话的人，相当具备管理者、项目经理的素质。
不是不适合当管理者。
只是不适合那种靠含糊的权威来驱动人的老派管理。
对于靠需求梳理、达成共识、风险管理、协调相关方来推进的项目经理型管理，反而很可能很适合。
13. 可以拿到明面上用的说法
从情绪上说，难免会觉得“碍事”“肤浅”“真蠢”。
但在实际工作中，最好别原样说出来。
在明面上，可以这样换个说法。
把主要问题和次要改进点分开
本次的主要目的是把文件送到本人手上，这一点已经完成，送不到的问题已解决。附页的填写方式，作为下次起的改进点，会改为打印。
已经提交过方案的情况
这件事我已经提交了方案。下次希望不要从零开始提点子，而是请您对是否实施、优先顺序和负责范围做出判断。
需要上司拍板的情况
有 A 案、B 案、C 案。考虑到影响范围和工作量，我认为 A 案比较合适。您拍板之后，我就按这个方向推进。
事后冒出追加要求的情况
按最初指示的范围，我已经做到了○○。如果还需要做到△△，请明确列入工作范围，我就继续推进。
被说“太单方面”的情况
这并不是单方面的要求，而是作为一份确认请求发出的，请对方在有送不到的原因或瓶颈时回复我们。
被说“去谈一谈”的情况
这件事本人看一下就能了结，而且纸面上也设了回复渠道，所以先以纸面确认的方式处理了。如果还需要口头确认，我会先明确对象和确认事项，再去处理。
14. 结论：不要让浅层的指摘毁掉你的主要成果
工作中重要的是，把主要问题和次要改进点分开。
主要问题解决了，那就是成果。
有次要的瑕疵，那就是下次的改进点。
这两件事不能混为一谈。
如果问题是给本人的文件送不到，主要问题就是“能不能送到”。
正式文件送到了，主要问题就解决了。
附页手写字难认，下次改成打印就好。
如果是针对部门课题的方案，主要问题就是“瓶颈是什么、先从哪里下手”。
方案既然已经提交，接下来就不是从头想，而是到了做判断的阶段。
对擅长需求梳理的人来说，浅层管理者的指摘相当碍事。
但没有必要被这种肤浅的指摘牵着走，连自己的成果都一并否定。
该看的是目的、原因、优先级、执行条件和结果。
表面的瑕疵，改进就行了。
解决了主要问题这个事实，不必抹去。
实用模板集
1. 文件送不到的处理记录
这次因为寄给本人的文件多次被退回，所以我们用纸面告知了这是给本人的，并请对方如有送不到的原因或瓶颈，回复给人事部门。
结果正式文件已送到本人手上，最初的送不到问题已解决。
附页上的手写部分，下次起改为打印。
2. 区分主要问题和改进点
本次的主要目的○○已经完成。
另一方面，△△作为下次起的改进点来处理。
3. 希望对方用上已有方案时
方案已经提交，所以这次希望不是从零开始提点子，而是请您对是否实施、优先顺序和负责范围做出判断。
4. 请上司在 A/B/C 中拍板时
目前可以考虑 A 案、B 案、C 案。
考虑到影响范围和工作量，我认为 A 案比较合适。
如果没有问题，就按 A 案推进。
5. 防止上司事后加码时
按最初指示的范围，我已经做到了○○。
如果还需要做到△△，请明确列入工作范围，我就继续推进。
6. 被要求直接去谈时
这件事本人看一下就能了结，而且纸面上也设了回复渠道，所以先以纸面确认的方式处理了。
如果还需要口头确认，请告诉我对象和确认事项。
相关文章候选
- 无权限责任陷阱：没有权限却只背成果责任的职场
- 别把未定义的工作揽在身上：明确拍板人和负责范围的方法
- 自我申报制度崩坏的时候：自己定目标的陷阱
- 防止事后评价的邮件模板
- 方案被已读不回时的自保记录
- 上司成为障碍的瞬间：审阅变成了挑刺的状态
- 人事工作中未定义业务的可怕之处
- 为什么不能把全公司措施变成个人目标
发布时的注意事项
这篇文章包含接近真实经历的内容，发布时一定要做匿名化处理。
- 不写公司名
- 不写个人姓名
- 模糊部门名
- 把“猴子”之类的内部说法替换成“上司”“管理者”
- 把文件种类和业务内容一般化
- 删掉具体日期
- 求职期间作为不公开的草稿处理
- 如果发布，要从“业务设计”“需求梳理”“管理者的角色”这个角度来写，而不是发泄愤怒
最后
擅长需求梳理的人，最好不要因为浅层的指摘而看不清自己的成果。
解决了主要问题，那就是成果。
有次要的改进点，下次改掉就好。
上司的职责，不是捡表面的瑕疵去逼问下属。
而是定目的、定优先级、担责任，并营造出执行的人能动起来的状态。
做不到这些的上司，不是支持者，而是噪音。
而且，不能让噪音抹掉你的主要成果。
