微信号:SanDunIT

介绍:移动改变生活,技术影响未来;我的三墩,我的IT.

“晓”说运营商核心能力掌控之路

2014-12-28 10:30 王晓征

按语:“运营商核心能力掌控之路”一文最早发表于作者微信朋友圈,后载于科技杂谈、云和恩墨等公众号。作者对于运营商核心能力掌控、去IOE、技术架构管控等均有鲜明独到的观点,故略改标题转发于此,“晓”说自成一家,供大家读之。

《运营商去O之我见》发表之后,转载和反响有点热烈,很多朋友提出来很多积极诚恳的意见和建议,在这里谢谢大家了。本人才疏学浅,抛砖引玉,能引起大家的思考,感到非常荣幸。

《运营商去O之我见》的文章中我提到了运营商核心技术力量弱,核心能力掌控缺失的现状。这种情况对于去O来说造成了一定的困扰。这个问题究竟是如何形成的?又该如何解决呢?这个问题说起来比较大,我姑且简单说几句吧。


国有传统企业自身体制和机制的限制,是导致问题出现的直接原因。简而言之,内部重业务轻技术,重项目轻运营,重汇报轻实干,重管控轻创新的机制终于还是占了统治地位。

当年某动刚成立的时候,机制一度有市场化的雏形,有些激励机制今天看来仍然不过时,有些做法现在看起来很怀念!这是最好的时代,这也是最坏的时代!这句话我在最近我们内部一篇大数据培训的材料中看到过,我觉得用在十来年前世纪交替之际的运营商也是蛮贴切的。那个时代遗留下来的一些好的遗产,一直给我们提供正能量到今天。


举个例子,那时候我们一度自己开发软件,一度拥有技术人员的培养和技术支援的机制,可惜最终由于种种原因,没有坚持发展下去,中道崩殂了。当年也有过所谓的大H技术通道,但是搞得不彻底,沿用了管理干部竞聘那套做法,真正的技术人员对那套充斥着管理思路,业务思路和PPT文化的技术通道很不感冒,最终还是演变成了资深员工和退居二线干部的通道,应该说这个机制对企业的发展仍然是有正能量的,但对设立它的初衷就大相径庭了。当年考虑的开发外包,也不能说就是错误的,在当时,在当年,不失为一个实事求是的,快速上手的,抓大放小的创新方式,问题在于后面没有持续演化下去!


今天我们IT部门的员工比当年多了几倍,但是我们大多数员工的工作重心都是业务,管理和日常性事物,典型的例子是万恶的PPT,这个大家都懂的......在技术上面的投入实质上非常有限,这直接导致了后继无人的危险!


现在遗留下来的硕果仅存的技术骨干和一批懂技术的干部,大多数是那个时代的遗产。运营商最后技术力量,就像沙漠里面的小草,就像突破三道封锁线走过草地雪山的红军,很多人离开了这个战线,人数锐减,剩下的人大浪淘沙,几经起伏,几度风雨,到今天仍然顽强地生存着。


但就像我在前两篇里面说的,目前我们自身的力量并不强大,太多的人流失了,今天我们在技术架构方面相对还有一点力量,但数据架构和应用架构(具体说是逻辑架构)则成了阿基里斯之踝!再说具体点,我们运营商可以自己不生产服务器和数据库,不开发应用,但是不能不掌握架构,不应该出现对任何一个层面的供应商出现过度依赖乃至近乎垄断的情况!从这个角度说,应用开发商是运营商IT技术方面最大的管理痛点,我们今天可以换网络设备厂家,换服务器厂家,甚至连适度去O也不是完全没有可能,但谁敢说我已经能够在核心应用开发的合作伙伴方面形成真正的竞争?全运营商行业我看都没有!(如果哪家运营商省级以上单位已经完全具备此能力,我一定虚心学习先进经验)运营商与合作伙伴应该是互相促进共同发展的关系,绝不应该形成对供应商的过度依赖,这也是运营商核心能力掌控应该达到的及格线。不幸的是至少在部分领域并没有达标。


