前阵子和一个做SaaS创业的朋友吃饭他苦笑着说了一件挺扎心的事公司成立五年业务还算稳但他发现自己变成了团队里唯一的“问题垃圾桶”——凡是没遇到过的问题无论技术上还是管理上的最后都只能他自己上。其他人不是不努力而是遇到难题第一反应就是等指令、找模板、问有没有先例。他问我说为什么我现在带着的这几个人能力也不差就是成不了所谓的“专家”这个问题我思考了很久。后来我给出的答案是因为专家根本不是“学”出来的甚至不是“做”出来的而是“被难题磨”出来的。一个工程师写了十年CRUD他不一定比写过三年分布式系统的人更值钱一个产品经理做了八年后台表单他可能还是搞不清用户为什么不用自己的产品。真正的专家是定义难题和解决难题的过程中长出来的不是靠工作经验堆出来的。这也是《创业之路》这一期最想聊透的一个底层逻辑想成为专家就得去拥抱难题、分析难题、解决难题而且要从项目级一路打到行业级、世界级。下面我会把这件事拆得很细包括为什么熟练度会骗人六个难题层级分别长什么样以及“定义难题”这个看起来抽象、实际上是分水岭的动作到底怎么做。1. 为什么“做了很多年”不等于专家熟练度陷阱1.1 熟练度是一条复利曲线但它只有下限我见过太多简历上写着十年经验的候选人他们的共性问题不是不聪明而是太习惯“做已知的事”。熟练度这个东西很有意思它确实会随着时间积累也会带来效率提升但它解决的是“问题空间已经明确”的情况。什么叫问题空间明确就是你拿到一个需求很清楚用什么技术、什么框架、什么流程去实现。比如写一个订单导出功能数据库表结构在那里接口规范在那里前端页面样式在那里你要做的只是按部就班地填代码。这类工作做得再快、再稳也锻炼不出专家能力因为你的认知边界根本没有被顶开过。熟练度真正的问题在于它的假象当你在一件事上熟练了五年你会很容易产生“我对这个问题已经很懂”的错觉。可是环境一变比如业务从单体迁移到微服务比如流量从一百人变成一万人在线你会发现自己之前的经验全部需要重构。老司机开车确实稳但把老司机扔到北极冰面上他照样要重新学怎么控制方向盘。我自己的团队里有几次技术负责人面试聊到一个真实场景“线上系统突然频繁Full GC你们怎么排查”那些背过八股文的人能说出调优参数但真正解决过这类问题的人回答顺序完全不同——他们会先说怎么隔离影响范围再看监控数据最后才是调参数。这就是“知道”和“被难题训练过”的天壤之别。1.2 专家不是知识多而是难题经验多如果拿一个公式来表示专业能力我不会写“专业能力 知识量”而会写“专业能力 ≈ 解决过的难题类型数 × 解决深度”。两者是乘法关系不是加法。一个人读过一百本架构书但是一个线上故障都没扛过他写出的架构方案和真正扛过宕机的人写出来的方案完全是两种质量。区别在哪里扛过宕机的人知道哪些地方最容易出事知道降级方案要在哪一步触发知道报警声一响哪个按钮不能乱按。这些细节没有一本书会写只有被问题真正捶打过教训才会长在自己身上。我举一个真实经历。早年我在一家电商创业公司做过技术负责人有次大促前夜支付回调服务突然大量堆积订单全部卡住不动了。按我当时的知识储备第一反应应该是去查Redis是不是慢了、数据库是不是锁了但是我那次没有这么做——我先把所有新进来的支付请求切到了一个备用的消息队列先把流量稳住了然后才开始看堆积原因。那一晚之后我才意识到这个“先隔离风险再查根因”的肌肉记忆根本不是课程教出来的而是被上一次故障教训砸出来的。解决难题的真正价值就在这里它会把解决问题的能力直接刻进你的反应系统里而不是停留在你的笔记里。1.3 难题和恐慌区之间存在一条成长路径当然我说“拥抱难题”不是让大家一上来就接世界级难题。美国作家提出的舒适区、学习区、恐慌区理论在个人成长领域很经典。舒适区是每天重复做的事学习区是那种有一点挑战、但跳一跳够得着的任务恐慌区则是完全超出掌控范围的事。真正有效的难题训练目标是让你长期待在学习区而不是拿恐慌区自我毁灭。一个刚入职两年的开发你让他去主导整个行业标准制定这不是锻炼这是劝退。但你可以让他去负责一个跨部门协作的接口改造项目这有挑战、有冲突、有不熟悉的业务方同时又有明确的范围护着他不会彻底失败。等他解决了这一层再逐步往上加码从带一个小模块到扛一个完整产品再到负责整个平台的技术演进。每一次往上跳半步难题都会更复杂、反馈周期更长、可变因素更多但只要你还在学习区里你就能在被难题打磨的同时不觉不敢崩溃。这条路径就是我说的“拥抱难题”的正确姿势。2. 六个难题层级逐个拆开看从项目级到世界级标题里提到的六个层级——项目级、产品级、公司平台级、行业级、国家级、世界级——很多人会当成一个抽象排序其实不是。每一级的难题性质完全不同对人的要求也完全不同。我建议你把它当成一个坐标系先找到自己现在卡在哪一层才知道下一步该往哪儿跳。2.1 项目级难题在资源约束下把结果交付出来项目级难题是一切的起点。它的典型特征是目标相对明确但约束条件很多时间不够、预算有限、人手不足、各方需求还在变。比方说老板丢给你一个任务“三个月内把老系统里的订单模块完整迁移到新架构保证数据不丢、业务不停。”这听起来很清楚但做起来全是坑——老系统文档不全、数据库字段含义没人说得清、业务方还说迁移期间要上一个大促活动。项目级难题的难点在于协调和取舍而不是单点技术。你需要回答的问题包括核心路径是什么边缘环节是什么哪些功能可以暂缓哪些数据即使迁移失败了也能手工修补。一个搞定过复杂项目的人会形成一套自己的“开工清单”第一天先找齐所有利益相关方确认真正的验收标准列出风险排序表而不是直接打开IDE写代码。这套东西很难从书本里学到因为每个项目的政治关系、历史包袱都不一样只能靠实打实做完一个又一个交付才会建立起那种“一拿到项目就知道哪儿会出问题”的直觉。2.2 产品级难题从“做出来”到“做得好用”很多团队都卡在这一层的跨越上。项目做完了功能全部上线了用户就是不用留存率一天比一天低。这时候你敢不敢承认你要解决的已经不是“实现问题”而是“定义问题”。打个比方一个库存管理App你把增删改查、盘点、报表全都做出来了但中小商家依然宁愿用Excel为什么因为你没有解决他们真正的难题——学习成本太高、迁移成本太高、老板不在店里店员不敢用。功能做得多反而是负担。产品级难题的核心是你能不能想清楚用户“痛苦”到底是什么。我做产品咨询时最喜欢用的一个方法是“五分钟访谈法”不用问用户“你想要什么功能”而是问“你最近一次因为这个事情发火是什么场景”。用户给出来的往往不是需求而是情绪记忆但那里面藏的是真问题。产品级专家和普通项目经理的分水岭就在这里项目经理解决的是“如何按时上线”产品级专家解决的是“如何让用户离不开”。前者是工程问题后者是认知问题。2.3 公司平台级难题机制、组织与文化当你开始处理公司层面的难题时会发现技术变量已经退到次要位置最大的难点变成了人以及把人组织起来的机制。比如公司从20人扩张到200人原来靠微信群吼一声就能解决的协作现在变成了一场灾难信息传不到、责任分不清、部门之间互相甩锅。这时候你遇到的问题没法像改代码一样改组织——因为你没法新建一个函数然后调用它你的每一次组织调整影响的都是几百个人的实际利益和工作习惯。解决公司平台级难题靠的通常是机制设计。我咨询过的一家创业公司销售和技术团队天天干仗互相怪对方导致项目延期。后来我们没有做更多的团建也没找HR做文化培训而是做了一件小事把项目复盘会从“看结果”改成了“看链路”每个环节必须有明确的输入和输出文件。就这么一个机制改动双方扯皮的事就少了一半因为责任边界从“感觉”变成了“记录”。公司平台级专家的能力本质上是一种系统思维——你要能在组织里找到那一个杠杆点用一个机制的微调撬动整个系统的行为改变。2.4 行业级难题重新定义游戏规则到了行业级难题的性质又变了。它是那种单靠你一家公司怎么努力都解决不了的问题需要产业链上下游一起改变。最典型的就是行业标准早期的各家系统API互相不通每家都是一个数据孤岛大家都很痛苦但谁都不想先改因为改标准意味着短期成本。真正能解决行业级难题的人不是技术最强的而是能说服更多玩家一起跟进的人。这个层级的专家往往做的事情不是“解决难题”而是“定义一个更优的约束条件组合”。比如你所在的行业所有商家都在抱怨数据迁移太痛苦老系统把数据锁死了每一家客户都受制于此。如果你能设计出一套更开放的数据迁移协议并且说服几个主要平台一起支持你就不再只是一个产品供应商而是整个行业规则的一个定义者。把行业级难题扛下来的人获得的回报也是指数级的——他不是在赢一个项目而是在赢一张生态位。2.5 国家级和世界级难题从基础设施到人类极限国家级和世界级难题是金字塔最顶端的两层。它们的共同特点是复杂度极高、周期极长、失败概率极大、没有现成的参考答案。国家级难题往往是一个庞大系统的基础设施命题。举个例子一个国家的医保、社保、教育等系统的数据天然分布在不同的部门和机构里它们之间要实现安全、合规、大规模的互联互通这不只是一个技术问题还是一个涉及法律、制度、隐私保护、多方利益博弈的系统工程。能在这个层级解题的人需要的不只是技术深度还有足够的耐心和对复杂社会的理解。世界级难题则是全人类共同面对的技术极限问题。比如可控核聚变、通用人工智能的算力效率、脑机接口的实时带宽或者新药研发中蛋白质结构预测这一类问题。这些难题最迷人的地方在于没有人知道正确答案你需要在一片黑暗里通过实验和推理一点点凿出光来。很多人觉得国家级、世界级离普通创业者太远我不这么看。每一个层级的能力都是靠下一层的难题喂出来的。一个把行业级难题解决得很漂亮的人自然会被更大的系统注意到然后被推向下一个更复杂的命题。解决难题的层级就是你职业生涯的真实天花板。2.6 给自己做一次“难题位置自查”不管你现在是技术负责人、产品经理、创业者还是刚入职的新人我都建议你每半年做一次自查确认自己当下在哪个层级。我的自查框架很简单就四个问题最近三个月你投入最多精力的一个难题属于哪个层级你能不能一句话说清楚这个难题的本质说不清说明你还在问题表象上打转。这个难题解决之后是只能让你一个人受益还是能沉淀出可复用的方法论让团队甚至行业都受益你上一次从恐慌区退回到舒适区是什么时候如果已经很久没有过“这个难题让我很慌”的感觉说明你可能已经停在一个地方太久了。这四个问题的答案就是你成长的刻度。我在《创业之路》里反复讲一个观点计划可以骗人目标可以调整但你的难题层级从来不会撒谎。它忠实地记录着你现在到底有几斤几两。3. 定义难题专家和非专家的分水岭3.1 大多数人拿到难题第一步就错了很多人以为“定义难题”是个很玄乎的动作其实它特别具体。我给大家描述一个场景老板把你叫进办公室急匆匆地说“最近用户活跃度下降得厉害你们技术部想想办法做个活动把用户拉回来。”如果你是那个“普通执行者”你会收到一个任务做活动。然后你开始想活动页面怎么做、发多少优惠券、要不要做分享裂变。但如果你是那个“被难题训练过的人”你第一时间想的应该是什么叫“活跃度下降了”下降的到底是哪个环节的活跃度是新用户注册后没有再次访问还是老用户的新功能使用频率降低这些问题的答案完全不同对应的解决方案也完全不同。大多数人的错误就是拿到一个模糊描述立刻跳进了“解决方案模式”。老板说活跃度低你就去做活动客户说系统慢了你就去加服务器产品说用户不喜欢新界面你就改回旧版。这种“症状驱动”的解题方式会让你一直很忙但永远在治标不治本。真正的难题往往被一层又一层的症状包裹着你要做的第一件事不是动手而是撕开包裹。3.2 一招“问题重述法”把模糊问题变成可定义问题我实践中特别有效的一个方法是“问题重述法”做起来也不复杂一共四步但每一步都需要克制住“马上开干”的冲动。第一步把对方描述问题的原话一字不差地写下来。这一步看起来傻瓜实际上很重要。因为原话里往往带着情绪和倾向比如“用户就是不爱用我们新功能”这句话本身就是一种归因它默认了问题出在“用户不爱用”上。如果你直接接受这个归因后面所有动作都会被带偏。第二步用“谁、何时、何地、做什么、遇到什么障碍、导致什么后果”这个框架把原话重新翻译一遍。还是“用户不爱用新功能”这个例子重述之后可能变成“在功能上线后的第3天到第7天之间有60%的已注册用户点击过一次新功能后再也没有回来过导致整体周活跃用户环比下降了12%。”你看这个版本就具体得多了而且它没有预设“用户不爱新功能”这个结论它只是描述了现象。第三步把重述后的问题套进一个“背景-障碍-目标”的结构里背景是团队花了大半年做了这个新功能障碍是用户完成首次体验后没有形成回访习惯目标是让用户在新功能里的首次体验时长从平均40秒提升到3分钟以上。到了这一步问题就已经从“用户不爱用”变成了“如何优化新用户的首次体验路径”这个方向才是可拆解、可执行、可验证的。第四步拿着你重述之后的问题定义去找至少三个利益相关者验证一下包括提出原始问题的人、受影响的目标用户、以及实际执行的一线团队成员。你会发现三方对同一个问题的理解经常不一样。老板心里的活跃度可能是营收产品经理心里的活跃度可能是功能使用次数运营心里的活跃度可能是打开次数。你把这个差异暴露出来才叫真的在定义难题。这一步做完难题才真正被交到你手上而不是你猜着接了一个烂摊子。3.3 三种定义错误的代价你要提前看清楚定义难题这件事做错了比不做更可怕因为它会让你朝着错误的方向全力奔跑。我总结过三种最典型的错误希望大家都绕开。第一种是定义得太窄。比如用户流失率高了你把它定义成“推送通道不稳定”然后花了两周去优化推送结果流失率一点没变。这就是把问题窄化成了自己擅长处理的技术环节忽视了用户可能压根是因为产品价值不清晰才走的。太窄的定义会让你用一个昂贵的方案去解决一个不存在的问题。第二种是定义得太宽。比如把难题定义成“我们要做数字化转型”或者“我们要提升用户体验”。这种定义听上去格局很大但它没有任何约束力你没法拆解它、没法验证它、没法判断什么时候算完成。它不是一个难题它是一个口号。太宽的定义会让你把所有资源都撒在一个无边无际的战场上最后什么都得不到。第三种是“抄来的定义”。很多时候我们懒得定义问题直接引用别的公司、别的行业已经有的问题定义比如“我们现在也要做数据中台”“我们要对标某某大厂的OKR体系”。不是说这些方向一定不对而是你没有和自身的场景连接起来没有回答“我们为什么要做、做完解决谁的什么问题”。抄来的定义会让你获得战略上的安全感但伴随着的是执行上的彻底迷失。因为所有难题只有长在你的业务土壤里才有真实的约束条件才可能长出真实的解法。4. 解决难题的实操框架从接手到复盘的四个环节定义完问题之后才是真正的硬仗。我给大家一套我自己在创业和咨询中反复使用的实操框架。它不一定适合所有场景但至少能让你在接到一个大难题的时候不用靠本能慌慌张张地摸索。4.1 先写一份“难题档案”再把脚踩到现场接到一个难题第一件事不是讨论方案而是建立一份“难题档案”。我建议你像写病历一样写一份文档内容包括五块第一问题现象即用户/老板/客户描述的原话和可量化数据第二背景信息包括这个问题存在多久了、以前试过哪些方案、为什么没成功第三关键证据就是能够证明问题严重程度的图表、日志、访谈记录第四利益相关者名单包括谁会受益、谁会被触动利益、谁会阻碍第五约束条件包括预算限制、时间窗口、合规要求。我当时在硬扛一些跨部门大项目时会发现这份档案写到一定详细程度很多“难题”自己就变简单了。因为大量难题的复杂感不是来自于它本身而是来自于信息不完整带来的不确定性。比如我发现一个支付成功率低的问题原本以为是网关配置错误但写完档案之后才意识到涉及支付的老业务方上个月刚刚换了负责人他对这个系统的历史一窍不通所以所有变更全被拒了。这根本不是技术难题这是组织协作难题。搞清楚这一点方案自然就出来了。但档案只能帮你建立框架真正有效的分析必须来自一线。写完之后你一定要到现场去去见真实用户去翻真实日志去和一线客服聊两个小时。坐在会议室里看报告和蹲在一线听到用户抱怨的原话两种信息密度完全不一样。有一次我帮客户排查用户退款周期太长的问题档案里写的全是系统性能瓶颈结果我去客服部坐了一下午发现最痛的点根本不在系统而是用户找不到在哪里提交退款申请。这种信息只有脚踩现场才能拿到。4.2 从核心变量出发拆解别在表象上花所有力气拿到足够的信息之后难题还是一张网你得把它拆开。拆解的原则是MECE原则——相互独立、完全穷尽。但我要强调一点拆解不是为了炫技是为了找到那个“核心变量”。我习惯把所有拆出来的子问题分成三类P0是如果不在第一时间解决整个项目就会死掉的问题P1是导致问题持续存在的根本原因P2是问题表现出来的各种症状。这个分类做完之后我要求团队把80%的精力全部放到P0和P1上P2那些症状项目除非影响特别大否则一律不做。举个真实的例子。一个在线教育产品的续费率只有12%行业优秀水平是30%。团队一开始列了一大堆问题课程视频画面不清晰、班主任回复不及时、学员群没人运营、App推送打扰太多。乍一看全是问题但如果按P0/P1/P2分类你会发现课程学习完成率低的学员续费概率只有5%学完超过50%课程的学员续费概率能到28%那P0就是“如何提升学习完成率”而不是那些层出不穷的具体体验小毛病。把核心变量抓住之后团队不再东一榔头西一棒子而是集中力量做“每周学习计划提醒”和“学完一个单元立刻给证书奖励”这两个动作。两个月后续费率从12%提到了19%。这就是核心变量拆解的厉害之处它不是让你做更多事而是让你少做一些不解决根本问题的事。4.3 给小成功设里程碑让大难题变得可以下嘴大难题天然会让人产生无力感因为它的反馈周期太长你可能连续忙了三个月看起来什么成果都没有。这时候关键技巧是主动给自己设置“小成功里程碑”。不要一开始就把终极目标当成唯一里程碑而是把解题过程拆成几个阶段每一阶段都定义出可验证的成功标准。比如上面那个续费率的例子如果你把里程碑设为“把续费率从12%提升到30%”团队第一个月就会陷入焦虑因为这个数字短期内根本动不了。但如果把第一个里程碑设为“完成100个流失学员的深度访谈找到弃学的主要原因”第二个里程碑设为“在课程完成率路径上上线两项干预测试”第三个里程碑才是“把续费率提升到20%以上”团队的节奏感就完全不同。前两个里程碑你有绝对把握完成而且完成之后第三个里程碑的实现路径就变得清晰了。小成功里程碑是一个很反直觉的工具它不是用来降低目标的它是用来让你在漫长解题过程中能够持续获得正反馈、保持解题意志的。4.4 复盘不是写总结是提炼可复制的方法论太多人把复盘做成了“工作总结”——做了什么、没做什么、下一步计划是什么。这种复盘价值很低。真正高价值的复盘是要把一次性的解题经验提炼成可以复用的决策规则。我做完任何一个大难题都会强迫自己回答三个问题。第一个问题下次遇到“同类问题”我第一时间应该做什么、不应该做什么把答案写成一个触发器如果再次出现X信号先执行Y动作。第二个问题过程中有哪些决策分叉点是我当时判断错了的这个错误暴露了我哪个假设是错的第三个问题哪些经验可以用一句话教给团队里的新人之前有一个项目我团队里一个架构师解决了线上数据库连接池耗尽的问题。他的复盘报告开头就很特别里面第一条不是“我做了什么”而是“任何一次数据库连接池告警出现时第一时间不是加大连接数而是先查慢查询日志”。就这一句话比报告后面所有技术分析都值钱因为它是一条可以马上被团队复用的决策规则。当一个人能够把难题变成规则他就从“解题者”变成了“定义者”从“这个难题的受害者”变成了“这类难题的掌控者”。这才是解决难题最终极的价值。5. 最后想说的专家的证明不是头衔而是解决过什么5.1 别等“够格”了才去碰难题真实世界里没有人会发一张证书告诉你“你已经够格了可以去解决难题了”。大部分人一直等等到自己觉得“准备好了”再上但那个时刻永远不会来。我自己的体会特别深我职业生涯里最有价值的成长几乎都发生在“我还没准备好但不得不硬着头皮上”的时候。所以我建议所有想进阶的人一个特别实用的动作主动举手。公司里那个没人想接的跨部门优化项目接团队里那个风险最高的技术重构接那个客户满意度最差的产品模块接。你不用管自己现在是不是“最资深”的那个人你只需要看一件事这是不是当前你跳一跳能够到的最高难度难题。如果是就举手。哪怕搞砸了你也会比不举手的人多拿到一份关于“为什么搞砸”的珍贵经验。失败了你损失的只是面子但成功的可能性会带来一次完整的层级跃迁。这笔账怎么算都划算。5.2 用两个问题识别真专家最后给大家两个我在找人、找合伙人、选技术负责人时一定会问的问题它们能帮你快速识别一个人到底是被难题淬炼过的专家还是顶着专家title的表演者。第一个问题是“你最近一次承认自己错了是在什么场景你是怎么发现并纠正的”真专家对这个问题的回答一定是具体的、甚至是难堪的因为他一定有过被现实教训到低头的经历。表演者通常会含糊其辞或者讲一个把责任推给他人的故事。第二个问题是“你上次说‘我不知道’是什么时候”真专家不怕暴露知识盲区因为他知道解决难题的本质是探索未知承认不知道是探索的第一步。表演者则几乎从不说不知道他们会试图用框架和术语把不确定性包装成确定性。这两个问题问下来谁在解题、谁在表演立刻一目了然。对我个人来说做《创业之路》这么久看着一批又一批读者从职场新人变成独当一面的负责人我越来越确信一件事难题不是麻烦难题是入场券。你今天选择躲开的那道难题会在未来某一天变成挡住你上升的那堵墙。你今天硬着头皮扛下来的那道难题则会变成你称呼自己为“专家”时最硬气的底气。如果你的桌上现在正好摆着一件让你很慌、很想拖的事情恭喜你这可能就是你职业生涯里最值得庆幸的时刻。