1.管理

产品管理

1.产品思维

5W2H分析法又叫七问分析法，创于二战中美国陆军兵器修理部。简单、方便，易于理解，实用，富有启发意义，广泛用于企业管理和技术活动，对于决策和执行性的活动措施也非常有帮助，也有助于弥补考虑问题的疏漏。
（1）WHAT——是什么，目的是什么，做什么工作。
（2）WHY——为什么要做，可不可以不做，有没有替代方案。
（3）WHO——谁，由谁来做。
（4）WHEN——何时，什么时间做，什么时机最适宜。
（5）WHERE——何处，在哪里做。
（6）HOW ——怎么做，如何提高效率，如何实施，方法是什么。
（7）HOW MUCH——多少，做到什么程度，数量如何，质量水平如何，费用产出如何。

用户体验 = 新体验 - 旧体验 - 替代成本。 所以大家都在做复刻，不再做创新。

团队管理

1.研发流程管理

• 项目流程
• 高稳定项目流程改进

2.项目管理

• 项目管理经验之谈
• 程序员心声
• 程序员面试
• 别人家的技术leader是如何建设团队、管理人员、沟通工作的？
• 技术总监思维：公司不在乎你干了多少活

3.管理工具

自己下属能力很强，但是由于公司或者团队内部没有晋升的空间了，为了稳住员工，可以设置下有名无实的tile。最好的例子就是阿里MVP，腾讯TVP。
按照彼得原理，人在晋升到一定程度时一定会遇到自己无法胜任的位置。这个时候需要我们自己能够打破职业认知。比如P6升P7，就不是单独自己一人完成某些任务，而是自己组织，推动。寻找如何实现团队价值，如何完成部门目标。

底层管理：
    对上，你需要理解领导的意图，考虑每一件事的核心目标、资源和风险；
    对下，你要拆解目标，让团队小伙伴形成一股合力，心甘情愿去朝着目标努力

评价一个管理者的好坏，从来不是看下属的评价，而是看最终实现的成绩。

管理工具：    
    OKR工作法：作用是上下级制定一致的目标。
    业务计划推进表：每件事落实到具体的人和时间。
    GRAI、ORID：复盘法，总结出有效的经验，减少犯错的可能。

外包管理

1. 前期规划与合同管理
   • 明确需求和目标：在项目启动前，IT部门要清晰梳理自身业务需求，明确项目的功能、性能、安全等方面的目标，形成详细的需求文档。
   • 制定规范合同：合同中要明确项目范围、交付时间、质量标准、付款方式、违约责任等关键条款，为后续合作提供坚实的法律依据。
2. 供应商选择与管理
   • 建立评估体系：从技术能力、行业经验、服务水平、信誉度等方面建立供应商评估指标体系，对潜在乙方进行全面评估，选择合适的合作方。
   • 定期考核：定期对乙方的工作进行考核，考核内容包括项目进度、质量、服务态度等。根据考核结果，对表现优秀的乙方给予奖励，对表现不佳的乙方进行督促改进或淘汰。
3. 项目过程管理
   • 建立沟通机制：建立定期的项目沟通会议，让乙方汇报项目进展、问题及解决方案。同时，设立专门的沟通渠道，方便双方随时交流。
   • 把控项目进度：要求乙方制定详细的项目计划，并按照计划推进项目。IT部门要定期检查项目进度，及时发现并解决影响进度的问题。
   • 监督质量：依据合同中的质量标准，对乙方交付的成果进行严格验收。对于不符合质量要求的成果，要求乙方及时整改。
4. 风险管理
   • 识别风险：与乙方共同识别项目可能面临的技术风险、安全风险、市场风险等，并制定相应的风险应对措施。
   • 数据安全管理：要求乙方遵守保险公司的信息安全规定，签订保密协议，确保数据在传输、存储和使用过程中的安全。
5. 关系维护
   • 建立良好合作氛围：在合作过程中，尊重乙方的工作，及时给予反馈和认可，共同解决遇到的问题，营造良好的合作氛围。
   • 促进知识转移：鼓励乙方在项目实施过程中，向IT部门的员工传授相关技术和知识，提升甲方自身的技术能力和管理水平。

工作法

1.四象限法则

计划安排：时间管理的"四象限法则"

2.五分钟定律

心理学中有个规律叫做5分钟定律：如果你缺乏做一件事情的动力，比如说学习一个技能一个乐器或者一门语言，你只要告诉自己。 "行，我就坐下学五分钟，就五分钟。"