我看过银行的架构管控思路,银行的看法就是掌握架构不等于不用进口用国产,简单地使用国内的软硬件产品并不能达到自主可控的目标,特别是在当前市场化和资本运作的大环境下,企业的国内外资本性质转换很快,所谓的国内和国外都是相对的,这方面市场上已经有了很多实际的案例。


银行提出的是“自主可控”研发,在满足甲方自身信息系统整体体系架构的前提下,自主研发核心和关键信息系统,并分层异构使用外部产品,实现对信息科技风险的可监控、可管理、过程可审计。简而言之,八个字,自主可控,分层异构。这个我以为很值得我们运营商的技术管理人去思考和借鉴。


今天,在我们大谈去IOE的时候,尽管我想出了各种各样的现实应对之策,但归根到底,自身技术力量的发展最后是绕不过去的,所以,必须找出运营商特色的核心能力掌控之道,换句话说的直白点就是如何加强对开发商的管控能力!我提出两手抓,两手都要硬的应对思路。


首先,必须从现在开始,总结得失,采取有效措施,奋起直追,培养积聚运营商自己的技术力量。这个我想来想去还是觉得是绕不过去。运营商之大,难道真的容不下技术人员的一张办公桌?不信,不甘心,要推动!此外,移动互联网时代,技术发展很快。传统的IOE技术架构正在逐渐演化为新一代以X86,闪存,开源应用平台,数据平台等技术为基础的新一代技术架构,站更高一点看,传统的IT正在向DT演进,在半个月之前,阿里巴巴董事局主席马云在内部邮件中提出,要在未来十年建立DT数据时代中国商业发展的基础设施。有的时候昨天的好就是今天的短,反之亦然。今天大家在一个起跑线上。IT和DT之间,不仅仅是一个技术的变革,而是思想意识的变革,IT主要是为我服务,用我来更好的控制和管理,DT是激活生产力,让别人活得比你好,DT的思想是相信别人比你聪明,IT的思想是我比你有能力,因为我掌握信息,你不掌握。所以,我们在这个时代,几乎大家是同一起跑线。所以,昨天运营商技术团队落后了,但今天我们有机会大破大立,创造后发优势。而且,运营商根本不需要去过度创新,不要去做第一名。木秀于林风必催之,做技术老大代价是很高的,运营商只要跟在互联网行业后面,学习吸收,批判接收就可以了,而这是很有利的发展条件。当然,我希望我们现在就行动,不要再拖下去拖到技术团队衰弱到连学习抄袭的能力都丧失了,那样就太可悲了。


具体做什么?

一、培养文化,尊重技术

在一些领导和管理部门或业务部门的员工看来,技术人员往往像是生活在另一个世界的科学怪人,他们不善言辞,脾气古怪,每次交流都是语言不详,每次汇报就是叫苦加要资源。而技术人员反过来看也是一样,我辛辛苦苦加班加点,你又未必懂我的专业你知道我有多苦吗?你知道我的价值吗?你听得懂我在说什么吗?于是,沟通不畅开始了,抱怨开始了,信息不对称开始了,甚至人才流失开始了。尤其是在运营商这种体制下,业务性型人员提拔的概率远大于技术型人员,再加上技术通道的不畅,造成技术人员价值和成就感得到满足的概率不高(有些技术人的心态是我不求工资有多高,但求被认可、被尊重总不过分吧 ),进一步加剧了这种情况的蔓延。

