（一）
和封闭时相比，我所在的项目组正式成立后只少了一个人，她是我们的设计师。由于她身兼另一个项目，以及设计中心本身的「支持」属性，所以自回到中关村，她就没再来过我们所在的办公区，所有的沟通几乎都依赖QQ和我徒步5分钟的专趟解说。
久而久之，那些不是那么重要的设计小需求就都被我瞒了下来——复用已有的样式，或是和前端商量着来。设计师大人当然也会察觉，只是更多时候会被「产品汪」的种种特性所蒙混，或是睁一只眼闭一只眼过去了。
恰好最近在大范围替换svg图标，我就让前端直接找设计师说要替哪些，省得我老当二传手，毕竟icon不至于说不清吧。结果证明是我天真了，前端关注的是这个icon在不同系统下的差异，而设计则跟关心这个icon出现在哪个页面，场面那必然鸡同鸭讲了。
事后我私下和前端说，「这下你知道我为啥能不走设计就不走设计了吧？」，背后的原因我自然没和他深讲，当然也绝非不尊重设计、不尊重专业，只是对小团队来说，这种沟通有时是伤害性的。
沟通的本质是目标的互相调节，然而把自己的想法完整输出并完全输入到另一个人身上已经很困难了，如果双方由于各自视角，对需求的理解有所差异，想达成妥协就必须耗费更多的时间。
人与人之间尚且如此，部门之间的相互推动更别提有多费劲。大公司往往低效的罪魁祸首之一便是部门内评审→跨部门评审，这背后自然还有别的深层原因，毕竟比起效率，大公司可能更在乎别的目标，两害相较取轻嘛，但效率却是实实在在的受损了。
而对小团队来讲，效率却是一切的源动力，任何导致低效的因素，都是需要警惕的。同时人的成长速度也依赖于效率，一个人保持高效的时间越长，他的成长必然也越快，两者几乎呈指数关系。
（二）
把这个问题搁到「产品」上也是如此。
上周体验了几天招聘者的日常，惊觉「投递后沟通」必火，当时还在部门内部写了这样一封邮件：
投递后沟通太重要了，看简历时疑问是随时产生的，如果能够实时问会很方便。而打电话的话会涉及到两个问题，一是不知道对方现在方不方便，二则是语言组织和「持续连接」的问题，至少对我个人而言，光是想想就够焦虑的了。
另外也有时间的因素，觉得打电话会完全切断自己当下的手中事，而即时沟通虽然沟通的效率更低，但至少能让我保持和手中事的弱链接，不然「重启」的效率更低。
这周上线后，发现这个功能并没有如预想般火起来，找了一些HR收集反馈，发现背后的症结依然在于效率，是我对效率的理解产生了偏差：
作为招聘者去体验时，我的场景依然是用人部门，背后没有需求方，给对方发消息后他会不会立刻理我对我来说没那么重要。因为我只是懒得打电话切断手中事罢了。
而HR呢？他们的「手中事」就是和候选人沟通，他们的背后有需求方在催命，如果发出一条消息对方不能马上回复，还不如直接一个电话过去来的高效。就算给消息加上了已读回执，也只是通过双方的心理负担来强行提高效率罢了，但效率的边界依旧在。
但为什么投递前的沟通，就会有市场呢？我猜是因为那时的需求是「简历」，能够免费获得简历，并且了解对方，当然愿意付出时间和Ta聊天——毕竟没有别的方式了呀。
总而言之，有沟通就会有效率边界，只不过囿于场景所限，有些沟通方式会比另一些高效那么一些罢了。
（三）
回到最开始的话题。
对协作产生需求的企业，一定是因为沟通出现了障碍、损害了效率，所以希望通过工具弥补。
这是否意味着「协作工具」的边界更多依赖于团队基因呢？
小团队对产品的专业度需求低，切割付费的空间比较小，同时这类团队靠吼基本就能解决问题，成员的协作基因无关痛痒，只要项目主导人推动就足够了。
而大公司的付费意愿更依赖于定制化需求，这有悖于SaaS的理念，并且此时的公司环境下，协作工具很难被推行起来，如果强行通过「沉没成本」来推行，又会回到迈不过去的定制。
所以也许「协作工具」真正要克服的，是每一个团队的边界——
对小团队而言是每个成员的自我驱动精神，大公司则是让每个成员都能理解「为什么」。
——而这些要求所指向的都是团队基因，可遇不可求呀。
（四）
回到价值原点，企业工具的意义在于更好的成果，更高的产出，更快的效率，然而协作只是提高效率的手段，两者不必然等同，毕竟前者在真实场景下存在前置条件。如此来看，协作也许不是标配。
