写博有道可循

《凤凰项目》讲述的是一位运维总裁，在短短几个月里，如何利用高人指点的方法，逐步改善运维部的工作效率，乃至最终对开发部和其它部门产生积极的影响，将公司从生死边缘挽救回来的小说。没错是小说，这样的形式大大加强了代入感，没经验的能获得更形象的意境，有经验的则能产生共鸣。里面主要围绕的是一个称为“三步工作法”来探索最优的流程设计、工作应遵循的原则。同时，在人物之间的对话，还学到很多为人处事的技巧，对提高工作情商有一定裨益。

故事线路

1. 大背景为公司正在开发着一个至关重要的凤凰项目，但已经延期和投入超预算（项目交付成果延期）
2. 其它系统经常发生事故，为降低事故率，开始重整变更流程，使精力可专注到主要项目（故障处理工作繁重）
3. 需要针对N多个安全审计问题，给出答复和整改计划，但人手严重不足（审计合规工作紧迫）
4. 开始发现很多工作都需要有同一个人的存在下才能开展，无论是修复问题、确认审计、项目开发（资源受限）
5. 开始使用白板贴卡片的方式呈现变更，并对变更分析分类，确定优先级、风险性、重要度、所需关键资源（可视化工作管理，建立快速工作流）
6. 得到高人第一次指点：控制工作导入，放正关键资源的位置，分析四类工作的定义
7. 为脆弱服务的变更制定流程（待命、公关、提前通知），低风险的标准变更正常快速通过，中等风险变更要得向相关部门咨询及获得认可（稳定工作环境）
8. 领悟出三类工作：业务项目、内部IT项目、变更。并制定人力资源库，接替瓶颈资源的非关键工作，即使是核心的内容，人力资源库同时需要形成组织过程资产，将打扰瓶颈资源的干扰名单收集起来（保护约束点资源）
9. 凤凰项目上线，即使加班处理问题，但也因问题过多被视作了失败。同时领悟出第四类工作：计划外工作，一直修复凤凰的问题导致其它工作无法开展。
10. 得到高人第二次指点：关于目标的五个聚焦步骤，一确认约束点，二利用约束点，三约束点置于次要地位。如何将约束点从计划外的工作中拉出来保护起来
11. 发票系统故障，CEO没法接受按变更记录排查解决问题的方案，再次搞砸IT的事项，开始重新建立团队内的相互信任
12. IT运维和开发两周内不再接受新项目需求，只做与凤凰相关的工作，而审计问题定性为次优先级。
13. 得到高人第三次指点：进入第三工作法，改进日常工作，提高预防性工作，给系统施加压力并强化。同时思考解冻项目的优先级（目标是增益回路，为主要项目开路）
14. 审计顺利通过，CIO缺乏掌握全局的信息，疏忽了对有实质影响的业务评判，一直提出冗余的合规性处理工作（刀刃没用对地方）
15. 向CFO了解其远近期目标，从更系统出发了解全貌，再定位出关键领域上的风险，安排针对性的合规性处理，同时向业务发起人了解到应提升项目快速交付能力从而降低资金锁定的周期，尽快回笼资金
16. 每一项目标形成一条价值链，列出指标对应依赖的IT系统、存在可导致的业务风险、对应的防范措施
17. 工作流已经改进，但批量规模仍然太大，需要从运维向开发建立起快速不间断的反馈回路，进行小规模的验证迭代
18. 应用上了当时开始流行的DevOps（开发与环境、配置集合，实现自动化），因其符合了目标的各种需求特性，最后凤凰项目二次上线取得完满结果

核心思想

技术价值流

缩短前置时间

三步工作法原则

第一步 流动原则

实现开发到运维的工作快速地从左向右流动，为最大程度地优化工作流，需要将工作可视化，减少每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标，加强流动性

• 将工作可视化
• 限制在制品数
• 减少批量大小（降低出错成本，包括检测和修复）
• 减少交接次数（自动化）
• 持续地识别和改进约束点
• 消除日常工作中的困境

第二步 反馈原则

从右向左的每个阶段中，应用持续、快速的工作反馈机制，通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复，可实现从源头控制质量，在流程中嵌入相关知识，实现技术价值流的高质量、可靠性、安全性

• 及时发现问题（识别设计和操作问题）
• 群策群力，战胜问题获取新知识
• 将区域性新知识应用到全局范围
• 领导持续培养以上人才
• 在源头保障质量（）
• 为下游工作中心而优化

第三步 持续学习与实验原则

建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验，主动地承担风险，从成功以及失败中学习，持续缩短和放大反馈环，创造更安全和承担更多风险的系统，进行试验比对手改进更快，从市场上战胜对方，形成迭代和实验的方法

• 建立学习型组织和安全文化
• 将日常工作的改进制度化
• 把局部发现转化为全局优化
• 在日常工作中注入弹性模式（加强抗脆弱性）
• 领导层强化学习文化

感悟

• 养成对下属的重视、了解，委托重任前还可以先找共同点切入
• 当工作问题和个人问题同时发生时，解决工作问题永远是首位
• 拒绝前，先表达出同理心，但关键问题还是需要坦白交代，并引用案例
• 问题的处理步骤：定位问题->挖掘核心原因->评估资源（人、时间、资金）->评估环境（可操作范围、需规避的风险）->制定方案
• 避免过度依赖人，组织过程资产不能不建立
• 优先级高的任务要更专注地去完成，否则产生计划外工作时会有更大工作量
• 非功能性需求可能才是发展的关键（短期内：重要不紧急，长期：重要紧急）

今句摘录

只可对上抱怨，不许对下牢骚

关键在于，我们在有限的时间里能够做什么，以及哪些系统是真正可以修复的

在瓶颈之后做出的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来，而在瓶颈之前做出的任何改进则只会导致瓶颈处堆积更多的库存

作为运维总裁，其工作是确保一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，这样才能提供稳定的、可预期的、安全的IT服务

控制工作的导入量，确保绝大多数受约束的人力资源都只能投放在为整个系统的目标所服务的工作上，而不只是为一个部门的目标服务

80%的风险由20%的变更造成的

黎明之前总有黑暗

限制驱导式排程法，队伍里最慢点童子军赫比实际上决定了整支队伍的行军速度，亚历克斯把赫比调到队伍前头，防止孩子们超前太远

把所有的工作周期都花在了功能开发上，而没有用在稳定性、安全性、可扩展性、可维护性、可操作性、持续性以及其它诸如此类的美好性能上（非功能性需求）

不仅仅要减少半成品，相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要

技术债，来自于走捷径，在短时间内也许行得通，像金融债务一样，久而久之利息成本会越滚越高

适当提高预防性工作是全面生产维护等计划的关键。改进日常工作比开展日常工作更重要

不断给系统施加压力，从而不断强化习惯并加以改进。系统里要经常出些故障，长久以往，再遇到困难就没有原来那么痛苦。

不断重复可以形成习惯，而有了习惯才能变得精通

资源的等待时间，等于资源忙碌时间的百分比除以空闲时间的百分比（指数上升）

一个部门内创建工作并确定其优先级就很难，而管理多个部门之间的工作则是难上加难

产品开发周期越长，公司资本锁定的时间也就越长，资金锁定期间是没有回报的

有效地管理IT不只是一种关键能力，也是公司业绩的重要预测指标

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 mingfungliu@gmail.com