首先还是呼吁一下,请各级领导,管理部门和业务部门的员工尊重技术人员。请至少能够尝试去倾听他们,去理解他们,不要轻易对他们呼来喝去,指手画脚。只要这么去做了,就算仅仅是一个形式,技术人员也会感到温暖。知道吗,据说某位运营商员工去阿里的真正原因还真不一定是为了钱,而是感到业务部门的员工往往只知道做二传手,一个业务需求看都不看就往他手里扔,态度稍有怠慢就去领导那里投诉,这种得不到尊重得不到理解的感觉对技术人员的打击才是非常致命的。看上去这段很虚,但我还是要放在第一点来提。

要改进这一点其实真没什么投入,一方面只要省公司以上领导发言的时候有关尊重技术的话多说几句,多说几次就可以了,第二点就是要把中央八项规定落到实处,尤其是第二,第三条。我在这里抄录一下:第二条、要精简会议活动,切实改进会风,提高会议实效,开短会、讲短话,力戒空话、套话。第三条、要精简文件简报,切实改进文风,没有实质内容、可发可不发的文件、简报一律不发。第三点针对运营商还要加上一条,去PPT!对于运营商来说,去PPT比去IOE重要多了。当然我这个去不是说机械地不准用,而是不要滥用PPT,一切以效率出发,能脱稿的尽量脱稿,能用word的尽量不用PPT。让我们的员工从文山会海中脱离出来,把时间,把生命都燃烧在真正产生价值的事情中去,找回世纪之交那种高效务实的作风来!


二、反思自己,创造价值

一个巴掌拍不响,运营商的技术人自己也要反思。难道技术人就没有责任了?甲午战争大家都在反思清政府腐败,难道海军就可以免责了?说到底战争胜负还是一线官兵打出来的。韩国足球队再买通裁判,也得自己过硬,中国队就算有了裁判,就能进世界杯四强了?扯远了,打住......

运营商的技术人能否提升自身水平,能否以业务价值的视角来看问题,能否在日常工作中找到自己新的定位,新的地位?互联网公司也不是在技术线上白白烧钱,人家也要看到价值的。技术人员们请扪心自问,如果公司现在给技术线加大投入,技术线能给出什么样的面向业务价值的KPI?其实不要去叫苦,环境现在确实不给力,但是我希望要么闭嘴,要么走人,要么推动,三者必居其一,叫苦不是一个可以接受的选项,必须奋进,必须提升自身能力,改变形象,必须有为公司创造出价值的决心和意识。

下面简单举几个例子。

价值一:业务价值。大数据时代了,通过什么样的技术创新,技术团队能够像互联网企业那样,为公司的决策提供有效支持,为公司的营销提供高效低成本的方案?我们的线上渠道什么时候可以取代实体渠道,成为公司营销的主力?这些方面,我们的技术人能做什么?

价值二:管理价值。我们的系统能不能真正提高生产者的效能,成为公司使用我们的it系统的员工工作上的大杀器?互联网企业提把客户感知做到极致,我们能不能多少也提一点?也做到一点?这些方面,运营商的技术团队能做什么?

价值三:经济价值。我们的支撑,网络,ICT系统大量使用传统的IOE架构,投资和成本居高不下,在技术架构演讲,为公司节省投资和成本方面,运营商的技术团队能做什么?


三,创造机制,培养队伍

终于谈到最关键的一点,运营商需要有能留住技术人才的机制,运营商的人力资源管理体系必须改革!

上面谈到过现行的大H体系名存实亡的现实,但是相信运营商的高层已经认识到了问题,相信运营商的人力资源管理部门不乏有识之士,只要有相关领导和部门的理解支持,这个问题一定能够解决,至少能够缓解。

我建议注意几点。

首先,必须有一个大H的准入范围管理,不能什么都往里面装,否则又走上老路了。必须限制范围,真正聚焦到那些真正的稀缺岗位,高价值岗位,专业性岗位。

其次,必须考虑一个合理的评价机制。现在的技术通道竞聘,评委大多是非技术部门中层和公司高层,加上真正的技术人员往往拙于言辞和PPT,在这种面试中脱颖而出的往往是适合M线的人。建议在形式上做出优化,增加客观分的比例,增加与其真正接触的员工领导的打分比重。

