售前5年,两种人生,多重感悟

企业动态
我觉得还是有必要解释一下我为什么把以前叫做商务演示。你可以不同意我的观点,但你不能剥夺我表达看法的权利。/坏笑。

[[205252]]

售前5年,两种人生,多重感悟

我叫李松波,李松波的李松波。2009年进入润乾到现在已经8年头了,从2012年开始做售前也5年了,说句心里话,只有从去年(2016年)开始我才感觉我做了真正的售前,以前不叫售前应该叫商务演示。这里说说这两年的感受,尤其是今年我们毅然决然转型去做数据计算后。

为什么以前是商务演示?

我觉得还是有必要解释一下我为什么把以前叫做商务演示。你可以不同意我的观点,但你不能剥夺我表达看法的权利。/坏笑。

众所周知润乾是做报表工具起家的,润乾报表经历了相当长的一段辉煌时期,我还清楚记得刚来公司时维护销售线索分发的程序,将网站上客户提交的信息转发到该区域的销售邮箱,每天我能看到大量的客户主动联系我们。我们都知道这种找上门来的客户往往成单率非常高,尤其是在前些年,找到我们的客户数量非常之大,我当时真切的感受是:做销售好简单啊,坐在家里等线索就行。那时候我并不知道润乾发展初期经历的那段艰难。

后来我从售后转去做售前了,开始了商务演示生涯。一般客户找到我们后,我们会跟客户做交流,交流时摆开PPT和DEMO嘡嘡嘡开讲,然后回答一些技术问题,然后,然后客户就直接买单了。这可能也是为什么小马哥觉得以前成就感十足但现在很失落的原因。所以前两天蒋总找销售谈话的文章我看到里面说以前的销售更偏商务,我当时第一想法是以前的售前也不太像售前,充其量也就是个商务售前。

凡事都有两面性,太好卖的产品会滋生出我们的惰性(符合进化论规律),我们没有了开疆扩土的魄力、没有了百折不挠的精神、没有了料敌制胜的敏锐、还没有什么自己补充啊。正常其他产品型公司应该不会这样,润乾之所以出现这种局面我分析是因为润乾报表当年独领风骚的缘故,技术强产品好,一家独大。那时候可领先追赶润乾报表的那个小兄弟不止一两个身位。所以造就了商务型销售和商务型售前也就不奇怪了,而且我们看到当年的屁股后面的那个小兄弟现在已经长大成人了,我想这跟人家在后面厉兵秣马、千锤百炼、劳筋骨饿体肤也有关系,虽然蒋总都承认公司经营方面出现了一些问题,但难道我们自己本身没有问题吗?

凡事都有两面性,太舒服就会容易空虚,不是郭德纲说的那种去干完XXX事后的那种空虚,是对售前职业的迷茫。我预见到了我将来可能什么都不是,做不了销售,搞不了研发,就悬在中间了。所以相当长一段时间我在网上找售前这个职位的发展方向,关于售前的论坛也不多(SYSVS算是比较好的了),最后总结出售前的出路无非就是转做销售、转做研发(少数)、继续做售前做咨询,也是那时候我才知道售前也分项目型售前和产品型售前,分别针对做项目和做产品的公司,前者一般很牛X,尤其是华为的售前,但显然我属于后者。

我几乎一直迷茫到去年(2016年)初润乾重组了营销团队,确定了发展方向。去年一年发生了我很多人生的第一次,第一次POC、第一次单独面对客户、第一次陪客户喝酒(喝倒那次你们不用问我,我也不会说)、开始高频率出差等等。去年一年我一句话总结:痛并快乐着,收获颇丰。

我扯了这么多,其实下面才是我重点想说的。/别打我。

我的变化

去年一年让我知道了即使是产品型售前也完全不是我先前想的那样,说句大家可能不爱听的话:现在我们卖集算器不好卖是正常的,以前那种等线索演示一次就成交的销售模式才不正常。让我认识到售前除了技术能力外,沟通、交友、知识面(不仅限专业)甚至喝酒都很重要,当然技术能力最重要,尤其像我们这种技术性很强的产品公司,主要面向的又都是ISV和SI之类的合作伙伴,所以下面的我的改变还是先从技术说起。

集算器和报表不一样

现在可能看不到用户在报表交流现场两眼放光了,放光现象在2003年润乾报表出现的相当一段时间还可以看到,但是现在没有了。不仅是对润乾报表不放光,其他报表工具也一样,我问过很多用户确实像现在大家经常说的报表工具技术已经非常成熟,原来润乾报表的技术壁垒已经被突破了。我曾经见过一个用户把报表工具的采购打到硬件包里,可见已经标准化到什么程度了。虽然国产报表工具的标准是我们建立的,那又怎么样呢,我们种出了第一颗白菜,但是指望客户现在还对满大街的白菜两眼放光怎么可能(这个类比如果蒋总看着不舒服就假装没看见吧,因为我不会删掉)。

