申健| 敏捷转型之规模化体系建设过程中的思考

1.嘉宾介绍

分享嘉宾：申健
优普丰全球合伙人
ICF -PCC /SA -CTC 双料认证敏捷教练江湖人称“申导”，优普丰全球合伙人，首席敏捷教练，国际Scrum联盟CST-认证培训师暨CTC认证敏捷教练及评委，ICF-PCC 专业教练，UCAC认证敏捷教练，LeSS规模化敏捷专家。2007年开始实战敏捷开发，历任过工程师、研发经理、敏捷教练等职务。对大型组织(500人以上)的大规模敏捷转型和工程实践的落地运用具有丰富的经验。他感兴趣于结合教练技术等软技能来帮助组织提升领导力和导入工程实践，从而提升产品开发的效果与质量。他常年担任全国敏捷社区组织者、评委和嘉宾。敏捷规模化咨询客户包括：赛诺菲制药、福特汽车、宁波银行、开思汽配电商、顺德农商行、思科、招商证券等。

2.内容分享
分享者：申健整理：王英伟

我来自优普丰敏捷学院（机构），我们有两个主要的业务：培训和Scrum认证课，另外我们也有一个咨询团队，帮助企业导入和转型。我今天讲一讲来自咨询团队的经验和中间的思考。案例来自金融行业，我们做的银行和保险这样的行业，你不是这个行业也没有关系，只要是来自传统行业，制造业、医药行业、金融行业这些不以IT为主要核心的企业都叫做传统行业。

01传统行业（如金融）痛点
这个是金融行业的政策，其它行业也有相应的所谓政策。这是国家大背景，行业大背景，实际上现实中我们会看到有很多的困境和难点，导致我们走得很艰难，具体来说有一些开发人员，你会发现好多团队混合在一起，拆分也拆不开。

业务与科技对转型收益需求是不一致的，业务有业务的需求，讲数字化是要求业务数字化，做银行业务，上线贷款产品的风控，提升交易额多少笔，他才不管科技怎么做的。科技是关注效能，证明自己干活了，内部质量提高了，刚才有人问吞吐量，吞吐量上升了，生产稳定性提升了，这是业绩。所以两种关注点兼而有之，都要考虑到。

02转型组织的失败与成功最关键的特征
今天上午听乔梁的演讲，很多事不是不能做，不是干不出来，首先要解决是否想做的问题，要不要做的问题。看到比较成功的转型都是跟业务精英直接挂钩，企业要的是业务业绩。
业务为牵引、组织优化、组织建设很容易做，转型是独立的，搞个试点吧，拉一批人，这样肯定能搞成功。我虽然是做咨询的，但是也肯定能保证成功，你给我钱保证试点成功。但是这个试点成功了，下一个团队怎么办？回答不了。
有些领导态度比较暧昧，汇报完了，领导说稳步推进，什么是稳步推进？就是他不想投入。

大家上过课，看过一些书也知道市面上所谓的规模化敏捷的方向，我自己也是LeSS工作过，包括SAFe框架，几千人搞敏捷也是做得比较好的。毕竟这是别人的故事，他有他的成功因素，有他的特殊的因素是你学不来的，比如说他们有一个特别好的领导，但是你没有。现实中的组织结构就是如此复杂，有些科室不是说以产品为中心的，或者以交付为中心的划得清清楚楚，划出来的就是长什么样的都有。我现在放弃说要强推一个什么框架，虽然这是我自己的理论指导，但那是我讲给客户听的，讲给团队听的。一是不会说要讲一个框架，而是要讲一个整体性的系统性的方案。从战略、策略的维度，分步走，我的目标是什么，定位是什么先讲清楚；二是组织结构做调整；三是人员能力；四是流程过程；五是工具和环境支撑。
简称为SSPPT五个角度。要把你的组织框架运行下去。

03传统科技组织转型的三步走战略
第一个阶段：打造标杆，几个产品线的学习探索。哪些团队能做得成的，组织缺什么，一般情况下都会发现一些问题。第二个阶段：内部复制，能做什么能投什么。第三阶段，自主发展，规模化扩展到整个企业，扩展到业务或者是扩展到其他的职能部门。先说结构，我们有一个银行业的客户，前几年大张旗鼓地做了敏捷转型，借鉴业务和IT做一个业务单元，共同做一个业务产品，做一个业务，当时做得很热，国内好多银行都过去参观。持续了三四年，现在又回到了原来的组织结构，其中一个重要的原因是领导换了。但是也没有问题，一开始做这种部落式的结构，我们认为可能有一种是基于现在的这种体制的一个结构，在里面做一些能力建设的一种，我们认为也没有问题，部落式的业务，然后是蓝色的，外包的角色。以交付为中心、以产品为中心的框架，在这里面给每个人按上相应的位置。