此外,建议加强人力资源部门的团队建设,运营商的人力资源部应该真正成为公司最重要的部门,具备对各类人才包括技术人才全面的评估能力。短期内,可以采取与技术部门合作的方式来治标,可以出具临时性的技术人才评定和激励方案,中期可以引入第三方专业的咨询公司,阿里就是这么做的,也就几十万上百万,只要真正做好方案,这点成本算的了什么?远期就是看人力资源部自身建设了......


四,找准方向,重点突破

应用架构和数据架构是目前运营商核心能力掌控最大的拦路虎。应用架构(以及逻辑架构)关注系统总体功能和业务逻辑设计、系统内部和系统之间的接口设计;数据架构关注元数据、数据存储、数据分布、数据模型、数据质量、数据生命周期、数据资产、数据同步等。只要在这两点上入手,必会收到满意的效果。这个前面多次提到了,不多说了。这两个方向就是我们的重点突破口!

如何去做呢?如何才能重拾旧山河,加强开发商管控,培养运营商自己的技术力量呢?

我先打个比方,讲个故事。从前有个老皇帝,他一手打下江山,能力超强,他可以每天工作十几个小时,他可以不要宰相,事必躬亲,于是朝政一片清明。很多年后老皇帝退了,新皇帝继位,新皇帝的能力远不如老皇帝,于是新皇帝设立了宰相,帮他管理朝政。一开始,一切太平,可是随着时间的推移,由于宰相才是天天接触日常具体政务的人,宰相权威日盛,新皇帝每天工作是轻松,但是渐渐觉得驾驭不了宰相,朝政有失控的风险。皇上急了,他贬斥了宰相,自己来抓朝政,可是宰相一休息,没打过江山的新皇上每天面对堆积如山的公文,几天就形容枯槁,几近奔溃了,没法子,又把宰相请回来,于是宰相上班了,朝政正常了,宰相地位更高了。这该咋办啊。事实上,宰相仅仅是文官集团的代言人,皇帝想以一己之力对付整个文官集团,除非是打江山的老皇上,新皇上确实是力有不逮啊!终于有一天,皇上灵机一动,终于想出来办法。对策一,釜底抽薪。皇帝最不缺的就是太监。给太监学文化,以文化太监队伍为基础,组建内廷,组建东厂。从此,外廷宰相和文官集团的公文,必须有內廷太监的确认才能执行,外廷和内廷互相钳制,东厂还时不时对文官集团的内部情况进行勘察汇报,皇上耳清目明,消息灵通,居中协调,倍感轻松。对策二,分而治之。你宰相不是能吗,你文官集团不是铁板一块吗?皇上自从有了内廷和东厂,对文官集团的影响力大了,于是进一步推进了官职改革,把原来宰相自己设计的铁板一块的官职,改成了标准化规范化的三省六部,各省各部之间职责清楚,分工配合,但各自又自成一系,于是,宰相就更不能一手遮天了。同时,皇上还委派自己的皇室青年子弟,成立锦衣卫与东厂一起工作,这样的体制成立之后,新皇帝终于可以稳坐江山了。

大家可能看出来了,老皇帝和新皇帝就是不同阶段的运营商IT部门,宰相就是核心应用开发商,文官集团就是应用架构,内廷和东厂就是独立第三方合作伙伴,皇室青年子弟掌管的锦衣卫就是局方自己的新一代技术人员,公文就是数据架构。

局方现状是技术团队实力凋零,对开发商依赖严重,暂时自己的技术力量还需要慢慢培养,暂时还不堪大用。因此,我们完全可以投入自己的局方人员,可以以老带新,力量不足的话再加第三方合作伙伴人员,通过SOA架构体系的建设,逐步理清应用之间的接口,相信掌控接口只是时间问题。等到瓜熟蒂落,水到渠成的那一天,我们真正地掌握了接口,把核心系统进行合理的拆分,至少要把现在动不动就是CRm、BOSS这样的巨无霸系统大卸八块。任何系统拆细了还能翻起什么浪花来啊?