现在有很多客户会对集算器两眼放光,虽然很多最终也没买(关于集算器销售遇到的问题和不是问题的问题不是这次讨论的重点,这里不展开)。所以我说集算器和报表不一样(场外音:废话,当然不一样,看名字就知道不一样)。

集算器是做数据计算的

我们知道报表工具做出来的报表是负责数据呈现的,虽然也具备一定计算能力,但是术业有专攻数据呈现才是它的强项,但集算器不一样,这家伙是做数据计算的。何为计算,根据已知量算出未知量,广义来讲任何数据处理过程都是计算。因此数据清洗转换加载是计算,汇总表跑批是计算,报表/大屏/BI数据源准备是计算,数据整理是计算,什么实时的、离线的,为报表服务,辅助数据库,辅助hadoop等这些涉及数据处理的过程都是计算,也都是集算器的强项,只不过目前我们没有针对各个场景做封装,而是把集算器设计成一个开放的计算框架,保证了高度的灵活性。我并没有说这么做一定好,凡事都有两面性,这也常常给客户造成集算器既不是ETL工具,又不是数据库,又不是巴拉巴拉的印象。如果从开放的计算引擎,计算语言的角度去看可能会好一点,所以怎么跟客户讲也挺关键的。

所以我们明显能看到,集算器能够hold的场景更广阔,而报表只是应用层的一小丢丢,这可能也是蒋总说集算器市场更广阔的原因之一吧(没和蒋总沟通,理解不对请纠正)。

这自然而然会牵扯到原来销售报表不涉及的一些知识内容,客户两眼放光正是源于这些内容。

搞数据计算涉及到的内容

集算器本身

让客户产生极大兴趣首先源于集算器本身。

集算器的设计确有独到之处(言外之意也有缺点),本文不是软广,不吹不黑讲道理,有说的不对让老板感觉辣眼的地方以蒋总的肚量相信也不会和我计较。关于集算器的技术原理、功能特性请移步观看蒋总亲自撰写的【集算器.docx】。

这里还是简单举几个例子,高效的指针式五表连接会比ORA快一倍,全面的内外存计算技术,尤其外存计算还支持多路游标、管道等处理方式,无中心机的集群环境可以有效避免单点失效、灵活的内外存数据冗余方案、可选的行存列存、字节表和全局变量用空间换时间等。集算器设计了一些通用和专用的处理方式,和hadoop里各个组件适用的场景不同类似,这些专用的处理方式在某些情况下处理会特别高效。这就随之带来一个问题,原来一招鲜吃遍天的日子一去不复返了,在数据计算的处理过程中要考虑的情况很多,不存在配置配置都能搞定的情况,要不hadoop生态里咋会有那么多组件。

集算器的应用确实有难度,别拿报表跟它比,大家不是干一个事儿的。要实现这样那样的计算有时就得这么麻烦,而集算器在设计时已经充分考虑了计算代码实现的复杂度问题,现在用集算器写起来感觉很难的原因是对它不熟悉,你用JAVA用存储过程会更麻烦,只不过大家对后者更熟悉一些,如果大家对集算器也很熟悉,我的经历是集算器代码无论是简洁性(长度)、还是可读性可维护性都完胜后者。这点相信我们更资深的同事会有更深感受,大家可以再咨询咨询他们,像星爷、虎哥。

以后如果客户再拿报表跟集算器比,我们一定要义正辞严不管他爱不爱听都要先说清楚,这玩意不说明白后面没法干。

集算器之外

让客户产生兴趣另外的原因是他觉得我专业。

搞计算,除了集算器技术本身还会涉及很多内容。首先可能就是集算器对位的产品,没有比较就没有伤害,现在常见的是MPP和hadoop,没有非常强烈的竞争关系,有时还可以和集算器混合使用,对于这两类产品咱们有很多同事之前都是搞这个的,我突然意识到我之前居然没有好好利用这些资源积极请教学习导致我现在仍然停留在一知半解的程度上。即使这样,我还能刷新很多客户的认知,客户即使最后不买他也可能会和我建立很好的联系。我这个人也比较喜欢交朋友,以前一些没做成的单子有些客户现在还联系。

这里说句题外话,蒋总经常督促我提高技术修养,很惭愧我做得并不好。所以写在这里鞭策一下自己。

