习惯 5: 分配工作
即使自己处理效率更高，质量更好，仍然需要委托！职位越高，越不靠单打独斗。
发展自己 -> 发展团队 -> 发展公司
分配任务时，并不是指令那么简单，让下属复述一遍确定理解了要做什么，什么时间之前做完。
这里面充斥着太多的变量，我们需要循序渐进的建立信任，可以参考这里
Google管理小团队的秘密
简单任务 → 常规任务 → 挑战性任务
│ │ │
└─基础训练 └─能力提升 └─突破成长
这个过程是一个信任建立的过程：技能评估 → 目标设定 → 任务匹配 → 持续指导 → 效果评估
也是一个不容易的过程：
习惯 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太厉害了，主动发现并解决了系统隐患，详细记录了解决方案，分享经验帮助团队成长”
表扬可能谁都会，但是巡训斥不是人人都会的，尤其是一些讨好型人格。训斥不要当着他人，避免情绪化，训斥不是为了发泄情绪，而是为了解决问题》：让部下建立假设， 为什么做的不好，如何改善。
代码质量问题
❌： 不好的训斥方式： “你的代码质量太差了，怎么能这样提交？”
✅：私下沟通： “我看了你提交的代码，有几个地方想和你讨论：
你觉得这段代码为什么会导致性能问题？如果要提高代码复用性，你觉得可以怎么改进？我们一起看看如何用设计模式优化这个结构？”
项目延期问题
❌： 不好的训斥方式： “又延期了，你的时间管理能力实在太差！”
✅：私下沟通： “关于这次项目延期：
你觉得哪些因素影响了进度？下次遇到类似情况，你会如何提前预警？我们一起制定一个更详细的里程碑计划好吗？”
