技术

IT这个行当之需求与时间管理 golang结构体和包中的类型或基础类型定义方法 golang中结构体的初始化方法(new方法) 项目管理总结 python函数式编程之-装饰器(Decorators) python文件批量处理 Go,互联网时代的C Python推导式演变(Comprehensions) 项目管理感悟 golang学习简单例子 了解GitHub工作流【译】 PHP Socket的使用 Apache 日志文件格式及简单处理 Python脚本--下载合并SAE日志 PHP命名空间及自动加载 基于CSS3实现尖角面包屑 部署Ceilometer到已有环境中 OpenStack Ceilometer Collector代码解读 OpenStack Ceilometer数据存储与API源码解析 OpenStack Ceilometer中的Pipeline机制 OpenStack Ceilometer Compute Agent源码解读 学习Python动态扩展包stevedore 学习Python的ABC模块 Python包管理工具setuptools详解 OpenStack Horizon 中文本地化 WSGI学习 在虚拟机单机部署OpenStack Grizzly 学习使用python打包工具distutils python包工具之间的关系 给OpenStack创建Ubuntu镜像 OpenStack Grizzly Multihost部署文档 为什么使用pip而不是easy_install HTML中meta标签viewpoint的作用 交互式编程-IPython 页面提速之——数据缓存 给OpenStack创建Win7镜像 Ceilometer的命令行使用 部署一个ceilometer-horizon项目 给OpenStack创建Windows XP镜像 几种企业的存储系统 概念模型、逻辑模型、物理模型的区别 五中常见的开源协议整理(BSD,Apache,GPL,LGPL,MIT) OpenStack监控项目Ceilometer的一些术语 VNC和远程桌面的区别 OpenStack Ceilometer项目简介 虚拟化与云计算中KVM,Xen,Qemu的区别和联系 调试和修改OpenStack中的Horizon部分 JavaScript变量作用域 kanyun worker原理 kanyun server服务 在OpenStack中部署kanyun kanyun的api-client命令 sae下的python开发部署和一个简单例子 OpenStack Nova内部机制 PHP可变变量 JS中防止浏览器屏蔽window.open PHP操作Session的原理及提升安全性时的一个问题

标签


为什么卖产品的比做产品的挣得多

2014年04月10日

在公司里程序员的工作非常辛苦,项目组忙的时候加班很多;而公司的销售整天吊儿郎当的,奖金却很高,感觉自己的血汗都成了销售买房换车的垫脚石,很不公平。

今天探讨一下公司销售人员的收入组成,花点时间谈谈为什么卖产品的(销售)要比做产品的(研发)挣得多。

读过『黑客与画家』的同学应该对Graham提出的「财富守恒定律」有印象:「如果你想要要赚100万美元,那就不得不忍受相当于100万美元的痛苦」。你可以将这痛苦分散到你接近四十年的职业生涯里慢慢承受,也可以集中在几年时间里一起担当。

相比于安安稳稳坐在公司里的研发人员,销售人员要经历相当大且密集的痛苦。

我有个朋友曾经做电话销售。他告诉我他们的要求是每天必须打够4小时的电话才能达标 —— 他们有专门的监控设施,精确记录从客户接通电话到挂断之间的时间。你可以大概估算一下,需要花多少时间,打通多少个电话才能凑够240分钟的通话时间?而且这些电话都需要在大致七八个小时的工作时间内拨出?

如果你看过「当幸福来敲门」,你应该能感受到那种忙碌到让人抓狂的紧张。

做Sales operation的朋友也跟我讲了她们公司的各种sales的故事:有个sales为了挽回一个大客户,一个多月风雨无阻地守在别人单位门口;她的老板,以前做sales时去一家竞争对手锁死的单位时次次被人直接赶出去,就差在门口立个牌子「xx与狗不得入内」。

她们公司可不是个小而无名的公司 —— 她们是一家顶尖的世界五百强。

所以不要矫情于自己的辛苦 —— 做研发的再辛苦也不过是工作时间上的折磨,不会有精神肉体的双重折磨。换到战争年代,咱们就是在兵工厂里造枪造炮的工人,而销售是真正拿鲜血换阵地的战士。

当然,如果这个世界以痛苦的多少来衡量收入的话,那么估计年轻力壮的都应该去练胸口碎大石了。你的一切付出,包括承受的痛苦与压力,只是performance的表现形式而已。真正重要的是,你究竟做出了什么样的performance?

比做出什么样的performance更重要的是:你的performance究竟该怎么衡量?

对于销售线上的员工,performance有这些维度衡量:

order: 签了多少单子 revenue: 销售额是多少 margin: 利润是多少 cost: 花了多少钱才赚了这些钱 这些维度都会和当期的任务额对比(是否完成任务),和去年同期对比(同比增长如何)。除此之外,还要看market share的变化。比如说今年市场非常好,整体增长40%,你原来占市场份额30%,今年只增长了20%,那么你的市场份额实际缩小到25.7%。即使完成了任务额(这种情况下,任务额制定的有问题),performance也会大打折扣。

这些都是大面上的衡量手段,还有一些更加细节的:

revenue/order的转化率 margin/revenue的利润率 cost/revenue的费用收入占比 等等。所有这些都会在月末,季度末,年中以及年末进行review。所以销售线上的员工能赚多少钱一目了然,努力提升业绩,就会得到按比例提供的奖金。

相反,研发的performance衡量起来很困难。我们可以依葫芦画瓢列一些度量手段:

bugs: 解了多少个bug customer issues: 解决了多少个customer issue features: 做了多少feature LOC: 写了多少行代码 ... 和销售的那些度量手段和数据大为不同的是,靠这些来度量研发的performance似乎都可以,但又都不靠谱。首先,所有这些手段都无法清晰地和公司的营收挂钩;其次,这些手段模棱两可,有些是度量起来麻烦,有些是绝对值不说明问题。比如说一个kernel的bug和一个UI显示的customer issue显然不是一个量级的问题,简单地认为customer issue地权重大会导致基础性的,难啃的bug被滞后处理。LoC就更不靠谱了,早年软件外包红火的时候大多以LoC来衡量价格,结果接单的公司就拼命地多写代码来充业绩,能写10行完成的函数恨不得写出50行来。

所以研发工作,尤其是个人的performance很难通过客观的数据清晰地度量。既然无法很好度量,那么我们就只能拿个相对而言「平均」的薪酬奖金。

还有一个原因是工作的重要性。一个产品的研发可能成百上千,每个研发人员都是里面的一颗螺丝钉而已;而销售人员,一个大区也配备不了多少(因公司而异),我记得在神州数码,一个销售可能就负责某个产品一个大区的事务。我们出来做事,最怕那种多你不多,少你不少的工作。但很无奈的现实是,研发恰恰是这样一个工种,尤其在「大」公司。再牛的黑客和数十个平庸的程序员放在一起一平均,performance也就不出彩了。

所以,好的程序员拿不到好的销售的薪酬的零头,是非常合理的。

有些事情知道了仅仅是为了自己好受些,相信我,不要因此试图改行,绝绝绝大多数程序员做不了销售的。

那该怎么破?好好读读「黑客与画家」吧,相信你能找到答案的。


golang-python学习心得
微信公众号:golang-python
个人微信ID:fuhao1121
网址:http://fuhao715.github.io
QQ:243312452
编程学习心得轻松学编程
回复:『 p 』查看python课程回复
回复:『 g 』查看golang课程回复
回复:『 m 』查看项目管理
回复:『 w 』查看其他文章
点击"阅读全文"进入http://fuhao715.github.io