改了八版需求才悟透：我们真的用对团队协作技术了吗？

去年9月23日，南京，我在紫金山脚下的软件园赶一个项目上线。本来约了早九点全组开需求对齐会，头天晚上台风过境，绕城高速封了，三个核心开发堵在半路上进不来。剩下的人在会议室泡了三壶茶，干坐了一个小时。有人提议，要不散了各自线上改？反正需求文档都在云上。 谁也没想到，原本计划一天的对齐修改，晚上六点就全部收工。比以往任何一次线下会议都快。 南京软件园研发团队线下会议协作场景

为什么会议室里的协作，越来越干不过线上异步？

为什么会议室里的协作，越来越干不过线上异步？ 很多人提起团队协作，第一反应就是坐在一起开会，头脑风暴，拍白板。那是十几年前的老黄历了。现在的团队协作技术，核心早就变了。 以前我们做协作，靠的是人盯人，你改了什么喊一声，我改了什么给你发个离线文档，最后汇总的时候拼拼凑凑，错漏一堆还容易吵架。我刚参加工作那会，改个方案要发好多版，文件名是「需求_v1」「需求_v2张改」「需求_v3王总最终版不修改」「需求_v3王总最终版真的最后一改」，光找最新版就要找十分钟。 现在呢？所有修改都在一个文件里，谁什么时候改了什么一目了然，根本不用传来传去。这不就是团队协作技术最实在的用处？ 核心变化就是，从「人等任务」变成了技术适配人。你有空你就改，我有空我就改，不用所有人凑在同一个时间同一个地点，技术帮你把不同时间不同人的修改拼对。

核心不是工具，是冲突消解逻辑

很多人觉得，团队协作技术就是买个年费的协作工具，开通所有权限就完事了。根本不是。工具只是载体，背后的冲突消解逻辑才是核心。 什么叫冲突？两个人同时改同一个位置的内容，你要删，我要加，听谁的？这就是协作最本质的问题。 最早解决这个问题的思路是锁，你改了就锁上，别人改不了，等你解锁了别人再改。这本质上还是串行协作，和排队差不多，效率低得很，遇到有人忘了解锁，全组都等，太坑了。 现在主流的两种思路，完全跳出了锁的逻辑。一种是我们天天用的在线协作文档在用的操作转换，简称OT，说人话就是，你每次修改都是一个独立操作，技术会自动把你的操作和别人已经完成的操作做适配，哪怕你们同时改同一个句子，最后也能把两个人的修改都合对，不会覆盖也不会乱码。 另一种，就是代码协作领域几乎一统天下的Git，用的是基于快照的版本合并。每个人拉一个独立分支，自己改完了再提交合并，有冲突的时候再提醒人手动解决。 两种思路没有高低之分，只有适用场景的区别。写文档改需求，OT的实时协作就很爽，大家可以一起调整内容，实时看到结果。写代码改系统，Git的异步分支就更稳，不会随便打断别人的开发思路，复杂修改也能人工确认风险。 Git版本控制分支合并冲突示意图

绝大多数团队，都踩过这些协作技术的坑

我见过太多团队，工具买了一堆，权限开全了，协作效率反而更低了。坑太多了，说两个最常见的。 第一个，为了协作而协作，什么都往工具里塞。连今天谁带奶茶、加多少糖都要建一个协作任务，开几十上百个群组，建几千个文档，最后找个东西要翻半小时，纯粹是为了用工具而用工具。协作技术的本质是减少内耗，你这反而给所有人加了活，增加了内耗。 第二个，迷信实时协作，什么都要实时一起改。我见过有的研发团队，居然用实时协作文档写代码，所有人挤在一个文档里改，一会儿这个删了那个的函数，一会儿那个改了这个的变量，一天下来光解决冲突都累死。说实话，不同的工作性质，要配不同的协作技术。需要脑暴发散、快速对齐的时候，线下或者实时协作没问题，需要深度思考、独立创作的时候，异步协作才是正确选择，给每个人留足空间，效率才高。 还有一个最容易忽略的坑，就是权责不清。协作太方便了，谁都能改，出了问题找不到责任人。上个月我帮朋友排查一个线上bug，最后发现是三个月前有人改了需求文档，把一个核心参数改了，但是没留说明，全团队都没人知道，最后上线出问题，翻了三天操作日志才找到责任人，硬生生耽误了上线时间。所以用协作技术，重要修改一定要留说明，不要嫌麻烦，这不是形式主义，是给自己留后路。 不过话说回来，团队协作技术再先进，也解决不了本身团队管理混乱的问题。要是你本来就职责不清、分工模糊，就算买了最贵的协作工具，该吵架还是吵架，该延期还是延期。技术从来都不是万能药。它只是帮你把原来要花在沟通、合并、找版本上的时间省下来，让你把精力花在真正该做的事上。 那天南京的雨停了之后，堵在路上的同事晚上进了城，我们一起去软件大道旁边的小龙虾店吃了一顿。没人说那天逼出来的协作改变了什么，但所有人都感觉到，原来我们不用天天凑在会议室开会，也能把事做好。 这就是团队协作技术最棒的地方——它不是用来强行改变你的工作方式，是给你多一种选择，让你在各种突发状况下，都能稳稳把事干成。 说白了，能帮你少干活多成事的协作技术，才是真的好技术。