编者注：本文的作者是团队协作工具Teambition的Growth Officer钱卓群，内容来源于Airbnb团队到Teambition访问时团队所做的一次关于如何设计产品、后续开发思路的分享，是当时presentation的细化和扩展。文章详述了Teambition总结的大脑工作和记忆的规律，以及Teambition是如何根据大脑的特性——“洞中微光”效应思考和设计产品的，我们也曾经介绍过他们是如何针对不同行业定制工作流程的。PingWest经Teambition授权，将全文编辑如下：

如果用硬件评测的眼光来看，我们的大脑并非完美和全能。我们的大脑有其精妙与强悍之处——即使不计较功耗，在模式识别（特别是涉及到人脸等存在）、归纳推理等领域也轻松领先目前的顶尖人工智能系统若干数量级。但凡是涉及精确的文本、画面的记忆记录、数字运算等方面，我们的脑力就会显得有些捉襟见肘，比如，如果不使用拆分技巧，我们很难迅速准确记住7位以上的数字……

了解清楚我们大脑的能力结构和特质会很有帮助。除了用于聊天听起来很酷以外，这些知识可以帮助我们更好地设计工具和工作的方法。正是因为对大脑特质的理解，我们开始应用思维导图，事项清单等工具，以求更高效、同时更少焦虑地工作（后面文章会重点讨论工具）。

我在这里想讨论三个我认为与协作工具的设计最相关的大脑工作特质，这些特质如何塑造了我们的工作形态，以及我们如何可以更好地顺应这一规律，制作出更趁手，更高效率、更少焦虑的工具。

大脑特质1：转换成本

转换成本，是我看到37signals团队和Joel Spolsky一直不断提到的，也被广泛地视为效率杀手的一个存在。简单来说，就是，开展工作之前，在头脑中记录和熟悉所有信息，是需要花费一定的时间和注意力的，如果因为被打断，突然切换任务的话，不仅新任务相关的信息需要被了解、熟悉，切回老任务时，同样的步骤还要被进行一遍。重返效率高峰的过程和睡眠一样，需要渐进，过渡过程中会有可观的效率下降，相比于连续专注工作，频繁在任务之间切换就会造成很多效率的损失。程序员界流行类似的笑话，熟悉了变量、理解了算法、调试好了环境，正准备大干一场，突然被叫去开了个会……

大脑特质2：想法的维护成本

想法的维护成本，是从我自己的观察和经历中总结出来的。意思是说，一旦我构思完成整个创意，有了想法之后，为了高保真全细节地记住这个创意，其实是要花费很大的努力的。之前有个RPG游戏（地狱之门？），召唤师召唤出一个小跟班，魔法值上限立即减少1/3，就是这种感觉。

很多人应该都有上讲台之前打腹稿的经历，来回的焦灼踱步多半也并不是为了想到更多的主意，只是在训练自己不要忘记已经想到的那些。 这个成本如此之高，以至于为了保险起见，许多人会宁可事无巨细诉诸文字记录，比如索性将演讲稿逐字写出。

前两大特质有一个非常有趣的关系，就是，转换成本的存在，让人深恶痛觉各种会议和打断，而想法的维护成本，又推动人们在有主意的情况下，即使知悉打断成本，权衡之下，也要趁着想法新鲜，把别人拉过来获得反馈。

大脑特质3：洞中微光

洞中微光是指，正如前文我们所说的那样，我们的大脑虽然可以记下非常繁复的信息，并且根据线索相当广泛地进行联想，但是每一刻，我们能够处理清楚的想法的规模是十分有限的（比如记录数字的话，最多只能7位），就好象在漆黑的山洞里面举着火把前进，每次被照亮的只有很小一片范围。为了尽可能减小这个特质所带来的影响，我们发明了各种各样的工具和方法，比如思维导图、事项清单（checklist）。这些工具提供的帮助，本质上是抽象化和模块化。

我先来解释一下抽象化，这个词通常让人有一种头痛欲裂的复杂感，但其实它的实际含义很简单。比如，我和你说到《变形金刚4》票房很好，然后问你，你怎么看这种现象。这里用“这种现象”所指代的“《变形金刚4》票房很好”，就是一个抽象。

模块化就更好理解了，"我今天讲三个点"，每个点前有导入后有总结，完成后再往后走。

抽象化和模块化往往结合使用，本质目标就是让你同一个时间只处理一小块事情，然后再积累起来，达成处理完了全局的效果。以项目管理的流程中的工作包分解（WBS）举例，比如先是解决更全局的问题，决定要成事要完成哪些模块，再是各个小模块更细节的内容的列举，最后是确定执行人、各种时间和资源的协调。分模块叠加，每个内容都会得到充足的关注和斟酌，但这些事项同一个时间一起想，则很容易流于零碎和肤浅。

我想讨论一些更复杂的方法和理念，它们都能进一步地顺应大脑的这些特质，同时，依赖如今的信息基础设施，第一次有望被以足够低的成本实现。

