工作踩坑录：团队、交流、协作与执行

本文是一篇工作随想，主要记录一些团队工作过程中遇到的问题，相应的解决方案，会涉及一些配套的软件、工具，或是管理方法等等。全文没什么专业性，仅为本人经验之谈，尽量讨论一些具备普适性效用的场景，不拘泥于细节的扣扣嗖嗖，欢迎吐槽。

前言

虽然我尽量会往普适性的方向讨论相关问题，但还是要说明一下我的工作的主要内容。我是一名产品经理（PM），虽然普遍这么叫，但我自己更愿意称自己为产品设计师（PD）。这个岗位如果对标到游戏领域的话，就是游戏设计师，也即大家普遍称之的策划。

产品设计师的主要工作自然是设计产品。但是设计这个词涵盖的概念太广了，就我所从事的领域而言就包含方案、交互、视觉、程序四个主要部分。当然，方案、交互、视觉、程序可以分工给不同的工种，而我主要负责的是方案+交互部分的产品设计工作。除了设计的主要工作外，不可避免地需要对产品负责，所以管理工作必不不少，偶尔也会抢占项目经理/leader/总监的一些工作。

具体的工作主要包含调研、数据分析、写文档、画原型图、结果验收等。至于具体的团队协作方面的工作，包含需求获取、需求交接/评审、需求验收三个部分。

• 需求获取：与用户/上级/其他团队（如市场、运营）交流，知道产品要做什么以及为什么要做这些（用户需求）。
• 需求交接/评审：在用户需求翻译成实现方案（怎么做/产品需求）后，对接执行团队，整个团队评估整体方案的可行性、潜在问题、需要时间等。这个部分交流的目的是保证执行团队可以把需求做出来。
• 需求验收：执行团队实际做出了的东西可能会与预期有差异，这个时候就需要及时跟进团队的结果产出，在妥协/完善/修改中推进整个结果的产出。

最后用斯坦福的设计方法论的基础模型来总结整个工作流程和需要交流的地方。

文档，文档，还是TM的文档

一说到交流，我们的第一反应会是面对面的交谈，或者即时通讯软件上的沟通，或者再正式一点的邮件。但是这种形式的交流（即时或半即时），主要的使用场景是讨论。凡是讨论，则必定会含有大量的不确定的信息/垃圾信息，使得工作目标模糊；加上这些交流很快会被新的交流淹没，就算讨论出了结果，明确的工作目标也很可能因被遗忘在某个角落而丢失。

所以唯一的解决方案就是白纸黑字确定下来的文档。这份文档需要随时供团队内的成员进行查阅，并伴随整个项目落地。「这份文档」也不仅仅代表一份文档，除了最重要的产品需求文档PRD，偶尔需要接触到的商业需求文档BRD和市场需求文档MRD，可以进一步包含会议记录、各类评审记录、用户研究报告、项目管理文档等等，还可能包含领导口头传话记录等（虽然不应该直接负责，但为了防止领导变卦最好还是留档下来给领导过一遍。）

总之，凡是需要协作与工作交接的部分，在讨论完成之后就需要有一个确定的文档，保证整个团队对于工作目标明确清晰，从而使得项目有序推进。团队里的开发同学有自己的开发文档、接口文档需要准备，交互、UI同学有交互、UI文档准备，测试的同学有测试文档，剩下的PRD以及各种杂七杂八的交流文档则基本上由产品经理包了。整个团队中产品经理对于业务的理解一定是最深刻的，所以多承担些别的同学不那么喜欢的文档工作，也是必须的。

修改与存档

上面说到我们需要一堆确定的文档指导工作推进，但是实际执行中，文档是会不断更改的。比如自己在写第一版的时候，可能就会私下里修改很多次；然后给领导过的时候，又会有一些修改；再之后发布给整个执行团队的时候，执行团队可能首次提问就会导致很多修改；然后就算执行团队需求评审通过了，在实际执行起来后也会遇到一些没预估的问题，这个时候又要进行修改或补充。

当然以上这些还算是正常的文档修改，通过一些备注、修改说明还能定稿。有些情况下领导一拍脑门整个方案大改，文档重构也是完全可能的。

所以如何做好这些文档的版本控制也得好好研究研究。随着各种在线协作文档的兴起，各种集成在软件中的版本控制已经完全能用。不必像开发那样严格按照dev、beta、release分支那样管理版本，产品经理对于文档的版本管理更多的是保持文档的良好阅读性。

比如在需要频繁修改的文档中首先就说明历次修改的内容，同时做好文档的目录，方便目标成员查阅。虽然一般情况下接触的文档很少有回滚版本的需求，但是若注意到某些破坏性的修改，可以考虑在修改前备份文档副本并标注版本信息（就和游戏存档一样）。

通知与交流

在实际的工作中，时刻要关注文档的受众，完成或修改文档后需要及时向受众沟通。文档天然在即时性上存在缺陷，所以需要通过这种方式弥补交流的缺陷。

一般情况下，我都会把各类文档的最新版直接呈现给团队成员，这一点会在工作空间中进一步讨论。实时协作文档工具（包括面向设计文档的Figma），因为部分解决了传统本地文档在交流上的痛点，这几年也是快速增长。

