第一部分：书中几个关键词的总结
三步工作法
第一工作法：建立从开发部到IT运维部之间的快速工作流。
第二工作法：建立从IT运维部到开发部的不间断反馈回路，在初始阶段就筹划产品的质量，避免返工。
第三工作法：改进文化。
四种工作类型：业务项目、IT运维项目、变更和计划外工作（反工作）。计划外工作会让我们丧失开展计划内工作的能力，因此必须不计一切代价消灭计划外工作。
改进文化：改进日常工作比开展日常工作更重要。可以有持续不断的两周改进周期，每个周都要实施一个小型的“计划 - 执行 - 审核 - 落实”项目。要建立一种不断尝试、勇于冒险以及从失败中汲取经验教训的文化和价值观。
约束点：即瓶颈。在瓶颈之外的任何地方做出的改进都是假象。
变更板：变更控制。需要确保运维能够掌握每一次的变更内容，并对每一次的变更做出评审，避免对现有系统的不良影响。
训练：训练让伟大的团队达成最优表现。对任何流程或技巧来说，训练成习惯，习惯成精通。
第二部分：自己的想法
结合运维组现状，有以下想法：
1.我们缺乏对变更的管理和控制，只有这个地方管理起来，才能进一步建立标准、快速的工作流。具体做法：
- 确定“变更”的概念和范围，显然我们的终点管控对象应该是数据库和系统的变更
- 数据库变更：我们已经准备了现成的变更标准只是还没有发布
- 系统变更：在需求变更评审之前准备变更内容的预判和意见，在评审完成之后正式上线之前出具变更报告，要求明晰每项变更带来的已知和潜在影响，分析报告显示在可控范围才能允许上线。
2.缺乏对约束点的认识。 - 不用说了。。最大的约束点肯定是无法实现批量，也就是自动化。所以我对自己的进度还是有点自责。
- 其次是能够转到前端去处理的问题，却因为整体战略或者其他原因无法给我们排期处理，这个问题不好解啊。
其他方面的想法：
1.里面还让我想起两个概念：持续交付 & 精益运维 。个人觉得“精益、标准”是提高团队效率并达到持续交付的关键所在。
2.关于之前跟你说的“感觉信息部在公司不是很受重视”，凤凰项目中也是一样的问题。但这本来是不正确的，我们是不是应该去努力赢得这种重视？正如书中说“IT部门应该是像电力系统一般的存在”。当然，我能够感觉到在向这个方向努力了……
3.书里有提到某高层的一些指标：
- 我们有竞争力吗？
- 了解客户的需求和期望：我们知道要创建什么吗？
- 产品系列：我们有正确的产品吗？
- 研发效能：我们能有效的创建产品吗？
- 上架时间：我们能尽快把产品推向市场并占有一席之地吗？
- 销售机会渠道：我们的产品能带来感兴趣的潜在客户吗？
- 我们遵守了对客户的承诺吗？
- 我们是在获得客户，还是在流失客户？
……
这些指标，是否也应该指导着我们IT部门的各项考评？
网友评论