什么是技术债务？

「债务」这个比喻非常恰当。最早提出「技术债务 Technical Debt」比喻的工程师 Ward Cunningham 对此做了详细的解释：

有了借来的钱，你可以比采用其他方式更快地做某件事情，但在还清这笔钱之前，你需要支付利息。我认为借钱是个好主意，我也认为赶快对外发布软件以获得经验是个好主意，但当然，你最终会回到这来，并且随着你愈加了解软件，你会通过重构程序来偿还那笔贷款，以此反映你所获得的经验。

本文将与你讨论技术债是如何产生的。但在那之前，我们先了解一些与技术债的产生原因和本质有关的常见误解。

误区一：技术债务 == 坏代码

到底什么是「坏代码」？

好的代码或许是整洁的代码，也可以概括为不会迫使你在未来做出特定决策的代码，它保留了选择的余地。而坏代码则不留余地，还会强加上一些原本不存在的约束。

我几乎没见过由「糟糕的开发者」编写的「坏代码」，至少在生产项目中没有（这正是代码审查的作用）。我遇到的大多数「坏代码」都出自受到约束影响的优秀的开发者。

误区二：技术债是错误的

技术债务和金融债务一样不分对错好坏。在非理想状态下——即没有足够的「现金」来满足需要——它就是产品开发工具箱中的一个有效工具。

误区三：构建完成就万事大吉

最常见的软件开发的比喻是修建建筑。在建筑行业，工作是按顺序进行的：

• 建筑设计师设计建筑并绘制图纸；
• 工人们挖掘地基、修建上层建筑、铺设管线并进行室内装修；
• 业主和租户高兴地搬进来，如有任何问题，再找维修人员解决。

这是一个通俗易懂的比喻，但却和软件行业不怎么类似。

与建筑相比，软件更像是园艺——它比混凝土更有机。你根据最初的计划和各种条件在花园里种植许多花木。有些花木茁壮成长，另一些注定要成为堆肥。你可能会改变植株的相对位置，以有效利用光影、风雨的交互作用。过度生长的植株会被分栽或修剪，颜色不协调的会被移栽到从美学上看更怡人的地方。你拔除野草，并给需要额外照料的植株施肥。你不断关注花园的兴旺，并按照需要（对土壤、植株、布局）做出调整。——《程序员修炼之道》

在（错误的）建筑比喻中，大部分成本是预先产生的。维护成本要么是名义上的，要么被视作偶发事件而忽略不计。

在园艺的比喻中，构建功能是漫长工作中的一个步骤（就像种植作物）。花园越大，所需的维护就越多。这是在重新种植以改变布局（重构），或扩大花园并种植新作物（添加新功能——这也需要维护）之外的工作。

90% 的软件成本均与维护有关——我很多年前就知晓这个数据，但每每想到还是觉得难以置信。

技术债是怎么产生的？

那么，技术债究竟从何而来？它可以避免吗？

技术债务的另一种理解可能是，项目当前所处的状态与「假设利用积累的知识重新开始而现在应处的状态」之间的差值。

技术债有两个来源：

• 决策的权衡和取舍（鲁莽 vs 谨慎）
• 制定和执行决策时所具备（或缺乏）的知识，即有意和无意

理想情况下，你会在充分了解情况且不向约束条件妥协的前提下做出决策。但现实可能是，你在没有全盘了解信息和背景时就启动了项目，还要根据时间限制（如利益相关者给的截止日期）或成本限制等约束做出权衡。

如何避免技术债是一门学问，而对「技术债可否避免」这一问题，我的回答是：

“可以避免，但技术债是一种工具，不是敌人。”

如何量化技术债？

「现在有多少技术债？」这么抽象的概念真的能被量化吗？

真的很难，或者说你无法可靠地跟踪技术债。如果向软件工程师了解如何实现某个功能或修复产品的某个部分，他们可能会提供一个估算结果，并将需要偿还的技术债务涵盖在内，但你仍然无法追踪它。

Chelsea Troy 提出了一个与技术债务高度相关的可量化指标：维护负载（maintenance load） 。

维护负载描述了开发团队花费多少精力来保持现有功能同以前一样运行。—— Chelsea Troy

维护负载是有关项目年限和构建实践的函数，其衡量单位是持续付出维护精力的开发者数量（ongoing developer effort）。

需要说明的是，维护负载 != 技术债务。

但它依然是一个非常不错的技术债务指标。如果需要更多的工程师来防止系统/项目崩溃，那么很可能意味着你有很多技术债。如果仅靠十几个人就能建立一家价值 10 亿美元的公司，那么他们大概率很好地控制住了技术债。

（作者 Jacob Bennett，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

技术分享 | SpringBoot 流式输出时，正常输出后为何突然报错？

用 MVP(最小可行性产品) 做低成本快速验证，为什么不灵了？

6 大原则！助你构建高绩效的研发强军 | Liga译文

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

问题出现

问题出现在上述第 3 点：正常输出一段内容后，后台突然报错，而报错内容由拦截器产生。

笔者仔细查看了报错日志，发现只是拦截器的问题：执行时由于某些线程变量不存在而报错。但是，这些线程变量已经在过滤器中初始化了。

那么问题来了：为什么这个接口明明可以正常通过过滤器和拦截器，并开始正常输出，却又突然在拦截器中报错呢？

场景重现

Filter

@Slf4j
@Component
@Order(1)
public class MyFilter implements Filter {

    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        // 要继续处理请求，必须添加 filterChain.doFilter()
        log.info("doFilter method is running..., thread: {}, dispatcherType: {}", Thread.currentThread(), servletRequest.getDispatcherType()); 
        filterChain.doFilter(servletRequest,servletResponse);
    } 
}

Interceptor

@Slf4j
public class MyInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(@NotNull HttpServletRequest request, @NotNull HttpServletResponse response, @NotNull Object handler) throws Exception {
        log.info("preHandle method is running..., thread: {}, dispatcherType: {}", Thread.currentThread(), request.getDispatcherType());
        if (DispatcherType.ASYNC == request.getDispatcherType()) {
            log.info("preHandle dispatcherType={}", request.getDispatcherType());
        }
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        log.info("postHandle method is running..., thread: {}", Thread.currentThread());
    }      

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        log.info("afterCompletion method is running..., thread: {}", Thread.currentThread());
    } 
}

WebMvcConfigurer

@Configuration
public class WebAppConfigurer implements WebMvcConfigurer {

    @Bean
    public MyInterceptor myInterceptor() {
        return new MyInterceptor();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(myInterceptor()).addPathPatterns("/**");
    }

    @Override
    public void configureAsyncSupport(AsyncSupportConfigurer configurer) {
        configurer.setDefaultTimeout(120_000L);
        configurer.registerCallableInterceptors();
        configurer.registerDeferredResultInterceptors();

        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("web-async-");
        executor.initialize();
        configurer.setTaskExecutor(executor);
    }
}

Controller

@Slf4j
@RestController
@RequestMapping("/test-stream")
public class TestStreamController {

