在职场中，我们常常会思考一个根本性的问题：工作的本质是什么？简单来说，工作就是一个不断发现问题并解决问题的过程，那么工作的价值就在于我们解决了什么样的问题。
每一个工作任务的背后，都隐藏着一个待解决的问题。比如：
- 当商品销量下滑时，我们需要找到提升销量的方法
- 当业务表现不佳时，我们需要制定策略提高业绩
- 当人手不足时，我们需要招募新的团队成员
这些都是典型的"问题-解决方案"模式。问题就像是我们的起点，而解决方案则是我们要到达的终点。
在这个过程中，真正的专业性体现在：如何在保证质量和效率的前提下，找到从问题到解决方案的最短路径。这就像几何学中两点之间最短距离是一条直线一样，专业能力就是帮助我们画出这条最优路径的工具。
解决问题的流程
麦肯锡对解决问题沉淀出了一个黄金的流程：
- 掌握真正的问题
- 对问题进行整理
- 收集情报
- 提出假设
- 验证假设
- 思考解决办法
- 选择最好的办法
- 执行办法
- 评估结果
因为掘金的读者大部分是IT人员，这里以IT项目举例，其实在任何行业都适用。
🙋 问题：用户反馈系统响应速度慢。
1. 掌握真正的问题
- 用户反馈系统操作响应时间超过3秒
- 主要发生在高峰期（上午9-11点）
- 影响到订单处理和库存查询功能
2. 对问题进行整理
- 系统响应延迟问题
- 并发访问压力问题
- 数据库查询效率问题
- 服务器资源使用情况
3. 收集情报
- 查看系统监控日志
- 分析服务器CPU、内存使用率
- 检查数据库查询性能
- 收集用户具体使用场景
- 统计访问量峰值数据
4. 提出假设
- 数据库查询语句可能未优化
- 服务器配置可能不足
- 缓存策略可能不合理
- 可能存在资源泄漏
5. 验证假设
- 使用性能监控工具分析系统瓶颈
- 检查数据库慢查询日志
- 进行压力测试
- 分析内存使用情况
6. 思考解决办法
- 优化SQL查询语句
- 添加适当的索引
- 实现数据缓存机制
- 增加服务器资源
- 实现负载均衡
7. 选择最好的办法
根据验证结果，确定最有效的解决方案组合：
- 优化最频繁使用的SQL查询
- 实现Redis缓存机制
- 对热点数据建立索引
8. 执行办法
- 在测试环境实施优化方案
- 编写缓存实现代码
- 评审代码
9. 评估结果
- 定量指标与定性指标评估： 系统优化前后优化后的性能测试对比，用户参与测试的直观感受
- 总结经验：记录解决方案与最佳实践，与行业标准的解决方案对比不足与后续探索方向
这就是本文分享的第一个工作习惯，工作中要建立解决问题的流程。
习惯 2 从"0"出发解决问题
在我所在公司证书续签是一个大麻烦，每年都会有大批量的证书需要续签，有一个非常繁琐的确认机制。
这个续签证书问题的表象是：
- 证书快过期了
- 需要定期续签
- 担心忘记续签导致系统故障
但本质问题是什么呢？
- 为什么我们需要手动管理这么多证书？
- 服务器上到底有多少应用在使用证书？
- 这些应用是否都还在活跃使用？
这意味着我们需要更深层的解决方案，比如：
-
服务器应用治理
- 清查所有运行中的应用
- 识别已停用但未下线的应用
- 建立应用生命周期管理机制
-
自动化管理
- 实现证书自动续签
- 建立证书统一管理平台
- 设置监控和预警机制
再举一个发传单营销的例子，当我们发传效果不好的时候，可能我们会想：
-
改进传单设计
- 加入小书签
- 优化视觉效果
- 改进文案内容
-
增加发放量
- 扩大发放范围
- 增加发放频次
- 增加发放人员
但是不妨以从零思考的路径，来重新审视问题。
-
首要问题：我们的目标是什么？
- 获取新客户？
- 提升品牌知名度？
- 促进销售转化？
-
本质问题：
- 发传单是否是最有效的营销方式？
- 目标客户群的获取信息习惯是什么？
- 是否应该考虑完全不同的营销渠道？
-
更优解决方案：
- 研究目标客户的行为习惯
- 考虑数字营销渠道
- 建立精准营销体系
- 设计多渠道营销策略
通过从零开始思考，我们往往能发现：
- 很多问题的解决方案不在问题本身
- 需要跳出现有框架思考更根本的解决方案
习惯 3: 去依赖路径
在很多时候，人们会习惯性地依赖过往的经验、常规的路径去认知事物和做判断，这就如同形成了一种固定的思维轨道。而强调去除依赖路径，就是要打破这种定式，避免被惯性带着走。
这种惯性的条件反射往往是将我们自己困在盒子里的原因。我们常常会基于自己已有的观念、过往形成的评价体系，条件反射般地对各种现象、事件给出观点和评价。
**如何突破依赖路径？
- 遇到问题立即用过去的解决方案 -> 暂停第一反应
- 习惯性做法是什么 -> 是否存在其他做法？
- 基于个人理解 -> 尊重不同视角，保持开放心态
这样我们才能克服自我障碍，建立俯视观点
-
从更高维度思考：
- 跳出具体问题看全局
- 考虑长期影响
- 关注系统性解决方案
-
接近事物的真相：
- 收集客观数据
- 进行多角度分析
- 寻找本质规律
实际案例
传统IT运维思维 vs 俯视思维
传统思维路径：
- 服务器故障→立即重启
- 性能问题→升级配置
- 安全漏洞→打补丁
俯视思维方式：
- 分析故障模式和根本原因
- 设计自动化运维系统
- 建立预防性维护机制
项目管理中的应用
条件反射式响应：
- 进度延迟→加班加点
- 需求变更→立即响应
- 质量问题→增加测试
俯视思维方式：
- 优化项目管理流程
- 建立需求管理机制
- 实施质量保证体系
实践建议
-
培养反思习惯
- 定期回顾决策过程
- 分析决策依据
- 评估决策效果
-
扩展知识视野
- 学习不同领域知识
- 借鉴其他行业经验
- 保持开放学习心态
-
建立系统思维
- 关注问题之间的关联
- 考虑决策的长期影响
- 追求根本性解决方案
通过去除依赖路径思维，我们能够：
- 发现更优质的解决方案
- 建立更系统的思考方式
- 做出更明智的决策
这种思维方式的转变需要持续的练习和自我觉察，但最终会帮助我们更接近问题的本质，找到更有效的解决方案。
同时我们在面对别人的问题，汇报，解决方法时也要保持批判性思维
案例1：项目延期处理
传统思维：
- 延期就加班加点
- 增加人力资源
批判性思考：
- 质疑：为什么总是出现延期？
- 分析：项目管理流程的问题
- 结果：改进了需求管理和任务分配机制
案例2: 服务性能低
传统思维：
- 系统性能下降就增加服务器配置
- 遇到问题就修补代码
批判性思考：
- 质疑：为什么需要频繁升级服务器？
- 分析：是否存在架构设计问题？
- 结果：发现并优化了数据库查询效率，解决根本问题
案例3: 处理客诉
传统思维：
- 收到投诉立即道歉并提供补偿
- 快速解决眼前问题
批判性思考：
- 质疑：为什么会收到类似投诉？
- 分析：投诉背后的共性问题
- 结果：优化了产品设计，从源头减少投诉
但是这里面一定要有"平衡"：
- 不是所有决定都要深入分析，都要挑战。
- 挑战时要有建设性建议，不是人身攻击。。。
习惯 4: 事情的优先级思考
时间管理矩阵大家都知道
sh
紧急 不紧急
─────────┬────────────
重要 │ 第一象限 │ 第二象限
│ 危机处理 │ 战略规划
─────────┼────────────
不重要 │ 第三象限 │ 第四象限
│ 琐事干扰 │ 时间浪费分享一下在这4个象限中实践：
- 紧急不重要：适当委派，简化处理，学会说"不"
- 不紧急不重要：别染上，尽量避免
习惯 5: 分配工作
即使自己处理效率更高，质量更好，仍然需要委托！职位越高，越不靠单打独斗。
发展自己 -> 发展团队 -> 发展公司
分配任务时，并不是指令那么简单，让下属复述一遍确定理解了要做什么，什么时间之前做完。
这里面充斥着太多的变量，我们需要循序渐进的建立信任，可以参考这里
简单任务 → 常规任务 → 挑战性任务
│ │ │
└─基础训练 └─能力提升 └─突破成长这个过程是一个信任建立的过程：技能评估 → 目标设定 → 任务匹配 → 持续指导 → 效果评估
也是一个不容易的过程：
- 正确期望，根据实际情况调整
- 不过度干预也不放羊， 把控关键节点
- 处理质量差异，最低可接受标准，改进建议，耐心指导
习惯 6: 沟通的高效性
沟通是工作中最核心的能力之一，我甚至有时候觉得沟通大于技术能力，表达不出来，等于没有。沟通能力加技术理解能力是竞争力。
明确的沟通框架
有明确沟通框架的人，会让人觉得更舒服，觉得你不是在浪费他的时间，举几个例子：
沟通技术问题
✅ "关于新项目的数据库设计，我有几个技术问题想请教，大约需要15分钟，您什么时候方便？" ❌ "你有时间吗？我想问个问题。"
✅ "我对当前的代码审查流程有个优化建议，可以节省30%的时间，您有10分钟听我说明一下吗？"
❌ "我觉得我们的代码审查流程需要改进。"
向上沟通
✅ "经理，我想汇报一下本周的项目进展，准备了5张幻灯片，大约需要20分钟，您看什么时候方便？"
❌"我要向您汇报工作。"
✅ "下周二的发布需要后端团队配合测试，预计半天时间，请问您这边能否安排人手？"
❌ "我们需要后端团队帮忙测试。"
你说一句话，对方需要再问几句才能知道你要干什么？这是在训练大模型呢？所以我们在和别人沟通时要明确目的，给出时间预期，以及自己做好充分的准备。
3个点的思考方式
在沟通时，对于任何事情，最好分成3个点，为什么是3呢？从心理学上来说，2个点太少，4个点太多。
比如在处理客户投诉这件事情的沟通上, 我们可以将沟通内容整理成3个点：
- 客户诉求梳理 我们详细了解到客户主要不满在于产品的交付时间延迟以及部分产品功能与合同约定不符。客户期望我们能在一周内给出明确的交付时间调整方案，并在一个月内完成功能修复或提供替代解决方案。
- 责任划分与行动安排
生产部门需重新评估生产流程，找出导致交付延迟的关键环节并加以优化，在三天内给出新的生产时间表。技术部门要立刻对功能不符的问题进行深入分析，确定是技术漏洞还是误解需求导致，在五天内制定出修复或优化方案，并与客户沟通确认。 - 客户关系维护。在整个处理过程中，客服部门要保持与客户的高频次沟通，每两天向客户汇报一次进展情况，同时为客户提供一定的补偿方案，比如延长产品质保期或者给予一定的产品折扣券，以弥补客户的损失并重建客户信任。"
3个点的目的也是让我们明确沟通目的和核心内容以不同的逻辑分类，比如你可以以重要性的逻辑分类，或者时间顺序分类等等，这样会让对方觉得你是一个有逻辑的人。
不仅仅是大的框架上，小的框架3个点也很重要：现状，原因，解决方案。 比如：
讨论产品改进时
- 现状：用户反馈登录流程过于复杂
- 原因：现有流程包含多次验证和确认步骤，增加了操作成本
- 解决方案：简化为一键登录，同时引入指纹识别提高安全性
代码质量问题
- 现状：近期线上bug数量明显增加
- 原因：测试覆盖率不足，代码审查流程执行不严格
- 解决方案：提高单元测试覆盖率要求到80%，引入代码评审机制
团队协作问题
- 现状：前后端团队的接口联调效率低下
- 原因：接口文档更新不及时，且缺乏统一的测试环境
- 解决方案：引入Swagger自动生成文档，搭建统一的测试环境
以事实为基础提出假设
沟通时需要假设，但是这个假设一定是基于事实的，而不是瞎说的。
举个麦肯锡工作法中的例子： A 和 B 员工调查一个连锁咖啡
A员工：这家咖啡厅周六人多，说明咖啡好喝
B员工：这家咖啡厅平日流量200人，周末流量500人，停车场满，以家庭单位来的多，所以客流量多
显然 A 的沟通毫无意义！
这种沟通在工作中我们也要注意：
❌ 主观表述："系统性能很差"
✅ 客观表述："系统响应时间增加至2.5秒，错误率达3%"
❌ 主观表述："新功能很受欢迎"
✅ 客观表述："日活增长15%，平均使用时长提升75%"
这种基于事实的假设分析，有助我们：
- 做出更准确的判断
- 提供更有说服力的论据
- 制定更有效的解决方案
- 避免决策偏差
将主张放在疑问里
用户有时其实不知道自己要什么或者不擅长表达自己的真实意图，但是我们可以帮用户做决定吗？站在人性的角度上：不可以。顺人性的做法是将主张放在疑问里，让客户说出"这就是我想要的"。
这样才能同理心，以及共同承担风险，建立关系。
比如现在需要设计资源，我们和老板直接主张： "设计部门需要提前介入产品开发流程。" 这要资源的能力就不太行。因为老板自己认同为什么设计部门要提前介入，你在整什么事情？
你需要通过抛出问题，让老板决策：
- "您觉得目前产品开发中，设计反馈的时间点合适吗？"
- "如果能在需求阶段就有设计师参与，会对最终产品质量有什么影响？"
- "您期望设计团队在产品开发的哪些环节提供更多支持？"
再或者跨部门推技术 直接主张： "我们应该使用微服务架构重构系统。" 谁会buying 你的想法？技术爱好者buying，他们的leadership 会同意吗？让他们的leader层决策：
- "现在的系统扩展时遇到了哪些具体困难？"
- "如果能让各个模块独立部署和扩展，对您的业务有什么影响？"
- "在性能、维护成本和开发效率之间，您最关注哪个方面？"
以及在面对用户的需求时，也要让用户真正参与到里面，而不是用户拍脑袋有一个想法。 用户要加入一个新功能：
❌ 直接回应： "好的，我们加入这个功能。"
✅ 正确的引导：
- "您期望通过这个功能解决什么问题？"
- "在您的工作流程中，这个功能会如何帮助您？"
- "如果有这个功能，您预计多久会用一次？"
沟通的核心在于引导用户实现自己的想法，减少误解，对抗，推动目标的实现：
引导思考 -> 避免冲突
建立共识 -> 自然的解决方案
深入了解 -> 理解真实意图的机会
促进合作 -> 建立信任 以及建设性讨论
习惯7：认可与训斥
同事做的好一定需要表扬，并且要具体的事情上表扬，这在肯定它对这个事情的付出被尊重，被认同，被看见。
比如1v1时表扬 "你这次的代码重构做得很好，特别是：提高了30%的性能，代码可读性明显提升，测试覆盖率达到95%！"
并且在公开场合也需要表扬，在团队会议上 "小A太厉害了，主动发现并解决了系统隐患，详细记录了解决方案，分享经验帮助团队成长"
表扬可能谁都会，但是巡训斥不是人人都会的，尤其是一些讨好型人格。 训斥不要当着他人，避免情绪化，训斥不是为了发泄情绪，而是为了解决问题》：让部下建立假设， 为什么做的不好，如何改善。
代码质量问题
❌： 不好的训斥方式： "你的代码质量太差了，怎么能这样提交？"
✅：私下沟通： "我看了你提交的代码，有几个地方想和你讨论：
- 你觉得这段代码为什么会导致性能问题？
- 如果要提高代码复用性，你觉得可以怎么改进？
- 我们一起看看如何用设计模式优化这个结构？"
项目延期问题
❌： 不好的训斥方式： "又延期了，你的时间管理能力实在太差！"
✅：私下沟通： "关于这次项目延期：
- 你觉得哪些因素影响了进度？
- 下次遇到类似情况，你会如何提前预警？
- 我们一起制定一个更详细的里程碑计划好吗？"