5分钟定律

3.P9工作法

P9 工作法的核心是 "从‘解决问题'到‘定义问题、系统化解决并赋能团队'的升级"， 强调高阶岗位需具备 "战略视野、系统思维、风险意识和影响力"，最终实现 "个人价值→团队价值→业务价值" 的递进式落地。 具体实践中，会因企业文化和业务场景略有差异，但核心始终围绕 "高效驱动复杂目标达成" 展开。

1. 以"问题本质"为核心，穿透表象抓关键
   • 面对复杂业务或技术难题（如系统架构瓶颈、跨团队协作卡点），不局限于表面现象，而是通过结构化分析（如拆解问题链路、梳理核心矛盾）定位根本原因。
   • 例如：当系统出现性能问题时，P9级工程师会先区分是"架构设计缺陷""资源配置不足"还是"业务逻辑冗余"，而非直接调参优化，确保解决方案直击本质。
2. 以"战略价值"为导向，平衡短期与长期
   • 工作优先级围绕业务目标与技术战略的匹配度展开，既解决当下核心痛点（如保障业务上线），又为长期技术演进铺路（如构建可复用的基础架构、沉淀技术标准）。
   • 例如：在需求开发中，不仅完成功能实现，还会同步考虑"是否符合技术中台规划""能否支撑未来3年业务增长"，避免短期方案导致的技术债务。
3. 以"系统化思维"驱动，构建可复用的框架
   • 拒绝"重复造轮子"，通过抽象问题共性，将零散的解决方案沉淀为标准化流程、工具或架构模式，提升团队整体效率。
   • 例如：针对跨团队接口协作问题，不仅解决单次需求的接口定义，还会推动制定全公司的API设计规范、开发统一的接口测试工具，从系统层面减少同类问题。
4. 以"影响力"为杠杆，带动团队成长
   • 不局限于个人完成任务，更注重通过技术分享、代码Review、架构评审等方式传递经验，帮助团队成员提升能力，形成"1+N"的效能放大效应。
   • 例如：在解决一个核心技术难题后，会输出详细的技术复盘文档，组织内部分享会，让团队理解"如何从0到1分析并解决同类问题"。
5. 以"风险预判"为前提，提前规避潜在问题
   • 对技术决策可能引发的风险（如架构重构的兼容性风险、业务扩张的性能瓶颈）有前瞻性预判，通过模拟推演、灰度验证、应急预案降低不确定性。
   • 例如：在推动数据库分库分表时，会提前测算数据增长趋势，设计多阶段迁移方案，并准备回滚机制，避免一次性切换导致的业务中断。

工作汇报

技术负责人的述职报告应该怎么写

金字塔原理

• 先结果 后过程；
• 先结论 后原因；
• 先论点 再论据；
• 先主要 再次要。

1.年终总结

• 一名微博架构师的2016年终总结

基本格式：

• 工作总结
• 个人思考
• 未来规划

2.述职

• 通过述职发现自己"变"了

述职是一种组织的管理手段和机制，通过述职老板们关注的点有两个

• 一个是价值和结果的呈现
• 另一个是个人的成长和变化。

3.周报月报

周/月报的格式

1. 本周概况
2. 主要事件
3. 你的观点 观察
4. 需要其他人的支持。

被架空的技术负责人

技术负责人被架空，往往不是被夺权。头衔、工资和汇报关系都没变。只是你开始只等通知，不再参与决定。

1. 信息先塌：你不是被瞒着，而是被体贴地绕开。方案都写完了才让你看，方向都拍了才让你评估风险。正常的晚知道是同步，被架空的晚知道是你本该在场却没在。
2. 决策太晚：别人问你意见，但业务取舍早就定好了。你能给的只剩一句"可行或不可行"。你可以问问自己：上一次真正否掉一件事是什么时候？
3. 人事最后倒：谁进谁留你都不管了，前两根柱子迟早塌。你对结果的影响，最后都是通过人来实现的。

怎么分清授权和架空？就看两件事：决定是谁做的？结果算在谁头上？

• 别人决定，结果算别人——这是授权。
• 别人决定，结果算你——这才是被架空。

遇到这事别去抢活，也别诉苦。直接对齐责任和权力："要我负责，就得让我定；定不了，责任请交给能定的人。"对方要是还不放权，那就交接走人。