作为一家全球化团队的 CTO，我如何管理团队，以及工具快速迭代背后的经验教训

[user7]

我们的产品

作为联合创始人，我所在的 Jina AI 是一家商业化开源软件公司，我们专注于打造针对多模态应用的 MLOps 工具，成立两年多来，累计融资 3750 万美金，连续两年登上 CBInsight 全球 AI 初创排行榜前 100 。

我们先后发布了包括 Jina、DocArray，Clip-as-servie，Dalle-Flow 等多个开源项目，累计超过 35k GitHub 关注。在这些成绩背后，是我们来自于十几个国家的全球团队，和我们围绕开源理念打造的工程师文化。

分布式

作为⼀家开源软件公司，我们把分布式开源协同作为我们⼯程师⽂化的基⽯。

分布式：分布式⼯作的关键在于信任和责任。

• 我们采取全球化招募的策略，不限制⼯作地点，不限制⼯作时间。对所有团队成员，我们允许⼤家每年有 30 天的时间申请远程办公，每周可以有 1 天居家⼯作。这背后其实是我们对于团队成员的充分信任和以解决问题为导向的价值观。我们不在乎团队成员是否每天⼯作 8 ⼩时，也不在乎解决⽅案是哪个级别的⼯程师提出的，我们只在乎问题有没有解决。只有可以解决问题，我们就会欢迎加⼊。

• 要实现分布式⼯作，很重要的是强调⾃驱⼒。⼤家会问难道你们分布式⼯作就没有员⼯摸⻥么？肯定会有，这也是为什么我们在试⽤期期间的离职率会相对较⾼。我们会在⾯试和试⽤期阶段充分的考察候选⼈的⾃我驱动⼒，不合适的成员我们会毫不吝惜的放弃，并不是说他们不优秀，⽽是他们不适合我们的⼯程师⽂化。

• 分布式协作的另⼀个关键词是责任。我们⿎励每⼀名团队成员都承担责任，都成为决策者。我们的每个⼩团队都有充分的⾃治权利，从技术选型到维护服务，从撰写⽂档到吸引社区客户，每个⼩团队都要对⾃⼰的项⽬负责任。同时，我们不会让团队成员为错误买单。因为每个⼈都会犯错误，初创企业其实就是⼀个⼜⼀个错误⾛过来的，我们强调的是尽量少犯错误，不犯相同的错误，及早发现类似的错误。

开源

开源不是把代码发到 GitHub 就结束了，开源是⼀种协作⽅式。

我们内部所有的代码都是全公司可⻅的，绝⼤部分代码也都是开源的，整个世界的程序员也都可以看到。所有⼈都可以去做 Code Review ，所有⼈都可以随时去给任何⼀个项⽬去修复 Bug 和提 PR 。这样的开源协作⽅式不仅提⾼我们内部的交流效率，同时也能充分发挥每个⼈的主动性。因为这样的⽅式类似于每个⼈都在公开的⼯作，⼤家⾃然⽽然的会对代码质量提⾼要求。《⽣活⿊客》这本书⾥也提到过这样公开⼯作的⽅式⾮常有利于提升⼯作效率和按时完成⽬标。可能有⼩伙伴会问我分享出去不久让⼤家都学了我的独⻔绝技了？但是，我很赞同的⼀个观点是，我们这个时代缺少的不是知识，⽽是专注⼒和意志⼒。⽽别⼈的注意⼒能帮助提⾼⾃⼰的意志⼒。通过开源这种公开的⼯作⽅式，其实每个⼈的意志⼒都会提⾼，也更有可能完成⼯作。

• 开源也意味着分享。每个星期的我们都会有公司内分⼯程团队的享，每个⽉的⼯程团队还会和社区分享我们最新的进展和社区⼀起讨论问题。分享的作⽤不仅仅在于分享知识，更在于帮助⼤家形成定期思考和总结的习惯，从⽽不断的去⾃我提升和改善产品。

• 开源的另⼀个常常被忽视的动作是要经常性的发布新版本。发布新版本不仅仅是为了保持快速的开发节奏，⽽且可以⿎舞团队的⽃志。

协同

协同的核⼼是标准化、⾃动化，减少能量耗散，让团队更关注核⼼代码。

- Code Review 是我们对每个⼯程师的要求。在 Jina AI ，每个⼈每天都会有固定的时间去 Review 其他成员的代码。我们在内部设⽴的各种⽅便搭建 AFR 的的机制，包括 Team Alias ，Slack 提醒，合并前强制 CR 等等。

• 多次 Commit ，尽早提 PR。我们对每个新⼊职的成员都会要求尽早完成⼀个 PR 。我们强调 PR 的 merge 才是⼯作的结束，我们会要求 PR 要尽量在 2-3 个⼯作⽇内合并。尽量避免⼤型 PR ，⿎励多个⼩ PR 。因为代码库是对全公司开放的，每个⼈都可以 CR ，也可以参与讨论。这样帮助初级⼯程师快速成⻓，同时讨论也能够迫使⼈去思考代码的实现是否合理。

