裁员过后，云厂商也要增加新岗位

我早就规划这文章很久了，看到马斯克要成立D.O.G.E部，感觉还是很押题，忍不住凑一下热点。

你们看，马斯克都要通过增设部门的方式来降本增效了……

一、增员解决管理规划等问题

公有云在2025年普遍会宣布实现扭亏为盈，但是，现在的盈利只是纠错带来的短期红利。云行业现在“加价超卖”的盈利模式并不可持续，我为此专门写过一篇《五年后云厂商怎么盈利》。

• 那些经过裁员扭亏为盈的云厂商，还能继续狠砍人力支出，但要继续裁员，就要精准识别员工的能力。云厂商还可以精简掉很多“刷存在感+免责+添堵”的标准和流程，这也能盘活大量资源，提高生产效率。

云厂商现在的管理工作有个明显的缺点：无论销售线还是产品线，管理者只关注财务数字（营收和利润），不考核公有云专业性业务指标。本文建议增加的几个岗位，大多都是为了摆脱这种原始状态。

• 云厂商都有同集团的兄弟业务线，这些业务线无论做好做烂，管理者不仅会关注营收财务数字，也会关注本行业的业务指标。而云厂商不了解该关注哪些业务指标，还总是遭遇数值造假，所以大家就退化成只关注财务数字了。

• 云厂商缺乏专业指标和数值刻度，只能通过财务数字来管理公司时，这是一种很呆滞、低效、不准确的管理方法。画饼分权阶段很容易变成赌徒比胆量，而验证财务数字需要等几个月甚至几年，产品能否售出和盈利也是个多因多果的混沌问题。

• 举个离题千里但有借鉴意义的例子，某个主管经济的大领导，最关注的是工业用电量、物流货运量这类不易造假且影响深远的基础指标。公有云也需要找到符合本行业的业务指标。

云厂商不仅要通过裁员等手段，提高执行层员工的能力和效率，更要新增几个“从未有过的”专业岗位。这些岗位并不是新的冗员，而是能逐步让云厂商的管理规划有目标，关键执行有保障。

• 本文介绍的几个工作都是从零新增的岗位，可能大家已经见过同名甚至同责的岗位，但这些工作确实没有人完成过。

二、打造“领导驾驶舱”

云厂商应该为高管提供数据可视化平台，让高管能看到重要的业务指标数据。

• 企业里有很多数据可视化平台，其中专供高管看的叫做“领导驾驶舱”。搭建数据可视化平台和对接数据都很简单，但是，因为大家都不了解公有云有哪些重要的业务指标，所以公有云缺乏可用的“领导驾驶舱”。

云厂商需要为“领导驾驶舱”而新增高级顾问岗位，此岗位从业者必须对云产品或云销售有较深的理解能力，不仅能为领导筛选出关键业绩指标，还要对每种业绩指标进行解读，面对异常指标还要给出处理预案。

• 每个公司内部都有一些全体员工可用的信息化系统，但“领导驾驶舱”和这些系统的工作逻辑完全不同，不要将两者混为一谈。

这是一种很偏门、很看领导个人习惯的工作，很难进行标准化介绍。这个工作在完成数据定义和接入以后，并没有正式完结，顾问还要经常对异常数据进行校验确认。

• 虽然听起来难以置信，但是我为《数据出错》专门写过文章，我的书稿中也郑重提醒了数据出错的风险。产品线给监控和计费等部门的数据出错后，这只是失误不是故障，犯错方会“知错就改、改了再犯、犯了再改”。

三、为销售戴上CRM紧箍

云厂商最大的管理漏洞，就是对销售体系“等到年底看数字”。这不是以目标为导向，而是撒手糊弄不做管理。云厂商需要给销售带上紧箍咒，将销售的推销过程纳入管理范围内。

• 销售签单一半看个人努力，一半看外界运气，只看数字不看过程的管理方式，无法识别出优秀销售。后续行业竞争加剧，每个云厂商必须识别和收拢优秀的销售。

• 销售是其他所有部门的上游需求部门，高管只看数字不看过程，那就是默许销售肆意浪费内部资源，这也是云厂商大量冗员的重要原因。云厂商想要继续降本增效，就得把好钢用在刀刃上，只给优秀销售的明确需求提供资源支持。

• 销售签单的等待时间太长了，如果只看数字不看过程，云厂商需要等待几个月甚至几年才能作出一些管理判断，这就导致管理决策的低效和呆滞。

