元旦过了,分红混到了,该惯例了。
惯例就该潇潇洒洒的走,不需要哀哀惋惋仿佛全世界都欠你的,或飞鸟出笼仿佛逃出生天一般欢脱自在,这都不是我的范。
先说一下惯例的原因,向内看满眼茫然,向外看机会很多。年近不惑,还奋斗的动,又不愿在这里混吃等死。
忘了多久以前开始混吃了。直到一天我孩子给我讲了个故事,一只母鸡教育孩子要辛勤下蛋,说“一月不下蛋,高压锅里见”,让我给她解释是怎么回事,我才警醒,这样混吃下去,下场就是“高压锅里见”。
我不想混吃等死。但是拔剑四顾,心中茫然,空有力没处使。再加上公司的政策逐渐对不惑之年的老秆子们不友好,外面又有大把的机会和挑战。这时只能眼睛向外,换一种活法。毕竟再等几年,身体只能越来越走下坡路。既然该受的苦迟早要受,为什么不早受,早受还有体力扛。
所以大家不要抱怨被辞职,被不续签,被惯例,被C,我不是那样的。
这些年的经验,教训很多,最近想了很多事情,趁着惯例总结一下。有用没用,既然进来就当看个热闹吧。
说说拔剑四顾心中茫然的事。最近心声上几个热帖,刀刀见血的针砭我厂云计算,都很到位。种豆得豆,其实这些事很早就埋下了种子。既然胸有块垒,不妨吐一下,就按我脑中的优先级,一个一个的解说。
- 关键词:惯性。产品-解决方案,盒子,批量复制,再挖存量金矿。定下目标,一定会完成。换个人来,一样能搞定。没搞定一定是用错了人。非我族群,其心必异。压强投入,什么都能搞定。研发兜底。
- 关键词:ISV。企业产品的销售,其实业界通用的玩法是转售和被集成。大部份的生意,其实是ISV在做,而且是ISV吃肉,我们喝汤。这个很简单,ISV有客户关系,理解客户业务,清楚怎么攒出一个成套方案。这时,ISV可以替我们屏蔽大量的定制化需求,或引导,或外包定制,或集成,方法很多。而我们根本没有在构建ISV关系上花大力气,仍然继续着运营商时代直销的方式。直销,肉和汤都是我们的,却是和大量的ISV为敌,进而和整个生态为敌。企业市场上的机会太多,项目都不大,指望我们的一线产品经理盯一个区域,几个行业,根本盯不过来。加上我们的产品经理不是以ISV的SA视角跟踪客户,导致大量的定制化需求—我们又不能随便在项目中集成第三方,而且一线产品挤也不可能有这种视野。
- 关键词:生态。企业解决方案的销售,其实需要的是发动生态。而我们根本没有将建立生态作为我们的战略。结果,就是我们处处碰壁,好像到处都是不怀好意的敌人。想起一个故事,一个人开车逆行,然后打电话给家里人说所有的车都在逆行,太危险了。
- 关键词:山头。外部内部山头林立,互相制肘。外部的山头:虚拟化,操作系统,Paas,Docker,大数据内核在2012,网络/安全在交企,运营/运维在软件产品线。内部的山头:数据中心,云计算,服务器,存储。每个团队都有自己的目标,但是力气无法拧到一起。
- 关键词:场景。场景太多:公有云,私有云,虚拟化,云平台,NFV,NFVI。各种场景差异巨大,却要放在同一套代码,同一个版本中相互融合协调。这就像桃谷六仙给张无忌硬灌的几股真气一样,难以调和。试想天下有几人能练就乾坤挪移啊。(原著中桃谷六仙是给令狐冲硬灌真气,作者笔误但不妨碍意思。)
- 关键词:薅羊毛。我们用开源的原罪:改,改不得,不改,又不行。开源与我们,就像一件反穿的软猬甲。其实业界用开源的玩法,主要是薅羊毛,卖周边,不像我们自己冲上去做了羊。
- 关键词:领军者的魄力。魄力不足。魄力,是做减法的能力。资源有限时,唯有做减法才能形成局部优势,力出一孔。而从战略决策,到战术动作,没有人做减法。做减法需要有横眉冷对千夫指的心理素质,也要有泰山压顶腰不弯的傲骨,而我们缺这样的领军人物。
- 关键词:简洁。技术方案是为客户需求服务的,越简洁的方案越容易稳定。太复杂的技术方案,不是好事。IT行业,并不是一个板凳要坐十年冷的行业,因为十年,技术已经更新了几代了。君不见虚拟化,下一跳的Docker,再下一跳的Lambda计算,大家都已经看到了。其实,从技术上讲,这些“新技术”有多少是从零构建的全新的技术呢?没有。每一个又有多复杂呢?没有,而且一个比一个简单。
- 关键词:用剑的大师。下一个时代,区块链,人工智能,一上来就是以服务的形式登场,而不是我们熟悉的产品或解决方案形式。我们所熟悉的七远八按三免九自,在这种场景下其实没有任何用武之地。我们所期望的,依靠产品经理给客户讲讲产品就能拿下销售的时代也将远去。破解之道是服务化,构建生态,专家社区,咨询服务等更贴近客户的方式。这时“市场呼唤研发”已经不管用了,铸剑的大师,并不是用剑的大师。华为擅长铸剑,却不擅长用剑。而不构建用剑的能力,有败无胜。须知剑法的极致,飞花摘叶也可伤人,为什么非要用你的剑不可?顺便问一句,说到“构建”,看到这里的您,想到的是华为该成立一个咨询部门吗?如果是,说明您下意识里仍然是封闭的,还没有想到利用生态这一层。
- 关键词:爆款。互联网产品的营销原则:爆款+面向目标受众的病毒式传播,而爆款必然是针对某个细分市场的击中痛点的产品。我们还在梦想一个不接触用户实际业务的“平台”能成为爆款,有点“缘木求鱼”的感觉。而这些深入接触用户痛点的产品,我们都看不上,因为太小,不能在华为的销服体系下大规模批量复制,所以都不愿意做。这时,不妨搞一些内部创业,让愿意做的人(比如我)去做,或者联系ISV去做,合作方去做,构建生态。
- 关键词:贫血+枷锁。所有资源向公有云倾斜,导致其他领域全部贫血。盒子时代的成功,阻碍了下一跳的发展。君不见,大数据,Paas,Docker,天生贫血,多个部门掣肘,还得带上不碰应用,不碰数据的枷锁。而大数据,Paas,Docker,更是那种铸剑的大师不是用剑大师的产品,再加上我们的枷锁,这些产品如果能发展得好,只能是神迹。
- 关键词:剑法教练。客户买剑,有一些是挂起来的,但大部份是舞起来的。我们的核心客户群应该首先是舞剑的,而不是挂起来的。因为只有舞起来,才能给客户自己带来收益,才能源源不断的买我们的剑。而我们并没有教客户舞剑,我们的销售只是卖剑,我们的服务仅是对剑的养护。服务器,存储,云计算,这样尚可,大数据,Paas,Docker这样就不行了。不用教客户舞的好看,但起码也得抡的起来才行。
- 关键词:不碰。数据是蛋,应用是鸡,数据和应用是鸡生蛋蛋生鸡的问题。但这和平台有什么关系?平台不过是个鸡窝。你能垒出多少个9的鸡窝,能抗八级台风九级地震,一键部署,平滑升级,有意义吗?
看完这些,您是否也觉得云计算是一个心比天高,命比纸薄,拽着猪队友,背着玄铁剑,扛着三座山,反穿软猬甲,带着一幅枷,形单影只的独行者,盯着满天的小星星,却幻想着追上太阳。你觉得,他快得了吗?
而对手已经组了团,而团里不乏用剑的大师,做小产品的大师,做集成的大师,懂行业的大师,没有枷锁,瞄准一个一个细分目标客户群欢脱的飞奔而去。
我在公司呆得最久的,是研发。其实MKT,在市场/服务眼中,也仍然是研发,PDT经理/BMT主任,在一线眼里,也还是研发。所以一线会说研发太牛气了。
而真正的研发团队,完全没有发言权,像螺丝钉一样勤勤恳恳闷不吭声,是沉默的大多数。不吭声,不代表没意见。忍,狠,滚,这个三部曲适合于每个人。狠和滚,不只在行为,也在心态。就像我自己开头说的“混吃等死”,其实就是心态上的滚。
如果心态上已经“滚”了,就“滚”彻底,眼睛向外,找找机会。时下的机会还是相当多的,下面我专门开一章来写,这一章还是来写写让我又爱又恨的研发。
前几天和一个跳出研发的兄弟聊,他说研发怎么一点追求都没有,我很无语,因为他在研发时也一样的没追求。
最近心声上有一篇“肩扛手提交付公有云”的帖子,其实反映了这个故事的一个切面,暴露的问题很多,试举一二。
- 庙堂之上作决策的人有一些假设(就让我度一下君子之腹…):只要饱和攻击就一定能成功。
- 研发都是砖头(美其名曰全栈工程师),摆在那里都行,所以工作量/效率=人月,只要凑够人头就可以。
- 研发会搞定一个功能在所有场景下的所有事,而且是免费的。
- 研发效率要不断提升,所以是可以压一压的。
- 已经做出来的东西,是没有后续成本的,丢了可惜。
- 业务需求优先,DFX不重要,如果DFX出了问题,研发负责搞定,没有成本。
其实,很多时候,为了快,大家欠了太多的技术债务,却没有时间去还。逐渐的,技术欠债成为常态,已经不再会有人去想还了。窗户上没有洞时,很少有人扔石头。而只要有了第一个,就会有第二个,很快整个架构就千疮百孔,到达热力学上的熵无限大,形成焦油坑。
如果你恨你自己写的代码,说明你还有有救。如果你对你写的代码已经没有感觉,没有感情,说明你已经在狠,在滚了,千万小心。在技术上没有了理想,和咸鱼有什么区别?
研发内部,最珍贵的,是系统工程师。这个位置需要懂技术,有全局的视野,熟悉每个模块,熟悉业务流程,熟悉团队的每一个人,有极强的责任心和沟通协调能力。而系统工程师不是天上掉下来的,都是踩着特性的尸体成熟起来的,养成成本极高。偏偏这个位置又特别关键,特别重要,劳心劳力。而我看到的,是大家都不愿意做系统工程师,这里面有一些问题:
- 系统太复杂,沟通矩阵太长太大,系统工程师力不从心;
- 考评/任职/奖金没有特别考虑倾斜,系统工程师吃力不讨好;
- 一次失败,不再任用。导致华为公司为培养系统工程师交的学费,打了水漂;
我所看到的,系统工程师的流失率极高,从Galax8800开始,到FusionCompute,FusionManager,到现在的OpenStack。而这些人的流失,如果是走到了更前端的SA,PM也还好,全局视角不会被浪费掉,但如果去了其它产品线,就太可惜了。
外面的机会。话说天下大势,出口逐渐疲软,人口红利消失,互联网+手机+微信已经完成了“人连网”的基础设施布局,国家在谋求产业升级,政府在谋求智慧城市。技术上,AI,IoT,区块链已经在跨越裂谷。智能制造,工业4.0已经引燃。民众从温饱到更有品质的生活追求,可以创造出大量的机遇。
如果要创业,要么做大平台(但你会遇到BAT),要么做精准细分市场下的高品质产品及服务,总之,机会很多。
年过40,再给人打工,也是一种选择。见过有一篇讲40岁的职场人的帖子,很不错,但总有一种英雄迟暮的悲凉在里面。
终于到了我心中最割舍不下的部份,FusionManager。
来云计算,我做了两件让我自豪不已的事,Galax8800和FusionManager,让我觉得我对得起华为付给我的报酬。往事不堪夸,我不想说这两个产品有多好,而且我也确实知道他们的千疮百孔,以及锦袍下面有多少跳蚤。
简单介绍下这两个产品。Galax8800是我们在云计算上的第一个产品,基于Eucalyptus架构,但基本重写了。Galax8800当时定位是大规模公有云架构,做了三个版本,及时刹车转向了虚拟化。这一次刹车转向,是非常正确的。
FusionManager,是转向FusionSphere架构后,在FusionCompute之上开发的云服务层。支持云服务化,支持自助服务,多数据中心,支持VPC/VFW/VPN/NAT/VLB等等大量的虚拟网络服务,支持硬件管理,异构虚拟化。对应到现在的产品组合上,基本等于OpenStack + ManageOne SC + AC 2.0 + eSight IT+OpenStack OM。而构建这个产品只用了三个版本(2.3/3.0/3.1),团队峰值100人左右。截止2014年底,运营私有云+公有云80+项目,不算虚拟化项目里面捎着卖的。这种产品形态,在2013年基本是天下独一份的,甚至现在看来也丝毫不落后。
只是这样一个产品,生不逢时,命比纸薄。此产品一度被划到IT软件DU,然后又回到云计算。回到云计算又赶上了OpenStack当道,只能接受被废掉的命运。而且因为此产品不在数据中心,数据中心就规划了ManageOne SC/OC两个产品,来替代FusionManager,但是却是基于FusionManager提供的云化能力在做。再后来虚拟化战略收缩,FusionManager变成了FusionCompute套件中的一个附属功能。
这个故事很长,说多了都是泪。但我的目的不是要说它,而是要总结经验教训。
- 组织越复杂,架构越复杂,成本越高。FusionManager只用了100来人,两年时间就可以做得相当好,而我们基于OpenStack+SDN却要更多的人,更长的时间来作。
- 产品的妈重要,婆婆也很重要。婆婆不看重的产品,会沦落到做妾都没人要的地步。所以,有志于做产品的兄弟,一定要找个好婆婆啊。
- 虚拟化市场下强推云的概念就是作死。有一段时间产品的战略是用云来打虚拟化,每个项目都必须卖FusionManager,结果收到骂声一片。对于客户就是想要个虚拟化的情况下,组织/VDC/VPC太过复杂。而时至今日,我们的私有云和公有云仍然是这些概念(哈哈,企业云的网络概念都是哥玩剩下的),客户就可以接受了。大家总是想复制软交换反打交换机那样的成功经验,但没有看到本质的不同—软交换还是交换机,客户体验是一样的。而虚拟化和云,体验完全不同,想用云反打虚拟化,很难。后面做的OpenStack纳管虚拟化特性,也从侧面印证了这个道理。
- 架构不是产品的竞争力。FusionManager 5.0作的死很能说明问题。FusionManager 5.0完全抛弃3.1架构进行重构,花了大量的力气,做了个很厚的平台,倒是统一了FusionManager,ManageOne SC,OpenStackOM的代码。然并卵,到5.1还不是因为各种原因拆开了。想想那个年代我和我的团队被架空,一帮人有多大胆地有多大产的红小兵,精英团队,胸脯拍的山响,最后又是自己挖坑自己埋。而FM 5.0,功能比3.1不仅没有增加还有减少,业务模型还变化了,徒然给自己惹来烦恼。
中间的故事太长,有基于FusionManager作产品却个个版本换架构的奇葩上游,有为了自己KPI强奸产品硬落架构整改的大架构师和PDU主管,有为了好销售要把FusionManager包装成另一个产品的PLM团队,有游说产品使用后又弃坑的平台团队,有SC和FM的各种恩怨痴缠,有苦逼的UHM团队的踯躅独行,有借着FusionManager卖高端防火墙和高端交换机的一线兄弟,有高大上到处演示却没什么项目用过的图形化编排功能,有为了FusionManager呕心沥血却不得不另谋高就的网络架构师,有二起来能到四却人见人爱的版本SE“二爷”,有专职的不进迭代却累成狗的代码架构师,有在相声中跟我一起变兔子的铁杆兄弟们。话说,我是不是该写一部产品开发那些事的情景剧……但是,产品开发狗们哪有时间看啊。
FusionManager,我为之呕心沥血,视如己出,却成为我心中永远无法割舍的痛,同时她也成为了我的牢笼。离开她之后,我就一直在混吃等死,直到现在。痴情无过,但蹉跎有错。我是自己的面壁者,也只有自己能破这个壁。
关于我多次被“拿下”,有些难堪,有些痛苦,但都必须面对,以警后来人。
- 视野要开阔一点,千万不要站在研发团队的角度去想事情。比如2010年我们和新加坡Starhub合作公有云,需要紧急开发定制一些自服务界面。当时我以团队超负荷为由极力抵制,最后这个系统由技术开发团队作了。虽然最终Starhub没有成气候,但是当时也是云计算拓展项目的一个尝试。我从Galax8800被拿下,就是因为这个原因。
- 千万不要越级搞事,除非你认为再无办法。这是我的真实故事。上面讲FusionManager最后有一句,“为了好销售要把FusionManager包装成另一个产品的PLM团队”,这个事如果落实,FusionManager就会多出一个便宜婆婆,而且界面,资料都得多出一套,纯粹属于不增值活动。这件事因为我给总裁发的一封邮件而停了下来。但是反过来讲,我没有求助我的直接主管,资源线主管,而是直接越级上报,这种行为在华为公司是行不通的。因为华为公司是一个等级森严的“金字塔”结构,至少在他被炸掉前还是,你的主管不会喜欢一个这样搞事的下属——很简单,你挑的事越有价值,就越表示你的直接主管没看到,不作为。大家不必骂这种想法,只要吸取教训就好。我从FusionManager被拿下,而且一直被冷冻,被边缘化,跟这个有非常大的关系。
然而,塞翁失马,焉知非福。从Galax8800被拿下后,云计算经历了长时间的“反攻倒算”,我的继任抗不住,离职创业去了,现在也做得不错。而我侥幸躲过这一劫,没有被波及。
这半年先是在中外运的交付项目里面混迹了一个月,结识了一帮好兄弟,也懂得了IT实施项目的过程。然后在技术开发认真学习了大数据的知识,理解了开源软件的玩法,更重要的,知道抬头看世界了。
后来赶上老板要求力出一孔,技术开发的大数据团队解散了,我于是拉着这一票队伍又回到开发,正是这一票队伍成就了FusionManager。
FusionManager生不逢时,最终混到连妾也做不了,但FusionManager锻炼的队务,又成就了公有云。无论如何,我都为这个队伍感到骄傲。
而我自己,终究是因为心有魔债,走不出来,怨不得别人。
那应该是在2010年的夏天的一个周末,连着三天的假期,我请设计团队的同事到我家做客,我自己包饺子请大家吃。我整整忙活了两天,买菜,剁馅,收拾屋子。第三天大家如期而至,很高兴的吃饺子,聊天,打牌。
2012年我被拿下时,我给大家发最后的邮件中,还说到如果有机会,我还想请大家吃一次饺子。
2013年春天,大数据技术开发团队面临被解散的命运。我带着我的团队,在唐延路的草坪上打了一下午的三国杀。在那以后,我的团队被拆,核心骨干跟着我到了FusionManager。我们自己写的流处理系统,还没有完成alpha版本就胎死腹中,我还在3ms上立帖“重整河山待后生”。
2014年,FusionManager 2.3,在上海移动纳管vmware成功,整个团队欣喜若狂。
2015年,FusionManager团队也走到了穷途末路,我带着设计团队,花光了所有的部门经费,在一个温泉酒店呆了一晚上,铁锅羊肉,打牌泡澡,不诉离觞。
在每一个命运的转折点,即使你早有准备,即使你先知先觉,却依然是无能为力。且留下这些沉甸甸的回忆,或许哪一天午夜梦回,大家还在一起,多好。只是不知道,我会不会哭醒。
该说的,不该说的,都说了。华为与我,珍贵如生命,毕竟为之奋斗了十六年(当然其中有混吃等死的日子)。无论如何,我总是希望华为能够基业常青,云计算能够托起华为的未来。
虽然我今天绝望了,但希望总是有的,沉舟侧畔千帆过,还有那么多为之奋斗的兄弟姐妹。只是,恕我先走一步了。
但无论如何,我以曾经是华为人而荣,为华为而荣,今生今世。
下定决心前是痛苦煎熬的,等到决心已定,心底却感到轻松了许多。只是离开了公司的大平台,往后的日子,需要自己打拼了。功罪宠辱身后事,淡看云起云舒,老的一页翻过,新的一页开始。
38岁起步,不算太晚。