谁工作没遇到过困难？我这么多年摸爬滚打，各种坑都踩过，有些时候真不是技术不行，是思路没打开。今天我就把我那些年，怎么从死胡同里绕出来的经历，给你们好好分享一下，保证你看完就能有点启发。
我怎么对付那些“无解”的问题
刚开始工作那会儿，年轻气盛，觉得技术能解决一切。直到有一次，接了一个老系统升级的项目，简直是噩梦的开始。那个系统是十年前的架构，代码像屎山一样，文档？那是什么？根本不存在。
第一步：先别急着动手改代码
我当时犯的错就是一头扎进去，想用最新的技术全面重构。结果改了一周，发现每改一个地方，另外三个地方就崩了。气得我差点想辞职。
- 我停下来，给自己泡了杯茶，逼着自己冷静。
- 我开始做“考古”工作：不是看代码，而是观察系统运行状态。
- 我把系统最核心的几个业务流程，手动画图，用最原始的流程图描出来。
- 然后，我找来那个系统的使用者（运营部的小李），让他给我演示操作，边演示我边问：“这里为啥这么点？点完后系统做了”
这么一搞，我发现问题不是出在架构老，而是出在“理解偏差”。我们以为核心功能是A，用户每天用的是B和C两个隐藏功能，而我们差点把B和C的依赖库全删了。
遇到沟通障碍，不要想着说服，要想办法“同步”
技术上的问题解决了，新的困难来了——跨部门协作。产品经理想要加个超级酷炫的功能，但是老板那边预算和时间卡得死死的。典型的“既要又要还要”。
第二步：把“不可能”变成“分阶段可能”
我以前的做法是直接拒绝：“不行，没时间，做不了！”结果就是大家都不高兴，觉得我拖后腿。
后来我学精了，学会了“分解”和“可视化”。
- 我把产品经理想要的“酷炫大功能”，拆分成十个小功能点。
- 把这十个点，按照实现难度和所需时间，贴到白板上（用便利贴，上面写上预估工期）。
- 然后把老板给的DEADLINE写上去，再把我们现有的人力资源写上去。
- 把产品经理和老板都叫到白板前，让他们自己看——“大家看到了吗？我们现有资源能做完前五个。如果要硬塞后面五个，除非时间延长一个月，或者人力增加两个人。”
神奇的是，当你把困难具象化之后，他们就不觉得是你故意为难了。他们会自己开始取舍：“那第六个不着急，先做前五个核心的。” 困难一下子就迎刃而解了，我从一个“拒绝者”变成了“协调者”。
被“经验主义”困住的时候，学学“新手思维”
很多时候，困难不是来自外部，而是来自我们自己的“惯性思维”。我一个老项目，运行两年了，突然跑出个性能瓶颈，所有人都觉得是数据库扛不住了，于是我们开始研究分库分表。
第三步：回到起点，质疑一切假设
我们花了一周时间做调研，发现要做分库分表，需要动整个业务流程，工程量巨大。我当时就觉得不对劲，这么大的改动，代价太高了。
- 我重新梳理了系统的所有日志，不是看报错，是看“慢查询”。
- 我发现最慢的查询居然是一个看起来非常简单的列表查询。
- 用我们固有的经验，这个查询肯定没问题。但我在本地模拟了一下，发现这个查询在某些特定参数下，走了错误的索引。
我们一直假设是“数据量太大”导致性能差，结果只是一个简单的索引设置问题。一个小时就解决了，省去了我们后面两个月做分库分表的巨大工作量。当你觉得一个问题需要“大动干戈”才能解决时，先停下来，问问自己：“有没有一种可能，我从一开始的假设就是错的？”
工作遇到的困难，很多时候是思维被锁住了。打破固有的边界，把问题分解、具象化，或者干脆回到原点去质疑它。这就是我这些年摸索出来的，对付那些看似“无解”问题的土办法。
还没有评论，来说两句吧...