非商业转载请注明作译者、出处，并保留本文的原始链接：/article/207218
乔梁，腾讯高级管理顾问，负责指导IEG 、MIG和SNG团队提高组织效能。他曾任搜狐畅游公司北方研发中心首席管理顾问，并先后在百度和诺基亚负责公司级敏捷组织转型工作。作为一位互联网研发管理与敏捷组织转型的实践者、持续交付领域专家，乔梁已为多个互联网、金融、通信公司提供相关培训和管理咨询服务。他在ThoughtWorks任职期间和《持续交付：发布可靠软件的系统方法》一书作者共同实践了持续交付，该书一经出版便获得了的Jolt大奖。作为《持续交付》的译者和审校者，乔梁率先将相关理念、原则与最佳实践在国内推广。
问：你曾在Thoughtworks工作过三年时间，并在那里接触和实践了持续交付。在Thoughtworks工作的经历给你最大的收获是什么？
最大的收获应该是与世界各地优秀工程师一起工作的经历。其实，早在，我就已经是持续集成的拥有者，并在自己带领的项目团队中尝试，但对其理解并不那么深刻，可以说是一腔热情＋机械的执行。加入TW后，和Jez Humble（《持续交付》作者之一）一起工作，做持续交付相关领域的一款企业级产品。这个团队的成员不只来自中国，还有很多国家和地区，包括英国，美国，加拿大，印度和香港等。在这样一个思想开放的团队环境中，真正体会并掌握敏捷开发的思想精髓，以及企业实现持续交付的基本原则，而不仅仅是机械性的最佳实践。
问：你在Thoughtworks时接触到了持续交付，但是却在百度和腾讯大规模地应用了这种方法，在这种应用的过程中，你最大的感触是什么？
在百度，只能算开启了百度持续交付之门，筹建了非常必要的的基础平台设施，并在几个试点团队中，收获了一定的效果。现在，我在腾讯作为三个事业群的管理顾问，参与了多个业务部门的相关管理工作，卷入深度也足够，所以效果更加突显。现在说到感触的话，应该说是：企业的持续交付之路并不仅是技术实施问题，还包括组织管理理念的转变和对企业文化的影响。从这一点上讲，可以说是企业的一种管理转型。需要从领导到员工，自上而下、自下而上的双向合力，才能取得更大的业务突破。
问：从你加入腾讯以来，无论是持续交付的网站，还是你在CSDN上的博客，你都更新得比较少（但是最近又频繁了）。请问更新频率变化的原因是什么？加入腾讯的这段时间你都从事了哪些工作？
CSDN上的博客一直是我在工作中遇到各种相关的解决记录，很象流水帐，各种内容都有，比较随意，没有什么重点。而在持续交付中文站，更多的关于方法论，和国外优秀企业的优秀实践的总结。自从到了腾讯以后，需要处理的工作多，比较忙，所以就没有更新了：)。现在，在腾讯相关管理工作中，辅导的团队比较多了，自然也有了一些新的管理体会。所以，打算把过去几年主要的管理经历记录下来。
问：你曾经在腾讯组织过数据中心系统稳定性的演习，这样的演习让你发现了哪些问题？
那是在腾讯一个业务部门做的事情，当时我负责研发管理工作。整个团队已经可以做到一天发布两个客户端版本。然而，持续交付并不是说“不断交付软件”就可以。俗话说，常在河边走，哪能不湿鞋。这么多的版本，发布后一旦出了问题，还应该能够做到：尽早发现，尽早止血，尽快处理。虽然，当时我们并没有遇到严重问题，但也要未雨绸缪啊。所以，就和团队一起筹划了那次演练。既然是演练，所以过程还是可控的。但所有人员只知道会有一次故障演练，并不知道具体的发生时间。通过那次演习，我们发现了团队应对流程中的一些协作效率和决策问题，同时也找到了一些程序及数据相关的BUG，这些BUG在正常情况下是根本不会出现的，当然也挖出了一些潜在的风险点。虽然这种演练会产生一些成本，但收获还是很大的。
问：你曾在腾讯帮助三百人的产品团队进行持续交付的转型，请问在技术架构解耦和组织架构解耦的过程中应该注意些什么？这两者之间有哪些重要的联系？
技术架构解耦与组织架构解耦，二者是相辅相承的，都应当以业务解耦为准。只有将业务之间的关联先分析清楚，才能够确保从业务维度对团队和架构进行合理折分，这样，团队才能做到目标明确，形成自驱力，更灵活应对业务的变化。
问：今年你TOP100Summit上分享的主题是腾讯MIG百人团队的转型过程，能否请你简要说明一下这次管理转型的最大难点是什么？另外，实施转型的过程中最重要的是什么？
关于“最大难点”，这是一个比较难回答的问题。因为，从开始讨论到落地实施，从走稳到取得良好业绩，前后持续了一年的时间。每个时期都有每个时期的难点。过程中每一个难题的解决，都会影响最终的效果。比如在启动之初，如何统一所有人对这次变革的认识？如何合理且清晰地划分业务领域？如何选择各业务的带头人？如何做到平滑过渡？要做哪些准备工作？这种重大变革，如何通过一种机制，能够使其不断地自我优化？等等，都是需要一步步解决的。而转型过程中，最重要的还是管理团队对这次变革的信心和决心。在互联网行业，变化实在太多太快，我们必须在变革的同时，还要保持业务和团队的稳步向前，管理团队承担了很大的风险。能够完成这样的变革，管理者一定具备创业者心态和决心，而不是作为守业者来处理相关的问题。
问：从《持续交付》出版一直到现在，软件行业对这种开发方式越来越接纳，请问背后的根本原因是什么？在这样的过程中，持续交付的实践方法有没有发生变化？（Jez Humble曾说过持续交付可能要十年后才能被人完全接受，这个时间提前了吗？）
我认为有两方面的原因。一方面是业务驱动。商业环境变化越来越快，这是个拼速度的时代。为了应对业务的快速发展和变化，就要求我们提升交付能力。
另一方面是技术演进。随着各种技术框架和技术平台的发展，使原来持续发布相关的较难解决的技术问题得到了较大的改观，比如现在的容器技术和微服务架构的发展，使得实现持续交付的技术成本相对有所下降。所以，新开发的系统可能有一定的便捷性，但对于那些既有的系统，这种改造还是需要很长时间。
与五年前相比，虽然大家对于持续交付的理念更为接受，但由于前面提到的组织、文化，以及技术等相关问题，仍旧还是需要一定的时间。在互联网企业，接受度和实施程度会稍高一些，但传统的企业应用软件领域，仍旧有很长的路要走。