工作空间

我对工作空间的定义是一个实体或虚拟的环境，用于向个人或团队呈现工作流中的各种实时信息，或者帮助人们快速查找工作需要的信息，从而帮助人们高效工作。

一个工作空间需要有一个大的工作目标，团队成员因为拥有这一共同的工作目标而聚集在这一工作空间中。当然在实际工作中，一个人往往会同时接手多个大的工作目标（项目），这种多线程操作稍后再谈。

看板

看板（KANBAN）工具是一个典型的工作空间工具，同时市场上几乎所有的协同办公/管理工具都会添加看板的功能，另外GitHub的Issue、Pull Request也和看板的理念类似。看板是一个可视化工具，通过将工作目标拆解，并放置在「未开始」「进行中」「已完成」三个基本的核心模块中，实现整体工作进程的可视化。

看板的管理属性会更强一些，管理者通过这种可视化可快速监控项目进度；团队成员也可在看板中明确自己的代办事项，合理规划自己的工作。一个团队需要有这么一个看板来激励所有成员的工作。

至于看板的实体或虚拟性，我个人倾向于在团队办公室竖一块玻璃看板，通过便利贴跟进子任务。站在实体看板前讨论问题和进度总是会让人更有感官上的冲击，让工作更加具象化从而起到更好的激励效果。

而虚拟看板的优势在于突破了空间限制，为远程办公等跨距离办公场景提供帮助。同时在「多维表格」这一概念起来之后，看板的可视化效果可以根据需要在列表、便利贴式看板以及甘特图间切换，满足不同的需求场景，可参考飞书「多维表格」的说明。比如列表模式可方便快速编辑、甘特图模式对于进程的综合展示效果更佳。

文档管理

看板工具虽然在任务可视化上很有成效，但在实际的任务推进上还是缺了一点味道，看板并不能方便地告诉成员如何完成任务。相应的，解决方案是前面提到的文档。对应到GitHub，则是核心的Code模块。

工作空间中需要有这么一个文档管理系统，包含最基础的存储、分类、查阅、编辑等功能。

我的实际使用流程一般就是直接在空间的合适目录建立新文档，完成后通知相关人员。在整个项目的持续时间内，相关的文档修改、添加等都在这一空间中进行，文档时刻保持最新且唯一状态（也即一个问题/工作流程对应一个文档）。同时整个文档空间对所有人开放，就算是暂时无关的成员也可对所有文档进行查阅，方便对整个产品业务进行认知和了解。

保持在线文档的「唯一」，省去了文档版本冲突、交流不在一个版本上的各种问题，从易用性角度完爆各类版本控制软件。

而在项目结束或者版本上线后，当前工作空间中的在线文档都会统一归档处理，通过「项目名称+版本号」的形式归档在本地SVN服务器中，供后续复盘或历史查阅使用。

至于线上的工作空间，则暂时清空。在保留产品线和空间结构的基础上，相关文档随着新一周期的工作目标而逐渐建立和丰富起来。不过实际上，产品经理和研发的工作时间线相对会错位一些，在研发后期一般下一轮的产品工作已经逐步启动，在这一时间段我会在个人工作空间先完善各种文档，然后随着新一轮项目的交流工作迁移到团队工作空间中。

多线程工作

理论上多线程完全是一个管理工作，暂时还轮不到我来负责统筹安排。不过我也不是完全没有多线程的经历，看书/剧总喜欢一本/部没看完的时候就新开一个坑（典型INTP了），工作上现在也是在三条产品线上多开。

对于多线程的工作空间，首先第一步是对每一个线程建立起一个独立的工作空间。对于个人而言，TA的工作域就是多个工作空间的集合，进入某一个工作空间即开展这一工作空间的相关工作。至于单独工作空间内的协作与交流，都与前面提到的无异。

唯一比较麻烦的是，由于多线程操作，时间管理更加困难了。虽然名义上叫做多线程操作，但是实质上事情只能一件一件的做。所以多线程本质上是一个时间安排问题，什么事先做，什么事后做，突发事件怎么应对，事件完成后的协作交流与任务交接等等。

比较有效的方式是项目规划阶段的甘特图与个人安排的甘特图之间的协调。从大到小拆解任务流程，在大阶段避免个人任务的冲突，小阶段适当灵活调整。不过这一切的基础还是团队leader对整个项目难度的把控以及对自身团队能力的把控，能够合理安排计划。

可惜管理工作讲起来太抽象了，以前单打独斗的时候没怎么重视管理的重要性。如今在各个团队中偶尔涉及一些小的管理工作，深知管理不易，虽然我基本上可以实现团队的成果按时提交。

碎碎念的总结

以上就是这篇文章的全部了，有一些技巧类的总结，也有一些工具、方法的介绍，还有一些抽象的说明。不论如何，工作中需要时刻保持思考、保持学习、提高效率。

最后，团队合作最重要的还是要放开自己，由向内思考（Introvert）转为向外交流（Extrovert）。虽然我在生活上倾向于INTP（主要是社交太无聊了），但在工作上还是倾向于ENTP，巴不得天天和团队内的成员对线（指解答问题、Push任务推进、说服大家接受自己的想法）。