此外,数据架构是另一条独立战线,套路也差不多。通过有实力的第三方合作伙伴,我们完全可以从数据架构审核入手,逐步推进,逐步培养,逐步延伸到数据架构设计。在这个过程中,局方可以逐步培养出自己新一代的数据架构技术人才。具体工作开展可以以先核心系统后外围系统,先审核后设计,先流程后工具,先表明后深入为原则逐步推进。这样也就达到了初步的核心能力掌控的目的,对开发商也就具备了初具规模的掌控能力。


通过以上措施,运营商完全可能挽狂澜于既倒,一方面迅速形成生产力,一方面逐步推进,一方面逐步培育出自己的新一代技术力量。这就是堂堂正正的阳谋,正大光明,稳健而坚定。

当然,和一些兄弟研讨后,我觉得,以上方案有几个地方也可能是有一定的局限性的。

首先,对合作伙伴的管理是需要成本的,运营商现在的合作伙伴数量已经不少了,再引入新的合作伙伴对运营商的管理能力是一个挑战。

其次,运营商现在没有明确清晰统一的的业务架构和产品架构管理体系,很多职能都分散在各个业务部门,业务部门之间的沟通和信息交互机制也有值得提升之处,俗话说,上梁不正下梁歪,业务和产品没管清楚一定害了需求开发,需求开发出了漏洞一定影响到运行运维......这给it部门构成了很大的压力,其中首当其冲的就是IT部门的需求管理员。现在的需求管理员对外要成为使能者,多少要帮助业务部门做好业务、需求,产品的梳理,需求实现的必要性和效能的分析,对内要做好需求分析和设计,压力是非常大的,在目前的体制下也缺乏有效的激励机制,对这个团队的发展造成了一定的困扰。而对于这个团队,很多工作都是难以找到也不适合交给第三方合作伙伴的。所以上述思路中对于独立第三方合作伙伴使用的适用范围是有一定的限制的,只能在技术架构和部分的数据架构、应用架构、逻辑架构的范围内起到一定的作用,不能面面俱到包治百病。

如果这样,或许可以这样搞:抽调精锐部队,集中兵力打歼灭战。抽调局方精干力量到需求管理员团队,把这块工作先顶起来,确保顶层建设不走偏。其他各条战线,还是走我上文中的路线,独立第三方+局方新生力量两手抓,互相配合,共同发展。或许如此可行?

暂时就写这么多,本人才疏学浅,分析得不一定全面,时间也比较仓促,很多观点一定是值得商榷的,还希望大家批评指正。如果能通过本文引出大家的讨论,能够为运营商核心技术力量的培育,核心能力的掌控引出一条真正可操作的路线,我就深感欣慰了。最后补充一句,我和很多合作伙伴的具体技术人员,管理人员合作都十分融洽,我对任何合作伙伴都没有什么偏见,以上分析纯属就事论事,而且我相信一个技术强大的甲方才能促进乙方的不断成长,希望通过大家的共同努力,推动整个生态环境的持续良性发展,谢谢大家!

--点击标题下方“三墩IT人”直接关注

 
三墩IT人 更多文章 三墩IT人与苏州研发中心进行私有云建设和后续发展的技术交流 浅谈软件定义存储 IT520,运动521——记信息技术部第四届篮球联赛开幕 都大数据了,备份还需要吗? 三墩IT人积极参加中国移动第二届科技成果交流会
猜您喜欢 如何获得领导赏识 1024访谈录#1:成为“温赵轮” React Native开发技术周报第十八期-框架多角度对比,技术文章,优秀开源项目(房产,B站APP,starter等) 知识点归纳(3) 程序员到底该如何学习?——初级