(转)再谈技术的价值

2015-11-23 Lingxian Kong 更多博文 » 博客 » GitHub »

原文链接 https://lingxiankong.github.io/2015-11-23-technical-value.html
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。


原文链接在此

创业团队里没有牛人是痛苦的,有了牛人就一帆风顺了么?

或者,明明牛人曾经就在身边,却一不留神错过了,这种事情你意识到了么?

总有创业者会疑惑,我好不容易找了一个背景资历特牛逼的合伙人,可是共事一段发现,也没觉得水平有多高啊,和我之前招聘网站很便宜的工程师相比也不见得高明在哪里啊。别说,这事真挺常见的。

感谢互联网,技术的价值得到了极大的尊重,但是一个很悲哀的事实是,相当比例老板往往是尊重的是别人家的技术。 昨天有些意犹未尽,今天想到哪里算哪里,可能组织的内容不够有条理,大家凑活看吧。

1

在相当多的情况下,优秀的技术保障往往没有存在感,其价值只有出问题的时候才会被人想起来。

典型场景 1,某个公司业务一直发展的不错,某天老板查工资单,咦,这个运维总监怎么工资这么高,没见他做啥事啊,好像除了报预算要加硬件带宽就没见他给公司做过什么贡献,也不知道这钱都花哪里去了,hr 过来一下,找个借口什么价值观不符送走送走,我有个远房亲戚做过网管,管过几百台电脑呢, 俩月后,各种运营活动出来抱怨系统支持不住业务发展,漏洞迸发,公司开始请猎头到处挖资深运维负责人。

典型场景 2,某个公司同时启动项目 A 和项目 B,两个项目上线后都受到市场好评,订单不断,老板开心,但 A 项目很快开始出现大量技术问题反馈,A 项目技术经理敬业又努力,天天加班救火到处跑客户现场处理问题。B 项目技术稳定支持工作云淡风轻,技术经理天天下班回家陪老婆孩子。然后 A 项目技术团队不断扩编,B 项目技术团队不断裁撤,最后 B 项目经理被勒令调往 A 项目团队做技术支持,A 项目技术经理升任总监。

以上案例纯属假设,如有雷同纯属巧合。但你说我都是无中生有瞎编的么?

在运维,技术保障等领域,没有存在感其实是技术的最高境界,但是很遗憾,因为没有存在感,所以往往无法被升职,被提拔,被认可。往往是问题越多,救火越频繁,存在感越强,越会成为领导喜欢的人才,特别是一些大公司,这种技术价值与所谓公司价值观倒挂的现象尤其突出。

2

为了展示技术而创造需求,是很多技术创业者的通病。

其实这段和主题不是很符合,不过想到这里我还是想说一下。

有些技术达人创业,他们因为掌握某种技术优势,非常希望把这个优势变成商业模式,但是他们也明白要从用户需求出发,可是真明白么?很多时候,他们会基于自己的优势,“创造” 出他们认为的用户需求,然后 “完美” 的用他们的技术优势来满足。

这种把 “炫技” 当作竞争力的,好像一直以来,下场都不是特别好,技术有优势当然不是坏处,但是你必须真正理解需求,再去考虑技术优势,而不是反过来。但这个弯子很多技术大牛总转不过来。

3

创业公司是否明确自己的技术目标和人才匹配度,长期以来是个问题,昨天我也提到这一点,脱离业务场景谈技术架构都是耍流氓,你找一个在大公司大体系里某个领域特别资深的专家,来解决你当前小公司的实际问题,真的合适么? 答案往往是不合适。

我以前举过这样的例子,我去架构师大会,听各位牛人分享,淘宝的技术专家,那方案杠杠的,水平超过我们不知道多少倍,我听了各种佩服,回来后,我们一样都用不上,这个,真心用不上,业务场景差距太大了,人家考虑的性能指标完爆我们两个数量级有没有。一个二线互联网公司技术负责人分享的一个技术话题和方案,技术含量肯定比不了淘宝网的,但是回来马上安排照此实施,效果立竿见影, 因为业务场景有相似处啊。

大公司的体系庞大,每个领域都需要极深的专业人士来操纵,可能光一个数据存储,就分了好几个不同的团队,有的专门做中间件和调度,有的专门做缓存,有的专门做 i/o 优化,有的专门做关系型数据库的持续性存储,可能还有的专门做备份和异地灾难恢复机制。你去请人家一个专家来了,第一,人家专长你多半压根用不到;第二,他可能还真就解决不了你的问题,虽然你的问题没人家那么复杂,但是涉及领域却远超他平时的工作范畴了。大公司要专深的人才,但小公司,特别是创业初期,最需要的是能力驳杂的全栈达人,你还会觉得大公司的人最合适么?