一、异步通讯

正如前文所述，我认为尽管知道切换成本很高，我们依然愿意容忍不断打断的重要原因，除了事态真的很急迫以外，就是一直维护着这个主意也是会牵扯精力的。这组矛盾一个自然而然的解决途径就是，允许一方先直接说他们想说的话，存起来，接收方稍后再处理（“异步”），传统的实现方法是雇佣助理或者秘书，来对信息进行缓存，在方便的时候再一项项处理。而现在的协作工具可以依赖软件系统大大降低相关的成本。

决定异步通讯效力的是这么两个维度：

1. 接收者侧：上下文完整程度，越少需要主动回忆拼凑的，切换成本越低。

2. 发布者侧：完整、逻辑的想法记录，甚至鼓励采用极有层次、带标签的形式来记录想法，目前我看到的最妥帖的尝试是workflowy。

通过异步通讯手段发布完信息之后，发布者就基本上可以算是任务达成，卸去很大一块维护想法的负担了。和直接打断唯一主要差别，就是他还需要再留心一下内容被接收的确认和等待后续的反馈。

传统组织协作中要求的“及时反馈”本质上也是一个帮助及时释放注意力资源的点，因为这样直接相当于帮你完成了一个“确认任务交代”的子任务，就不必再拨出精力维护这个想法了，于是所有的进展又可以增量地往前推进一些。异步通讯也可以考虑通过优化通知和反馈在这个方向上继续帮助减轻焦虑。

同时，如果这个套系统能够自行区分一下轻重缓急（这里的依据也可以来自发布者的选择），不进行不必要的打断提醒（响声、弹窗），则上佳。

二、自动化

协作系统或者更传统的OA系统，本质上是信息处理系统，那他们的本职之一也就是要能够根据规则替代手动操作，比如替代原本一项项的粘贴。讲起来简单粗暴，但是效率就是从这里产生。

模板、复制、移动 甚至更复杂的副本并行等机制都是。

本质上来讲，一项功能值得被整合进系统，各种操作的时间和复杂度成本至少首先应该持平已经普遍被采用的做法，比如用excel来手动管理甘特图和项目进度，或者用百度网盘、dropbox来分享文件，然后任何不损伤效果的操作简化都是加分，任何更加复杂的实现都是减分，加分减分相抵消，要务必保证有个大比分的正值。并且，即使积分是正的工具，也未必能够保证能在短期内立即被采用，因为还要考虑团队迁移和适应的成本。

三、降低焦虑

一般说到效率，大家觉得所指的都是时间，而实际上涉及到使用效率的另一个重要的层面是焦虑，为了说明这个问题，让我们先看一下这个例子：如果要求你点选浅蓝色的按钮，以下的界面那个更让你感到舒适？

是这样：

还是这样：

完成两个动作所占用的时间是应该是几乎一样的，但引起的焦虑和消耗的注意力则是截然不同的。更何况现实中，小的按钮，可能还处在更复杂、有更多类似的小按钮作为干扰的界面中，你需要集中更多的精力才能确保顺利完成目标。

那为什么完成功能时，尽可能降低使用者的焦虑这么重要？除了让使用者的进入门槛更低以外，还有我们前文讲的“洞穴微光效应”——我们的运行内存实在太小，一个不注意，过多精力被界面、交互牵扯，就有可能丢失手头真正重要的主意，尤其是涉及项目协作这种处理“正经”主意的时候，这点尤其重要。

这个目标就给产品在功能扩张的时候提出了一个非常重要的约束：需要权衡直接增加功能带来的代价。

交互方面有苹果等企业留下的非常优秀的例子，包括高频功能入口显著，低频功能入口可以稍微隐藏，尽量使用符合直觉和日常物件的交互逻辑等等……

这个方面asana做了一个略微激进的选择，他的很多功能都依赖用户之前的互联网产品的经验，熟知列表、标签、follow机制，并且界面细密，需要足够的熟练之后才能得心应手。在我看来，和asana抢用户，从功能配置以外的部分入手反而会更有效率。

四、数据透视功能

我准备花一整篇文章的篇幅来讨论数据透视的功能，也作为这个系列的压轴，以体现我对这类功能的期待。在我看来，这是我们天生的大脑处理起来最费力，而信息系统可以帮上最大忙的地方。

首先我们需要解释一下数据透视和相关的信息维度的概念，我们一步步展开，我保证，虽然这些名词看起来像数学，但其实没有数学和数字出现，不难：）

1. 信息的维度

让我们通过举例来解释，协作系统中的一条任务，可能会有很多不同的属性点，比如它有执行人，有其他参与者，有截止日期，有备注解释，有子任务，有标签，有附件、有讨论……这里的每一个属性点都可以被称为一个维度。

维度多并不代表信息多，我们也可以把上述所有类别的信息压缩成一条文本（一个维度），就像很多人常收到的邮件一样，信息量是一样的：

