群体的经历：为什么一切都放进项目
群历的名字取自「群体的经历」。信息都在一个地方，经历才能沉淀下来；所以我们把每一件事都放进它所属的项目，不在别处另起一份。
今年春天，我们接到一个客户的二期需求。开工前，团队要先回答几个问题：一期踩过哪些技术坑？当时为什么否掉了另一个方案？验收时客户提过什么保留意见？
这些问题几分钟就有了答案。技术问题和解决办法在任务的评论里，方案的取舍在讨论里，需求背景在文档的历史版本里。没有人需要回忆，也没有人需要去翻半年前的群聊。
这就是群历名字的意思：群体的经历。一个团队做过的事、做过的决定、为什么这样决定，都应该能找回来。
经历不是被删掉的，是散掉的
很少有团队会主动删掉重要的信息。信息是自己散掉的。
方案在群聊里讨论，结论在某个人的私信里，文档在另一个工具里，任务又在第三个工具里，最关键的那句话是会上口头说的。每个工具单独看都没问题，问题出在它们之间的缝里：有人要把群聊里的结论搬到任务里，把任务的进展搬回群里，搬的时候总会漏掉一点。
半年后，聊天记录被几千条消息淹没，文档还在但想不起叫什么名字，说过那句话的人已经换了岗位。
所以我们的判断是：关键不是功能多少，而是信息在不在一个地方。
规则只有一条：每件事都属于一个项目
在群历里，任务、文档、文件、讨论、日程、目标、转发进来的邮件，都放在某个项目里。我们自己的做法是，一件事不论大小，都放进它所属的项目：
- 没有「太小不值得记」的事。「周四的后期挪到晚上」也可以是排班讨论下的一条评论，两句话就定下来，以后也找得到。
- 决定在哪里做出，就留在哪里。在任务的评论里定的，就留在那条评论里；影响面大的，再补进文档。
- 在别处聊过的，把结论带回来。电话里、会上、走廊里说定的事，回到项目里写一句「决定：……」。
这条规则听起来很普通，难的是坚持。只要有一部分工作留在群聊里，项目里的经历就是残缺的，大家很快会觉得「反正群历里也找不全」，然后回到群聊。
为什么按项目，而不是按人或按时间
信息总要按某种方式组织。群聊按时间组织，私信按人组织，我们按项目组织。
按时间组织，旧的信息会被新的淹没。按人组织，信息会随人一起离开：一个人调岗或离职，他私信里的上下文就没了。
项目是人们回头找东西时最自然的线索：「上次给那家咖啡店拍的那组」「App 3.0 那次发布」。项目有自己的成员和起止时间，新人加入项目，就能看到它从第一天起的全部经过，不需要谁再给他讲一遍。项目做完可以归档，归档后仍然可以随时打开查看。
经历需要时间才会值钱
这套做法有一个代价：第一天，群历是空的。
一个新团队刚搬进来时，感受到的只是「又多了一个工具」。价值是复利式的，要等几个月后第一次回头找东西，才真正显现。所以「先试试其中一个功能」体验不到群历的好处，那恰恰是它要避免的碎片化用法。
我们建议的开始方式是：选一个真实的、刚开始的项目，整个团队一起搬进来。具体做法见第一个月怎么开始。
几个让经历留下来的习惯
- 链接，不要复制。 在正文和评论里用 @ 引用任务、文档和讨论。每条记录都有引用号（如 T1042、D45），记录移到别的项目，引用号和链接都不变。
- 改原来那份，不要另起一份。 文档、讨论和任务描述都保留历史版本，改了之后还能看到每一版。「方案 v2 最终版」这样的副本，只会让人不知道该信哪份。
- 放错了就移走。 记录可以用「移动到…」移到它真正所属的项目，评论和引用号都跟着走。
- 做完归档，不要删。 不再推进的任务改成「已取消」，做完的项目归档。删除的内容只在回收站里保留 30 天，过后就没了；取消和归档的内容一直都在，随时能找回。
- 机器人的工作也留在项目里。 机器人用自己的名字评论和写文档，它做过什么，和真人一样记在项目里。见和机器人同事一起工作。