团队协作就是各展所长成就共同目标

话说，前两天无意间跟同事讲起一件陈芝麻烂谷子的事，完之后，果断后悔——正所谓，好汉不提当年勇，现在听起来，总感觉像是吹牛的节奏。

没想到被这轻描淡写的几句调侃，瞬间激发共鸣，不禁回想起当年跟小伙伴，一起熬夜讨论方案、建模、编程，以及写论文的日子——我们不就是那个“理想参赛3人团队”吗？所谓“论文判官”简直就是说我的，好吗？

话说，在TechComm胆敢提起写论文这种事，你懂的，注定要跟技术传播扯上关系。那么，就借着这段经历，聊聊我对技术传播中团队协作的理解。顺便向当年的小伙伴致意：过了这么久，你们都还好吗？

那年，我上大三。

01

时间过去太久，已经想不起当初是在怎样的机缘巧合之下，参与到全国大学生数学建模大赛，莫不会是因为被抓壮丁吧：刚好需要有人顶上缺位，同时，刚好我看起来像是一个人。

最终确定共同参赛的3位团队成员，除我来自计算机系之外，还有一位与我同届的数学系女生，以及一位小我俩一届的计算机系男生——现在看来，他们大概就相当于“建模大神”和“编程皇帝”的角色吧。

02

比赛有两套应用题目可选。对于掉书袋的呆子们而言，看着都跟天书似的。我们从中选取了一道貌似调度优化的题目，以此开启了接下来的3天艰苦赛程。

首先，由团队3人共同参与方案讨论，头脑风暴、互相启发，尽可能多地提出解决思路，在不断地肯定与否定中调整方向，最终确定一个最具可行性的方案。接下来，由“建模大神”抽象成模型；再由“编程皇帝”以代码实现。

过程并非一帆风顺。受限于设备的计算性能，输出结果所需的计算时间，很可能是我们完全无法接受的漫长。因此不得不停下来，重新讨论改进方案，划分出子任务，对前一阶段输出的结果进行人工干预，经必要的简化后，再进入下一阶段的计算——如此迭代收敛，尽可能快地逼近最终结果。

03

虽然不确定，我们得到的结果是不是标准答案上的那一个，但是……时间已所剩不多，匆匆切换状态，进入论文写作的环节——而我则因惯常于写作，自然而然地成为执笔主力。

于是，从题目分析、方案权衡，到模型建立、算法说明，直至代码实现、结果输出，层层递进地将整个过程中存在于每个人头脑中的知识，转化为可在屏幕上阅读的文字和图形，确保前后文逻辑通顺。

除此之外，还要适当地包含遇到的问题和解决办法——虽然它们作为被排除的情况，最终不会体现在结果中，但每一个曾经付出努力到过的地方，都值得传递给评委老师知道。

同时，“建模大神”和“编程皇帝”则在一旁紧张地盯着屏幕，确认与自己负责部分相关的内容，包括但不限于公式、代码，以及描述等，已经在文章中完整、正确、清晰地表达。

04

虽然这次经历只不过是学生时代的比赛实践，却如同真实工作场景的缩影，依然可以从中体会出，与文档开发相关的团队协作经验。

首先，技术写作需要建立在对所写内容的充分理解的基础上。换句话说，如果一个作者，连自己输出的内容都搞不清楚，很难想象，他可能给读者讲明白，更不要说，使用最简洁凝练的语言。所以，仅仅把技术写作看成机械地编辑、排版，或者翻译，而没有从内容创作的角度去理解它，显然有失公允。

为了能够建立起对写作内容的深刻理解，比赛中，需要全程参与解题过程，与小伙伴充分交流讨论；工作中，同样需要尽可能多地参与到设计讨论与评审中，与同事深入沟通。不同的是，后者的团队规模往往更大更复杂，甚至横跨多个部门也是有的，全程参与恐怕会陷入信息过载的境地，因此需要从流程上，明确定义关键动作及交付物，确保相关信息传递到恰当的干系人。

技术写作需要明确面向对象，及所要达到的目的。比赛中，向评委老师说明问题的求解思路（而不仅仅是汇报计算结果）；工作中，向用户传递各种各样的产品信息——都需要有的放矢地组织内容，确保内容的逻辑通顺。

团队成员需要共同保证文档的内容质量。显然，无论是比赛还是工作，团队成员各有专攻，少有面面俱到的大神，可凭借一己之力，handle全场。所以，虽然文档开发由一人执笔，却需要全体责任人共同参与，保证各自的相关信息已经充分表达。

05

在提交论文的那一刻，紧绷的神经终于得以释放，身体仿佛被掏空，困意猛然袭来。这时的我们，绝不会想到，之后会因为这篇论文获得北京第一、全国第二的成绩——要知道，能够设法在有限的时间内，发挥各自所长，互相配合地将事情做到尽可能好，就已经非常满足了。此时，心里头全部念想，就是补觉3天3夜，谁都不要叫醒我。

如今，我从事的工作刚巧也是游走在数据科学家与开发工程师之间，收集整理工业大数据产品的相关信息，输出用户文档——冥冥之中，似有轮回。