很多年前在当时的公司（那会还没自己创业），带的产品部门和设计部门加起来有小 100 号人。

团队协作上我当时定了个规则，别的部门我管不着，但我的部门成员：任何人都不允许私聊业务问题，也不允许设置私有的 channel。所有的业务讨论都必须在公开 channel 里进行，无论是否与其他人直接相关。

背后的思考主要有以下几点：

1. 产品团队的管理特性
产品和设计团队（尤其是产品经理）是最难管理的群体之一。他们的工作不像研发体系那样可以完全标准化。
(a) 他们的工作中包含大量的理念、规划、想法、对错判断和讨论思考。
(b) 这些内容多是非结构化的，产品经理日常大量的时间并不一定是在追求短期结果，但非常重要，值得被频繁、深度地思考。
(c) 当产品经理多了以后，管理大家的想法、确保我的理念能传递给所有人，就成了一件至关重要的大事。

2. 业务域的高度耦合
一个中型项目过去往往按业务域分工，但不同业务域之间的耦合度其实非常高。你以为只是某一块业务的问题，但推进到开发阶段时，往往发现其他业务域的人也必须被 involve 进来。

3. 管理者的掌控感需求
作为管理者，我们需要一种掌控感。这种掌控感并不是说所有关键进度我都要了如指掌或由我确认，而是说：
(a) 哪怕你最后只给我一个结果，我也要看到这个结果形成的过程。
(b) 你们是怎么思考的？决策依据是什么？判断优先级的逻辑是什么？
(c) 这个过程我至少要能看得到，这样即便我去纠正，我也能知道你是因为什么原因、在哪种思考方向上走偏了。

如果能让我在关键节点参与进来，我会觉得更踏实，因为人都需要这种掌控感，所以下属有时候利用管理者的这个心理能拿到更好的 “结果”。

那阵子还看到 GitLab 内部的一个 remote playbook，提到他们 CEO 的 OKR 里有一个很重要的 KR，叫作“减少组织内私聊率”，我当时非常有共鸣。

现在大家都在讨论 AI native 时代的组织协作方式，也有蛮多产品，有意思的是，这些产品发布的时候老想制造对立。

比如Slack 是旧世界的，需要一个 AI 时代的 Slack；Notion 是旧世界的，需要一个 AI 时代的 Notion；Linear 是旧世界的，现在需要一个 AI 时代的 Linear。

但你要是真问这些产品的创造者，背后对于组织协作的理念和思考到底是什么，其实也挺难让人买账（buy-in）的。

我们现在创业团队的做法是，日常主要使用两类工具：一类是 Slack，一类是 Linear。

1. Slack：整家公司的“组织面板”
(a) 在过去非 AI 时代，Slack 承载的最大价值是人与人之间的交流，价值点比较杂
(b) 现在我们把它更多定义为组织内的面板，它的价值变得更窄，但更深了。首先是“吹水”的价值，聊些乱七八糟有的没的，当成内部论坛也行；其次是资讯聚合器：谁看到了哪篇文章、哪个帖子或哪个有意思的项目，把链接分享出来；再就是“业务讨论”：这些讨论不需要当下立即有结果。当然，所有的讨论还是不能私聊，甚至不能当面聊，哪怕两人对面坐着也得 Slack 公开 channel 里聊。

2. Linear：是在 Slack 这个组织面板下的，它是短期内要有结果事项的触发器。譬如谁在某个地方提到了任何一件事，就创建一个 Issue 给 Linear
(a) 配合 Hermes Agent，它会调用每个人本地的 Runtime 来写代码，最后再通过 PR 把结果 push 到 Slack 里面
(b) 在整个过程中，我们不像过去传统方式那样使用 Linear

此外，Slack 存在的另外一部分价值是每个人维护自己 Coding Agent 的 Specs 和 Rules，也算是所谓的 Harness 的一部分吧。

AI Native 的组织协作这个话题很有意思，最近跟人交流比较多，懂得的人自然都懂；不懂的人，心里互道一声傻逼，反正 dddd 吧。😂