ONES CTO 冯斌：敏捷思想是不确定时代的通行证

在企业级研发管理过程中，项目延期、成本超出预算、项目管理工具无法覆盖业务需求、软件质量差等难题，长期阻碍着企业更好更快地交付产品。尤其是当项目体量达到一定规模后，技术研发管理对于企业研发效能的提升，变得越来越重要。

对于企业研发团队负责人与正准备过渡至管理层的技术人员来说，团队当前的工作情况如何？如何改进？面向未来，哪些有效的软件研发管理策略能提升开发人员的工作效率？这是需要时刻思考的问题。

近日，InfoQ 大咖说直播间成功邀请了 ONES 联合创始人兼 CTO 冯斌先生，就《大型研发团队如何落地有效的软件研发管理策略》这一主题进行了访谈直播。作为长期深耕企业软件研发效能管理领域的企业，ONES 已帮助了上百家百人以上企业团队实现研发效能提升，对企业研发效能提升有着系统的方法论与成功实践经验。

以下为直播 Q/A 内容整理，略有改动，供大家参考。

项目管理是软件研发的刚需

InfoQ：请您做一个简短的自我介绍，给大家打个招呼。

冯斌：我是 ONES 的联合创始人兼 CTO 冯斌，我是 2008 年工作的，工作经历主要分为三个阶段。第一阶段是软件工程师，先后在金山、网易任职。2011 年到 2015 年赶上移动互联网第一波创业浪潮，做了正点闹钟，总安装达到了亿级。2016 年后再次创业做了 ONES ，作为 CTO 负责技术与产品相关的工作。

今天我主要会围绕 ONES 在做的 TO B 企业研发管理工具来展开讲解，介绍一下我们为什么要做 ONES？同时我们团队在企业研发管理领域做了长期、深入的研究，也沉淀了一些方法论，对于程序员都是刚需，所以也想在这里跟大家分享一下。

InfoQ：很多创始人对于公司的名字都比较重视，作为公司的联合创始人兼 CTO ，你能谈一下 ONES 这个名字背后有哪些特殊的含义吗？

冯斌：在软件项目管理中，有一个特别大的痛点，那就是如果不能将研发全流程工作串联在一起的话，其协同效率和改进效果都会差很多。

所以我们创业的时候就想开发一个打通研发全流程的工具，希望让软件研发中的所有事情都能覆盖到，于是想到了“万事”这个名字。ONES 是“万事”中文谐音，同时也有“很多”的意思。

在大型企业团队研发管理过程中，项目管理是一个刚需。

当团队变大之后，我们很难通过单纯的线下沟通去了解整个项目的运行状态，包括这中间产生的许多数据、文档、日志、Bug 等，如果没有办法对这些信息做一个系统全面的整理，同时通过数字化的形式来进行风险分析、监控与管理，那么最终我们的整个项目就很容易失控。

所以我们的愿景，是希望加速整个软件研发管理过程中的数字化进程。

当然，要达到数字化其实分为三个阶段。首先是「在线化」，让项目内容（本地的 Excel、文档）等管理进行线上化共享。其次是「结构化」，通过字段、属性，状态等维度，将一件事情变成结构化的数据对象，这样就可以被筛选、搜索、聚合。最后，还需要能够让这些数据关联起来，达到一个「智能化」的效果。

对于超过 100 人的团队来说，这三个阶段是必须的，而我们的目标，就是帮助企业的研发团队实现以上三个阶段的转变，最终实现高效的研发管理目标。

敏捷思想是不确定时代的通行证

InfoQ：对于开发者而言，哪些企业研发过程中的问题是真正影响并制约他们效率？除使用工具外，还有哪些比较通用的方法论可以借鉴？

