编辑导语：如何搭建一个高效的团队是每个企业老板都为之苦恼的事情。很多事情从正面想不出办法来的时候，从对立面开始思考或许会有新的发现。如何搭建一个低效团队？这篇文章为大家总结了九个组建低效团队的方法。感兴趣的朋友一起来排排雷。

查理·芒格说：“反过来想，总是反过来想。”

排除掉错的，剩下的更可能是对的，所以想要搭建高效团队，不妨先了解一下怎么低效。

一、不说互联网“黑话”就不要说话

日常用语会让沟通太顺畅，所以产品在工作中必须说“黑话”而且只能说“黑话”。配合不符合日常习惯的语法结构，务必要把需求方和研发绕晕。

贴心整理了一些互联网“黑话”常用词：

复盘、赋能、沉淀、倒逼、落地、串联、反哺、能力、输出、聚合、集成、抓手、拆解、打通、吃透、分发、辐射、复用、耦合、对齐、勾兑、方法论、耦合性、端到端、颗粒度、护城河、组合拳、点线面、全量投入、价值转化、复用打法、资源倾斜……

举例：

我们沟通下→（黑话）我们勾兑下

我尽量做→（黑话）我会全量投入

实际应用中，一句话不要只用一个黑话词，至少要两个。

举个例子：

“从产品低耦合开发角度来看，当前X平台配置应用较重，功能布局不集中，需要提高业务线基础业务层的产品支撑能力，聚合基础业务管理能力”。

（人话版：X平台功能不合理，需要改版）。

二、每天开晨会，1个小时起

冗长的会议是降低工作效率的不二法门，一定要掌握。

不要担心会上无话可说，可以让大家汇报手头工作，挨个来，挨个挑错，问得越细节越好。

反正没人关心其他人在干什么，所以不会有人发现作为team leader的你每天在问同样的问题。

借汇报名义，除了召开晨会，还可以召开周会月会。哦对，要让大家写周报，这样就可以在周会上挨个念自己的周报，有效丰富了会议内容。

三、开会要叫齐所有人

按理说，大会定小事，小会定大事。

所以要想降低工作效率，必须开大会。

比如页面上改1个字，这种需求也要聚齐所有技术环节（前端、后端、数据、测试……）和业务方。

不要怕别人问为什么改文案要后端参会，问就是以防出现产品没考虑到的风险。

四、处理需求的流程越长越好

上面说的改文案需求，也要走处理需求的流程。流程越长越好。

怎么制定一个最长的流程呢？

需要你发挥学习精神，搜集所有专业书、专业文章，把里面推荐的流程节点都记下来，合并同类项后取并集（注意是并集不是交集哦，交集的话你就只能抓重点了，没办法降低工作效率）。

然后再加一些自己臆想出来的流程节点。

举个例子（示例流程极繁琐，出于人道考虑，建议直接跳到第五个建议）：

1. 收集需求

必须走邮件或OA，而且要有窗口期，比如每周一收集需求，其他时间不认。

需求邮件要严格按照模板填写，必须附上MRD（市场需求文档）和重要性评估文档（用来说明这个需求为什么重要和有多重要）。

如果一个需求方有多个需求没有被处理，要让对方把自己的需求先排个优先级。

假如你的需求方刚好有一些不擅长文案工作的，比如施工团队，恭喜你，可以从源头消灭很多需求。

2. 需求准入

拿到MRD和重要性评估后，产品先去和技术沟通，生成SOW文档（工作说明书）。

SOW是从产品的角度再把需求描述一遍，根据和技术的“勾兑”提出一个粗略的产品预案。

注意要粗略别涉及细节，因为还要给接下来的PRD（产品需求文档）留出存在空间。

有了MRD和PRD，还要在中间插入一个SOW是挺尴尬，但是也正好能让团队花更多的时间在文档上，把注意力从真正重要的事情上转移开。

除了SOW，还必须跟技术拿到粗估的工时，细化到各环节的人天上。

把工时和重要性对比，一起作为某个需求值不值得准入的参考，没有人会质疑这种操作的正当性。

有了以上文档，聚齐需求方、产品、技术开需求准入会，用来决定哪些需求可以做（只是说可以做，不要涉及什么时候做哦）。

情况理想的话，一个准入会就能消磨一下午。

3. 需求排期

需求在会上准入后，开始写PRD，然后聚齐所有技术去宣讲PRD，让大家各自报准确工时。

同样，叫齐所有人开排期会，又可以愉快地消磨一个下午。

4. 开发

进入开发流程，产品退居二线，主要工作是盯紧各节点时间，比如开始、提测、上线等，每天跟进并汇报。

如进度有异常，请项目经理协助处理。

5. 验收

产品先验收，没有问题后由需求方验收；如果验收有问题，走修复流程。

6. 培训

验收完成后，出培训文档，和上线邮件一起发送需求方。

同时召集宣讲会，把新功能向所有利益相关方进行宣讲。

最后，流程制定出来后，要发邮件给所有相关部门，再安排个培训大会，要签到的那种，目的是“勒令”大家配合。

由于流程过于繁琐，总会有人落掉文档、错过窗口期，这样就能名正言顺地推掉了。

五、不要信任其他部门，不要为了提高效率分工协作

接到一个新需求，追问背景+看数据只是基本操作，“负责任”的产品，不管需求有多小，深度和广度上都要挖掘到位：

深度上追踪数据来源，广度上厘清所有关联项。

比如对某个功能，销售有自己的建议，不要参考，一定要亲自调研，最好能直接约谈客户。

再比如出现一个异常，开发有自己的解释，不要相信，直接杀到最底层，自己去看服务器日志！

在你追杀式的“需求调研”过程中，需求方很可能临阵退缩决定收回需求，可是一个“负责任”的产品不能半途而废，毕竟深挖需求是政治正确，就算别人指责你抓不住重点也能反驳回去。

六、时刻准备免责和甩锅

也别忘了免责。核心是“书面证据”：即没书面证据的都不重要。

当别人质疑你时，就能以“之前没沟通过”、“邮件早就发你了是你自己没理解”“以邮件为准”之类的话术免责。

七、工作内容不能透明

设置重重帷幕，才有空间夸大自己的工作量和重要性。

比如，在某系统点击一下就能完成的工作，只要对方不知道，就可以夸大成要一整天来处理的复杂工作。

八、闭门造车

业务提出来的需求先放一放，放飞产品自己的想象力去设计。

反正做什么、什么时候做，最大决策权在产品，不要让对产品一窍不通的业务部门来干扰你。

耗费产研团队大量精力做出来的东西，运气好的话，能直接作废。

九、团队最好能异地办公

有条件的，可以在不同城市分设办公区，没条件的，一个在海淀一个在朝阳也行，总之团队能不在一起办公就不要在一起，尤其是团队leader最好和成员分开，例如leader在上海，其他成员在北京。

大家不见面只线上沟通，才方便摸鱼。

最好经常出差。出差最棒的是路上花的时间也算工作，在天上飞来飞去即使什么产出没有也可以让自己显得非常忙。