Atlassian 最具争议的增长决策｜Mike Cannon-Brookes

摘要

• Atlassian 的可服务市场远不止开发者工具：超过一半用户从事的并非技术岗位。 Cannon-Brookes 对品类的定义是经过刻意设计的：「我们解决人的问题，不解决技术问题。」Jira 从2002年的缺陷追踪工具，演变为问题追踪器、路线图系统和连接技术团队与财务、人力资源、销售、市场等业务团队的通用工作流引擎。

• Cannon-Brookes 认为，AI 会压缩业务流程，而不会让工作流软件消失。 Agent 会从流程图中移除单个方框和分支，但相关文件、链接、评论和输出仍会重新进入流程，接受审核、审批或进一步自动化。他的逆共识判断是：AI「是加速器，不是替代品」（“an accelerant, not a replacement”）。

• Rovo 之下真正的战略资产，是一张具备权限感知能力的「团队协作图谱」，包含超过1000亿个对象和连接，环比增速超过50%。 这张图谱自2019年起由连接 Atlassian 产品和外部 SaaS 应用的链接构建而成，为企业搜索、上下文理解、排序和 Agent 行动提供底层能力。已有超过350万人每月使用 Atlassian 的 AI 功能：「我们不想营销 AI，我们想把它交付出去」（“We don’t want to market AI; we want to ship it.”）。

• AI 显然正在提升从任务到代码的速度，但 Atlassian 拒绝把代码生成变快等同于客户价值，甚至拒绝将其等同于已经实现的生产力提升。 编码约占开发者每周工作时间的1/3，而生成式代码会把工作转移到重建心智模型和审核输出上。考虑到高 token 消耗工具可能让每名开发者花费数千美元、让 Atlassian 每年支出数千万美元，DX 将量化交付指标与定性调查结合起来，以寻找真实 ROI。

• Atlassian 的应用层战略，是提供上下文并选择模型，而不是把产品押注在单一模型供应商上。 其生产级 AI 网关运行着超过75个模型，Rovo Dev 在一项典型任务中可能调用2至3个模型，包括 Claude Code 或 Gemini。一个值得注意的内部用例不是从零创建产品，而是对超过500个代码仓库进行 API 变更——大规模「割草」（“mowing the lawn”），让工程师重新回到「景观设计」（“landscape architecture”）。

• Cannon-Brookes 既不接受开发者大规模被替代，也不接受只有资深工程师才能继续就业的判断。 他预计5年后 Atlassian 会雇佣更多开发者；让1名资深工程师搭配4至5名经验较少的工程师，仍有持续存在的经济价值，而 AI 可以放大后者的产出。责任仍由人承担：无论代码由 Rovo Dev、Cursor、Claude Code 还是 GitHub Copilot 生成，提交或审批代码的人都对其负责。

• Atlassian 的经营准则是「把增长周期拉长，而不是追求更快增长」，即便公司最新披露的营收增速约为21%、云业务增速为26%、RPO 增速为40%。 Cannon-Brookes 希望5年后仍能实现超过20%–30%的持久增长，而不是为了眼前营收，把所有可用资金都花在一个季度上。他给投资者的关键判断是：公司是在播种未来需求，还是只是在收割过去的工作，直到「田地荒芜」。

精读

上游暂未提供，后续同步将继续补齐。