• 前线销售的错误反馈，会极大地误导了云厂商的管理决策，比如，我谈《客户谈降价怎么办》时，就介绍了某些Five只能听懂也只会说出“降价”这个词。让销售把推销全过程录入系统，能够减少丢弃内容和胡编乱造的重要手段。

要管理销售，CRM是个好工具，但是，现阶段CRM根本不是合格的紧箍咒。云厂商需要招聘一些懂销售、懂客户、懂产品的CRM实施顾问，让CRM的内容简化，但格式变严谨，易于统计且和后端支持联系起来。

• 通过严谨的格式，让销售的工作易于统计。销售和客户之间的所有互动行为，包括但不限于宣讲、测试、签单、投诉、流失，都可以在CRM系统里做成“下拉菜单+勾选框”。这样既可以减少填表难度，更让CRM数据变得有结构、有逻辑，方便统计和触发下一步工作。

• 让销售需求和后端支持连接起来。销售需要经常找后台同事承接客户需求——包括常规测试实施和提能降价等等硬核挑战。需求起自哪次沟通，需求的具体内容，销售对需求的判断，需要哪位同事工作到什么地步，这些信息也可以总结成“下拉菜单+勾选框”。这样云厂商就可以统计销售花费了多少公司的支持资源，还能监督支持部门是否胜任了工作。

四、名副其实的产品管理

销售和产品经理都是提需求的部门，上一节中对销售脱离管理的乱象描述，都可以复刻到产品经理岗位上。此外，产品经理只对总体销售额承担“陪绑”责任，用业绩管理产品经理是严重的倒果为因。产销日常配合经常脱节，产品和销售相互甩锅时，高管都分不清谁是混蛋。

很多公司都有同名的产品管理部门或者产品技术委员会，我也给他们做过正式培训。但是，这些只是同名岗位，和本文内容无关。真正的产品管理工作，需要以组会考核的形态，完成三类重要工作：

• 真正需要公司层面做管理的产品经理不会超过20人，因为管理基数小且不同产品的差异大，产品管理不用在IT系统里搞模板，通过开会审查并且长期留证就足以完成管理工作。该工作只需要两三位专职顾问，另外找一些产品、售前、售后当兼职顾问即可。

• 产品管理的第一个重要工作是，检查产品经理真正的工作业绩。这些工作业绩是，产品设计者提供权威的产品介绍、竞品分析、接入实施、技术服务相关的资料，并且要保证这些资料内容准确、有说服力和竞争力。这些文档必须简单易懂，产品管理团队不用刻意了解产品，在评审会上读不懂这些文档，产品经理的工作就是不合格。

• 产品管理的第二个重要工作是，检查产品经理真正的技能水平。云产品会有大量的运营数据，整理这些数据的源头和证据、表象和趋势、对内外影响关联、数据调整方法，就是产品经理最重要的工作。让产品经理介绍这些数据的来源、真实性和相互逻辑关联，就是在考察他们的技能水平。

• 产品管理的第三个重要工作是，确认产品在公司的定位是否合理。所谓产品定位，就是这款产品到底是“主力营收型云产品”、“技术支撑性云产品”，还是不重要的云产品。产品定位点低没关系，公司对产品的要求也就低了；产品定位高了，高管就要为产品张罗资源并增大关注度。

五、对售前进行改组换岗

我的很多读者和现实好友，都是解决方案架构师（简称SA）。我的书稿第14章和《减员云售前可以降本增效》中都公开介绍，SA岗位该收缩乃至撤销了。这些SA在读完全文后，并没有恐惧愤怒，而是支持我的主张。

本文从公司管理的角度，再重提一下我对售前部门的改组建议。云厂商应该让大部分SA改回售前的本名，既能节省人力支出，还能让公司管理变简单。

• 解决方案架构师也是架构师，水平再差也得是个中高端工程师。当年的云厂商因为产品不完善，需要解决方案架构师承担“现场产品经理+现场实施专家”的职责，该岗位需要管理一堆技术工程师，和销售没有隶属关系而是跨部门合作。

• 云厂商在大肆扩张时，根本找不到足量的SA人才，只能招聘普通售前冒充架构师。这个同名岗位下有两批完全不同的人，带来了严重的管理混乱。云厂商因为给正牌SA很高的待遇，所以给这些普通售前也提供了高薪。因为售前就是依附于销售的，云厂商要求正牌SA也归属销售部门，给普通销售当抹布。