冯斌：表面上来看，企业研发最困难的是在协作上。这里面最明显的一个现象就是，许多风险很早之前在项目的某个环节就已经出现了，而且部分人员已经知道这个风险可能会对整个团队造成一些长期损害，但最终的结果却是，决策者看不到，最终风险被忽视，只能到最后这个项目或软件需要发布或结束的时候，这个风险才又会上升到整组成员都认知到的层面，对项目的进度和质量产生无法挽回的负面影响。

事实上，出现这种情况的原因，主要是因为在最开始的时候，这些风险只存在于一部分人的脑海中，他没有通过一些在线化、数据化的方式记录并度量出来，同时将这个风险放到大家随时可以访问到的工具里，导致了信息传递的速度减慢，决策也很难快速响应这些变化，最终在协作上出了问题。

协作的效率跟两部分有关，首先是团队的组织方法，包括敏捷、DevOps 等方式。在有了方法之后，如何通过工具、数字化加速信息流通效率也很重要。在这两个方面持续深化，就可以解决研发管理中的绝大多数问题。

InfoQ：软件研发管理方法理念的创新大致经历了瀑布型研发、敏捷开发、如今又在提 DevOps ，刚好这些领域公司都有涉足，你是怎么看待软件研发管理过程中出现的这些创新理念的？

冯斌：大概在 60 - 70 年代，我们看到更多的是瀑布式的协作方式，讲求一层一层地推进，先定好需求，然后设计好后再去编码，最后再去测试。但为什么后来又会出现敏捷、DevOps 等软件研发模式，其实最根本的原因，是商业社会中软件研发的需求总在不断变化，我们的竞争对手也在不停地求变，这导致的结果是——在内外部环境不断变化的情况下，这种从一开始做一套完整的预设、按部就班的协作方式，并不能有效地面对问题，甚至存在很大的风险和不确定性。

这个过程中，一个比较明确的趋势是，我们先把整个过程中最有效、最重要的部分做了，然后给到客户去检查并且提出一些反馈建议，最后再不断地去做调整。面对这种不确定，我们希望通过快速反馈的方式去实现持续迭代，其实包括敏捷、DevOps 本身都是从这个角度出发去考量的。

我觉得敏捷是现代的复杂性倒逼行业而产生的，我们看到许多敏捷宣言中的领导者，其实他们都经历过项目辛辛苦苦做了一年甚至两年后，结果客户反馈不满意，「需求已经变了」，或者直接就说，「当时是我们想错了！」。

于是大家开始反思如何得到一个更接近真实答案的结果，最终敏捷、DevOps 的出现，其实本质都是出于一个快速的反馈，希望快速地接近业务本质，快速做出调整迭代并最终达到一个比较理想的状态。

DevOps 是在 2013~2014 年左右开始在国内被大规模采用的，他的迅速发展，主要是因为互联网的出现打破了时间、空间上的制约，使得大量用户聚集到了同一个地方，这导致了技术架构层面的变化，我们开始需要去研究微服务等架构模式的转变，而微服务模式的出现又导致了我们的运维也产生了很大的变化，原来靠手工去解决的问题，现在已经不能解决了，必须通过一些研发介入来参与系统的开发运维，共同讨论并且把整个项目做出来。

事实上，DevOps 打破研发和开发之间职能墙的逻辑，与敏捷打破研发过程中的部门墙的思路是一致的。所以 DevOps 更多是从敏捷延伸出到开发、运维结合上的一种自动化工程理念。

InfoQ：单就敏捷而言，由于过度强调快速迭代，导致了企业在采用这一方法进行软件研发的时候往往想不清楚就开始行动。在你看来技术团队在保证研发效率的同时，该如何避免过度敏捷？

冯斌：其实我们在跟客户交流的时候，确实会遇到这样的情况，客户发现自己把版本发布的周期已经缩得非常短了，但是结果还是不理想。其实这里面最本质的问题是，大家在用敏捷的时候只看到了形式，却不能理解其中的底层逻辑，于是最终的结果是只能为了敏捷而敏捷，却没有与实际的工作、业务情况相结合。