• 统⼀的编程⻛格。我们强制进⾏⾃动化的代码⻛格检查。

• 提⾼协同效率的⼀个关键是尽可能⾃动化⼀切流程。我们⾼度依赖 GHA ，有⾃动化的版本发布，有⾃动化的 Release Notes ⽣成，⾃动化的⽂档⽣成，⾃动化的代码⻛格检查等等。

• ⾃动化的另⼀个要求就是尽可能多的写测试。我们⾮常强调测试的覆盖率，要求项⽬的覆盖率都要在 75% 以上。充分的测试才能保证我们能够⾼频次的发布和流程的⾃动化。

踩过的坑

上⾯聊完我们的成功经验，下⾯也说说我们犯过的错误。

• 分布式⼯作的前提是，能够得到及时反馈。GitHub 这样的⼯具的确是帮助我们实现了异步分布式的⾼效协作，但是我们也看到这样的协作⽅式也有失灵的情况。尤其是团队成员⻓时间不能得到有效的即时反馈，这会严重影响⼠⽓和员⼯的成⻓速度。

• 沟通能⼒是分布式办公的前提。并不是所有优秀的⼈都适合分布式办公，我们招聘过⼀些优秀的程序员，但是因为沟通能⼒不⾜，很难和其他成员进⾏远程协作。更重要的是，物理的间隔让彼此的信任很难建⽴，如果沟通能⼒再差⼀些，就会让双⽅基本不太可能建⽴起信任。

• 管理者⼀定要在试⽤期内确认成员是否符合公司的⼯程师⽂化。如果不适合，⼀定要果断决策。“hire, develop and cut smartly, so stars are in every position". 我们的⽬标是让每个⼈都各司其职，各得其所。⽽不是假仁慈，让优秀的员⼯离职。

从神经搜索到多模态应⽤

⼯程师⽂化对于科技企业是维持⾼效率的关键。作为 Jina AI 的核⼼项⽬之⼀，Jina 在过去两年的时间内已经完成了三个主版本的迭代，迭代背后其实就是我们⼯程师⽂化在⽀撑。我们的⼯程师团队会积极回复社区提问，也会认真的总结反馈，我们的三次迭代都是根据⽤户反馈进⾏的⾃我升级。我们⽤了 8 个⽉的时间发布 Jina 1 ，发布后收到很多反馈说东⻄好⽤，但是学习曲线太陡峭，学习成本太⾼。所以我们很快的做出调整，简化概念，优化设计，在 6 个⽉后推出 Jina 2 ，社区反映热烈。Jina 2 推出后，我们内部的⼯程师留意到开发者在部署到⽣产环境时的困难，主要是因为我们对于 Kubernetes 不能做到原⽣⽀持。于是我们⼜开始了第三次重构，在重写了两万多⾏代码之后，我们发布了 Jina 3 ，也迎来了我们社区增⻓的⼜⼀个⾼潮。

截⾄⽬前，Jina 代码仓库已经累计收获 GitHub 上的 16,370 开发者的收藏。从 Jina 0.0.5 到 Jina 3.10.1 ，我们⼀共发布了 360 个版本，累计新增代码 88,240 ⾏，删除 18,309 ⾏。除了代码的快速迭代之外，我们的⽂档⽔平和社区问答的活跃度也得到了社区的普遍认可，⽽我们并没有专职的⽂档撰写和社区论坛维护⼈员，这些都是⼯程师在⽇常⼯作中主动完成的。

在 Jina 3 之前，我们把⾃⼰定位在神经搜索领域。在开发 Jina 3 的过程中，我们内部的⼯程师也注意到我们底层⽤于封装多模态数据的数据结构其实⾮常通⽤，完全可以当做⼀个单独的⼯具使⽤，于是⼀个新的项⽬ DocArray 应运⽽⽣。随着 Jina 3 和 DocArray 的推出，我们的社区⾥开始衍⽣出很多 MLOps 相关的应⽤，包括有社区⼩伙伴⽤ Jina 去搭建 NLU 平台，我们⾃⼰也尝试⽤ Jina 和 DocArray 去搭建⼀些⽣成 AI 的应⽤，推出了 Dall·E Flow 和 DiscoArt 这两个开源项⽬，也获得了⾮常⼤的成功，纷纷冲上了 GitHub 的全球 Trending 排⾏榜。在最近，我们也尝试和⽤ Jina 去搭建了基于 Whisper 模型的语⾳到⽂字⽣成 AI 应⽤。

总结

从神经搜索到 MLOps 平台的演化背后，我们内部强调快速开源协同的⼯程⽂化发挥了⾮常⼤的作⽤。

了解 Jina AI

• 官网：jina.ai

• GitHub：get.jina.ai

• 文档：docs.jina.ai