在数字化协同的大背景下，过去一年 CODING 以老牌代码托管工具为基础，华丽转型为一站式 DevOps 研发管理工具。本次课程《CODING 做敏捷这一年：理解一站式 DevOps 产品思想》由 CODING 运营及项目协同产品总监张路宇进行分享，主要分析数字化协同的工具对于敏捷的作用，并现场互动讨论观众喜欢的工具、团队如何实践敏捷，做工具产品的挑战等等问题。
Part 1. 数字化协同在敏捷导入中的价值
大家可能会问这样一类问题：
工具在敏捷导入中扮演了什么角色？
电子看板是否更具优势？
CODING 和 TAPD/JIRA 等等有什么区别？
......
这一切都反映了不管是选工具、选方法还是选理论，企业的根本关切在于他们能否提升效率。回顾传统的管理学研究，美国管理学家泰勒的经典著作《科学管理原理》被德鲁克誉为“20 世纪最伟大的发明”。这本书阐述了 20 世纪这段时间工业革命以及管理学、组织学上进步的根本原因在于分工，因为分工产生了流水线，因为流水线才有了工业化，因为工业化才有了以机器取代人力的工业革命。把福特推上机器时代奠基人地位，并创造了“福特之工业奇迹”的，就是泰勒科学管理原理在工业化流水线上的成功运用。
亚当·斯密的《国富论》时间出现的更早，这本书里举了一个例子，亚当·斯密发现工厂制造大头针需要完成很多的工序，抽铁丝、拉直、切截、削尖铁丝的一端、打磨铁丝的另一端（以方便装针头）等等。通过分工，十八道工序可以分别由十八个专门的工人负责完成，实现效率上的提升。原本一个人需要完成十几个步骤，培训成本、上手成本以及切换工作的成本都非常高，通过工具的分解，这十八个工人就能实现效率上的根本提升。这种现象在国内的传统制造业中也能看到，都是基于提高单体劳动者的劳动效率来提升工作效率。这种管理理念被称为管理 1.0，也就是对管理有一个基础的认知。然而如今来看标普 500，也就是全球 500 强公司的成分股变化，在管理上有了颠覆性的改变。下图展示了从 1988 年到 2000 年，再到 2008 年排名前十的公司数据。
1988 年居于前列的有 IBM、通用电气、福特这样的企业，他们的竞争优势在于有一定的技术优势或者资本优势。例如石油行业有资本优势，或者类似 IBM、福特这种公司通过大规模的生产和标准化实现公司市值的大幅提升。到了 2018 年，格局有了很大的改变，排在前列的公司如苹果、谷歌、亚马逊、微软，都被称作为技术驱动的平台型企业，或者说价值网络构建者的企业。比如苹果有 iOS 生态，腾讯有微信生态，这些企业都是生态的构建者。在这短短的几十年里，前十名的公司从传统的规模化资本驱动、流水线驱动的企业逐渐转换为数字化平台构建的价值网络驱动企业，企业市值也翻了十几倍。
通过以上这些现象，可以发现今天企业面对的挑战和二三十年前企业所面对的挑战截然不同，核心竞争力的构建主要来自于企业强调创新，以及业务本身有价值网络性质这种指数的上升。组织面临的内部管理挑战也会随着时代的变化而改变：
- 强个体的价值崛起
在传统的分工模式下，强调的是 100 个员工把一件事分成了 100 个 1%，因此大家的上限其实是有限的。然而能为公司创造最大价值的人通常只占据公司人数的 5% 或者 10%，这些人的个体价值可以达到无限。这就是当今数字化企业核心竞争力的一个来源。
- 影响组织绩效的因素由内部转向外部
在当今时代，做一个产品去投入市场时，成败的原因往往在外部，比如资源整合是否良好、和外部生态的接入程度高不高。比方说一个电商企业，是否有和阿里巴巴等平台实现最大化的合作，比如利用直播等多方渠道。然而过去对于制造业企业或者一个传统的公司来说，影响绩效的核心因素往往是内部阻塞过多，内部事项不够顺畅，内部管理不良。
- 驾驭不确定性成为组织的核心挑战
不确定性是所有组织面临的一个核心挑战，经过二十多年的时代变迁，今天的企业所面临的挑战几乎发生了完全性的改变。企业里个体成员的价值是有限还是无限，这笔帐是可以计算清楚的。过去分工无法应对的挑战，在实际管理和员工执行中非常明显：做的事情与战略割裂，与资源脱钩，与用户脱节。这些其实也是敏捷需要解决的难题——敏捷不是用来增加单体效率，而是帮助团队最快地发现需要解决的问题。小团队或者敏捷的团队在比较大型的公司里，需要全面审视公司能够提供的各种资源以及顶层意识的传达，我们称之为敏捷和传统模式的平衡。如果过度敏捷，就会出现以上种种问题；如果过度集权，可能不会犯与战略割裂的错误，但是与用户脱节的风险又提高了。这里可以引用德鲁克的话：“动荡时代最大的危险不是动荡本身，而是仍然用过去的逻辑做事。”
分工的管理原理，传统上大家认为是一个非常科学的方式，但是今天不管是在制造业企业还是传统软件公司其实都有这种能力，在中国已经不具备相对优势。这里举一个非常典型的例子：微信红包。2013 年微信红包诞生，今天微信支付和支付宝在移动支付领域都各占一片江山。但是早在五年前，微信支付在移动支付这个市场完全不具备优势，被支付宝碾压式的统治。腾讯想方设法希望能把支付业务推出去，然而最后成功的是一群年轻人。他们利用业余时间在小团队里做了一个内部小项目，完成微信红包小程序的设计，一夜之间发生裂变，后来的事情大家都知道了。自组织诞生的微信红包根本性地改变了移动支付战局，这样的成果需要对用户情景非常敏感，非常有创意，非常有创新力，非常有勇气的团队成员去发掘出来，这是一个非常好的组织内自下而上的例子。今天在谈论效率时，我们关注的仅仅只是分工，但分工只是一个基础，比如团队中的成员可能分前端后端，在这个基础上，更需要重视的是协同。效率来源于协同而并非分工，引用索尼成立之初创始人的话：“要充分发挥技术人员的技能，建立一个自由、豁达、轻松愉快的理想工厂。“因此现在做一个工具，至少要实现三点才能满足团队在软件工程上的需求：
1.注重协同效应，1+1>2
2.超越流程，基于卓越工程实践
3.一致性、沉浸式的融合体验
团队在使用工具实现协同时要实现 1+1>2 的价值，并且要超越流程。仅仅有项目管理的流程或者理念只能帮助团队有一个好的开始，真正成功的项目依旧是基于卓越的工程实践的。此外，团队应该有一致沉浸式的融合体验，而并非是割裂的。如果员工在实际工作中，每天都要在不同的软件之间切换甚至换账号，那么他的状态会非常容易被打破。因此基于对产品理念的理解，我们引进了一个四层模型：
信息可以分为四个流程：知识、需求、代码、制品。这些信息可以在一个系统的信息面上有一定程度的打通，在同一个团队做到适度聚焦开放透明。比如有一个员工，可能在他专注工作的时候，代码在平常的信息面里可以高效地找到，但如果要启动发散性思维、思考当前目标是否正确时，就应该能够在平台中跨职能获取其他几个层面的信息。那么这就需要凭借技术的力量穿透其内外部资源流动和分享，把硬性边界变成柔性边界。
Part 2: CODING 如何【敏捷地】做敏捷
之前分享了对于数字化协同的理解，接下来我们来看看 CODING 是怎样去做敏捷的。CODING 在 18 年时从自身的代码托管服务转型为 DevOps 基础设施——一站式研发管理平台。在此之前，CODING 做了接近三到四年的代码托管，当时的想法是做中国的 Github 或者做出 APP 这样一个形式。服务开始转型时，当时 CODING 有 100 多万个人开发者用户，但实际上对于企业严肃的管理需求和团队协同需求是一无所知的。那么这时我们就在思考 CODING 的产品定位是什么。
上图有四个象限，展现了几个不同的协同工具。比如比较传统的 Jira，可以理解为一种单体的组件式协同工具，但是在国内团队比较需要的中心化管理方面能力就很差，或者说它非常欠缺从代码到制品，再到持续集成 TDD 这样的一套流程，需要另外组合开源工具链才能满足基本需要。华为的 DevCloud 作为一个一站式产品，具备一个研发团队的一切所需，同时又是高度集权中心化管理，因此是一个非常适合传统企业自上而下去推进的平台。然而实际上推到下面团队时，对于工程师而言却是一个压迫感很强的监管工具，而不是协同工具，团队文化容易受到破坏。CODING 并不想做 Github 这种非常轻量、管理需求基本可以忽略的平台，也不想做 DevCloud 这种集权管理的工具。CODING 给自己的定位是一站式研发管理工具，能够解决大部分问题，并且在中心化和自组织之间能够找到一块重叠的区域。
CODING 在 18 年底时决定面向企业和团队提供全面的管理服务，并且希望能从简单的代码托管服务扩展到包括持续集成、制品库等功能的一站式服务。CODING 的优势在于有百万开发者用户基础，并且有原生的 Git 仓库技术和一定的数据分析能力，而挑战是新的服务需要面向完全不同的角色——企业和团队领袖，很多开发者对于敏捷、DevOps 理念的了解比较匮乏。另外如果团队需要进行管理变革，特别是牵涉到敏捷等领域，需要满足康威定律，也就是对组织结构和人员架构进行重新审视。最后还需要公司和团队树立变革目标并且找到领头人，这些都是 CODING 作为工具无法触达的。
四阶段产品路线图
CODING 的产品路线可以分成四个阶段，第一个阶段用时两个月，对缺陷进行跟踪；第二个阶段用时不到一个月，对需求进行拆分；第三个阶段开始引入迭代周期，通过 Backlog 池等模块引入周期概念。目前 CODING 还未实现第四阶段，也就是信息流融合，打通代码流、制品流以及信息流。下图为 CODING 产品的整个开发流水线。
CODING 目前的产品水平和发展速度在业界已经可以被肯定。下图可以看到 CODING 和其他竞品功能的对比。许多不同的协作产品的本质区别通常在于利益相关人的区别。比如说 TAPD 首先服务的是腾讯内部的部门，可能就不会优先照顾外部团队；Gitlab 和 Jira 等工具，他们本身的基因决定偏向工程化，对于团队复杂目标、大型项目规划管理以及中国团队所需的本地化统计功能是无法处理的。因此左右产品表现的通常是背后的理念或者说是利益相关人的差异。
Part 3. OKR 与敏捷的结合实践
用户需要了解到 OKR 实践的误区。通常用户对于需求有两种场景，一种是类似于绩效的团队目标管理，也就是一个季度或者一个月每个人需要达到某些目标，这是一个典型 OKR；另外一种场景是跨项目的项目管理，比如要做移动端商城这样一个产品，这个产品有不同的版本周期，分布在不同的项目组中，项目经理可能想对它们进行集中化的跟踪。在权衡不同的需求之后，计划上线的某一个版本就是团队目标。OKR 三层结构包括目标、结果和执行，因此团队 PM 或者有权限的人可以创建一个团队，在特定周期去完成一个有挑战性的目标，然后为这些目标设立一些关键结果。有些项目无法用量化结果来权衡，CODING 的自动跟踪模式的创新之处就在于关键结果和执行之间可以做一层关联，分布在不同项目之间的任务可以关联在一起，这些任务如果都完成了，会自动达成 OKR 量化的目的。
这种思路是因为 CODING 希望 OKR 推进过程应该既满足上层需求，又不干预团队内部，尤其是敏捷团队非常需要拥有个性化的工作模式和任务分解力度。如果从 CEO 或者更高层面来公布一些任务，就违背了 OKR 的初衷，会把团队原来已经搭建好的敏捷工作流和工作节奏完全打破。
另外 OKR 实践有一些普遍存在的认知误区。首先，OKR 不是自上而下，而是自下而上的，主动权应该下发给团队来发挥创造性。对于关键目标，团队需要有非常深刻的理解。团队同时需要做到透明，也就是说所有人都应能够看到所有成员的 OKR 目标，而不是只能看到自己的。最重要的一点是 OKR 应该有一定程度的挑战和容错，很多公司和团队在实践 OKR 过程中，设定这个月必须达到 80 分、90 分，完全违背了 OKR 的设计理念。OKR 是为了给团队提供一种动能，去设定一些挑战的任务，有挑战必然就有风险，即使失败了，大家也应当持有包容和成长性的思维，而不是为了达成目标去设定一些轻松能完成的任务。以上就是本次分享的全部内容，谢谢！