还有一种情况客户可能因为技术跟我建立很好的关系,就是我实实在在地帮他解决了问题。搞计算跟原来搞报表真的不一样,即使是跟报表相关也不一样。举个例子,我最近接触了两个用户说速度慢想优化,这两个场景都不是报表,都是数据库本身的计算。性能优化是我们经常碰的场景,有时候我们听到客户报表慢会非常兴奋,不是幸灾乐祸而是提升性能正是集算器的强项。但有时我们直接冲上去动手就干效果却不尽人意,非技术方面的不讲,从技术角度来说,我们应该先做一些前期分析工作,查询花了多长时间、数据规模有多大、做的什么样的计算、性能瓶颈是出在I/O上还是CPU上、机器的I/O吞吐能力如何、CPU的核数和主频多少等,这些信息跟客户一起碰出来以后往往就能算出来当前配置下的极限计算时间,然后在去判定客户的计算时间是正常还是不正常的,有时候一算完他现在的时间是正常的,比这快才不正常。大家可能觉得这些工作是必须的啊,有啥说的必要吗?因为我主要想表达我原来搞报表连这些基本的东西都不涉及、涉及也搞不懂,不光我,有时候客户也没有这个意识,我跟客户把这些分析给都摆出来客户会很认可,如果去优化可能达到的效果是什么样的,如果这个理论值客户能接受我就动手做,否则就没有做的必要了。

其实我主要想表达的是搞计算涉及的知识层面更广、更深,相对应用层的报表更能体现一个人的能力和价值,我现在只是接触了皮毛。不管咋样我现在对数据计算这条路产生了极大的兴趣,不管将来做不做技术都还会一直在这个领域里深耕,借用朱总理的一句话:无论前面是地雷阵,还是万丈深渊,我都将一往无前,鞠躬尽瘁,死而后已。

我的兴趣在计算

因为售前和销售是夫妻,我经常跟销售在一起,有的时候甚至一起吃一起睡(仅限男销售,其他性别概不接待),我经常会站在他们的立场思考问题,思考完经常得出一个结论:难,真难;如果前面还要加上一个副词的话那就是:真TM难。但是从另外的角度来看,哪有不难的呢?公司、产品啥都牛叉坐在家里等线索不难,但是那有啥意思呢,别的不说,也挣不来钱不是。

销售是公司创收的唯一来源,有时候我们说客户是我们的衣食父母,我觉得销售至少也算大爷大妈(此处应该有掌声)。所以有时候为了业绩卖卖报表没啥问题呀,这块我就敢跟蒋总掰扯,有些客户很重要,基于公司战略、客户关系就需要聊聊报表方面的合作难道不可以吗?但是最终一定要转,这种临时性的策略不长久。

我铺垫了这么多其实想说一件事,不是售前不支持销售关于报表的工作,是我们对数据计算产生了真爱。这也是现在为什么有时我们会拒绝搞报表的原因,当然现在基本不存在分歧了,咱们都已经走上了同一条康庄大道。所以有时候一些任务售前和销售一起来评估(不限于报表),如果我们都觉得有必要那就搞,如果有分歧像宏哥说的上升到他那里去解决,所以不要因为出不出台、做不做的问题憋在心里,摆出来大家讲道理。谁无暴风劲雨时,守得云开见月明,没有解决不了的问题!

最后唠叨

根据最近的一些感受,个人的一点想法和建议。

性能优化要慎重

我们经常帮客户做报表优化、性能优化,这类工作确实是集算器的强项,但最好把前期工作做的七七八八再动手,否则效果可能不理想。

集算器试用要协调技术资源配合

集算器的确存在使用门槛的问题,上面我已经说了做计算都这样,集算器还算简单的呢。所以客户在用过程中肯定有各种问题,这时候最好投入技术资源配合,别让客户乱倒腾,否则效果往往不好,包括验证场景的选择最好我们也一起参与。现在除非客户主动提,否则我都不说官网下载你随便试用的话。

以上愚见,望轻拍。

责任编辑:武晓燕 来源: 润乾
相关推荐

2010-03-11 14:34:47

Python环境

2011-03-03 10:26:04

Pureftpd

2020-03-06 08:39:03

5G云计算技术

2009-09-14 19:25:09

Ruby form

2010-09-07 11:09:59

2010-10-11 10:31:51

MySQL分区

2010-02-24 14:25:48

WCF地址

2013-05-27 14:31:34

Hadoop 2.0

2015-12-31 09:56:22

2021-08-11 06:57:16

ShuffleSpark核心

2010-07-14 16:28:58

配线架

2010-08-06 09:38:11

Flex读取XML

2009-06-23 18:18:13

SpringHibernate

2023-03-29 13:06:36

2010-04-20 15:32:20

主控负载均衡

2022-03-15 08:25:32

SparkShuffle框架

2010-06-07 17:41:42

Sendmail 配置

2010-08-11 14:22:26

Flex弹出窗口

2010-09-17 09:37:27

Java安装方法

2011-08-09 13:50:01

iPhone动画UIView
点赞
收藏

51CTO技术栈公众号