右下方是业务方，敏捷里没有PO，往往是业务担任比较好，我们见过的业务做得都效果比较好，但也不是业务都那么配合，于是我们会有所妥协。该有的底线应该做哪，如果确实做不到所以我说在严格遵循敏捷原则的情况下可以做的。

说到流程统一的反馈迭代节奏—One Sprint，所以在经典的Sprint节奏下，变成一个类似的迭代机制，比真正的研发提早做。进行原始的业务分析，一句话需求系统支持的要求，具体怎么支持什么都没说，这个时候就得再做需求细化。总比过去说一定要把所有需求都谈完再进行开发要好得多，需求也是滚动进行，再往前是一个产品共创，多个部门之间的需求，改变优先级的划分。

最左边的产品功能，最右边是上线发布，版本计划、上线，形成验证，变成了业务整体的闭环。这样的话形成了不止是开发的反馈循环、迭代循环，一个业务的后评价机制，评价上线的内容是不是有用。所有的需求都是有成本的，都是有代价的，这个机制建立起来才是真正的业务机制。

每一个节点，虽然这里面有瀑布的影子，但是每一个节点还是应该有一个Check，至少要少一个低级的错误，至少不要留在开发迭代中。

效能度量要从解决问题和指导改进行为出发，度量数据能发现什么问题，指导下一步的行为往哪里走，这就是好的度量。比如说研发人类的分布、人类的负载，能不能从DevOps平台收集的数据回答这些问题，如果能够回答就是好的度量。

软性的人才，光有硬的流程、岗位职责是不足以支撑的，迭代好的流程越能暴露人才不足的问题，人才不足在两周内都有能够好用的软件上线，这是我们的现状，开发的行业门槛太低，是不是买个电脑就可以写程序，每个人都可以，问题是你写出的代码能看得懂吗？有没有质量问题？自己说不清楚，很多程序员都是我写完程序之后找人测一下，这不是你自己应该做的吗？自己不知道，这是我们的行业现状。测出了bug，不承认是自己写的，还搞什么高大上的业务敏捷，还度量，不是白扯吗？他就是不会干。

纸上谈兵，玩真的，会做，不等于会教。搞好人际关系，教育和说服，写出可行的方案，手把手示范，促进聚焦和共识，引发觉察。敏捷教练都不需要买个电脑，有嘴就行。大家知道中国敏捷教练最多的是什么地方的人吗？天津排第二，第一是大连，因为能说，这就是优势。我们做敏捷教练不是我们说自己是教练就是教练，就算你做过敏捷做过项目做过教练，也不等于你会教，教人是有技巧的。这些年我总结下来几个事情：搞好人际关系，人家愿意听你的才有机会。
教育说服，讲一些理论是有必要的。

能写方案，我们圈里面很多人不会写文章，不会写PPT，虽然我们讨厌写PPT，但是我们自己不会写，写出来的东西自己不愿意看，懒得写，其实因为不会写你才会懒。

促进聚焦共识，也叫引导，怎么叫大家有一个共识，讨论，大家把心里话说出来，这也是一个软性的技巧。
引发觉察，怎么通过专业性的对话，发觉自己的真正的用途，进阶的技巧。

CMMI/ASPICE等审计合规的证据，如果你从文档的角度我们也可以做，敏捷的一些实践对应到所有的过程预演就可以满足审计的要求，跟大家分享一下。

PICE等审计合规的证据，如果你从文档的角度我们也可以做，敏捷的一些实践对应到所有的过程预演就可以满足审计的要求，跟大家分享一下。

刚才提到几种规模化的框架，常见的，也有一些自己的优势和劣势，多对多产业产研结构的解法比较复杂。有的贴近研发，像Scrum为@Scale比较高难度，没有一个框架可以套到我的客户上。

04ALPHA
我们有原则，ALPHA原则，精益ALPHA屋，最上面的屋顶，中间有六个柱子，需求管理、配置管理、文化建设等，底下是度量和DevOps平台。第三个轮子是ALPHA平衡轮，成熟度的度量，就像去医院看病一样，一般是先做体检，没有上来就给人开药方的，你看你戴眼镜就得吃这个药，我没病？你有病就得吃这个药。前面的小字看不清，看不清就得吃药。这是转型的一个套装，字比较多，就不念了，这是一个具体的介绍。