50 人以内团队做协作诊断：数据准备清单

诊断结论的可靠性上限，在你整理数据的那一刻就定下了。模型能做的只是把你给它的关系如实算出来——数据里丢掉的维度，结论里找不回来。

这份清单覆盖必须准备的字段、可以省略的部分，以及最容易让结论失真的四个坑。

为什么是 50 人

先说明规模边界。协作网络分析有一个不随工具改变的物理限制：节点过多时，网络图会退化成一张"毛球"（hairball），密度、中心势这类结构指标也随规模失去区分度——两者都在趋同。

超过 50 人的处理方式不是硬撑，而是按项目或子团队拆成若干 50 人以内的小组分别诊断。这通常还更准：跨项目的协作模式和项目内的协作模式本来就是两回事，混在一张图里会互相污染。

必须准备的四个字段

关系数据的每一项（一条边）至少要有这四个字段：

字段	含义	缺了会怎样
from	发起方	分不清谁主动谁被动，瓶颈与被孤立无法区分
to	接收方	同上，有向信息是判断协作质量的关键
channel	渠道类型	不同渠道的信息密度与处理成本不同，混在一起会让权重失真
count	频次或强度	只知"有往来"不知"多频繁"，密度与中心性会失真

再加一个时间维度，二选一：

• timestamp：适合连续采集，能做趋势
• period：适合手工整理，比如"2026 年 8 月"

没有时间维度就做不了趋势分析，只能看到当下这一张快照。而结构变化往往比结构现状更有信息量——某个通道从有到无，抵得上十条"某某沟通较少"。

可以省略的部分

• 内容。 不需要，也不该要。详见我们另一篇关于数据边界的说明。
• 精确权重。 同一条边填 12 次还是 13 次没有区别。手工整理时按量级给（如 1 / 3 / 10 / 30）比填精确值更诚实，也更快。
• 单次交互的时间戳。 除非你要做精细的节奏分析，否则按周期聚合就够。
• 岗位与级别。 对结构诊断没有帮助，反而会诱导人把结构问题读成层级问题。

四个最容易踩的坑

坑一：交了一张无向无权图

只写"谁和谁有关系"，不写方向和频次。

这是最常见的偷懒，代价也最大：它直接抹掉了本清单里最有价值的两个维度。同样一条产品与研发之间的线，"产品找研发 20 次、研发找产品 0 次"和"两边各 10 次"是两种完全不同的组织状态，无向图里它们长得一模一样。

坑二：把渠道压成一条

把所有往来合并成"沟通"一个渠道。

事实上群聊、邮件、会议、工单的信息密度、留痕程度、处理成本都不一样。合并之后，一个"每天三场会"的团队和一个"每天三百条群消息"的团队可能呈现出相同的边权，但它们是两种问题，需要两种解法。

坑三：时间窗选得太短或太长

• 太短（一周以内）：会把偶发事件当常态。某个人恰好休假，图上就多出一个孤岛。
• 太长（半年以上）：会把已经解决的旧问题一直算在账上，也会让最近的变化被历史平均掉。

建议 3 到 6 周，且最好避开明显的假期与发布高峰。做完一轮之后，下一轮用同样长度的时间窗，两组数据才可比。

坑四：引用了未声明的成员

关系里出现了 from 或 to 指向一个没有在成员清单里声明的 id。

后果不只是那个节点显示不出来——它会让真实的节点数与成员数不一致，密度的分母算错，进而影响所有基于密度的判断。整理完之后一定做一次交叉核对：关系里出现的所有 id，都能在成员清单里找到。

整理流程建议

1. 定范围。 一个项目或一个子团队，不超过 50 人，明确时间窗。
2. 列成员。 先出成员清单，给每个人一个稳定的 id。角色字段留空也没关系，填了更好。
3. 采关系。 只取元数据：谁、向谁、什么渠道、多少次、什么时间。
4. 交叉核对。 关系里的 id 全部能在成员清单里找到；成员清单里没有从未出现过的孤立 id（除非确实存在被孤立的成员，那是结论的一部分）。
5. 提交前自查。 时间窗是否一致？渠道是否分了类？count 是否有明显量级错误（比如某条边比全团队总量还大）？

一个关于小团队的提醒

如果团队在 10 到 30 人之间，请注意一件事：匿名化在小团队里几乎不成立。

关系数据即使删掉了名字，看报告的人也能从"谁和谁交互多"反推出是谁。这不是数据脱敏没做好，而是小团队的拓扑本身就携带身份信息。

所以第一轮建议只看团队级结论，个体级结论在明确授权之后再看。规模小不等于风险低，恰恰相反。