说一下我的一个人才观点,我觉得最适合给创业公司提供完备的技术指导的,既不是如今大公司的技术达人,也不是小公司的多面手,而是见证了一个巨头从小到大的那一小撮技术达人。也就是从 BAT 早期开始就加入并一路跟到公司超大业务规模的核心技术负责人,这样的人,既知道小公司的技术是如何起步的,如何在低成本下完成基础架构的搭建;也知道业务规模爆发后技术架构是怎样演进的,如何应对各种复杂场景中的技术挑战,但是这样的人,基本上都财务自由了有没有,岂是一般创业公司能请的起的呢? 可是,我们反过来想,这些人当年大多也是从菜鸟工程师起步的,既然人家可以这样起来,你为什么不塑造一个环境来培养潜力股呢?

4

技术的价值并不是只体现在服从和完成上。

似乎和 1 有矛盾,其实是两个不同的层面,保障层面和创造层面。不能因为创造层面的价值去忽视保障层面的价值。

google 倡导工程师文化,允许工程师自己去思考去设想去实现一些自己认为好玩的事情,是的,也可能是一个纯炫技的东西,但也许正好在某个业务线的发展中,这个炫技突然就变得非常有价值。

在上文里,我说以炫技为核心竞争力的往往不是正确的,但是必须指出这里存在一个空间,就是在满足用户需求的具体业务场景中,存在一些特定的技术发挥空间,而在这个领域,非技术人员往往是无法担当指导和规划能力的,但现实是,很多时候非技术人员以为自己可以担当指导和规划能力。

场景说话,一个用户平台,也许是游戏,也许是电商,随便吧,老板说,你看人家有个栏目叫 “猜你喜欢” ,挺好的,你们也搞个。 产品人员来了,说,这个吧,我们把转化率高的放这里吧,这样用户粘性强。运营人员来了,这个,当然放利润率高的了,收益至上。商务合作来了,这个,我刚签了合同,这个伙伴非常重要,老板发话了,他们的东西必须保证给量,我不管,这个位置我要了。然而,没有一个人问一句技术,你对这个位置有啥想法么? 他们已经认定,技术你只要服从就好了,而他们的出发点都忽略了一个前提,这个位置长期来看其给平台带来的效果好坏,应该是一套机器学习算法自动调优决定的,而不是他们拍脑袋的决定的。

我在过去的发展经历里,我个人认为,最有成果的那些东西,都不是领导安排的,而是自己想做的,做的目的和初心,也不是如何的高大上,而是好奇心,好奇心是最能体现技术价值和发展技术成果的驱动力,我希望更多人能理解这一点,这也是 google 的工程师文化之所以有活力的源泉。 那么,如何让技术的好奇心和公司的业务发展路线尽可能一致呢?我的建议是,在以前的文章里提到过,尽可能让技术懂一些业务,懂一些应用场景,他们对这个了解越多,他们可能好奇心就越贴近你的业务诉求,比如说,我想知道为什么我的这个用户会流失?我想知道为什么我们产品的转化率不如对手的?当他的好奇心和你的业务方向一致时,他的所作所为的价值,很可能超出你的想象。

就好比《三体》里提到的,物理学家之所以去钻研世界的本质,并不是因为各国的政府领导人要求,也不是多么高大上的使命感,而是好奇心,好奇心推动着人类的进步。

回到昨天提到的案例,那个技术大牛说他优化的算法对转化效果的提升极为明显,然后补充了一句,之所以这个事情能很顺利的做成,是因为没有任何领导在这个领域提出任何方案和目标,他们原本只是做一些日志监测,对一些用户行为做了研究,然后基于好奇心,在毫无绩效目标压力的情况下去做了些事情,然后发现效果惊人的好。 当然,这里还有个前提,这个技术大牛在他们公司的项目决策体系里有足够的话语权,可以安排足够的测试和直接推动成果上线,但并不是每个公司都会给技术专家这样的权限。

如果,你只是把技术人员当作俯首听命的执行者,而不肯发挥他们的创造力,那么,他们的价值又如何才能体现呢? 一个极具思维活力,极具创造才华的技术高手,和你从招聘网站找到的熟练程序员,又有什么区别呢?