我们在去帮助一些团队做研发效能提升的时候，会更加注重与实际情况的结合，并不会过度强调快速迭代，不会为了敏捷而敏捷。比如说在一个业务推进的过程中，我们强调迭代并不是说一定要保证两周一次产品发布，我们可以两周跟客户演示沟通一次，通过这种方式拿到团队所需要的数据和需求，进而帮助产品研发更好地得到反馈。

敏捷等方式确实为我们提供了许多非常有用的思想和理念，但是我们在用的时候首先要理解他的深层次逻辑，然后再结合实际的情况进行调整，形式值得模仿但它不一定能完全解决问题。

团队超过 100 人，领导就不知道员工在干啥了

InfoQ：相比小型研发团队，大团队会面对哪些研发管理挑战？在管理方法和工具上要做出哪些调整？

冯斌：本质上，大型团队在项目管理过程中的痛点会更多。

如果按照在线化、数据结构化、智能化这三个阶段来划分的话，在一个 10 个人的团队中，即使不用做在线化也能够很好地实现沟通以及快速协助，但是如果上升到一个 100 人以上团队的话，那么在线化、结构化、智能化就会变得非常有必要。

举例来说，如果做不到在线化，那么就会存在信息不对称、不透明的情况，这样的情况如果在小团队可能会好一点，大家也都能够接受，但是到了大的团队的话，轻则降低协作效率，重则影响团队凝聚力。

「结构化」也同样重要，如果在一个相对小一点的团队内部，可能初期的文件比较少，大家通过查文档就能找到想要的资料，但是如果到一个 100 人以上团队的话，文档的数量是海量级的，这个时候文档可能是一个小团队的百倍甚至是千倍了，这时候再去翻文档，就会非常困难。

在大型团队中，领导经常会说，“我现在其实不知道整个团队里的工作进行情况是怎样的”。在一个小团队中，领导可以亲自去问一遍每个人的工作，但是到了上百人的大型团队，这就不可行了，所以必须得借助一些智能化连接的工具，实现有效的管理和决策。

InfoQ：需要如何改进呢？

冯斌：对于大型团队的管理而言，可量化的工作和数据是非常重要的。在一个 100 人的团队中，管理者想要通过单一文档的形式管理每个人的工作情况已经非常难了，最好的情况就是首先实现数据的在线化，然后通过结构化的手段实现对所有数据的聚合关联，通过数据、图表的形式来实现管理。

在工具上一定要注重连接性，这样才能做到数据的打通，对于大型团队而言，这是一个必须的选项，有了量化之后才能对团队管理作出具体的监控管理，及时调整。

InfoQ：软件研发的时候有哪些具体的量化指标可以作为研发管理参考呢？是考察代码量吗？

冯斌：软件研发的量化，需要关注整个软件研发端到端的价值体现，否则所有忙碌可能只是内卷的产物。在我们看来主要由两个因素来体现：进度与质量。

如果我们将以上两个指标直接与组织的商业价值绑定，可以将其反馈到 KPI 或 OKR，与员工日常工作绑定。当然，对于代码量有时我们也会去看，不过更多的是在改进效率的时候去看。

例如，当我们改进研发效率时，会通过加入一些工具的方式，深入到需求讨论、设计研发、测试等不同的环节，分析这些过程中的数据与团队的行为表现，从而定位低效的具体环节。整体的改进，必然是分解到各个局部进行击破，这时候我们可以结合多种像「代码量」的过程类指标，帮助我们进行分析和改进。

大型团队采用研发管理工具的三个理由

InfoQ：从公司产品采购的维度来看，后续市场对于研发管理工具的需求将会呈现出什么样的变化？哪些客户会越来越重视研发管理？

冯斌：无疑是大型团队了。主要是因为这样的团队已经形成了成熟的管理层级，管理项目的人和写出代码的人已经不是直接的管理关系了，所以这个时候就非常需要研发效率管理工具来进行管理。

我以三个主要的场景，来说明一下大型团队为什么需要用研发管理工具？

