国内大厂 To B 领域业务的组织协作的困境
三、组织协作的困境
公司大到一定规模，就没办法再像小团队那样进行协作，360 度人才评估、绩效、OKR、KPI、季度考核、年末考核、晋升答辩…… 管理者们发明了一大堆制度和工具，妄想能让团队继续保持高效协作。殊不知，这些方法和工具只是在降低管理者的工作难度，对于一线效率是大大的负增益。
一个 toB 小公司的 PM 洞察到一个改进点，简单地在草稿纸上画了一下草图，利用中午吃饭时间和关系好的研发小哥们简单说一下，吃完饭回来找前端快速出一个交互和界面，到了晚上 10 点班车发布后，PM 的微信上就收到消息 “那个玩意儿已经发布了，你快去线上测下看看”。
与此同时大厂又是怎么样的风貌呢？
PM 首先需要撰写一篇狗屁不通的 PRD
产品总监需要像上朝一样一一评审
设计得出一套保高保原型，然后找人调研测试，因为只有这样研发才肯开搞
技术方案和文档一写就是一两天
好不容易代码交付，又是一堆测试和发布流程
周报上收获满满，客户那一个双周干着急
我知道看到这里有人要坐不住了，肯定会说：
「不这么做，怎么保证质量？」
「软件作坊那样做很不符合规范」
「这样搞就是为以后埋坑」
「北大青鸟培训班出来的才这么开发」
「听你这么说，就知道你没系统学习过软件工程」
来我先统一回复一下：你没理解我说的意思
我当然不反对科学、规范、系统地进行软件研发工作
互联网圈很多都是高学历的聪明人
你们都知道什么才是理想化的协作方式
然而在大公司，这一切都变味了
美国有「政治正确」，而互联网公司有「流程正确」，规范和方法成了避免背锅的工具，让本来应该简单敏捷的迭代过程变得复杂而冗余
非常不敏捷的「敏捷开发流程」只是一个例子
除此之外，大厂还有一万种方法来拖累组织协作效率
一个季度就 13 周
大厂需要在上季末花费 2 周来总结复盘
再在季度初花 2 周来确定计划目标
接下来的 2 周通常是目标的拆解和确认
你算算吧
真正能干活儿的时间还有多少
为了管理庞大的组织体系，大厂花费了非常多的心血在制定组织协作规范上
而这样的规范正是让公司变得臃肿低效的元凶
当大厂的 toB 团队面对市场时，沿用下来的、不可更改的协作规范变成了束缚他们的枷锁
市场的声音、用户的反馈都在淹没在了无尽的 meeting schedule 里
你说，这仗你怎么打得过？
作者：Passluo
原文链接：https://twitter.com/passluo/status/1290750619624411136
