《加速：企业数字化转型的24项核心能力》分享

由于几乎所有的公司都依赖于软件，因此软件绩效对于如今任何公司来说都至关重要，软件交付绩效受到许多因素影响，包括领导力，工具、自动化，以及持续学习和改进的文化，概括一下就是组织绩效依托：高效的团队实践、管理实践和领导力实践。

这本书分三个部分：

第一部分讲述了软件交付绩效如何驱动组织绩效，侧面回答为什么很重要

第二部分总结了研究背后的科学，设计决策和所用的分析方法，希望能影响更多人看见这些提高组织绩效的核心能力实践

第三部分讨论了转型，透过能力和实践在实际工作的样子，帮助转型路上的企业明确自己如何优化技术流程，业务流程，工作文化和改进周期，这就是对创新组织的意义，同时也提醒在位者切勿指望通过花钱来实施文化和复制成功，需要自己发展符合环境和目标的道路，这需要持续的努力、投入、专注和时间，而这些所有的付出都是值得的。

读完之后确实对背后的底层逻辑更理解了，知其然更能知其所以然，建议只要和IT相关的人都阅读一下这本书，并在工作中去实践，正所谓学以致用。

我重点分享前面两部分，第三部分我也还在ing的状态，今年我也会去分享我们转型的故事。

Part1：从工程实践和精益管理实践展开分享

核心能力速查表

读后感分享：

1. 认识到数字化转型，变革领导关注能力 over 成熟度，团队的核心能力提升 over 花里胡哨的面子工程；

2. 在组织文化还没有安全感的时候放弃度量，如果数据和舆论不一致的时候一定是数据出了问题（哪里有恐惧哪里就有错误的数据），在度量之前必须了解和重塑组织文化，免责、授权、同理心。

3. 对文化进行建模，文化层面分3个层面：基本假设/价值观/工件

   -了解文化的现状定义目标识别差距，参考Ron Westrum的组织特征模型

   Ron-Westrum 组织特征模型

   病态性组织-权力导向	官僚型组织-规则导向	生命型组织-绩效导向
   低协作性	中等协作性	高协作性
   消灭信使	忽视信使	训练信使
   逃避责任	限制责任	共担风险
   不鼓励连接	允许连接	鼓励连接
   失败后寻找背锅侠	失败后寻找公平	失败后进行调查
   不创新	创新导致问题	实现创新

   度量文化建议使用类似心理测量的意愿度测量，所有人测完后取平均值

   1-7分：非常不同意-不同意-些许不同意-既不同意也不反对-些许同意-同意-非常同意
   

   	1	2	3	4	5	6	7
   1.积极寻求信息
   2.当传递失败信息或坏消息时信使不会受惩罚
   3.共担责任
   4.鼓励和嘉奖跨职能协作
   5.失败后进行调查
   6.鼓励提出新想法
   7.失败首先被认为是改进机会

4. 度量软件交付绩效采用DevOps的4KM（4 个关键度量指标），前三个和组织绩效强相关，变更失败率和组织文化强相关。

   
   

5. 组织文化可以预测软件交付绩效和组织绩效

6. 改变组织文化最直接的方式是重塑团队行为

7. 采用持续交付实践知道什么work什么不work，质量提升后满意度提高

8. 高绩效企业与低绩效企业之间的差距主要体现在能否在第一时间内做正确的事情，能否小批量工作和持续不断的在过程中测试，减少失败。

9. 松耦合的架构确保团队的沟通带宽不会被实现级别的细节决策耗尽

10. 让团队可以变更他们所负责的产品或服务，而无需依赖其他团队或系统，架构师应该为此努力，而不是控制团队必须使用什么工具或技术。

11. 信息安全内建，展开坚固运动，坚固运动宣言，坚实是每个人的责任。

• 我很坚实，更重要的是，我的代码很坚固

• 我认识到软件已经成为现代社会的基础

• 我认识到这一基础角色带来的巨大责任