• 正牌解决方案架构师在销售线发挥不了什么作用，不仅仅是没有工程师干活，根本原因是自己没权限作出产研决策。这些SA人才应该转岗去做产品经理，他们懂技术、懂客户、懂业务，就是做产品经理的最佳人选。

整体销售线，或者一级销售团队，需要留下两三名正牌解决方案架构师。但是，这几个留守SA的定位和用法和普通售前完全不同。

• 留在销售团队的正牌SA，只为销售大BOSS服务。普通销售就找普通售前做支持，普通售前支持不了的客户项目，就不要再浪费公司资源了。

• 留在销售团队的正牌SA，主要工作是写文档和做培训，把自己的能力复制下去。SA需要依据产品经理提供的权威资料，提供模板化的客户拜访、产品介绍文档，在培训之后做几次考试，帮公司筛选又聪明又勤奋的销售。

• 留在销售团队的正牌SA，可以在销售大BOSS的指挥下，跟进最重要的几个客户项目。客户很喜欢这种直通云高管的技术专家，销售也不能垄断重点客户的客情关系了。如果有带客户跳槽到新东家的销售，新东家派个技术专家协助你搞客户关系，这没什么不妥的吧？

• 留在销售团队的正牌SA，可以代表整个销售部门对产品线提出改进需求。这是一个大销售团队的需求，产品经理必须郑重处理认真回应，否则不是高层投诉就是全员拒卖。

六、重申技术服务工作

很多朋友都不理解，我为什么这么重视“售后客服工作”？但这真不是客服，甚至都不是我发明的新工作。我呼吁新增这个岗位，就是云厂商对如何服务好客户缺乏概念。

首先从公司管理的角度分析，云厂商在面向大客户时，客户的技术团队和产研故障，处于管理失控状态。

• 云厂商和客户之间仅凭销售建立单线联系，而且销售很容易拦截下所有的客户信息，让公司和客户彻底隔离。这样的害处有很多，我就举个《客户要砍价怎么办》的例子，请大家仔细想想，是客户真的只看价格，还是销售只听得懂价格？

• 云厂商现在只在维护和客户采购部门的关系，并没有维护和客户技术团队的关系。云销售并不是客户技术团队的朋友，云销售找客户技术就是去套情报了，客户技术找云销售不是投诉就是索赔，售前售后也要配合销售的沟通节奏。

随着公有云进入存量竞争的时代，云厂商需要竭力避免客户流失。但是，因产品质量差和故障导致的客户流失，在云厂商内部处于听天由命状态。云厂商需要新增技术服务角色，该角色最大的价值，就是扛下客户流失的责任。

• 大客户的流失就是三类原因，第一商务问题，第二客户业务萎缩，这俩都算销售的锅；第三，因为自家产品技术差或故障，导致客户流失，这个锅现在扔到了销售头上，但销售有能力推进改善吗？平台故障或者技术差，就是研发水平不行，产品经理都惹不起研发，领导也不知道具体是哪一位研发能力差，让销售硬扛这类客户流失，就是管理失职。

• 云厂商需要借鉴传统IT企业（SaaS企业除外）的经验，新增一个能和客户技术部门交朋友的技术服务专家岗位。这个岗位懂技术，能够推动改善产品质量，也能够和客户技术部门交朋友，只要此岗位能够对研发自然人进行追责，就能够承担“因产品质量导致的存量大客户流失”的责任。

除了挽回客户流失之外，技术服务专家还能做很多工作。比如，当客户同时使用多云时，把优质负载留给本云，把垃圾负载留给友商；再比如，向产品经理提供详细的需求和环境信息，帮助改善产品。但限于篇幅，就不展开介绍了，大家有兴趣可以看看我的书籍第17章和《技术服务工作的呼吁推演》一文。

结语：事在人为的新起点

我之前写了很多呼吁裁撤冗员、降本增效的文章，但本文是在呼吁增员增效，两者并不冲突。

云行业要走向高效正规化，不仅仅要裁撤冗员，更要从基层执行力到高层管理规划，都引入称职的新鲜血液。执行层增员要靠《从甲方挖掘高手》，而管理概念的革新，需要在持续迷茫后痛定思痛，然后看看我这篇文章。

本文呼吁的增员，如果运作不当，确实会成为新的冗员，而且这种冗员会感染管理层，对公司的伤害会更大。但是，这是运作不当的执行问题，并非本文呼吁的方向有误。成年人要有复杂信息的逻辑判断能力。

本文来自微信公众号：云算计，作者：曹亚孟