首先，是「团队动力」的场景这是一个自下而上的过程，所有一线的工程师都需要知道整体的目标是什么？明白如何做对齐？这里就需要有一个数字化的工具来做管理，让大家都知道这个项目的整体目标是什么？如何迭代？关系到什么项目？有哪些指标？在什么时间点要与什么项目联同发布？

如果缺少这样一个比较清晰的顶层信息管理，那么底层的人能动性就会很弱，而且他们在一线发现的问题也很难通过一个有效的路线反馈给上层，因为他缺乏一些上下文的理解，即使发现问题，但是也不知道为什么会有问题。

再一个就是「跨部门协作沟通」的场景。一个团队壮大之后，免不了有不同的版本和功能之间的依赖，作为一个版本的负责人，可能他需要了解不同版本之间的依赖关系是怎样的，不同版本之间是否存在延期风险，是否需要做出调整，这里其实也存在着信息的不对称，需要做出同步和监控。

最后是「自上而下的管理」。在一个大型团队中，如果领导想了解整个团队、整个项目的运行情况，如果没有一个数字化的工具来打通的话，这个目的是非常难以达到的。

综合来看，在越是大型的团队中，就越是需要有专门的数字化工具来打通，实现研发管理。

数字化加速让研发管理变得更重要了

InfoQ：在你看来，未来企业团队在工作或者互相协作的模式上将呈现出怎样的特色？企业研发管理在其中将扮演着怎样的一个角色？

冯斌：今年有非常多的外部因素影响，例如年初疫情大大加速了企业数字化转型的进程。

因为疫情，我们不得不在家办公的时候，许多团队如果缺乏一个数字化的工具，协作起来就会非常地困难。经历数十天在家办公后，大家逐渐找到适合自己团队的数字化工作方式，至少不至于工作完全无法开展，这也为团队数字化转型提供了更多信心。

项目管理工具其实就是软件研发团队的 ERP 系统，在这个系统中，许多直接关系到整个团队研发的资源利用率、投入产出比、工作效率等信息，能够直接影响整个项目管理的成功与否。

项目管理在一个想法从开始到落地的全过程中，都处于一个非常中心的位置。尤其是在团队内部需求不明确，外部商业环境不断变化的情况下，我们如何通过一个数字化的工具来快速地获取反馈，实现快速的迭代？这些都是项目管理过程中非常重要的工作。

对于大型团队的研发管理工作而言，我认为未来还是需要进一步通过采用数字化管理工具的方式，实现对上述流程的量化与管理。

InfoQ：了解到荔枝 FM 是咱们这边的客户，能通过这个例子，用最通俗易懂的方式说明一下公司的产品是如何解决实际业务场景中的问题吗？

冯斌：荔枝 FM 在我们客户群中属于数字化能力较强的一类，在选择我们产品的时候，更多是选择一个灵活功能强大的工具承载团队的工作方法。

除了互联网这一类技术能力比较强的公司外，我们更多的是帮助一些数字化转型意愿比较强，同时自身工具、人才、管理体系还不够完善的企业完成整体体系的建设。如零售、物流、金融、高科技等行业，它们依靠软件能力优化其在千亿市场的商业效率。随着大数据、AI 等技术成熟，这些企业的软件研发团队规模也越来越大，项目管理问题也就越来越凸显了。

以我们某一个国有企业信息部的金融行业客户来说，它的研发过程分为了项目立项管理、需求管理、研发过程管理、Bug 管理以及反馈管理等。其业务已经经营了十年以上，在这一过程陆续通过不同的系统实现管理落地，数据之间难以连接，要实现统一管理和量化分析变得非常困难，这导致他的数据最后只能通过人工的方式连接，低效又容易出错。

后来，客户使用 ONES ，将所有的研发项目管理数据通过我们的产品管理，实现端到端的整合，解决了数据孤岛的问题，为后续去做智能化的转型打下了良好的基础。