n年前，我在一家企业负责最近新启动的电商系统的优化。项目启动会上，产品总监留下一句话就匆匆离场："你们把系统好好梳理一下，现在太乱了。"会议室里只剩下我和几位工程师面面相觑。什么算"不乱"？商品数据有几十个字段，哪些该留哪些该砍？供应商对接的逻辑要不要重写？性能要到什么水平才算"梳理好了"？这些问题一个都答不上来。
类似的情境一再重演。运维同事半夜接到报警，冲进会议室问"这系统到底该不该现在扩容"，没人能给出判断依据；技术负责人被老板叫去谈年终目标，老板说"你要提升团队的技术影响力"，回来之后辗转反侧，不知道"影响力"在绩效考核里到底值几斤几两。
这些看上去是不同的问题，骨子里却长着同一副骨架：模糊性。模糊性最折磨人的地方在于，它让你觉得自己应该做点什么，但所有努力都像是往雾里挥拳，使不上劲。后来我慢慢想明白了一件事：处理模糊局面的能力，不只是技术管理者的一项加分技能，而是决定你能否在这个行当里生存下去的底层能力。
而这种能力，又可以分为两个互锁的维度：一个是对"事"的模糊性进行拆解，一个是对"人"的预期进行澄清。两者缺一不可。
先谈对事的模糊性。我们这些 IT 人，骨子里被训练成了解决逻辑问题的高手，可真实的工作环境恰恰相反。需求和目标从来不会以"输入一个整数数组，返回排序"的形式交到你手里。它们往往长成这样："调研一下业界怎么做推荐召回"，或者"把系统的可观测性搞起来"，再或者"数据库最近不太稳，你们看看"。
我见过太多工程师在这种场景下直接跳进解决方案。听到"性能优化"就抓起工具开始跑火焰图，听到"架构升级"就打开文档画微服务拆分图。这就像有人告诉你"屋子里有点暗"，你二话不说开始凿墙开窗，结果发现人家只是找不到开关。在没有界定清楚问题之前，所有解决方案都只是在掷骰子。
真正解决问题的第一步，是承认自己面对的根本不是一个现成的问题，而是一片充满了未知变量的场域。每一处模糊都是一个维度，每个未知维度都让可能的解决方案空间指数级膨胀。想要在这片高维空间里找到出路，唯一的武器就是提问。
我有一个笨办法，但屡试不爽。接到一个模糊任务之后，我会先打开一个空白文档，定一个十五分钟的倒计时，然后开始往里面倾倒所有能想到的问题。不管问题看起来多蠢多基础，先写下来。比如老板让我"把系统的可靠性提上去"，我的问题列表一开始会是这样的：
- 现在系统可用性是多少？
- 我们怎么测量可用性的？
- 最近三个月出过哪些故障？
- 故障的平均修复时间是多长？
- 哪些模块如果挂了影响最大？
- 用户感知到的"可靠"和运维监控面板上的"可靠"是不是同一回事？
- 可靠性做到什么程度算"够用"？
- 公司愿意为可靠性投入多少成本？
这个阶段最忌讳自我审查。不要在心里给问题打分，不要觉得"这问题太初级了问出来丢人"。模糊性的本质就是信息缺失，而你根本不知道缺失的那块拼图长什么样。
把问题倒出来之后，进入第二步：给问题分类。有些问题我自己就能回答，比如"最近三个月出了几次故障"，去翻一下告警历史就有答案。有些问题我得去找特定的人聊，比如"哪些模块挂了影响最大"，得问业务方和产品经理。还有一些问题，至少在现阶段没人能给出确切答案，比如"可靠性做到什么程度算够用"，这取决于公司当下的战略优先级和资源预算。
分类的过程就是在做降维。那些自己能回答的问题，直接填上答案，维度就闭合了。那些需要找人聊的问题，变成了我的采访提纲。而那些暂时无解的问题，我会把它们拆成更细的子问题，或者反过来问自己：如果这个问题暂时没有答案，我能不能用一个合理的假设先顶上？比如不知道"够用"的可靠性具体是三个九还是四个九，那我可以先假设目标为 99.99%，然后去验证这个假设在当前团队和预算条件下是否可行。
在这个过程里，我会不断重复"提问，分类，寻答，再提问"的循环。每一次循环，问题空间就收缩一圈。那些最初让人觉得无处下手的模糊指令，会慢慢显露出轮廓。最让我意外的是，每当我带着整理好的问题列表去和上级或跨部门同事沟通时，对方的反应往往非常积极。原因很简单：没有人喜欢面对一张白纸。你拿出一份写满了问题、假设和部分答案的文档，对方可以很轻松地在这上面打勾、画叉、补充修改。这和让对方从零开始帮你搭建框架，难度差了不止一个量级。
经过几轮这样的循环之后，那个最初模糊得像一团雾气的指令，最终会凝结成一个清晰可执行的陈述。比如"把系统可靠性提上去"会变成"在未来六个月内，将影响外部用户的故障次数降低百分之八十，同时不牺牲核心接口的平均响应时间"。这句话有明确的时间边界，有可量化的指标，有约束条件。到了这一步，团队里的每个人都知道自己要往哪个方向使劲，剩下的只是工程执行问题而已。
但事情到这里并没有结束。在我这些年的观察里，大量项目延期和团队摩擦的根源，并不在于技术问题没想清楚，而在于"谁该做什么""谁有权决定什么""谁需要知道什么"这些角色边界上的模糊。这和事层面的模糊同样致命，甚至更难察觉。
几年前我帮着某企业整合企业内部工具链的团队。接手不到两周就发现，开发组和运维组之间弥漫着一股说不清道不明的紧张气氛。每次发布新版本，两边都互相抱怨。开发说运维部署流程太保守，动不动就回滚；运维说开发提交的变更文档语焉不详，出了故障根本不知道怎么排查。我去找两边分别聊，发现每个人的叙述都各有道理，但拼在一起就是鸡同鸭讲。
后来我把两个团队的核心成员拉到一间小会议室，在白板上画了一张角色职责矩阵。纵轴列出从代码提交到上线交付的所有关键环节，横轴列出两个团队的成员名字。然后我问了一个非常朴素的问题：针对每个环节，谁来负责执行，谁来负责审批，谁来提供咨询，谁只需要事后知悉。一开始大家填得很慢，中间还有几次争论，但填到第三行的时候，气氛开始起了变化。有人恍然大悟地说"原来你们希望我们在测试环境就介入"，也有人松了口气说"早知道回滚决策权在你们那边，我就不用每次都熬夜盯着了"。
这张矩阵就是管理工具中常说的 RACI 模型。执行（Responsible）、审批（Accountable）、咨询（Consulted）、知悉（Informed），四个维度看起来简单，却是把隐性预期暴露在阳光下的最好手段。很多协作上的摩擦，本质上都是预期错位。你以为对方会在上线前帮你做一轮性能验证，对方以为那是你自己的事。你以为某个技术决策需要向架构组报备，架构组觉得只要邮件抄送他们就够了。这些错位一天不纠正，团队就要在无意义的扯皮里消耗一天。
澄清预期这件事，不仅适用于平级协作，在面对上级时同样关键。不少技术管理者会跟我诉苦，说不知道老板到底想要什么。我的第一个问题永远是：你有没有把你认为的"老板想要什么"写下来过？大部分人听到这个问题会愣住。他们的习惯是等老板给一个明确指令，或者旁敲侧击去"揣摩圣意"。但揣摩出来的东西往往偏差极大。
更好的做法是反向操作。不要问老板"您对我的期望是什么"，因为你把构思框架的负担甩给了对方，对方给出的答案很可能依然是笼统的。换成这样：写一份文档，标题就叫"我对今年核心目标的理解"，里面把你认为最重要的三到五个目标列出来，每个目标附带你打算怎么衡量进展、需要什么资源、存在哪些风险。然后把这份文档发给老板，说"这是我基于之前的沟通梳理出来的理解，您看有没有偏差"。
这个动作的力量被严重低估了。绝大多数人在面对一份具体草案时，都能给出精准的反馈。因为修改一份已有的东西比凭空创造一份东西省力太多。老板可以在你的草案上划掉一条，加注一条，调整某个指标的权重。一轮对话下来，双方脑子里的那幅图景就对上了。这比反复追问"您到底想要什么"要高效得多，也体面得多。
还有一种更微妙的预期模糊，发生在团队内部的技术决策上。比如某个工程师负责的系统模块需要重构，但你作为管理者并不确定他打算做到什么程度。他说的"优化"可能只是改几行性能瓶颈，你说的"优化"可能是把整个模块的抽象层次推倒重来。这种认知偏差积累久了，就会出现"我都重构完了你还不满意"和"你这叫哪门子重构"的互伤场面。
破局的方法其实和前面一模一样。你完全可以坐下来对工程师说：咱们把这次重构的目标用五条可验证的陈述写下来。不需要长篇大论，就五句话。比如"核心查询路径的延迟降至两百毫秒以内"；"模块对外接口保持不变，调用方无需改动"；"新增单元测试覆盖率达到百分之八十"；"重构期间的线上流量采用灰度切换方案"；"整个周期控制在三周之内"。五条写完之后，双方逐条过。哪条有歧义就展开聊，哪条不切实际就调整。就这么一个简单的动作，能把后续无数次的来回确认和返工成本省掉。
现在回头看我最早提到的那两个困境，它们其实是被同一把钥匙解开的。技术项目里的模糊性，靠的是用问题把问题空间撑开、看清楚之后再收拢。人际协作里的模糊性，靠的是把每个人脑子里那个隐形的预期翻出来、写成白纸黑字、然后互相校准。两件事在底层逻辑上是一模一样的：把潜藏的东西显性化，把混沌的东西结构化。
我在带团队的过程中反复体会到，技术能力再强的工程师，如果不会拆解模糊目标，永远只能在别人画好的框里做题。而如果不会澄清预期，就算个人能力再突出，在团队里也会变成一个不稳定的耦合点。反过来，能把这两件事做好的人，哪怕代码写得不是最漂亮的，也会成为团队里最被信任的节点。因为大家知道，什么事情到了他手里，都能从一团乱麻变成一匹顺滑的布。
你可以把这个过程想象成在浓雾里开夜车。车灯照出去的距离有限，但只要车在动，方向盘在你手里，前方的路面就会一段一段地亮起来。你不需要拥有穿透整片大雾的超能力，你只需要知道车灯怎么用，并且相信每照亮一段，就离目的地近一段。那些最让人头疼的模糊指令和模糊关系，在事后回头看时，反而成了你成长最迅速的节点。因为在驱散迷雾的过程里，你学会的不仅是处理这件事本身，更是一套可以迁移到任何陌生领地的方法论。
所以当下一次有人交给你一个语焉不详的任务，或者你感觉和某个同事之间隔着一层说不清的隔膜时，不妨先别急着烦躁。那是雾来了，而你手边正好有车灯。打开文档，开始提问，开始写草案，开始画那张职责矩阵。你会发现，那些看似不可穿透的模糊，其实比你想象的要薄得多。
(声明：本文企业和个人名称均为虚构)
发表于 1 小时前
|
查看: 5|
回复: 0
