《加速:企业数字化转型的24项核心能力》分享
由于几乎所有的公司都依赖于软件,因此软件绩效对于如今任何公司来说都至关重要,软件交付绩效受到许多因素影响,包括领导力,工具、自动化,以及持续学习和改进的文化,概括一下就是组织绩效依托:高效的团队实践、管理实践和领导力实践。
这本书分三个部分:
第一部分讲述了软件交付绩效如何驱动组织绩效,侧面回答为什么很重要
第二部分总结了研究背后的科学,设计决策和所用的分析方法,希望能影响更多人看见这些提高组织绩效的核心能力实践
第三部分讨论了转型,透过能力和实践在实际工作的样子,帮助转型路上的企业明确自己如何优化技术流程,业务流程,工作文化和改进周期,这就是对创新组织的意义,同时也提醒在位者切勿指望通过花钱来实施文化和复制成功,需要自己发展符合环境和目标的道路,这需要持续的努力、投入、专注和时间,而这些所有的付出都是值得的。
读完之后确实对背后的底层逻辑更理解了,知其然更能知其所以然,建议只要和IT相关的人都阅读一下这本书,并在工作中去实践,正所谓学以致用。
我重点分享前面两部分,第三部分我也还在ing的状态,今年我也会去分享我们转型的故事。
Part1:从工程实践和精益管理实践展开分享
关键实践 | 核心能力 | 检测方式 | |
1 |
版本控制 |
持续交付能力 |
|
2 | 部署自动化 |
持续交付能力 |
计算机执行重复性任务, 而人类解决问题 |
3 | 持续集成 |
持续交付能力 |
每次变更触发自动化单元测试,任何一个构建任务失败开发立即修复它。 |
4 |
主干开发 |
持续交付能力 |
活跃分支任何时候不超过3个,非主干分支的生命周期小于1天 |
5 |
测试自动化 |
持续交付能力 |
当自动化测试通过时团队确信他们的软件是可发布的 |
6 | 测试数据管理 |
持续交付能力 |
团队拥有充足的测试数据,测试数据不局限于自动化测试所需要的数据,可用于运行自动化测试套件,可以按需获取测试数据 |
7 |
安全左移 |
持续交付能力 |
安全实践融入到日常工作 |
8 | 持续交付 |
持续交付能力 |
小批量工作,一开始就将质量嵌入到过程中 编码-单元测试; 详细设计-集成测试; 概要设计系统测试; 需求分析验收测试 |
9 |
松耦合的架构 |
架构能力 |
不依赖外部团队,可独立部署 |
10 |
授权团队 |
架构能力 | |
11 |
用户反馈 |
产品与流程能力 | |
12 | 价值流 |
产品与流程能力 | |
13 |
小批量工作 |
产品与流程能力 | |
14 |
团队实验 |
产品与流程能力 | |
15 |
变更审批流程 |
精益管理与监控能力 | |
16 | 监控 |
精益管理与监控能力 | |
17 | 主动通知 |
精益管理与监控能力 | |
18 | 限制在制品数量 |
精益管理与监控能力 | |
19 | 可视化工作 |
精益管理与监控能力 | |
20 | Westrum组织文化 |
文化能力 | |
21 |
支持学习 |
文化能力 | |
22 | 团队间协作 |
文化能力 | |
23 | 工作满意度 |
文化能力 | |
24 | 变革型领导力 |
文化能力 |
核心能力速查表
读后感分享:
认识到数字化转型,变革领导关注能力 over 成熟度,团队的核心能力提升 over 花里胡哨的面子工程;
在组织文化还没有安全感的时候放弃度量,如果数据和舆论不一致的时候一定是数据出了问题(哪里有恐惧哪里就有错误的数据),在度量之前必须了解和重塑组织文化,免责、授权、同理心。
-
对文化进行建模,文化层面分3个层面:基本假设/价值观/工件
-了解文化的现状定义目标识别差距,参考Ron Westrum的组织特征模型
Ron-Westrum 组织特征模型
病态性组织-权力导向 官僚型组织-规则导向 生命型组织-绩效导向 低协作性 中等协作性 高协作性 消灭信使 忽视信使 训练信使 逃避责任 限制责任 共担风险 不鼓励连接 允许连接 鼓励连接 失败后寻找背锅侠 失败后寻找公平 失败后进行调查 不创新 创新导致问题 实现创新 度量文化建议使用类似心理测量的意愿度测量,所有人测完后取平均值
1-7分:非常不同意-不同意-些许不同意-既不同意也不反对-些许同意-同意-非常同意
1 2 3 4 5 6 7 1.积极寻求信息 2.当传递失败信息或坏消息时信使不会受惩罚 3.共担责任 4.鼓励和嘉奖跨职能协作 5.失败后进行调查 6.鼓励提出新想法 7.失败首先被认为是改进机会 -
度量软件交付绩效采用DevOps的4KM(4 个关键度量指标),前三个和组织绩效强相关,变更失败率和组织文化强相关。
-
组织文化可以预测软件交付绩效和组织绩效
-
改变组织文化最直接的方式是重塑团队行为
-
采用持续交付实践知道什么work什么不work,质量提升后满意度提高
高绩效企业与低绩效企业之间的差距主要体现在能否在第一时间内做正确的事情,能否小批量工作和持续不断的在过程中测试,减少失败。
松耦合的架构确保团队的沟通带宽不会被实现级别的细节决策耗尽
让团队可以变更他们所负责的产品或服务,而无需依赖其他团队或系统,架构师应该为此努力,而不是控制团队必须使用什么工具或技术。
-
信息安全内建,展开坚固运动,坚固运动宣言,坚实是每个人的责任。
我很坚实,更重要的是,我的代码很坚固
我认识到软件已经成为现代社会的基础
我认识到这一基础角色带来的巨大责任
我认知到自己的代码将以我无法预料的方式被使用,以非其设计目的的方式被使用,而且使用时间长于预期
我认识到自己的代码将受到强劲对手的持续攻击,而这会威胁我们的人生安全、经济安全和国家安全
我认识到上述诸点,并且我选择坚实
我坚实,因为我拒绝成为漏洞的起源
我坚实,因为我保证自己的代码将服务于它的使命
我坚实,因为我的代码可以面对挑战并坚持不懈
我坚实,不是因为这样做很容易,而是因为我有必要这样做,我将直面挑战。
软件开发的管理实践-精益管理实践提高稳定性、质量和速度帮助团队改进
未来不再是IT自嗨的敏捷,一定会是结合产品管理驱动敏捷,驱动绩效
持续交付的工程实践 & 精益管理实践双流集合产生的组织行为影响
Part2:变革领导力如何提升员工满意度和身份认同感
第一阶段也是先评估团队的eNPS值(1~7分)
|
第二阶段就是变革领导者需要五个维度去支持团队的行为,领导者无法靠自己实现目标
受访者对上级领导的变革型领导力度量(1~7分)
关于远景:
清楚地了解我们的目标
清楚地了解他或她希望我们的团队在5年后是什么样
清楚地了解组织的发展方向
关于鼓舞人心的沟通
会说一些些话,使员工因为是组织中的一员而感到自豪
积极赞赏团队
鼓励人们将变化的环境视为机遇
关于智力开发
激励我以新方式思考旧问题
有办法迫使我重新思考我以前从未质疑过的一些事情
让我重新思考我在工作中所做的基本假设
关于提供支持
在行动前会考虑我的个人感受
表现出已经充分考虑了我的个人需求
认为应该充分考虑员工的利益
关于认可他人:
当我做得比平时更好时,会表扬我
承认我的工作质量有所提高
-
当我取得杰出的工作成果时,会从个人角度称赞我
教练和TL改善团队文化和支持团队的小技巧
与其他团队里的同事建立信任
鼓励员工在各部门之间转岗
-
积极寻求、鼓励和奖励那些促进协作的活动(例如利用混沌工程的灾难恢复测试练习建立关系,和IT部门,安全部门,业务部门)
作为技术TL的一些带团队的小技巧:
确保现有资源可供组织中的每个人访问和使用,创造机会和空间用于学习和改进
专门做培训预算,并确保员工知道有这样的预算,让员工有权选择他们感兴趣的培训的项目,培训可以利用上班时间,以便于利用组织中的已有资源
鼓励员工每年至少参加一次技术会议,并向整个团队总结他们所学到的知识
设置内部黑客马拉松,让跨职能团队成员可以聚集在一起做项目
管理团队组织内部“牦牛日”,即多个团队一起偿还技术债,因为技术债很少能排上优先级
定期举行内部DevOps小型会议,预先准备的演讲和开放空间相结合,参与者自发组织各种对话
给员工留一些时间来专门实验新的工具和技术,例如20%的工作时间或发布后的几天时间。为特殊的项目分配预算和基础设施。
部落负责人创造学习氛围的小技巧:
做培训预算,并在组织内部倡导培训
确保团队有资源参与非正式的学习,并且可以探索新想法
让失败是安全的
创建共享信息的机会和空间(产品部落负责人可视化自己的战略改进、绩效监控、产品组合路线和领导层动作的4个维度的信息,让TL知道如何发力)
鼓励分享和创新,通过演示日和论坛,让团队彼此分享创造的东西
确保团队可以自主选择工具
让监控成为优先事项(优化你的基础设施和应用程序的监控系统,做到数字化运营,高响应力)
团队实践 |
管理实践 |
领导力实践 |
|
文化 |
*孕育生机型文化 |
||
*内建质量,持续度量和监控 | *强调质量,保护团队的质量保证能力 | ||
*给团队流出时间去学习和创新 |
|||
组织结构 |
组建跨职能团队,多技能的小团队、促进团队间的交流和合作 |
*度量和管理(矩阵式跨职能价值流) 培养内部教练,并为他们提供支持 |
|
直接学习和统一价值观 |
*与客户交流,向客户学习,用客户的反馈验证(Gemba) |
*与客户和团队交流,向他们学习(Gemba) |
*与客户、团队、供应链合作方以及其他利益相关方交流,向他们学习 |
*通过练习提升创造力, 鼓励团队利用练习时间学习和创新 |
*为提升创造力流出预算和时间 | ||
*理解并能展示客户价值,识别可用于度量质量的指标 | |||
战略部署 |
*将团队目标可视化,理解为何这些目标有助于企业战略 |
*帮助团队将目标可视化,理解并解释这些目标有助于企业战略(战略承接,接球) |
*练习战略部署,将所有目标可视化,向经理解释目标,帮助他们合理制定自己的目标 |
*积极监控和展示目标完成情况 | |||
通过分析和系统的问题解决方法促进信息的流动(PDCA) |
展示并分析工作流,识别障碍,优先处理有碍客户价值、客户体验和团队目标的问题, |
价值流映射和分析,帮助团队理解工作价值 |
优先支持底层工作流的映射和分析 |
系统的解决问题,通过分析找到问题根源 | 优先清除系统性障碍 |
||
升级跨职能的问题和系统性问题,提出关于问题根源的假设,设计并开展可控的实验,度量实验结果,分享结论,改进 | 协调解决跨职能的问题,解决或升级系统性问题 |
采用“接球”实践和PDCA循环,按照优先级安排解决问题的人 |
|
节奏和惯例 |
*展示、度量和监控工作流,留意偏差 |
||
*拆分需求、定期且频繁的发布 |
|||
*展示需求、WIP和已完成的工作(看板) | |||
*最小化并展示WIP | |||
根据目标为需求制定优先级 | |||
确定并实践标准工作方式 | |||
举行每日站会,根据需要升级问题(接球) |
与团队负责人举行每日站会,根据需要解决、协调或升级问题 |
与直接下属定期举行站会,解决问题 |
|
支持团队成员互相学习 |
培训团队成员,支持团队学习 |
培训经理,培养内部教练 |
|
定期复盘(针对工作内容和工作方式) |