国内大厂 To B 领域业务的组织协作的困境

作者: 唐杰 分类: 天下杂侃 发布时间: 2020-08-26 17:39

目录:
一、领导层的困境
二、人才的困境
三、组织协作的困境
四、赛道选型的困境
五、写在最后的话(写在第四篇结尾)

三、组织协作的困境

公司大到一定规模,就没办法再像小团队那样进行协作,360 度人才评估、绩效、OKR、KPI、季度考核、年末考核、晋升答辩…… 管理者们发明了一大堆制度和工具,妄想能让团队继续保持高效协作。殊不知,这些方法和工具只是在降低管理者的工作难度,对于一线效率是大大的负增益。

一个 toB 小公司的 PM 洞察到一个改进点,简单地在草稿纸上画了一下草图,利用中午吃饭时间和关系好的研发小哥们简单说一下,吃完饭回来找前端快速出一个交互和界面,到了晚上 10 点班车发布后,PM 的微信上就收到消息 “那个玩意儿已经发布了,你快去线上测下看看”。

与此同时大厂又是怎么样的风貌呢?

PM 首先需要撰写一篇狗屁不通的 PRD

产品总监需要像上朝一样一一评审

设计得出一套保高保原型,然后找人调研测试,因为只有这样研发才肯开搞

技术方案和文档一写就是一两天

好不容易代码交付,又是一堆测试和发布流程

周报上收获满满,客户那一个双周干着急

我知道看到这里有人要坐不住了,肯定会说:
「不这么做,怎么保证质量?」
「软件作坊那样做很不符合规范」
「这样搞就是为以后埋坑」
「北大青鸟培训班出来的才这么开发」
「听你这么说,就知道你没系统学习过软件工程」

来我先统一回复一下:你没理解我说的意思

我当然不反对科学、规范、系统地进行软件研发工作

互联网圈很多都是高学历的聪明人

你们都知道什么才是理想化的协作方式

然而在大公司,这一切都变味了

美国有「政治正确」,而互联网公司有「流程正确」,规范和方法成了避免背锅的工具,让本来应该简单敏捷的迭代过程变得复杂而冗余

非常不敏捷的「敏捷开发流程」只是一个例子

除此之外,大厂还有一万种方法来拖累组织协作效率

一个季度就 13 周

大厂需要在上季末花费 2 周来总结复盘

再在季度初花 2 周来确定计划目标

接下来的 2 周通常是目标的拆解和确认

你算算吧

真正能干活儿的时间还有多少

为了管理庞大的组织体系,大厂花费了非常多的心血在制定组织协作规范上

而这样的规范正是让公司变得臃肿低效的元凶

当大厂的 toB 团队面对市场时,沿用下来的、不可更改的协作规范变成了束缚他们的枷锁

市场的声音、用户的反馈都在淹没在了无尽的 meeting schedule 里

你说,这仗你怎么打得过?

作者:Passluo
原文链接:https://twitter.com/passluo/status/1290750619624411136

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注