CODING 敏捷实战系列加餐课：CODING 作敏捷这一年 - 理解一站式 DevOps 产品思想

在数字化协同的大背景下，过去一年 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 是为了给团队提供一种动能，去设定一些挑战的任务，有挑战必然就有风险，即便失败了，你们也应当持有包容和成长性的思惟，而不是为了达成目标去设定一些轻松能完成的任务。以上就是本次分享的所有内容，谢谢！

点击观看完整录播视频