signed

QiShunwang

“诚信为本、客户至上”

11.敏捷组织转型四步法 - 培训,调研方案

2021/6/24 18:17:32   来源:

大的组织变革从来都不是一蹴而就的,需要有策略地逐步推进,在保持组织生产力稳定的前提下实现转型。从传统的研发方式步入敏捷研发模式,打造高绩效的敏捷组织,可以参考如图所示的敏捷转型路线图。

在敏捷转型的过程中,需要注意如图所示的敏捷转型4个关键结合点。

具体说明如下。

(1)从顶向下与从底向上相结合:任何大的组织转型或变革,都需要进行顶层设计,需要得到高层领导的支持;同时,还需要得到底层人员的支持与拥护。

(2)内部教练与外部咨询相结合:对于一个不成熟的组织或团队,其在转型过程中一定会遇到很多问题,教练作为一面镜子,可以给予及时的指导,协助团队快速成熟。为了保持持续性,企业需要培养自己的教练;同时,需要吸取外部的最佳实践与经验。

(3)传统模式与敏捷模式相结合:敏捷作为一种研发模式,不一定适用于所有项目,有些项目采用传统的模式可能效率会更高;这两种研发模式可以结合使用。

(4)制度流程与管理工具相结合:好的实践需要传承、固化,离不开制度流程;要想把流程变成人的日常习惯,离不开管理工具,二者必须有机结合。

第一步——培训

对全员进行培训、赋能,让所有人从理念、意识上达成一致,这是转型的重要一步。鉴于此,需要针对不同的角色提供不同的课程,毕竟每个人的关注点是不一样的。“培训”示例如图所示。

第二步——调研定方案

每个组织、每个部门面对的痛点问题不一样,业务也不一样,需要采用有针对性的转型方案,做到有的放矢,方能一击必中。在启动转型前,需要对关键利益干系人进行访谈,了解不同人的目标与关注点,了解业务场景与问题,共同协商制定方案与举措,为达成业务目标服务。“调研定方案”示例如图所示。

成立转型决策委员会的目的是统一思想,高举高打,将高层的支持落到实处,同时把控大的方向,毕竟敏捷转型需要从如下几个维度体现收益:缩短产品上市时间、提升交付质量、提高交付效率、提高客户满意度或提升业务指标、降低成本等,这些都是高层关注的维度。通过建立定期沟通机制,可以将最新的进展及效果呈现给高层,同时把在转型过程中需要得到高层支持的举措提出来,及时得到响应,具体如图所示。

敏捷转型工作小组是推动组织转型的核心力量,也是负责具体举措落地的关键人物,除了需要敏捷教练提供指导,还需要各部门的接口人收集各自部门的进展与问题,宣传干事负责转型的宣传工作及相关文化的打造,从而实现全方位的覆盖,具体如图所示。

敏捷团队的组建是一个艰巨的任务,需要打破传统的部门筒仓,尽量让每一个敏捷团队都是跨职能的特性团队,即能够端到端地完成一个需求或功能的交付,以减少团队间的依赖及转交,避免交接的浪费,加快交付速度。一开始,可以先从虚拟团队做起,各角色成员可以保留各自的筒仓管理条线,但必须让每个成员全职为一个团队工作,并保持稳定,不断推动团队朝自组织、自管理的方向发展,如图所示。

所有工作的起点都是需求,管理好需求就可以做到事半功倍,团队就能形成稳定的迭代节奏,并及时响应外部需求。产品负责人作为产品待办列表的唯一负责人,需要驱动相关人员做好需求梳理工作,在迭代计划会前保证达到DoR(Definition of Ready)状态,即提前协调好外部依赖、UED工作等;同时一定要定义好清晰的验收标准;做好需求条目化以适应迭代计划与开发,具体如图所示。

为了可持续开发,团队需要形成节奏感。根据经验,建议团队选择2周迭代机制,毕竟1周太短,3周太长。有了稳定的节奏,才能计算出团队速度,将其用于发布规划,或者在迭代计划时作为选取工作量的参考标准。在多团队协同时,建议多个团队选择相同的迭代周期及起止时间。另外,建议不要把发版日期与迭代结束日期进行绑定,完全可以根据需要在适宜的时机进行发版。例如,虽然团队的迭代周期是2周,但在2周内可以实现4~5次的发版上线,也就是我们提倡的“按节奏开发,按需要发版”,如图所示。

敏捷发布火车(ART)是非常好的一种协同方式,可以有效地将多个团队协同在一起,实现复杂产品的快速迭代。一个ART通常由50~125人组成,基本可以满足当前业界多数复杂产品的管理需求。对于ART的管理,需要有严格的准入制度,就像高铁检票一样,每个子团队都保证质量与效率,才能保证整体的交付质量与效率ART一旦确定发版时间,就不应该因任何原因延误,而且火车时刻表应该提前公布,这样所有相关团队都可以自主进行针对性排期。为降低发版风险,可以通过灰度发布等方式缩小影响范围,如图所示。

一个ART承载的发布内容可能会由多个项目组成,这就属于项目群管理。为了透明化项目群的进展,可以把每个团队的关键交付物及时间节点、相互依赖、外部风险、整体里程碑等内容可视化在一个物理看板上。这样,跨团队的SOS会议可以在这个物理看板前开展,更有仪式感,信息也会更融合,如图所示。

持续集成(Continuous Integration,CI)已经成为很多敏捷团队的标准实践,搭建一个CI系统越来越容易,但最关键的还是纪律性,如开发人员是否每天至少提交一次代码、每次CI失败是否有人及时修复、在失败修复之前是否不再提交新代码、是否能够做到固定频率的集成(如不超过30分钟),具体如图所示。

团队发布节奏越来越快,单独依赖手工测试的团队已经越来越难以应对当前状况,这就需要提升自动化测试的比例。自动化测试比例也不一定越高越好,要考虑经济合理性。自动化测试也不一定一次性补齐,可以设定策略与计划,从核心关键的回归用例做起,逐步提升比例,具体如图所示。

在《敏捷宣言》背后的12个原则中,有一个原则强调“面对面的沟通是最有效的沟通方式”,这点尤其重要,这也是强调敏捷团队尽量都是本地团队的原因。一定要为团队创造出这种物理环境与氛围,让大家面对面坐在一起,提高协作效率,这是管理层必须承担的责任。同时,办公行政也要从办公的桌椅布局上给予支持,如拆掉过高的格子间。具体如图所示。

敏捷强调团队整体的成功,只有团队目标达成了,才有个人的成功。正所谓“胜则举杯相庆,败则拼死相救”。从特性团队的角度,要增加整体激励,而不过多奖励个人,毕竟个人的过度成功意味着其他个体的失败,具体如图所示。

通常,没有度量就没有改进,但度量什么就会得到什么。这就要求不仅要度量结果,还要度量过程。成熟度评估就是在整体度量指标的驱动下,通过对过程的度量,保证改进方向的正确性及实现过程的正确性,如图所示。