明天9点前由你负责带上ABC三位同事完成 #大象关进冰箱# 的任务，具体步骤为： 1.打开冰箱门 2.放入大象 3关上冰箱门，注意冰箱是西门子的，请务必确认把门关严。冰箱的具体参数请参见下面的文本，有问题回信讨论……

当然，上述的邮件，不好记，不好处理，我还是要手动去创建任务和日程的，如果多了还是容易让人头大的，它实质的缺陷我们接下来讨论一下：

2. 透视的意义：围绕特定维度，减少复杂度

协作系统光存下所有的信息只是第一步，光考虑储存的时候，信息维度的多少本质上没有太大差别。

但我们对协作系统的追求必然不止于此，创建很多维度真正的意义在于，这些信息可以依据某几个属性被标准化地处理和呈现。比如我如果创建了“截止日期”这个属性点，那么我就有机会通过系统来帮我找到将要在一周之内到期的任务，或者，已经过期的任务；我可以查看我是执行人的任务；或者将两者结合，找到执行人是我且即将过期的任务，这样的信息就会很有用了。

我们做的上述事情就是透视——只依据有限的维度（通常仅仅是一两个）来归类和简化信息，得出结论，进而指导行动。

透视可以有许多很有趣的用例，比如根据任务是否逾期，用红色或蓝色来表示，把各种日期细节的比对变成更宏观更能被自然接受的呈现。或者把可以作为日后参考的内容，打上“范例”的标签，将来需要培训或者回顾改进流程的时候，直接通过标签筛选出最佳实践的列表，这样的知识管理相比传统方式，不需要额外做编写百科的工作，同时保留的信息还更加充分。

就像我们之前说过的那样，由于我们的大脑的工作内存其实很小（"洞穴微光效应"），这类明确标准的信息比对，由协作工具来完成，效率会很高，反馈快，造成的焦虑低，让我们可以空出手来解决那些真正核心的问题。

我们的目标是能让Teambition尽可能地储存好关键的信息，并提过详尽完善符合直觉的透视方式，向乐高积木一样，让用户来组合这些可能性，发挥创造的威力。

3. 在透视的基础上，雕刻

限于我们有限的大脑工作内存，再大的项目，归根到底最后都是只能通过渐进的方式完成。我们不断对整个项目中更小的部分做出判断，并记录成果，最后的汇总，完成项目。

能让透视功能用处更大的功能是，允许雕刻，也就是，我可以根据透视之后这个小侧面呈现的信息进行判断操作，并且相关改动能够被记录和反应到全局里面，用渐进的方式，每次在最合适的信息配置下处理可控制的问题，通过积累这些稳健的进度来推进项目，使得最终形成的判断，顾及了尽可能多的重要信息。

比如Teambition内部，每一个迭代开发之前都需要有一份完整的开发项目表，而直接从千头万绪的需求筛选总会是非常头疼的。我们不直接判断哪些需求要这期做，而是一步步分散来做。首先，每个需求提出不久就会先被预筛，有初步值得做的迹象的，就移入”接受“ 子集，并打上相关的战略主线的标签。每次确定迭代候选前，先选择要加强的战略主线，再从对应标签的”接受“子集里，确定进入这次开发排程的需求。

比如用允许雕刻的方式来进行项目监管，应该是这样展开：通过可视化界面的一小片红色发现有逾期风险的项目，直接展开这个项目的详情，发现主要是一个任务被卡住且已经快到期了，继续展开这个任务的详情，在里面直接提供资源完成任务，或者调整计划，并打上标签“需回顾”，数据库直接记录这一变动，自然，所有根据这份数据运算出的所有透视结果也会做出调整，比如执行这个快到期任务的同事，他的个人工作列表中的快逾期提醒就会消失，整体工作进度界面中，包含这个任务的项目也不再是红色报警状态。整个项目完成后，通过查看“需回顾”标签所覆盖的内容，总结经验，改进下次的流程。通过这样一个内容照看的系统，核心是让用户通过雕刻的方式，每次选定恰当的信息配置，有把握地操作，通过逐步做增量的方式，搭建好整个工作的框架。

重新再回头来看协作工具的意义

于是这就是我们的愿景：通过透视解决信息的繁乱，在此之上通过雕刻，一次次有把握地处理一小块信息，帮助更低焦虑地基于更多信息做出决策，再基于异步通讯让团队能够协同高效地根据各自的特长分别雕刻自己擅长的方面，工具在过程中自动化地提供支持，进一步扩展团队能达到的可能。

目前协作、透视、雕刻这一系列的做法貌似还需要很多相当强的假设，但也许，有朝一日，这个概念会和“无纸化办公”，或者“到处有wifi”一样，成为自然而然的现实。毕竟，它们更符合我们渴望更高效的本性。我们到来，我们看见，我们征服，与诸君共勉。