当前位置: 代码迷 >> Java面试 >> 十年小结(19):售前养成计划(上) - 刚开始有点嫩
  详细解决方案

十年小结(19):售前养成计划(上) - 刚开始有点嫩

热度:529   发布时间:2016-04-17 20:49:34.0
十年总结(19):售前养成计划(上) - 刚开始有点嫩
对我过去感兴趣的朋友们,请看十年总结系列文章 

--- (我发到灌水区以后,发现人气很差,看来混个脸熟很重要)

预期中的项目二期因为种种原因推迟了, 
有经验的朋友们应该了解,除了软件公司在抢项目,动用自己的关系来影响用户的立项决策, 
用户企业内部各部门之间也经常有斗争,谁掌握着更多的项目,就意味着更大的权利和利益。 

新公司的老板倒不在乎,毕竟我们这块也不是公司的主营业务, 
而且他觉得二期肯定会有,只是时间的问题,于是他让我做好一期的维护,有时间就对系统进行完善和扩展。 

原来的公司(现在是合作公司)在剥离了研发部门以后,将更多的精力投入到售前和销售, 
奈何没了做技术的支持,跟用户交流只剩下PPT了,连个像样的演示都拿不出, 
见我这边项目结束,人都闲下来了,于是前老板赶紧张罗着让我去支持售前。 


提到售前,就要说说跟我一起卖过来的一个人:南南, 
他年龄挺大,具体岁数我没有具体问过,但应该跟我不在一个年代, 
过来新公司以后,我跟他之间有些暗战,主要是争这个团队的控制权。 

我的个性并不是特别强势,也不是热衷于权力斗争的那种性格, 
但南南来到新公司后,表现出一种想上位的欲望,而我并不认为他可以让我信服, 
于是暗地里较劲,当然,我是绝对不玩儿阴的。 
新公司的老板可能也感觉到了,于是最后的结果是:他的主要精力转向售前,而我管理研发。 
(南南是部队出身的,做事儿很敬业,很认真,我对他并没有什么成见,
他跟原来公司的老板是旧识,老板抓他过来可能也是给了他一些承诺,
再加上他的年龄,所以他觉得自己应该获得控制权,也是人之常情。) 


既然南南转向售前了,那么为什么还要让我也去做售前工作? 
让我踏踏实实来改善产品不好吗? 
你们整天跟用户白话还不够,还要让我去跟用户吹牛,关键是,吹完卖什么? 
(说售前是白话和吹牛,虽然有些夸大,但对很多小公司来说,也并不算过分夸张) 

这些抱怨的话,我暗示过,摆上桌面谈过,老板一副“山人自有道理”的态度,给我罗列了不少理由: 
1、 做产品的不接触市场,永远不可能成功(至理,我现在很认同) 
2、 南南在售前方面还需历练(他南方人,说话口音重,而且一紧张有舌头轻微打结现象) 
3、 为你好,锻炼你(这我也认可了) 
4、 需要为下一个项目努力,否则大家都没饭吃。 
(其实后来我明白这段经历让我受益颇多,但从回忆的的角度考虑,我还是要忠实的描述当时的心情。) 


做售前有两项主要工作:向客户介绍系统和编写文档。 
因为刚毕业那阵子,我就有当培训讲师的经验,所以在人前讲话和写材料都不是问题, 
当然了,如果没有这个潜质,也许老板压根不会让我上,因为毕竟客户也不是那么好糊弄的。 

刚开始,我对售前工作多少有些许抵触心理, 
一方面,是因为开发方面还有太多的事情要做,放下不管去干别的,总觉得不踏实, 
另一方面,说实在的,也有些怵头。 
不怵别的,只是做技术习惯了,人太实诚,跟用户吹牛的时候心里发虚, 
就是我标题中所说的,刚出道,有点嫩。 

其实在05年初的时候,我就客串过一次售前,且被用户折磨的一塌糊涂,让我至今无法忘怀, 
最主要的原因是:我太清楚软件的实际情况了! 
让我站在台上侃侃而谈我们根本没有,或者根本不可能完成的功能, 
这心理素质、应变能力和脸皮不经过一定的历练,还真难做到。 
说实话,这方面的能力,甚至比编程更加重要。 


随着演讲次数的增加,我逐渐掌握了一些技巧,而这些技巧,同样可用于团队内的沟通上, 
比如:要控制说话的速度,以便听众能够跟上你的思路。 
比如:要跟听众形成良好的眼神互动,尤其有人提问的时候认真的看着他们。 
比如:回答问题之前先肯定对方“您这个问题提得真好”,“您这个问题非常关键”。 
比如:给出“否定”答案的时候要慎重, 
即便你心知肚明这个东西没法做,也最好说:这个问题,我们回去和研发确认一下。 
比如:如何移花接木,把A用户的一些想法灌输给B,用从B用户学到的知识回答C用户的问题。 


如果说跟用户交流的兴趣还是逐渐增长的,那么参与投标写标书,则每次都是特痛苦的经历。 
一般一套标书由商务点对点应答、资质证明、技术规范书的点对点应答、技术/方案建议书等几部分组成, 
其中“技术点对点”和“技术建议书”的文档量都是重头戏,通常是由我包揽。 

第一次写点对点应答的时候,我按实际情况,写了很多的“不满足”,结果立即遭到内部否决, 
自此,我知道,无论能不能做,应答中原则上是不可以说不满足的(除非极特殊的情况), 
因为别的公司也是这么干的,无论什么都能做,都以先拿下项目为目标。 
这也可以算是发标方和应标方之间的默契和潜规则吧。 
从此,我一直认为,投标拼的不是技术,而是关系和消息(消息在报价上非常重要)。

本来不满足的事情写满足,让本来就枯燥的文档编写工作更加的痛苦不堪, 
有些用户要求比较简单,只要写“满足”即可,而有些用户则要求对满足的条目解释如何满足, 
这样就不得不绞尽脑汁的想或者查,如果要增加这样一个功能,该怎么做,能怎么做。 


就这样,在以售前为主的工作中,走过了2006年,进入2007,我30周岁了。 


--- 

在应标这件事儿上,我总怀疑用户是在故意"折磨"开发商,
发标以后,总是要求很短的时间内就交标(一般一周以内),
所以加班、熬夜写标书是常有的事儿。拼凑标书的感觉,真的很痛苦。

不过,如果有机会参与售前,面朝屏幕背朝人的程序员们,
勇敢的去尝试一下吧。

做开发的人多数比较单纯,信奉努力就有回报,
在这个基本信仰不变的前提下,适当注意策略和手段,应该会有更“公平”的回报。

------解决方案--------------------
再阅。
------解决方案--------------------
up
------解决方案--------------------

------解决方案--------------------
顶了!
------解决方案--------------------
那您现在32岁了。。。。。。。。。
------解决方案--------------------
来给你顶一下,没看到你往水区发呢,呵呵。问个私人问题,您现在多少工资啊??可以选择不答,呵呵
------解决方案--------------------
  相关解决方案