乔梁:“持续交付”不是守业者的游戏

非商业转载请注明作译者、出处,并保留本文的原始链接:http://www.ituring.com.cn/article/207218

乔梁,腾讯高级管理顾问,负责指导IEG 、MIG和SNG团队提高组织效能。他曾任搜狐畅游公司北方研发中心首席管理顾问,并先后在百度和诺基亚负责公司级敏捷组织转型工作。作为一位互联网研发管理与敏捷组织转型的实践者、持续交付领域专家,乔梁已为多个互联网、金融、通信公司提供相关培训和管理咨询服务。他在ThoughtWorks任职期间和《持续交付:发布可靠软件的系统方法》一书作者共同实践了持续交付,该书一经出版便获得了2011年的Jolt大奖。作为《持续交付》的译者和审校者,乔梁率先将相关理念、原则与最佳实践在国内推广。

问:你曾在Thoughtworks工作过三年时间,并在那里接触和实践了持续交付。在Thoughtworks工作的经历给你最大的收获是什么?

最大的收获应该是与世界各地优秀工程师一起工作的经历。其实,早在2004年,我就已经是持续集成的拥有者,并在自己带领的项目团队中尝试,但对其理解并不那么深刻,可以说是一腔热情+机械的执行。加入TW后,和Jez Humble(《持续交付》作者之一)一起工作,做持续交付相关领域的一款企业级产品。这个团队的成员不只来自中国,还有很多国家和地区,包括英国,美国,加拿大,印度和香港等。在这样一个思想开放的团队环境中,真正体会并掌握敏捷开发的思想精髓,以及企业实现持续交付的基本原则,而不仅仅是机械性的最佳实践。

问:你在Thoughtworks时接触到了持续交付,但是却在百度和腾讯大规模地应用了这种方法,在这种应用的过程中,你最大的感触是什么?

2011年在百度,只能算开启了百度持续交付之门,筹建了非常必要的的基础平台设施,并在几个试点团队中,收获了一定的效果。现在,我在腾讯作为三个事业群的管理顾问,参与了多个业务部门的相关管理工作,卷入深度也足够,所以效果更加突显。现在说到感触的话,应该说是:企业的持续交付之路并不仅是技术实施问题,还包括组织管理理念的转变和对企业文化的影响。从这一点上讲,可以说是企业的一种管理转型。需要从领导到员工,自上而下、自下而上的双向合力,才能取得更大的业务突破。

问:从你2013年加入腾讯以来,无论是持续交付的网站,还是你在CSDN上的博客,你都更新得比较少(但是最近又频繁了)。请问更新频率变化的原因是什么?加入腾讯的这段时间你都从事了哪些工作?

CSDN上的博客一直是我在工作中遇到各种相关的解决记录,很象流水帐,各种内容都有,比较随意,没有什么重点。而在持续交付中文站,更多的关于方法论,和国外优秀企业的优秀实践的总结。自从到了腾讯以后,需要处理的工作多,比较忙,所以就没有更新了:)。现在,在腾讯相关管理工作中,辅导的团队比较多了,自然也有了一些新的管理体会。所以,打算把过去几年主要的管理经历记录下来。

问:你曾经在腾讯组织过数据中心系统稳定性的演习,这样的演习让你发现了哪些问题?

那是2013年在腾讯一个业务部门做的事情,当时我负责研发管理工作。整个团队已经可以做到一天发布两个客户端版本。然而,持续交付并不是说“不断交付软件”就可以。俗话说,常在河边走,哪能不湿鞋。这么多的版本,发布后一旦出了问题,还应该能够做到:尽早发现,尽早止血,尽快处理。虽然,当时我们并没有遇到严重问题,但也要未雨绸缪啊。所以,就和团队一起筹划了那次演练。既然是演练,所以过程还是可控的。但所有人员只知道会有一次故障演练,并不知道具体的发生时间。通过那次演习,我们发现了团队应对流程中的一些协作效率和决策问题,同时也找到了一些程序及数据相关的BUG,这些BUG在正常情况下是根本不会出现的,当然也挖出了一些潜在的风险点。虽然这种演练会产生一些成本,但收获还是很大的。

问:你曾在腾讯帮助三百人的产品团队进行持续交付的转型,请问在技术架构解耦和组织架构解耦的过程中应该注意些什么?这两者之间有哪些重要的联系?

技术架构解耦与组织架构解耦,二者是相辅相承的,都应当以业务解耦为准。只有将业务之间的关联先分析清楚,才能够确保从业务维度对团队和架构进行合理折分,这样,团队才能做到目标明确,形成自驱力,更灵活应对业务的变化。

问:今年你TOP100Summit上分享的主题是腾讯MIG百人团队的转型过程,能否请你简要说明一下这次管理转型的最大难点是什么?另外,实施转型的过程中最重要的是什么?

关于“最大难点”,这是一个比较难回答的问题。因为,从开始讨论到落地实施,从走稳到取得良好业绩,前后持续了一年的时间。每个时期都有每个时期的难点。过程中每一个难题的解决,都会影响最终的效果。比如在启动之初,如何统一所有人对这次变革的认识?如何合理且清晰地划分业务领域?如何选择各业务的带头人?如何做到平滑过渡?要做哪些准备工作?这种重大变革,如何通过一种机制,能够使其不断地自我优化?等等,都是需要一步步解决的。而转型过程中,最重要的还是管理团队对这次变革的信心和决心。在互联网行业,变化实在太多太快,我们必须在变革的同时,还要保持业务和团队的稳步向前,管理团队承担了很大的风险。能够完成这样的变革,管理者一定具备创业者心态和决心,而不是作为守业者来处理相关的问题。

问:从2011年《持续交付》出版一直到现在,软件行业对这种开发方式越来越接纳,请问背后的根本原因是什么?在这样的过程中,持续交付的实践方法有没有发生变化?(Jez Humble曾说过持续交付可能要十年后才能被人完全接受,这个时间提前了吗?)

我认为有两方面的原因。一方面是业务驱动。商业环境变化越来越快,这是个拼速度的时代。为了应对业务的快速发展和变化,就要求我们提升交付能力。

另一方面是技术演进。随着各种技术框架和技术平台的发展,使原来持续发布相关的较难解决的技术问题得到了较大的改观,比如现在的容器技术和微服务架构的发展,使得实现持续交付的技术成本相对有所下降。所以,新开发的系统可能有一定的便捷性,但对于那些既有的系统,这种改造还是需要很长时间。

与五年前相比,虽然大家对于持续交付的理念更为接受,但由于前面提到的组织、文化,以及技术等相关问题,仍旧还是需要一定的时间。在互联网企业,接受度和实施程度会稍高一些,但传统的企业应用软件领域,仍旧有很长的路要走。


更多精彩,加入图灵访谈微信!

你可能感兴趣的:(敏捷,持续交付,图灵访谈)