• 我认知到自己的代码将以我无法预料的方式被使用，以非其设计目的的方式被使用，而且使用时间长于预期

• 我认识到自己的代码将受到强劲对手的持续攻击，而这会威胁我们的人生安全、经济安全和国家安全

• 我认识到上述诸点，并且我选择坚实

• 我坚实，因为我拒绝成为漏洞的起源

• 我坚实，因为我保证自己的代码将服务于它的使命

• 我坚实，因为我的代码可以面对挑战并坚持不懈

• 我坚实，不是因为这样做很容易，而是因为我有必要这样做，我将直面挑战。
  

软件开发的管理实践-精益管理实践提高稳定性、质量和速度帮助团队改进

未来不再是IT自嗨的敏捷，一定会是结合产品管理驱动敏捷，驱动绩效

持续交付的工程实践 & 精益管理实践双流集合产生的组织行为影响

Part2：变革领导力如何提升员工满意度和身份认同感

第一阶段也是先评估团队的eNPS值（1~7分）

第二阶段就是变革领导者需要五个维度去支持团队的行为，领导者无法靠自己实现目标

受访者对上级领导的变革型领导力度量（1~7分）

关于远景：

• 清楚地了解我们的目标
  

• 清楚地了解他或她希望我们的团队在5年后是什么样
  

• 清楚地了解组织的发展方向
  

关于鼓舞人心的沟通

• 会说一些些话，使员工因为是组织中的一员而感到自豪
  

• 积极赞赏团队
  

• 鼓励人们将变化的环境视为机遇
  

关于智力开发

• 激励我以新方式思考旧问题
  

• 有办法迫使我重新思考我以前从未质疑过的一些事情
  

• 让我重新思考我在工作中所做的基本假设
  

关于提供支持

• 在行动前会考虑我的个人感受

• 表现出已经充分考虑了我的个人需求
  

• 认为应该充分考虑员工的利益
  

关于认可他人：

• 当我做得比平时更好时，会表扬我
  

• 承认我的工作质量有所提高
  

• 当我取得杰出的工作成果时，会从个人角度称赞我

教练和TL改善团队文化和支持团队的小技巧

• 与其他团队里的同事建立信任

• 鼓励员工在各部门之间转岗

• 积极寻求、鼓励和奖励那些促进协作的活动（例如利用混沌工程的灾难恢复测试练习建立关系，和IT部门，安全部门，业务部门）

作为技术TL的一些带团队的小技巧：

• 确保现有资源可供组织中的每个人访问和使用，创造机会和空间用于学习和改进

• 专门做培训预算，并确保员工知道有这样的预算，让员工有权选择他们感兴趣的培训的项目，培训可以利用上班时间，以便于利用组织中的已有资源

• 鼓励员工每年至少参加一次技术会议，并向整个团队总结他们所学到的知识

• 设置内部黑客马拉松，让跨职能团队成员可以聚集在一起做项目

• 管理团队组织内部“牦牛日”，即多个团队一起偿还技术债，因为技术债很少能排上优先级

• 定期举行内部DevOps小型会议，预先准备的演讲和开放空间相结合，参与者自发组织各种对话

• 给员工留一些时间来专门实验新的工具和技术，例如20%的工作时间或发布后的几天时间。为特殊的项目分配预算和基础设施。

部落负责人创造学习氛围的小技巧：

• 做培训预算，并在组织内部倡导培训

• 确保团队有资源参与非正式的学习，并且可以探索新想法

• 让失败是安全的

• 创建共享信息的机会和空间（产品部落负责人可视化自己的战略改进、绩效监控、产品组合路线和领导层动作的4个维度的信息，让TL知道如何发力）

• 鼓励分享和创新，通过演示日和论坛，让团队彼此分享创造的东西

• 确保团队可以自主选择工具

• 让监控成为优先事项（优化你的基础设施和应用程序的监控系统，做到数字化运营，高响应力）