（微信公众号：生菜阅读）

今天菜园子发起的话题是团队协作工具，有人问: 什么是团队协作工具？

简单来说，就是由于团队分工不同，大家协同工作的时候需要借助一些工具，来帮助分解安排工作细节、确定任务优先级和执行计划、记录和确认各不同环节的交付物等。目前此类工具非常多，但是侧重点略有不同，看大家的发言提到的就有十余款工具，诸如Teambition、禅道、TAPD、Confluence、Slack、Bearychat、企业微信、钉钉等等。一般来说，大家总是会选择其中一款或多款联合使用。

工具如此多，也从侧面反映了，其实没有一款工具能满足于所有场景。这当然不是说这些工具做的不好，而是软件研发、互联网应用研发、特别是今天的移动互联网应用研发，在过去这些年变化发展太快，传统的项目管理方法论几乎全部被颠覆，新的方法论没有形成并被标准化，所以今天各团队的实际执行情况，如果去做一个调研，会发现各有一套，和下围棋“千古无同局”一样，几乎是“业内无同法”。

在我刚工作那会儿，其实还不是这样，我们大学里已经有软件工程导论这样的课程、还有诸如设计模式、UML建模等课程来系统传授从需求分析，到系统架构设计的各环节。等到进了公司里，也是各组分工明确，还有专职的PMO团队，负责制定整体的项目计划并保证执行环节的各节点，几乎随便啥事儿，都有一个标准化流程等在那里，一旦被触发，先做什么后做什么一目了然。偶尔有个事儿流程没有包含，那么做的第一件事，一定是先把这个空白给补上，保证下次再遇到，就可以有流程来控制。

所有的文档、都有中心化的地方来存储。也有一个Wiki，供所有人查阅，哪怕是几年前一个产品需求说明书，也都能找到。

一个产品从需求诞生到最终交付，按照当时的教科书来说，需要有：需求分析、概要设计、详细设计、编码、测试、交付、验收、维护  等环节，每个环节都有标准的文档输出作为记录，这些文档都会有一个模板(通常由十几页)，每一个环节和下一个环节的交接，都需要开会，比如产品经理完成了需求分析，交给研发团队，必须开一个会，双方对需求分析的结果表示没有异议，一旦这个会双方确认完了，就表示研发团队认可了这个需求的合理性，后续必须在指定的时间内完成编码，不能再甩锅给产品经理说需求不明确，或者技术实现有难度。

类似这样的会在整个研发过程中，也会有十余次，期间还可能有反复。

如此冗长的流程，带来的结果有几个：

团队之间的责任非常明晰、也会起到互相督促的作用，比如不靠谱或者没想明白的需求，在很早期就会被拦住，根本无法获得研发资源；

所有的文档都质量较高(低了无法被下游团队接受)，并且由于都有命名规范，使得未来的检索和追溯非常方便；

交付的产品质量较高，毕竟被打磨的时间很长，引入了各方意见，考虑的比较周到细致；

交付的周期很长，当时大约是18个月左右向市场推出一个大版本；

由于交付周期很长，一旦错过了一趟车，就意味着要等很久，如果做错了一件事，那更是很糟糕，要挽救几乎只能用一些召回策略，不大可能得到快速修复。

由于5，所以对质量的把控也很重要，一般都有严格的质检团队，保证出厂的产品没有大的瑕疵，也因此会进一步加长交付周期。

十年前的这一套流程，是非常标准化的，几个跨国大厂，虽然细节有差别，但是基本上都遵循了这套方式（不然也无法写入教科书），所以当时的PMO岗位从一个大厂切换到另一个大厂，对个人是差别不大，对公司也是可以很好的复用其经验的。

不过，大家都知道，随着移动互联网时代的到来，今天已经几乎没有哪个厂是这么玩的了，原因很简单，移动互联网是一个全新的增量市场，而且瞬息万变，几乎没有一个产品能够以如此缓慢的迭代速度面向市场，所以：

团队规模急剧缩减了、更提倡小分队作战；

团队之间更提倡协同配合而不是互相监督，有问题不管是谁的锅，大家必须一起扛；

文档质量也没法要求了，差不多就得了，不然来不及做；

发布周期也缩短了，一周一发甚至一周双发也不是不可以；

相应的交付质量也下降了，用快速迭代来解决可能的质量问题；

测试的重要性被大大削弱了，基本只有很少的测试，甚至没有专职测试，真正的完整的测试其实交给用户来完成了，反正很快下一版又出了，有问题可以修(高级的还有热修复技术)；

正是在这样的快节奏的催促下，无论用什么工具，投入在工具本身的维护成本，都变成了一个需要考量的问题，因为每多一个工具，就意味着你需要维护这个工具上的信息正确性，在繁杂而快速的工作中，这一点是很难保证的，以至于实际执行过程中，这个活儿很可能就变成了产品经理的工作。专职的PMO也变得不大需要了，团队需要每一个人都是有实际产出的，全程“监工”性质的PMO就显得太奢侈，而且由于变化快速，即使有专职的PMO，也会疲于奔命的在各团队之间搬运信息。也有一些团队协作应用在尝试用机器人辅助一定的AI技术来担任这个职责，也是有趣的尝试，不过还没有看到显著的成果。

所以现在最理想的团队工作模式是怎样的呢？

把团队足够细分，不超过5人，把产品经理、设计师、架构师、后端工程师、前端工程师、测试的活儿全干了，所以必定有人是身兼多职的，这也是为什么全栈工程师一度很流行，因为1个人可以干这里面的三个活儿。

给团队充分授权，最好不需要再请示任何人，就可以直接决定产品层面的所有事情、包括需求、优先级、排期、交付时间、交付方式等等。

被充分授权的团队，作为一个统一的管理单元，向上级负责，考核方式可以是KPI，也可以OKR。

团队内部的工具，就不那么重要了，完全可以自己决策，由于是一个利益共同体，所以如果产品经理花了太多的时间在写文档上，研发也会捉急。所以团队内部会磨合出一个最合适的度，使得研发能理解产品的设计、即使出现了表述不清，也能够随时沟通。

在理想状态下，这样的几人小组，不用任何团队协作工具，哪怕就记记笔记，也是完全可行的。

菜园子里，经常听到有小伙伴抱怨，说自己写的文档一直被研发团队怼，怎么办？ 我通常的答案是：

如果你的研发团队总是怼你，多半来说，是你的文档的确写的不够好，但是解决的方式，并不是立即去提升自己的文档水平（这也很难在短时间内提升）。

被怼反映的更深层的问题是产品和研发团队处于对立的立场，双方没有绑在一起，在这种情况下，研发去挑战产品的方案，是完全符合其自身利益的，毕竟一旦接受了你的方案，就变成自己要承担所有的风险了。

所以要解决这个问题，必须主动和研发团队立场一致，如果公司没有从制度上保证这一点，就只能靠自己去点对点的解决了。

毕竟产品和研发坐在一个板凳上实时沟通，才是效率最高最信息无损的沟通方式啊！

P.S. 我不是教你们去撩研发小哥哥......