    @ApiOperation("流式输出示例")
    @PostMapping(value = "/example", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public ResponseEntity<StreamingResponseBody> example() {
        log.info("Stream method is running, thread: {}", Thread.currentThread());
        return  ResponseEntity.status(HttpStatus.OK)
            .contentType(new MediaType(MediaType.TEXT_EVENT_STREAM, StandardCharsets.UTF_8))
            .body(outputStream -> {
                log.info("Internal stream method is running, thread: {}", Thread.currentThread());
                try (outputStream) {
                    String msg = "To be or not to be!";
                    outputStream.write(msg.getBytes(StandardCharsets.UTF_8));
                    outputStream.flush();
                }
            });
    }
}

根据以下运行日志，我们可以看到拦截器的 preHandle 确实执行了两次，并且此次调用过程共有 3 个线程（io-14000-exec-1，web-async-1，io-14000-exec-2）参与了工作。

2024-05-06 07:35:27.362  INFO 209108 --- [io-14000-exec-1] o.a.c.c.C.[.[localhost].[/java-study]    : Initializing Spring DispatcherServlet 'dispatcherServlet'
2024-05-06 07:35:27.362  INFO 209108 --- [io-14000-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2024-05-06 07:35:27.365  INFO 209108 --- [io-14000-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 3 ms
2024-05-06 07:35:27.402  INFO 209108 --- [io-14000-exec-1] com.peng.java.study.web.config.MyFilter  : doFilter method is running..., thread: Thread[http-nio-14000-exec-1,5,main], dispatcherType: REQUEST
2024-05-06 07:35:28.107  INFO 209108 --- [io-14000-exec-1] c.p.java.study.web.config.MyInterceptor  : preHandle method is running..., thread: Thread[http-nio-14000-exec-1,5,main], dispatcherType: REQUEST
2024-05-06 07:35:28.121  INFO 209108 --- [io-14000-exec-1] c.p.j.s.w.r.test.TestStreamController    : Stream method is running, thread: Thread[http-nio-14000-exec-1,5,main]
2024-05-06 07:35:28.152  INFO 209108 --- [    web-async-1] c.p.j.s.w.r.test.TestStreamController    : Internal stream method is running, thread: Thread[web-async-1,5,main]
2024-05-06 07:35:28.167  INFO 209108 --- [io-14000-exec-2] c.p.java.study.web.config.MyInterceptor  : preHandle method is running..., thread: Thread[http-nio-14000-exec-2,5,main], dispatcherType: ASYNC
2024-05-06 07:35:28.167  INFO 209108 --- [io-14000-exec-2] c.p.java.study.web.config.MyInterceptor  : preHandle dispatcherType=ASYNC
2024-05-06 07:35:28.174  INFO 209108 --- [io-14000-exec-2] c.p.java.study.web.config.MyInterceptor  : postHandle method is running..., thread: Thread[http-nio-14000-exec-2,5,main]
2024-05-06 07:35:28.183  INFO 209108 --- [io-14000-exec-2] c.p.java.study.web.config.MyInterceptor  : afterCompletion method is running..., thread: Thread[http-nio-14000-exec-2,5,main]

问题分析

1. 方法调用流程的差异

众所周知，SpringBoot 的普通输出接口调用流程图如图 1 所示。

结合日志，我们可以简单画出流式输出接口对应的流程图（图 2）。

2. 线程的差异

普通接口的执行时序图如图 3 所示。

而流式接口的时序图如图 4 所示。

解决问题

通过分析，对流式输出的情况提出两种解决方案：

1. 将过滤器中的部分业务逻辑迁移到拦截器中。
2. 根据条件，跳过第二次的拦截器 preHandle 方法。

笔者选择了第二个方案，实现代码如下。

@Slf4j
public class MyInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(@NotNull HttpServletRequest request, @NotNull HttpServletResponse response, @NotNull Object handler) throws Exception {
        log.info("preHandle method is running..., thread: {}, dispatcherType: {}", Thread.currentThread(), request.getDispatcherType());
        // 如果是异步请求，则跳过
        if (DispatcherType.ASYNC == request.getDispatcherType()) {
            log.info("preHandle dispatcherType={}", request.getDispatcherType());
            return true;
        }
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        log.info("postHandle method is running..., thread: {}", Thread.currentThread());     
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        log.info("afterCompletion method is running..., thread: {}", Thread.currentThread());
    } 
}

需要注意，请求线程和回调线程都需考虑清理线程变量，不然会导致内存泄漏。

>> LigaAI 往期精彩阅读 <<

用 MVP(最小可行性产品) 做低成本快速验证，为什么不灵了？

6 大原则！助你构建高绩效的研发强军 | Liga译文

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

不过很遗憾，这并不是一个正确的问题——这也是九成的初创公司走向失败的一个重要原因。据 Exploding Topics 报道，10% 的初创企业无法顺利度过第一年，而 70% 的企业也在第 2~5 年宣告失败。 最终，只有十分之一的初创企业能够幸存。

在过去 20 年与创业者的合作中，我参与了 20 多家初创企业从创意萌生到 IPO 的全过程——能获得成功的公司少之又少。我从中学到最有用的一课，不是「企业为什么能成功」，而是它们「会被什么击败」。

其中大部分首次创业者不够投入，往往仅凭直觉就匆忙拼凑出一个不经测试的产品，而其他人则是过于投入而忽略了市场验证和测试，产品功能要么太过单一，要么过分臃肿。

你可能想说：“这不就是没有通过 MVP （Minimum Viable Product，最小可行性产品）进行快速学习吗？”

——说的很好，但也不准确。

这个问题的关键在于「V」是什么。在商业语境下，真正重要的是 Viable 还是 Valuable？

首先，让我们从灯泡的故事讲起。

灯泡带来的启示

你或许在小学时学过「爱迪生发明了电灯泡」。

但事实并非如此。

在爱迪生之前，包括埃比尼泽·金纳斯利（Ebenezer Kinnersley）、汉弗里·戴维 （Humphry Davy）和约瑟夫·斯万（Joseph Swan）在内的许多发明家已经发明出了各式各样的白炽灯丝。甚至在 19 世纪 70 年代，当爱迪生转向安全、可持续、经济且无异味的照明方案研究时，就已经有了一些关于白炽灯泡的专利（当时主要的室内照明方案是煤气灯）。

作为一名创新者和企业家，爱迪生早就决定，商业变现不必依靠发明本身。他更感兴趣的是「完善」，即让事情变得更好或更便宜。 我很喜欢《纽约客》的说法：

爱迪生从不寻找需要解决方案的问题，他所找的是需要修改的解决方案。

当时现有的灯泡解决方案不太实用，而且灯泡的使用寿命也不长。也就是说，它们是可行的，但并不是特别有价值。

这正是爱迪生能够脱颖而出的原因。爱迪生和他的团队在位于加州门洛帕克的总部对 3,000~6,000 种材料和灯丝进行了测试，直到 1879 年才发现碳是最佳的解决方案。一年后，他们发现碳化竹子可以燃烧超过 1,000 个小时，于是今天为人熟知的白炽灯泡诞生了。

爱迪生如此努力创造的不是 MVP，而是 MVE（Minimum Valuable Experience）——最低价值体验。

如何将人们迫切需要的东西，变得易于获得、经济实惠且经久耐用？ 这才是真正的「灵光一现」。

A.C.T 框架

了解如何建立 MVE 前，有两个关键点需要注意：

• 你的故事就是策略。
• 表达的方式非常重要，它决定了用户对产品是「无感」还是「每月复购」。

所有的一切都是为了了解你的用户，了解什么话术和信息能够引起他们的共鸣，以及哪些策略、触点和触发条件能够刺激他们采取行动。

为了快速高效地建立 MVE，我开发了「A.C.T 框架」。它有助于快速明确方向并节省大量无用的营销活动。A.C.T 框架由三个重要部分组成：

• Audience 受众
• Communication 交流
• Touchpoints 触点

A = 受众群体：你要对「谁」说话？

想要知道说些什么，首先得弄清楚你要跟谁交流。

• 谁是你的理想客户？
• 客户考虑新的解决方案时，想要/需要/使用的是什么？
• 在寻找新方案的过程中，他们会搜索什么？
• 是哪些习惯、行为、目标或者决定性特征吸引了他们来使用你的产品？

C = 交流：你要说什么？

这是一件「用什么方式传递什么信息」的艺术。

你必须用能够引起客户共鸣的语言和方式，用他们的方法跟他们交流，去传达那些适配他们味蕾（和钱包）的愿景或动机。

T = 触点：在哪分享信息？

弄清楚「和谁说」以及「说什么」之后，就可以好好想想「该怎么做」了。

设计能刺激客户采取实际行动的触点和触发条件，包括官网展示、社媒传播和邮件营销等等。其核心目的是辨别和确定最有效且投资回报率最高的渠道和策略。

这也是最容易出错的部分。有时候，你可能只需要一个简单的注册表单，而有的时候则需要采取更有策略性（如建立私域群组）或更复杂（如一个详细的销售漏斗和沉浸式故事）的方法。

案例应用

假设现在要推出一款全新的无酒精啤酒饮料，你会如何应用 A.C.T 框架回答以上问题？

（花点时间，动动小脑瓜 ）

下面分享我的回答。别担心，问题没有标准答案，思路和分析才是重点。

A：无酒精啤酒的理想受众是谁？

传统人口统计特征中的年龄、性别或地理位置等数据并不能提供太多有效信息，因为无酒精啤酒很可能不在任何标签中。

从行为角度来看，购买无酒精啤酒的人喜欢喝啤酒，但不喜欢酒精对健康、行为能力和工作效率的影响；他们富有猎奇心，足够开放，愿意尝试和接受新鲜事物。

C：要向他们传递什么信息？

我需要让理想客户知道，这款饮品提供了最接近啤酒的体验：它采用高品质原料，通过手工精酿制成，其炫酷的包装甚至可以媲美最流行的 IPA 啤酒。最重要的是，它的热量很低，并且不会产生任何宿醉感。

T：在什么渠道发布和传播信息？

无酒精啤酒代表了一种健康但仍然可以享受乐趣的生活态度，所以年轻化的短视频平台是很好的渠道。如果是线下宣传，健身房旁边的水吧或者支持多人聚餐的健康餐厅也是不错的选择。

A.C.T 框架有助于了解「哪些体验或触点可以带来产品吸引力」。

对某些人来说，最好的触点可能是社交媒体上某个热门话题下的一张精美表单；对其他人而言，可能是一个关于产品如何提升生活品质的巧妙故事，或者一场能够清楚传递「我们如何能帮你成为更好的自己」的精彩活动。不同的品牌和产品会有不同的答案。

而「A.C.T + MVE」能让你快速迭代，获得最有价值的体验。当你专注于研究潜在客户真正重要的事情时，你就能点亮他们的生活。

在我看来，这是通往商业成功的唯一可行路径。

原文作者为 Pete Sena，内容经 LigaAI 翻译整理。

>> LigaAI 往期精彩阅读 <<

6 大原则！助你构建高绩效的研发强军 | Liga译文

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

然而，尽管出现了许多理念和项目管理框架，例如敏捷（Agile）、Scrum、极限编程（XP）、看板（KanBan）和团队拓扑（Team Topologies）等，但只有少数企业知道如何高效地开发软件。我遇到过许多错误模式，最终导致进度延迟、软件质量恶化和客户满意度下降。为了避免无效管理并达成更优秀的表现，你应该了解软件项目/产品管理的最佳实践、理念及原则。

其中影响范围最大的实践之一是搭建团队结构的方式。许多研究（如康威定律）证明，如果用错误的方式搭建团队结构，团队绩效将受到极大的制约。在本文中，我将根据自己的经验和深入研究，解释能够在组织中构建有效结构的几项原则。

1. 系统设计先行

搭建高绩效研发团队的第一条原则，是在设计团队结构之前，先设计你想要的系统。美国计算机科学家和计算机程序员 Melvin Edward Conway 于 1967 年提出康威定律（Conway’s Law），该定律描述了组织的结构和沟通方式将制约其生产的系统设计。如果一个组织组建了设计团队、业务团队、前端团队和后端团队，那么系统的输出也将是业务文档、设计组件、前端组件和后端组件，这需要大量的团队沟通才能完成最终的整合并交付给用户。康威定律下的团队结构是最普遍的反模式之一，直到今天仍有许多组织在使用。

下面这种团队结构无需频繁交流，也能让团队独立地为用户提供价值（尽管无法做到完全独立）。它也被称为流对齐团队、功能团队或跨职能团队。

2. 考虑认知负荷

Matthew Skelton 和 Manuel Pais 于 2019 年出版的《高效能团队模式：支持软件快速交付的组织架构》描述了软件研发组织中的四种基本团队：流对齐团队（Stream-aligned team） ，使能团队（Enabling team） ，复杂子系统团队（Complicated subsystem team） ，以及平台团队（Platform team） 。这四种基本团队的背后是一个重要的心理学理论：认知负荷——指工作记忆资源的使用量。

上一条原则所解释的团队结构在《高效能团队模式》中被称为流对齐团队。流对齐团队是跨职能的，也是独立为用户提供价值的主力军。然而，流对齐团队太忙了，以致于无法赶上新玩意儿，比如新的技术、管理方法或领导力，也无法处理基础设施。如果把过多的责任压在流对齐团队身上，他们就无法处理任务，团队表现也会变差。 因此，为了减轻他们的认知负担，其余三个团队（使能团队、复杂子系统团队和平台团队）都要前来支援。

• 使能团队帮助流对齐团队学习向用户交付更高价值所需的新事物，诸如技术、架构、UI/UX、管理方法等。使能团队可能由内部/外部导师、教练或顾问组成，他们可以在流对齐团队中教授和实施新事物。
• 复杂子系统团队负责需要特殊技能或可与正常交付隔离的特定组件，例如机器学习模型、特殊图形/动画或认证 API。复杂子系统团队所处理的组件将通过讨论确定，因为它们与流对齐团队之间没有明确界限。
• 平台团队负责构建和提供一个平台，以让流对齐团队可以在该平台顺利地部署和发布，向用户交付价值。 在团队拓扑的背景下，平台是一个包括文档、指南、DevOps 和基础设施的综合概念，旨在帮助流对齐团队顺利部署。

3. 保持团队精干

原则之三是让团队保持「小而精」。 许多研究和知名企业都表明，「小而精」有比「大而全」更高的效率、更好的业绩——这是因为小团队的沟通更加有效，团队中的每个人都能随时了解情况，并提高参与度。亚马逊自创立之初就实行「两个披萨」原则（即组建团队和参加会议的人数不超过 9 人）并取得了真正的成功。

《敏捷革命》的作者 Jeff Southerland 在「Scrum 指南」中也解释说：“Scrum 团队小到可以保持灵活性，大到能够在一个迭代内完成重要工作，通常是 10 人或者更少。总的来说，我们发现较小的团队沟通更顺畅，工作效率更高。”

4. 仆人式领导力

Daniel H. Pink 在《驱动力》一书中提出了「驱动力 3.0」。他认为自工业时代以来，人类的行为动机已然发生了变化，他还审视了驱动力的三大要素：自主、专精和目的——它们可以持续激励我们。

• 自主（Autonomy） ：人类想要决定如何做。
• 专精（Mastery） ：人类想要成长。
• 目的（Purpose） ：人类寻求意义。

由 Robert K. Greenleaf 提出的「仆人式领导理论」正是驱动力 3.0 的体现。这是领导哲学的一种，其主要实践是为团队服务，使团队成员在工作中保持高度的参与度、积极性和可持续增长。在传统的领导方式中，领导者（老板）以命令和控制的方式命令团队成员（下属）做什么以及如何做。传统的领导风格无法激励个人，也无法提高他们的参与度和工作表现。

而仆人式领导者会设定一个目标和愿景（目的），将实现目标和愿景的方法下放给个人（自主），并提供学习新东西的机会（专精） 。

5. 持续改进

截至 2024 年 1 月，丰田是全球最大的汽车公司，其实践和理念一直影响着所有商业行业，如七大浪费、5S（Seiri 整理、Seiton 整顿、Seiso 清扫、Seiketsu 清洁、Shitsuke 素养）和 3M（Muri 超负荷、Muda 浪费、Mura 不均匀）。其中，最著名的理念是 Kaizen（改善）即持续改进业务流程。无论业务类型或情况如何（即使公司拥有行业最高的市场份额），都 100% 有改进的空间。 没有完美的企业，因此必须不断成长。

从长远发展来看，持续改进会产生复利效应。该术语最初来自金融学中的「复利」，意为利息长期呈指数级增长并产生被动收入。同样，如果团队和业务持续改进，他们的业务流程也将大幅改善，销售收入会成倍增加；其弊端在于大多数人由于短期看不到显著效果，会停止持续改进，但长期来看，持续改进所带来的效益是巨大的，因此需要坚持不懈和耐心。

Scrum 是最流行的敏捷框架，起源于丰田，也是持续改进的实践。在 Scrum 中，持续改进发生在「迭代回顾 Sprint Retrospective」中，Scrum 团队讨论他们在未来的工作中可以做得更好的地方。这是 Scrum 解决团队表现问题并成为应用最广泛的敏捷框架的最大原因之一。

6. 稳定性

搭建高绩效研发团队的最后一项原则是稳定性，即团队结构/成员和工作流程应保持稳定。不稳定会使团队混乱，影响工作效率和表现。

首先是团队结构和成员的稳定，这意味着他们不应频繁变动或调动。 比如，如果组织经常在不同团队之间调动开发人员，那么开发者被分配到新团队时就需要重新熟悉工作方式、代码库和文档，从而降低工作效率。

其次是工作流程流转的稳定性。如果工作流程不规范、不统一，团队成员就会对如何工作感到困惑，产出质量也会不一致。 丰田将标准化定义为业务最关键的实践之一，因为大野耐一强调工作应该顺畅地进行，没有阻碍和浪费。作为丰田生产方式（TPS）的成果，用于将工作流程和任务状态可视化的看板（Kanban）应运而生。

总结

在软件研发组织中，构建有效的团队结构对提高团队效率和工作表现至关重要。本文总结了构建高绩效研发团队的六项原则，它们分别是：

原则一： 系统设计应该比团队构建更早完成。

原则二： 充分考虑认知负荷并组建支持团队（使能团队、复杂子系统团队和平台团队），以协助核心团队（流对齐团队）工作。

原则三： 让团队保持在小而美的规模。团队规模越大，沟通也会变得更加复杂，进而降低工作效率。

原则四： 实践仆人式领导，围绕驱动力 3.0 帮助团队提高参与度和工作表现。

原则五： 无论如何都要坚持持续改进。哪怕在行业遥遥领先，也一定有进步空间。

原则六： 维护团队结构和工作流程的稳定性。这对于避免混乱和追赶成本，提高团队绩效非常重要。

（原文作者为 Eiki，内容经 LigaAI 翻译整理）

>> LigaAI 往期精彩阅读 <<

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

宁波银行：在「金融科技」引擎上，沉浸式提效减负

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

本文将分享如何使用 useDialog Hook 封装 el-dialog，实现更灵活、更易用的弹窗组件。

一、问题澄清

「将一个通用的组件应用在多个页面」是一个很常见的实际场景。

举个例子：以购买应用程序为例，用户可能在付费页面进行购买操作，也可能在浏览其他页面时触发购买需求，此时就需要弹出对话框引导用户完成购买行为。

为了实现这一功能，过去通常会采用以下步骤：

1. 封装购买组件：首先创建一个通用的购买组件，以便在不同页面和场景下复用。
2. 在付费页面渲染购买组件：将购买组件直接嵌到付费页面中。
3. 在其他页面使用 el-dialog 展示购买组件：在其他页面通过 el-dialog 控制组件的显示，利用 visible 状态变量（通常是一个 ref 响应式变量）动态控制对话框的弹出与关闭。

虽然这种方式可以满足功能需求，但随着该组件被越来越多的页面和功能所使用，维护也会愈加复杂繁琐——每增加一个使用页面，都必须重复编写控制显示/隐藏的逻辑代码。

那么，有没有更好的方法可以简化这个过程？是否可以通过某种方式，用一个单独的函数全局控制购买组件的打开和关闭，从而减少代码重复，降低维护成本？

二、关于 useDialog Hook

在 Vue 中，Hook 允许在函数式组件或者 API 中「钩入」Vue 特性。它们通常在组合式 API（Composition API）中使用，这是 Vue 提供的一套响应式和可复用逻辑功能的集合。

本文提到的 useDialog Hook 就是一个封装了 el-dialog 组件基本功能的自定义 Hook，它还可以提供附加特性以便在项目中管理和展示弹窗。

三、实现 useDialog Hook

useDialog Hook 需要达成以下目标：

1. 满足基础用法，传入 el-dialog 的基础属性以及默认slot显示的内容，导出 openDialog 和 closeDialog 函数；
2. 支持 el-dialog 的事件配置；
3. 支持默认 slot 组件的属性配置；
4. 支持 el-dialog 其他 slot 配置，例如 header 和 footer 等；
5. 在内容组件中抛出特定事件支持关闭 dialog；
6. 支持显示内容为 jsx、普通文本、Vue Component；
7. 支持在显示内容中控制是否可以关闭的回调函数，例如 beforeClose；
8. 支持显示之前钩子，例如 onBeforeOpen；
9. 支持定义和弹出时修改配置属性；
10. 支持继承 root vue 的 prototype，可以使用如 vue-i18n 的 $t 函数；
11. 支持 ts 参数提示；

（一）准备 useDialog.ts 文件实现类型定义

import type { Ref } from 'vue'
import { h, render } from 'vue'
import { ElDialog } from 'element-plus'
import type {
  ComponentInternalInstance,
} from '@vue/runtime-core'

type Content = Parameters<typeof h>[0] | string | JSX.Element
// 使用 InstanceType 获取 ElDialog 组件实例的类型
type ElDialogInstance = InstanceType<typeof ElDialog>

// 从组件实例中提取 Props 类型
type DialogProps = ElDialogInstance['$props'] & {
}
interface ElDialogSlots {
  header?: (...args: any[]) => Content
  footer?: (...args: any[]) => Content
}
interface Options<P> {
  dialogProps?: DialogProps
  dialogSlots?: ElDialogSlots
  contentProps?: P
}

（二）实现普通 useDialog 函数

下面的函数实现了含目标 1、2、3、4、6 和 11 在内的基础用法。

目标 1：满足基础用法，传入 el-dialog 基础属性及默认 slot 显示的内容，导出 openDialog 和 closeDialog 函数；
目标 2：支持 el-dialog 的事件配置；
目标 3.：支持默认 slot 组件的属性配置；
目标 4：支持 el-dialog 其他 slot 配置，如 header 和 footer 等；
目标 6：支持显示内容为 jsx、普通文本、Vue Component；
目标 11：支持 ts 参数提示；

export function useDialog<P = any>(content: Content, options?: Ref<Options<P>> | Options<P>) {
  let dialogInstance: ComponentInternalInstance | null = null
  let fragment: Element | null = null

  // 关闭并卸载组件
  const closeAfter = () => {
    if (fragment) {
      render(null, fragment as unknown as Element) // 卸载组件
      fragment.textContent = '' // 清空文档片段
      fragment = null
    }
    dialogInstance = null
  }
  function closeDialog() {
    if (dialogInstance)
      dialogInstance.props.modelValue = false
  }

  // 创建并挂载组件
  function openDialog() {
    if (dialogInstance) {
      closeDialog()
      closeAfter()
    }

    const { dialogProps, contentProps } = options
    fragment = document.createDocumentFragment() as unknown as Element

    const vNode = h(ElDialog, {
      ...dialogProps,
      modelValue: true,
      onClosed: () => {
        dialogProps?.onClosed?.()
        closeAfter()
      },
    }, {
      default: () => [typeof content === 'string'
        ? content
        : h(content as any, {
          ...contentProps,
        })],
      ...options.dialogSlots,
    })
    render(vNode, fragment)
    dialogInstance = vNode.component
    document.body.appendChild(fragment)
  }

  onUnmounted(() => {
    closeDialog()
  })

  return { openDialog, closeDialog }
}

（三）实现目标 5

目标 5：在内容组件中抛出特定事件支持关闭 dialog；

1. 在定义中支持 closeEventName ;

interface Options<P> {
  // ...
  closeEventName?: string // 新增的属性
}

2. 修改 useDialog 函数接收 closeEventName 事件关闭 dialog。

export function useDialog<P = any>(content: Content, options?: Ref<Options<P>> | Options<P>) {
  // ...
  // 创建并挂载组件
  function openDialog() {
    // ...
    fragment = document.createDocumentFragment() as unknown as Element
    // 转换closeEventName事件
    const closeEventName = `on${upperFirst(_options?.closeEventName || 'closeDialog')}`

    const vNode = h(ElDialog, {
      // ...
    }, {
      default: () => [typeof content === 'string'
        ? content
        : h(content as any, {
          ...contentProps,
          [closeEventName]: closeDialog, // 监听自定义关闭事件，并执行关闭
        })],
      ...options.dialogSlots,
    })
    render(vNode, fragment)
    dialogInstance = vNode.component
    document.body.appendChild(fragment)
  }

  onUnmounted(() => {
    closeDialog()
  })

  return { openDialog, closeDialog }
}

（四）实现目标 7、8

目标 7：支持在显示内容中控制是否可以关闭的回调函数，例如 beforeClose；
目标 8：支持显示之前钩子，例如 onBeforeOpen；

1. 在定义中支持 onBeforeOpen、beforeCloseDialog 默认传给内容组件，有组件调用设置；

type DialogProps = ElDialogInstance['$props'] & {
  onBeforeOpen?: () => boolean | void
}

2. 修改 useDialog 函数接收 onBeforeOpen 事件并传递 beforeCloseDialog。

export function useDialog<P = any>(content: Content, options?: Ref<Options<P>> | Options<P>) {
  // ...
  // 创建并挂载组件
  function openDialog() {
    // ...
    const { dialogProps, contentProps } = options
    // 调用before钩子，如果为false则不打开
    if (dialogProps?.onBeforeOpen?.() === false) {
      return
    }
    // ...
    // 定义当前块关闭前钩子变量
    let onBeforeClose: (() => Promise<boolean | void> | boolean | void) | null

    const vNode = h(ElDialog, {
      // ...
      beforeClose: async (done) => {
        // 配置`el-dialog`的关闭回调钩子函数
        const result = await onBeforeClose?.()
        if (result === false) {
          return
        }
        done()
      },
      onClosed: () => {
        dialogProps?.onClosed?.()
        closeAfter()
        // 关闭后回收当前变量
        onBeforeClose = null
      },
    }, {
      default: () => [typeof content === 'string'
        ? content
        : h(content as any, {
          // ...
          beforeCloseDialog: (fn: (() => boolean | void)) => {
            // 把`beforeCloseDialog`传递给`content`，当组件内部使用`props.beforeCloseDialog(fn)`时，会把fn传递给`onBeforeClose`
            onBeforeClose = fn
          },
        })],
      ...options.dialogSlots,
    })
    render(vNode, fragment)
    dialogInstance = vNode.component
    document.body.appendChild(fragment)
  }

  onUnmounted(() => {
    closeDialog()
  })

  return { openDialog, closeDialog }
}

（五）实现目标 9、10

目标 9：支持定义和弹出时修改配置属性；
目标 10：支持继承 root vue 的 prototype，可以使用例如 vue-i18n 的 $t 函数；

// 定义工具函数，获取计算属性的option
function getOptions<P>(options?: Ref<Options<P>> | Options<P>) {
  if (!options)
    return {}
  return isRef(options) ? options.value : options
}

export function useDialog<P = any>(content: Content, options?: Ref<Options<P>> | Options<P>) {
  // ...
  // 获取当前组件实例，用于设置当前dialog的上下文，继承prototype
  const instance = getCurrentInstance()
  // 创建并挂载组件，新增`modifyOptions`参数
  function openDialog(modifyOptions?: Partial<Options<P>>) {
    // ...
    const _options = getOptions(options)
    // 如果有修改，则合并options。替换之前的options变量为 _options
    if (modifyOptions)
      merge(_options, modifyOptions)

    // ...

    const vNode = h(ElDialog, {
      // ...
    }, {
      // ...
    })
    // 设置当前的上下文为使用者的上下文
    vNode.appContext = instance?.appContext || null
    render(vNode, fragment)
    dialogInstance = vNode.component
    document.body.appendChild(fragment)
  }

  onUnmounted(() => {
    closeDialog()
  })

  return { openDialog, closeDialog }
}

通过上面的封装使用 useDialog Hook 后，需要弹窗时，只需要引入该 Hook 并调用 openDialog 方法，非常方便简洁。此外，这样的封装也会让后续修改弹窗逻辑变得更加方便，只需要在 useDialog Hook 中修改，无需逐个重复编辑。

四、useDialog Hook 案例实操

下面，我们使用 useDialog Hook 来解决开头提到的应用程序购买问题。

（一）创建 components/buy.vue 购买组件

<script lang="ts" setup>
  const props = defineProps({
    from: {
      type: String,
      default: '',
    },
  })
</script>
<template>
  我是购买组件
</template>

（二）在 pages/subscription.vue 页面中使用 buy.vue 购买组件

<script lang="ts" setup>
  import Buy from '@/components/buy.vue'
</script>
<template>

  <Buy from="subscription" />

</template>

（三）在其他功能页面中弹出 buy.vue 购买组件

<script lang="ts" setup>
  import { useDialog } from '@/hooks/useDialog'
  const Buy = defineAsyncComponent(() => import('@/components/buy.vue'))

  const { openDialog } = useDialog(Buy, {
    dialogProps: {
      // ...
      title: '购买'
    },
    contentProps: {
      from: 'function',
    },
  })

  const onSomeClick = () => {
    openDialog()
  }
</script>

拓展：useDialog Hook 的其他应用

beforeClose & closeEventName 示例：buy.vue 购买组件

<script lang="ts" setup>
  const props = defineProps({
    from: {
      type: String,
      default: '',
    },
    beforeCloseDialog: {
      type: Function,
      default: () => true,
    },
  })

  const emit = defineEmits(['closeDialog'])

  props.beforeCloseDialog(() => {
    // 假如from 为 空字符串不能关闭
    if (!props.from) {
      return false
    }
    return true
  })

  // 关闭dialog
  const onBuySuccess = () => emit('closeDialog')
</script>

<script lang="ts" setup>
  import { useDialog } from '@/hooks/useDialog'
  const Buy = defineAsyncComponent(() => import('@/components/buy.vue'))

  const { openDialog } = useDialog(Buy, {
    dialogProps: {
      // ...
      title: '购买'
    },
    contentProps: {
      from: '',
    },
  })

  const onSomeClick = () => {
    openDialog()
  }
</script>

总结

使用 useDialog Hook 封装 el-dialog 可以让前端技术更加有趣简洁。笔者也希望大家能尝试这样的封装方式，让前端代码更加优雅且易于维护。

优秀的工程师就同优秀的厨师一样，掌握了精妙的烹饪和调味技巧，就能让每道菜都变得美味可口！

>> LigaAI 往期精彩阅读 <<

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

宁波银行：在「金融科技」引擎上，沉浸式提效减负

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

软件研发是一个涉及人员多、流程多、系统多的复杂工程，LigaAI 和极狐GitLab 一直在积极探索安全、高效交付的方式。LigaAI 在「AI+研发协作」领域持续创新多年。作为以人工智能技术为核心的新一代智能研发协作平台，LigaAI 通过 AI 和强大的多端联结能力，为众多企业提供了一站式需求管理、智能项目助理、研发洞察等产品和服务。致力于通过 AI 场景化繁为简，提升协作效率，赋能研发团队，LigaAI 秉承更智能、更轻巧、更高效的理念，助力研发团队高质量、高效率地创新成长。

经过多年的深耕极狐GitLab 已经发展成为一个囊括敏捷项目管理、源代码托管、CI/CD、安全合规等众多功能的企业级一体化 DevSecOps 平台，通过提高研发、产品、运维、测试、安全等人员之间的协作、简化繁杂工具链的运维、加速价值流的流动来实现软件交付效率的提升，同时保证软件研发的安全可靠。

LigaAI 和极狐GitLab 的合作，将构建 AI 时代研发提效新范式。

范式一：研发需求智管理，研发效能新洞察

在需求开发过程中，产品、设计、开发、测试、运维等多个角色需要通力协作，而跨职能团队间无缝的增量传递是提升研发效能的关键。传统需求管理方式中，需求文档撰写、状态更新和同步以及项目进度跟踪常常造成人效的浪费。在 LigaAI 中，产品经理可以通过 AI 自动编写 PRD 文档并补充上下文语境，让 AI 分析需求质量，并一键创建待办需求，快速实现文档与需求的双向联动，不仅提高了文档质量和录入效率，还确保每条需求都有完备的跟踪和记录。

在需求管理方面，LigaAI 也为团队提效进阶赋能，例如智能归集个人待办、自动生成日报/周报、可视化项目进度与风险等等。借助 AI 能力，研发人员能够在海量的需求数据中，快速获取待办、进度、阻碍和风险等重要信息，从而提升决策效率与质量。LigaAI 实现了产研业务一体化协作，为研发提供全新的视角，真正专注于交付价值。

高效的需求管理是软件快速交付的开始。LigaAI 让需求管理变得简单、智能、高效，也会让研发人员对于需求的理解更加透彻，再配合极狐的源代码托管、GitLab CI/CD，让软件研发快速、高质量交付真正落地。

范式二：人机结对智编程，代码交付新体验

编码、测试、评审并合并到主干分支，这是研发人员常见的代码交付流程。AI 可以融入到这个流程中的每一个环节，诸如用 AI 进行代码辅助编写、用 AI 自动生成测试用例对代码进行测试、AI 自动推荐「硬核」审核员对代码进行评审等，XP 中提倡的结对编程，在 AI 的帮助下，得以真正落地实践，这个过程对于效率的提升是不言而喻的。此外，AI 还可以对代码块进行解释，帮助新入职员工或者代码评审人员快速了解代码的背后逻辑。AI 化身成为研发人员的「个人小助理」，实现有 AI 随行，码力无限。

极狐GitLab 本身有完成的 JiHu Flow 来标准化软件研发流程、提高代码质量，同时提升大规模团队的协作和研发体验，在 AI 的加持下，这种工作流带来的效率提升会被进一步放大，价值也会更加凸显出来。极狐GitLab 将用 AI 赋能软件研发工作流，带来软件交付新体验。

简化代码提交操作也是优化用户体验的重要一环。过去，研发人员完成编码后，还需切换到其他工具更新任务状态，这会造成上下文切换和信息同步不及时的问题。LigaAI 通过插件将需求和编码工作关联起来，实现统一管理。现在，研发人员可以在 IDE 内直接查看个人待办和需求详情、同步项目状态，并且利用提交消息功能自动提交代码信息，无需来回跳转，专注于编码创造。

范式三：漏洞风险智化解，安全合规新防护

安全是软件交付的底线，随着软件代码行数、功能的增多，安全风险也在增加，在软件敏捷交付的时代，就需要安全提前介入来确保软件交付的安全性，这也是这几年火热的 DevSecOps 的由来。极狐GitLab 在 DevSecOps 方面开发了大量的功能，不仅引入了大量安全测试手段（7 大安全测试方法） ，还将这些安全手段和内置的 CI/CD 无缝集成，实现变更代码的自动扫描，研发人员或代码审核人员在 MR 中就可以看到扫描出的安全漏洞，并根据修复建议进行快速修复，从而缩短漏洞的修复时长，提高变更代码的安全性。

但是这种情况下，安全报告的解读还是需要专业的安全知识，或者专业的安全人士，漏洞的发现也多在测试阶段。在 AI 的加持下，安全漏洞的发现会更进一步—— 在研发人员编码的时候，AI 就能够识别出代码中的潜在安全风险，并且给出修改建议；而在测试阶段发现的安全漏洞，AI 能够像专业的安全人士一样用研发人能懂的话术对漏洞进行解读，并且给出修复建议，这样不需要其他人员的帮助，研发人员就能够自行解决代码中的漏洞，整个安全漏洞的修复周期是会大大缩短的，代码的安全性也就得到了保证。

此外，项目级安全与风险同样不可忽视。LigaAI 融合大量行业最佳实践，在海量的原生数据中解析出涵盖团队、项目和工程三个维度的诸多核心研发管理指标，全程动态追踪软件交付表现，以 AI 诊断保障项目交付安全。

在项目进程中，产品经理可以根据量化指标数据和基于 AI 的智能建议，掌握团队及项目的健康情况和潜在风险，快速调整策略方向；技术负责人可以从工程角度洞察研发团队的编码表现、任务流转数据及分支处理效率，借助 AI 智能专家提供的诊断建议，提前识别工程瓶颈，精准优化；CTO 能够根据「性能等级标杆」快速辨析组织的研发效能和关键阻碍，而 AI 结合实际情况，提供可行的优化建议，助力项目顺利完成。

写在最后

软件研发领域已经迈入 AI 时代，单纯地使用人力或者传统工具进行研发提效可能会是一件收效甚微的事情，学会利用 AI 的力量来放大传统工具的能量，提升研发效能是 AI 时代每位软件人都需要做的事。而 LigaAI 和极狐GitLab 已经在这条路上做了很多探索，相信两个产品的结合能够为中国程序员及企业带来提供新质生产力的利器—— AI 赋能的企业级软件研发平台。

关于LigaAI

LigaAI 是新一代智能研发协作平台。我们以人工智能技术为核心，致力于通过 AI 场景化繁为简，提升协作效率，赋能广大研发团队。从开发者的具体工作场景出发，LigaAI 通过人工智能将开发者们从繁杂琐事中抽离出来，为其提供简洁、智能的协作体验，也为不同类型的组织提供数字化、个性化、智能化的项目协作平台。

欢迎体验新一代智能研发协作平台 LigaAI，快人一步打造 AI 增效引擎！

日前，LigaAI 与深圳市企业联合会、西云数据联合举办了「AI 驱动增长，研发数智化升级」技术专题沙龙。本次活动围绕「AI+」应用实践，邀请到 LigaAI 联合创始人兼 CTO 张思、西云数据高级解决方案架构师王高雄分享生成式 AI 在具体工作及业务场景中的落地经验；到场嘉宾们还就「智能化手段对研发效能的提升及对企业增长的影响」展开了交流与探讨。

活动特别邀请到深圳市企业联合会康永魁会长出席并致辞。康会长指出，AI 命题紧扣大湾区发展和高质生产力的时代要求，企业探索 AI 驱动力，积极推动新技术在企业研发、管理及业务等领域的应用，将有助于思路启发、视野开拓、技术赋能和管理创新。

活动中，LigaAI 联合创始人兼 CTO 张思作了题为「AI 当道，研发如何驱动企业越阶增长」的分享。他从 AI 应用场景选择到 AI 提效的量化与管理，全面解读了生成式 AI 可以如何为产研团队所用并持续赋能——借助「三环模型」筛选可 AI 化的具体场景，通过 LigaAI 「采集-跟踪-诊断-提升」四步曲量化和优化 AI 效益。

张思强调，AI 技术在工作场景中全方位融合已成为必然趋势，对 AI 祛魅才能更好地让新技术为己所用：Copilot、Auto-agent 和 AI Agent 都是数字化劳动力，其本质都是企业的资产和工具，无需过度「神化」。

西云数据高级解决方案架构师王高雄则带来「生成式 AI 助力企业出海，赋能业务扩张」的精彩分享。他首先介绍了生成式 AI 的最新成果和行业动态，又深入浅出地讲解了 Amazon Bedrock 在助力企业出海方面的场景应用和案例经验。

他指出，生成式 AI 是集高科技、高质量与高效能于一身的重要的新质生产力，而 Amazon Bedrock 已在检索增强（RAG）、虚拟角色塑造、文本分析/生成、图片生成与重塑等业务场景提供支持。

主题分享结束，思维的激烈碰撞正式拉开帷幕。现场嘉宾们围绕行业落地和业务结合经验展开交流和分享，更深入探讨了 AI 及数字劳动力对组织架构、流程优化、人效提升和研发效能等的影响。

活动总结

人工智能无疑是当今时代最具变革性的技术力量，也正在以惊人的速度重塑各行各业的生产协作方式。作为一家以 AI 技术为核心的企业服务公司，LigaAI 相信 AI 技术将为企业带来更多增长机遇和创新动力。

期待下一次相遇，期待与更多朋友一起见证 AI 带来的行业飞跃。

关于 LigaAI

LigaAI 是新一代智能研发协作平台。我们以人工智能技术为核心，致力于通过 AI 场景化繁为简，提升协作效率，赋能广大研发团队。从开发者的具体工作场景出发，LigaAI 通过人工智能将开发者们从繁杂琐事中抽离出来，为其提供简洁、智能的协作体验，也为不同类型的组织提供数字化、个性化、智能化的项目协作平台。

>> LigaAI 往期精彩阅读 <<

宁波银行：在「金融科技」引擎上，沉浸式提效减负

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

过去一年，颠覆性的创新技术和成果频频涌现，外部环境不确定性加剧。在那些或抓马或平凡的日子里，LigaAI 持续分享了许多优质的最佳实践与成功经验，试图为广大研发团队带去一些确定性。

随着 2023 正式汇入时间长河，LigaAI 也整理了这一年中备受好评的重磅文章，并将一整年的创意、想法和思考精炼为 8 个年度关键词，希望与你一起回顾新一年的收获与成长。

01：AI 赋能

2023 年，是 AGI 和大模型空前发展的一年：ChatGPT 点燃全行业对大模型的探索热情，从「百模大战」到应用落地，全世界都为之疯狂。作为一个以 AI 技术为核心且高度重视效率的团队，LigaAI 一直在挖掘「AI 赋能研发提效」的无限可能；在不断强化产品力的同时，我们也听到许多焦虑和质疑的声音：

• 当 AI 可以听、说、读、写、看、画，甚至思考，「我」会不会被取代？
• 类似 ChatGPT 的能力能多大程度地帮助组织提升工作效率？
• 当「AI 布局」成为角逐新高地，生成式 AI 会如何影响产品形态，重塑产业价值？

大模型元年，LigaAI 在反复追问、思考、实践和验证中去虚务实，更加坚定了「用 AI 技术赋能广大研发团队」的创业初心。

《ChatGPT后，B端产品设计会迎来颠覆式革命吗？》

《对话 ChatGPT：现象级 AI 应用，将如何阐释「研发效能管理」？》

《五一特辑 | 人类 vs AI：玩梗大作战，看看谁是最后的赢家？》

02：研发效能度量

数字化时代，提升研发效能，加快高质量价值交付已然是众多企业的核心竞争力和重要目标之一。有度量才有管理——研发管理提效自然也离不开精准可靠的量化指标。

LigaAI 从速度、质量和价值等维度出发，整理并解析了含 NPS、Cycle Time、Lead Time、MTTR 等在内的常见效能度量指标；通过提供一个具象直观的数据管理视图，帮助研发管理者更科学、更全面地洞察组织交付能力，精细化提效增长。

《什么是研发 Lead Time？》

《用Cycle Time做度量，优化研发交付效率成功一半》

《9 个研发质量管理指标，一次理清！》

《质量指标大PK：MTTR vs MTBF，谁是靠谱王？》

03：可持续生产力

毫无疑问，世界正在阔步迈向 AI 驱动的时代。当开发复杂度和研发管理复杂度日渐攀升，「如何让开发工作效率以同等速率跟上增长」或将成为围困组织的灵魂拷问。秉承着「以人为本」的价值观，LigaAI 期望助力企业建立一支健康稳定、敏捷高效、自组织的研发强军，赋能企业维护可持续的研发生产力。

高绩效团队通常具备哪些优势和特点？研发管理者可以如何科学管理及提升组织生产力，并长期维护健康的可持续工作状态？欲知详情如何，且看下列分享~

《高绩效团队的 5 个优秀习惯，看看你占了几个？》

《如何科学判断研发团队是否在健康工作？》

《准AI时代，如何衡量程序员的工作效率和生产力？》

04：业务提效

生成式 AI 有望带来相当于全球行业收入 9% 的新增价值，而工作与协作范式的转变也为突破增长困局带来转机。行业新贵频出，企业换代速度加快让「理解业务，稳定增长」成为企业生存的第一要义，也给研发团队提出了更高的要求。

作为离前沿技术最近的部门，研发团队必须为「如何充分释放 AI 和工具的潜力并为企业创造业务价值」递上一份令人满意的答卷。关于软件工具和 AI 能力的驾驭技巧，LigaAI 有话要说。

《宁波银行：在金融科技引擎上，沉浸式提效减负》

《论 PMF 和结果导向如何影响组织效能？》

《生成式 AI 如何释放开发者的生产力？》

05：技术管理进阶

“要做企业和研发团队的陪跑者”，LigaAI CEO 周然如是说。任何企业和组织都离不开管理者，而在「技术晋升管理」相当普遍的研发领域，两眼一抹黑的无所适从却才是新晋管理者的工作常态。

围绕「技术管理进阶」，LigaAI 创作和分享了一系列干货文章，全面拆解了从技术到管理、从「管事」到「管人」的常见难题及解决办法，以帮助更多（准）技术管理者更快、更好地开展新工作。

《压箱底的技术管理成长经验分享，请收好！》

《新晋技术管理者如何推动组织变革？》

《向上管理：三个技巧，教你如何与老板高效协作》

06：技术狂欢

将工程师文化贯彻到底。这一年，LigaAI 持续分享了多篇技术解决方案，并有幸在多个开发者社区获得程序员朋友们的广泛认可。在坚持做知识沉淀和技术交流的日子里，「看见自我成长」也荣登我司开发者们的「成就感榜单」榜首。

稳住心态做研发，静下心来搞技术。未来，LigaAI 还将继续以「为开发者社区添砖加瓦」为己任，持续分享技术博客，坚定务实地向上生长。

《72小时灵感冲刺，创意就该这么玩 | Hackathon特别策划》

《前端进阶：如何在 Web 中使用 C++？》

《如何编写同时兼容 Vue2 和 Vue3 的代码?》

《ChatGPT API 调用总超时？解决办法在这》

07：SaaS 出海

2023，中国企业出海火热依旧。与往年 ToC 产品引领出海不同，这一年越来越多 ToB SaaS 企业主动地在国际化市场寻找第二增长曲线。

出海掘金潮下，LigaAI 不由地好奇国内外市场需求是否「有壁」？一个主要由中国人组成的研发团队如何提升组织能力，才能快速响应和服务国际客户的需求？为此，LigaAI 专门向拥有国际化基因的出海领先企业讨教了一番。

《SaaS 出海，如何搭建国际化服务体系？》

08：价值驱动

价值，是过去一年在我司出现频率最高的词汇，没有之一。三年多来， LigaAI 回答得最多的问题是「和其他研发管理工具相比，你们有什么不同？」ChatGPT 带着 AI 飓风席卷全球后，LigaAI（一家「标榜」以 AI 技术为核心的公司）难免被频繁地问到「你们的 AI 能做什么？」

三周年那天，我们正式向大家告白「LigaAI 为什么而存在？」——颠覆低效的研发协作模式、消除顽固的研发管理盲区、建立起以科学度量和精细化管理为基座的价值交付舰艇，智能化赋能研发管理。

《LigaAI：从效率、度量和价值维度，成为研发团队的智能医生》

写在最后

2023，变化依旧是时代主旋律。经历增长放缓、「AI 入侵危机」和「出海淘金记」等时代巨制后，LigaAI 反而能更加专注且坚定地关注自我跃升，向内生长、向外突破。

这一年，我们更坚定要用 AI 技术赋能研发团队；

下一年，我们还将继续以 AI 技术赋能企业成功。

2024 赋能研发提效，LigaAI 步履不停！

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

（小剧场：某天午饭时间）
“最近怎么有这么多会议！上午开了两个小时的会，需求又做不完了 。”
“别提了，我今天排了三个会，根本没时间处理其他工作，还不知道几点能下班呢……”

根据微软对全球 31, 000 名员工开展的一项调查，低效的会议是影响工作效率的第一大干扰因素，其次是召开过多的会议。

大大小小的同步会、讨论会、审查会、复盘会不仅将工作时间拆解得支离破碎，还会让成员因「会议恢复综合症」而无法立即从无效会议中恢复过来，重新集中注意力投入工作。无法打造沉浸式工作时间，维护深度专注状态，极大地影响了个人和团队的工作效率。

为了克服会议疲劳，Shopify 在今年一月份宣布取消所有三人或三人以上的定期会议，并禁止周三举行所有会议。该举措涉及大约 12, 000 次的日程安排和活动，相当于节省了 322, 000 个员工工时。

大刀阔斧地砍掉会议是不是提高团队效率的灵丹妙药？ 或许，首先要弄清楚「我们为什么要开会？」

我们为什么要开会？

我们为什么要开会？

这个问题看似简单，但却值得深思。我认为开会是为了推进工作、完成工作，尽管实际情况并不总是如此（或者说，通常不是这样），但会议声称旨在推进目标、完成工作、共享信息、做出决策，或者至少要以一种异步沟通无法实现的方式取得进展。

毕竟，这就是会议的独特之处：大家聚在同一个物理或虚拟空间里，能够进行实时对话。这应该是非常高效的——不是文档或邮件、没有滞后的反馈信息，只有进展。

我们选择开会，因为这是更好的协作方式。

以上是会议应该达成的目的，但却不是我们开会的真正原因。你是否也曾对着自己的日程安排感到沮丧和无奈？因为你充分意识到自己会在一种效率极低的状态下忙得不可开交，却对此无能为力。我有过，那真的太糟糕了！

这种看似无解的「会议滥用症」，实际上是其他更糟糕的问题的表征。

问题一：协作流程支离破碎

频繁开会是流程瓦解的表现。我们把开会当成倚仗和退路，每当不知道该如何完成工作，或者不愿意投入真正能够推进目标的流程时，就安排一场会议。我敢打赌，那些对流程嗤之以鼻或者不愿参与其中的管理者们，正是导致会议泛滥的元凶。

问题二：对工作内容一无所知

频繁开会也是对工作内容茫然不知的表现。这通常是因为没有人愿意花时间弄清楚并解决这个问题。

我们将「会议」与「生产力」混为一谈，如果不开会，就不知道该做什么（或者不知道如何证明自己的工作价值）。 于是，我们说服自己「开会就是我的工作内容」，或者「无法提高工作效率是因为我没有参加会议」。即便真的是这样，那也更像是对会议的控诉，而不是疯狂开会合理化的理由。

问题三：职场权斗的必然结果

频繁开会也可以是权力斗争的表现。「接连不断的会议邀请不就说明‘我很重要’吗？每个人看到我满满当当的日程表都会这么想的。」

这种情况下，在踏进会议室的那一刻起，会议桌上的位置就比任务完成的实际效果更重要了。

是时候该反抗了！

几年前，当我意识到自己究竟在为什么而开会（还参加了如此多的会议）后，我开始了「会议抗争之旅」。

我拒绝参加那些我认为无须出席或者浪费时间的会议；我取消了所有单纯为了彰显身份地位的会议。 我深刻意识到我拥有着怎样的特权——大多数人都不能直接取消或拒绝出席会议。

我分享这个经历，是因为它让我认识到会议对我们的影响。虽然花了六个月的时间，但我逐渐将会议减少到原来近一半的数量。作为团队负责人，我本该频繁地参加各种会议，但我没有。

与我的同事和大多数直属下级相比，我参加的会议要少得多。坦白说，一开始的感觉并不好，我觉得自己一天什么事都没干成，总害怕错过什么；我担心砍掉会议实际是搞丢了自己的工作。但慢慢地，我意识到我为自己创造的所有时间都是一份礼物。砍掉会议并不代表与团队脱节，而是可以着手解决潜在问题的信号灯。 我有更多时间思考、设计、做出贡献，还可以处理那些需要我的问题。

我仍有一半以上的时间穿梭在各个会议室，但在这些会议中，我变得更加专注，准备也更加充分。我能够花更多的时间进行有效沟通，虽然会议减少了，但高效的即时通话增加了。

为了达成这一目标，我不得不重新学习一些东西，但我意识到砍掉一半的会议是一种提高管理效率的策略。

「会议滥用症」的疗愈之法

我对自己的日程安排有一定的控制权，但并不是每个人都能这样，而且一个人的日程表也不能解决真正的问题。一个急需解决的结构性问题是，管理者该做什么？

大多数人指出，优化会议规范是解决办法。问题的关键不在于会议过多，而在于「无效会议」太多，即会议效率低下。如果能够提前发送议程、阅读材料，并严格控制会议节奏和进程，那么所有会议都将变得极其高效。

我非常喜欢这个想法，但我从未见过它真正奏效——可能是因为这种方式就像在用创口贴和消炎药治疗复合性骨折。不过，如果你认真对待它，了解真正的隐藏病灶，或许能够摆脱「会议滥用症」。

下面是我实践过的具体做法。

最重要的治疗方法是建设优秀的流程。
无论你在做什么——产品、营销、研究、政策或服务——你都需要一个清晰的、完整的、端到端的流程路径将它实现。否则在此之前，你可能会陷入会议泥潭。

开会就像用仅有的锤子砸东西——用它，是因为没有其他工具了。良好的流程应该是轻量的、高效的、有强适应性的。 你需要清晰的项目计划流程以及井然有序的全功能产品开发与设计流程；你还需要专门负责处理这些事务的项目经理。一个优秀的项目经理可以通过减少会议，证明自己的价值。

你还需要改进开会的方式。会议中存在许多浪费时间的情况，以下是三个减少会议时间浪费的技巧。

1. 专注实时讨论，提高会议质量

用其他方式完成所有与高质量开会无关的事情。会议的独有优势是可以展开实时讨论，所有与此无关、与会议无关的部分，比如更新、参考信息同步、文档整理、幻灯片更新等等都应该去掉（全员会议和庆祝活动等文化会议除外）。

在取得项目进展上，实时对话和讨论比其他任何方式都更加高效。

2. 开门见山，才是高效的开始

立刻解决最难的问题。在会议开始的 5 分钟后，请开始讨论最困难的问题。我参加过很多长达一小时的会议，其中大部分是在前 55 分钟浪费时间，直到最后 5 分钟才进入重头戏。那为什么不直接从这开始呢？

3. 有效的会议，离不开信息透明

关于会议规范，有一点我完全认可——会议总结与共享。你需要记录会议纪要，然后同步给所有人。如果一个会议产出了决策，但没有让该知道的人都知道，那还算有效开会吗？

以前，我曾专门开会了解其他会议的情况……不能重蹈覆辙了，真的！

写在最后

即使你无法控制所有会议，了解会议泛滥和滥用的原因及解决方法也非常有用。你可以为解决「会议泛滥」创造条件，采取行动使会议变得不再必要，并让每一个人都注意到这点，还可以对自己的日程安排有更多的掌控权。

请记住，除了极少数的例外，你的本职工作不是参加会议，而是取得进展，达成目标。如果开会是你知道的唯一实现途径，那么你将不得不安排一次会议来讨论这个问题。

（原文作者为 Judd Antin，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

宁波银行：在「金融科技」引擎上，沉浸式提效减负

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

将金融科技作为重要生产力，宁波银行坚持深化科技与业务融合，是金融行业数字化转型的典范。在研发流程数字化建设早期，宁波银行率先实现从代码提交到发版上线的一体化升级。伴随业务水平和企业目标的发展，「研发全流程数智化管理」被提上日程，而为研发协作而生的 LigaAI IDE 插件正是打通需求到开发，搭建价值流「最后一公里」的重要一环。

围绕沉浸式、自动化和精细化三个目标，宁波银行与 LigaAI 基于「奋进号」平台，联手打造「LigaAI IDE 提升项目」。 通过减少个人时间浪费、抹平团队协作障碍，为行内开发者打造沉浸式工作体验，以数据驱动赋能研发管理。

01 LigaAI IDE 插件：沉浸式工作，小改善有大跃升

走在行业数智化建设前列，宁波银行也面临着研发流程信息化的伴生问题：项目信息和开发工作分散在不同工具中，研发人员需要在多个系统和平台间反复跳转才能查看需求、管理和跟踪研发工作。 开发者的工作节奏被迫打乱，无法专注思考和编码，而依赖手工更新状态既无法保证时效，还会在上传下达中浪费研发资源。

LigaAI IDE 提升项目无缝连接需求管理与代码管理，覆盖 IDEA 、Android Studio、VS Code 和 Eclipse 等宁波银行所需的集成开发环境（IDE），以插件形式为研发人员打造沉浸式个人工作空间。得益于 LigaAI 为其特别定制的工作类型、详情字段和关联管理等，开发者们无需切换至奋进号或 IM 工具，在 IDE 内就能直接查看个人待办工作、了解完整的需求详情、掌握项目进展、更新和传递需求状态、提交反馈和评论，高效管理每日工作。

LigaAI IDE 插件实时同步项目更新与变更，不仅增强了高价值信息的流通性，还让开发者免受工具切换、思路阻断的困扰，最大程度保障了充足的专注时间，释放更多生产力。

改善工作体验少不了「沉浸式代码评审」。基于奋进号的开放能力，LigaAI IDE 插件将代码托管平台的能力嵌入 IDE，不仅支持 MR 的快速创建和自动关联，还支持记录和查看代码修改详情，通过将代码差异与详情以清晰直观的方式统一起来，帮助开发者高效完成代码评审，提升整体工作效率。

02 LigaAI IDE 插件：自动化提效，攻克协作信息差

安全、合规和风控是金融科技发展和创新的底线，对宁波银行而言，研发流程规范和审核制度再怎么严谨都不为过，但这难免会给力求高效和流畅的研发协作带来「小烦恼」。

以代码管理为例，宁波银行在探索实践与持续改进中，对创建/合并分支、提交代码、代码评审等环节提出了明确的操作要求和规范，还设置了多个如代码关联核验的检查节点和质量管理门禁。

过去，开发者们需要自行根据工作类型及分支命名规范，手动为每张卡片创建和拉取分支。 如果遇到突发的缺陷或事务，即便能够快速编码，也常常会因为卡片信息缺失或分支命名错漏而流转受阻。

现在，有了 LigaAI IDE 插件将整个过程智能化，开发者可以在 IDE 内快速创建卡片和分支，自动关联开发任务或事务，并自动填充需求信息。 在简化操作路径的同时，LigaAI IDE 插件用强大的自动化功能代替手工创建及填报，提高研发进程中信息的准确性和及时性，为高效协作打下基础。

提到代码关联管理，研发平台负责人彭老师告诉 LigaAI，行内开发者提交代码时，如果未按要求提供卡片、人员等信息或者提交了错误的信息，都会导致 PR 失败；同时，受到卡片变更规则和质量管理门禁的约束，回退代码也不容易。

因此，研发人员通常会从提前整理好的文档或者已提交的代码中复制模板，再手动替换内容。即便如此，信息错漏导致的提交失败和返工依旧时有发生。

从开发者的具体工作场景出发，LigaAI IDE 插件「智能 Commit Message」功能很好地解决了这个问题。借助 LigaAI 模板化和自动化的能力，开发者能轻松实现代码与卡片的精准关联，有效改善因信息错报、漏报导致的返工和浪费，为后续顺畅的研发协作提供保障。

03 LigaAI IDE 插件：精细化管理，击破效能瓶颈

践行数智化管理，研发效能度量体系和可视化分析是强有力的臂膀，宁波银行深谙此道。由于行内业务繁多、开发者们使用的 IDE 种类不一，且 IDE 原生能力无法满足组织对数据和权限的复杂要求，宁波银行曾受限于缺失的开发数据和时效滞后的进度信息，难以有效开展有据可查的管理赋能。

引入 LigaAI IDE 提升项目后，宁波银行在奋进号原有的 DevOps 能力基础上，补全了「需求管理 – 代码开发」的价值链路，全面打通端到端数据采集通道，真正实现研发全流程数据留痕。

利用真实完整且实时同步的团队过程数据，管理者可以构建可靠的数据分析闭环，并根据目标与愿景确定度量指标；结合「可视化效能视图」和「数据洞察面板」，还能快速洞悉关键指标的变化趋势，甄别异常与潜在风险，及时制定针对性优化策略，精准打击效能瓶颈，提升研发效能。

LigaAI IDE 插件优秀的一手数据采集能力同样备受组织流程规范的青睐。 以制度性的「工时登记」为例，开发者通过插件内嵌的「报工」功能，在编码完成后即可填报/补报实际工时和工作内容，无需担心忘报、漏报。管理者基于及时同步的一线反馈，也能更合理地分配团队资源，提高组织的风险管控能力。

写在最后

数字经济时代，金融数智化转型已成为广泛共识。积极发展金融科技，加快推进数智化转型是金融行业的时代快车。

在 LigaAI 的助力下，宁波银行通过数智化建设探索「如何将有限的研发资源投入在更高价值的需求上」——以人为本，沉浸式体验释放生产力；化繁为简，自动化刷新协作效率；数据驱动，精细化赋能效能提升。

在提质增效的浪潮中，宁波银行将持续加大金融科技资源投入，全面推进数智化金融服务改造，加速系统化、数字化、智能化布局落成，持续优化客户服务体验，更好地赢得客户、服务客户、经营客户。

未来，LigaAI 也将与宁波银行一起，持续探索更多数字化、自动化和智能化落地空间，帮助其抢抓金融数智化转型机遇，全面为企业提效减负。

减少个人时间浪费，抹平协作障碍，赋能企业提质增效，欢迎使用 LigaAI 智能研发协作平台。