第一次参加公司研发部门高级别会议之感

来源:互联网 发布:java线程优先级main 编辑:程序博客网 时间:2024/05/02 00:42

看到这个名字,是不是觉得非常霸气,是不是觉得哥非常牛,是不是羡慕哥。

好吧,如果你只是这样想的,那只能说明你太年青了,小伙子,你有许多事还是不懂,慢慢来,你会懂的。

先简单给此会议来定个小调吧:

这是一群由乌合之众参加和召开的荒唐会议!

会议召开的背景

我们公司的研发部门在持续不断的进行改革,改革嘛,说白了就是上面换人了,蛋糕要重新分了,上一次改革的口号和方针当然是一定正确且响亮。

“公司研发软件进行大平台化战略,应用模块化,业务专业化,人员精英化!”

具体执行起来当然有许多突破性的创举,对于手机上层应用开发的最大的改变就是:

手机上层所有的android应用都打包起来,只对项目提供各个版本的APK,而做项目的人是看不到源码。

这个改革当然是对项目有好的方面,几个人专门负责一个重要的应用(如二到三个工程师负责Launcher应用),一个人负责一个不怎么重要的应用(如一个工程师负责一些已经稳定的应用),当然会从表面上显的更专业,更模块(这建立在一些基础上,如果负责的工程师水平更专业和实力更强,可以起到这个作用,如果负责的工程师水平一般,那么只有风萧萧兮易水寒了,一切都白搭)。

这个对于做项目的人来说,

影响有好的一方面,好的方面是一些客户需求会集成到了应用APK中,工作量会少一些。

但是影响也是致命的,上层应用的源码从此与工程师天人一方,应用的工程师基于上是没有可以调试,学习,研究的源码了,可以不夸张的说是断了一个应用软件工程师技术水平上升的途径,相当于是一个人突然之间没有主食可以吃了,每个喝点水,吃点零售。

特别是因为公司内部配合,协调的问题,而做项目的工程师没有源码,许多本来非常简单的问题,现在解决起来非常困难和无厘头。

比如修改一个字符串,经常是做项目的人白痴一样找对应APP应用的负责工程师请求支援和指导,我已经碰到过二次修改一个字符串,每个字符串修改了一天,最后才修改成功,这搞笑不,荒唐不,有意思不,想骂娘不。

有感于此种方式的种种问题,一个多月前,在一次部门研发会议上,我讲了一下此问题,要求APK的源码对于工程师开放,可以让工程师自己看到源码,更方便问题的解决,项目进度的提高,特别是工程师水平的提高,并且当天晚上写了一封洋洋洒洒的邮件详细的说明了此问题严重性和迫切性。公司其中一个领导(方便后面大家识别,我们称呼其为support_XXX1)非常重视此问题,推动APK源码的开放问题的解决。

然后,国庆十一之后,此次公司研发部门高级别会议胜利召开了。

会议召开的过程

这是一个高规格的会议:

参与此会议的领导有:

研发模块执行总监兼产品项目部总监一名(我们称呼其为midlle_XXX1);
研发副总经理一名(就是上面推动此问题解决的领导support_XXX1);
部门长三名(一名我们称呼其为sillence_XXX1,一名我们称呼为oppose_XXX3,一名我们称呼为hidden_XXX4);

此外还有一个什么都不是的低级别软件工程一名(就是我这个SB,我们称呼其为XXX吧),还有我们组长一名,软件配置一名(我们称呼其为config_XXX),会议记录秘书一名。

让我们以热烈的掌声欢迎各位领导于百忙之中列席会议,开始这场让我长见识,刷新三观的会议秀。

开始就是support_XXX1询问我,APP应用的源码我们可以下载了没?
我当然是如实回答:没有。

support_XXX1就觉得奇怪,说XXX总(此总为软件中心执行总监兼芯片平台部总监,我们称其为oppose_XXX2,职务高于部门长,低于midlle_XXX1和support_XXX1,)已经在研发领导微信群里说APP应用的源码权限已经开放了,并且找到了当时的oppose_XXX2在领导微信群里的聊天记录,然后询问了软件配置config_XXX,我们现在可以下载APP应用的源码不?

config_XXX的答复为:现在我们这边是没有人可以下载到APP应用的源码,如果要下载,需要找oppose_XXX2申请,申请通过后才可以下载。

然后support_XXX1再询问hidden_XXX4,你们部门有人可以下载APP应用的源码不?

hidden_XXX4摇摇头,说不能。

于是就电话连线oppose_XXX3,询问APP应用的源码权限事宜,oppose_XXX3开始说此事情已经落实了领导的指示了,APP应用的源码已经开放了,但是事实上现在没有任何一个人可以下载,这当然就是问题啊,你是谁落实了,怎么落实的,什么时候落实的啊?oppose_XXX3又讲了许多没用的推脱责任的废话,导致support_XXX1怒了,拍桌子开始训人了(这个我是可以理解的,领导一个多月前推动的事情,你们反馈说已经落实了,领导一个月后再来看,我cao,什么进展都没有,什么工作都没有做,还是在叽叽歪歪的讲这么多废话,不发飙才怪,换你你也会飙)。

support_XXX1领导说,公司所有的资源包括源码,都是整个公司的资源,这不是某一个部门的,也不是某一个的,一定要求此资源共享出来,要求尽量不设置门槛,让工程师都可以下载,说这是上次在老板那里,领导一起达成的共识,要求今天要下班前落实,一定要让我和公司级别为T9以上的员工和XXX都可以获取到源码。

oppose_XXX3就反驳起来了,说我那里私有了,我共享啊,然后竟然对怼起来了,你没有看错,我也没有写错,是真的对怼起来了。

这个时候,当然就会有和稀泥的人出现了。

这时midlle_XXX1看形势不对,就立刻将电话联线挂断,结束了此争吵。

我一看这形势,不对啊,领导们啊,这不像是解决问题啊,这感觉就真是和稀泥啊,此问题感觉马上就要就这样不了了之了。你觉得如果这样一种已经在老板那里达到一致共识的问题,并且是已经有了要共享结论的问题,如果在这种级别会议上都不能解决的话,那此问题就真的是永无解决的可能性。

我非常着急的立刻插上一句话:”midlle_XXX1总,这种问题,一定要有最后解决时间,因为这个问题已经提出了有一个多月了,如果你们这样,那这个问题二个月后还在争论!“,说完后,我真是非常生气的将手机不重不轻的掷在桌子上。

这时hidden_XXX4总就立刻对我说,XXX,你不要着急,下面我来协调来解决此问题吧。

然后,我就退出了会议室,完美的结束了我的第一次参加公司研发部门高级别会议的议程,领导们继续下个议题的友好讨论。

值得玩味的是,sillence_XXX1全程一句话没有说,sillence_XXX1是我们部门的部门长。

会议后续处理结果

然后,下午hidden_XXX4总非常积极的联系了另一个软件配置负责人(我们称呼其为oppose_config_XXX1),制定APP应用的源码的权限开放规则。经过一下午的拉人,最后终于制定出了一整套科学,规范,合理,高效,扯蛋的APP应用源码权限开放规则:

  • 互联网应用

1.对于互联网应用(因为其有变现的东西,为了安全保密,源码安全级别非常高),工程师先向一个XXXX总(我们称呼其为oppose_XXX1,其公司职务级别为市场技术副总兼产品技术部负责人,非常高,比oppose_XXX2高,至于与midlle_XXX1和support_XXX1职务级别谁高,我也不知道,请不要问我,因为我的级别实在是太低了)正式邮件申请同时抄送给oppose_config_XXX1。
2.当oppose_config_XXX1收到oppose_XXX1总的邮件确认同意后才开放对应的权限。
3.工程师这才可以下载对应的应用源码。

  • 非互联网应用

1.对于一般的应用,先正式邮件向oppose_config_XXX1申请
2.oppose_config_XXX1开放对应的应用源码读权限。
3.工程师下载对应的应用源码。

我测试了一下,下载了一个非互联网应用和互联网应用。确实可以下载,就是发现了一点点小秘密,这二个下载的应用源码竟然是比较老的版本(一个NLauncher应用,一个截图应用(此应用为最新的应用源码),N,android 7.0的源码,看到了吧,小手段,小心思,小把戏,领导啊,你们真的都是人精,同时都把别人当做是SB,哈哈,小样的,玩吧)。

我真正要研究的源码是android 7.1的Launcher应用,现在已经给oppose_XXX1邮件正式申请了,请我们看看到底几天可以通过申请拿到代码吧,哈哈(我估计中间一定会有许多曲折,一定不会顺利通过,一定会浪费许多时间,这才此流程的目的所在,哈哈,小样的,玩吧)。

然后,将此APP应用源码权限开放规则以正式邮件的方式群发公司研究软件所有工程师。

会议召开的感想

我输了

有的同事收到APP应用源码权限开放规则的正式邮件后,对我说我这件事做的好,你赢了。

大家觉得我在这场申请应用源码开放的问题上,到底是赢了还是输了?

表面上看,确实是现在APP应用源码权限已经开放,我赢了;其实,我是输了,并且是输的一败涂地,输的一无所有,输的永无立足之地。

大家请看我的分析:

支持APP应用源码权限开放的有:

研发副总经理(support_XXX1)

明确反对APP应用源码权限开放的领导有:
更高级别领导一名:oppose_XXX1
高级别领导一名:oppose_XXX2
部门长一名:oppose_XXX3
当前配置总负责人:oppose_config_XXX1

实际行动反对APP应用源码权限开放的领导有:
部门长:hidden_XXX4
有的人可能不明白,为什么啊,hidden_XXX4不是在积极的推动APP应用源码权限开放嘛。其实,大家都是老狐狸,hidden_XXX4在开会后这么积极的推动APP应用源码权限开放,主要是为了支持oppose_XXX2,防止此事闹大,先稳住局面,先走一步表表态,你看,我们现在开放了APP应用源码吧,但是基于如何开放,开放的门槛如何设置,时间如何拖,开放哪个版本,这都是可以操作的吗。(江湖谣言hidden_XXX4与oppose_XXX2是铁哥们)。

研发模块执行总监兼产品项目部总监(midlle_XXX1)
一个表面上看起来是和稀泥的中间派领导midlle_XXX1,其实立场就是反对APP应用源码权限开放的。其将电话联线挂断的目的其实和hidden_XXX4一样的,呵呵。

而事实上,现在公司软件基本上就是由这些反对APP应用源码权限开放的领导主持着。看到没,我趟的是一个深不可测的浑水,我面对的是一群占据高位的力量。

怎么样,明白了吧,这就是我为什么输了,并且输的这么惨的事实。

最后,我想说一下sillence_XXX1总,sillence_XXX1总是我们的部门长,可以人全程没有说一句话,他的态度是什么呢?其实,我们当然知道是支持APP应用源码的开放。但是,为什么他一句话都不说呢?是因为他不方便表态,不敢表态,还是表态了没有任何作用,说话没有任何份量呢?(江湖谣言,sillence_XXX1在公司基本上处于弱势的地位,无论他说什么,做什么,提议什么,都会有一帮人反对,这….,当然江湖谣言,大家不要当真,且听之)

我怕吗

事实上我是输了,并且是输的特别惨。

那么我害怕吗?

答案当然是一目了然的,谁人不害怕啊,就算是武松这么牛的人,上山打老虎前也是害怕,要先喝点烈酒,壮壮胆啊。

先说一下在问题面前,所有的人在我眼里只分为二种人:
一种是实力比我强,能力比我强,眼光比我准,这种人,我一般喊他们为哥。
一种就是实力比我弱,能力比我弱,眼光比我差,这种人,我一般喊他们为废物。

所以,在和这么多领导面前讨论这个问题的时候,我当然是害怕的。我害怕自己的实力比别人弱,能力比别人弱,眼光比别人弱差,我害怕自己在别人的眼里就是一个废物。

至于什么身份职务,什么上下级,我还是不害怕的。只要我们是以问题的事实为依据,以更好的解决此问题为目标,如果你的解决问题方法比我的好,就算你的职务比我低,年经比我轻,我也会在心里喊你一声哥。如果你的解决问题方法比我的差,就算你的职务比我高,年经比我老,我也会在心里送你一个废物的荣誉称号。

触动利益往往比触及灵魂还难

为什么这样一个开放应用源码的问题,搞的这么复杂。

其实非常简单,就是APK应用源码封闭起来控制在自己手上,就可以牢牢掌握住软件的命运,然后就可以抬高自己的地位了,小算盘嘛。

这个只提供APK,没有源码真的是会对做项目,对软件工程师是个坑,我只是基于此问题,想要将源码开放给工程师,真的这个要求一点都不过分,这个应用的源码本来就是android提供的,你他娘的把他打包起来,封装成APK,说是你们做的,这真是不要脸。

但是,开放应用源码不行,理由总是找得到的,并且还非常多。

观点斗争是假的,方向斗争是假的,其实权力斗争才是真的,利益斗争才是真的。

触动利益往往比触及灵魂还难,谁要敢动我的利益,谁就是我的敌人,我们一定要干掉他。不管他提出的问题是不是实际存在,不管他是谁!

为什么我会说这是一群由乌合之众参加和召开的荒唐会议!

假如,有一个问题A,我们确认此问题A是要修改,然后组长说XXX,问题A分给你了,你解决一下,大概要多长时间?我先看一个此问题A比较简单,回复说半天搞定,如果此问题A是一个小功能开发,那么我可能说此问题A有点小复杂给我二天时间。如果二天后,我发现此问题A还是没有解决,原因是有一个技术点还没有搞定,那么我要反馈给组长说明延迟的原因,继续重新申请一天时间解决此问题A,然后不断调整计划和时间表直到此问题A的解决。

可见问题的解决有几个关键点:
1.先评估和确定此问题是否要解决
2.如果确定此问题要解决,那么明确的指定责任人,制定解决问题的时间计划表。
3.按照当时制定的时间表来与责任人确认问题解决的进度,调整问题的时间计划表.

那么,我们再来看此会议,会议议题完全是没有目的性,做为一个已经在老板那里,领导一起达成的共识问题,没有指定任务的明确执行人,没有任何的时间计划表,已经一个多月了,问题还是没有任何进展,执行力之弱令人发指。现在发现了问题,领导竟然没有想着重新开始此问题的解决,而是互相对怼起来,没有看到担当,有的只是推脱,有的只是和稀泥,有的只是没有任何结论和计划的散会。

用我平时的话来说,就是你们他娘的都是一帮废物

所以我才说:这是一群由乌合之众参加和召开的荒唐会议!

问题的解决

此问题是我提出来的,现在这个样子,怎么办?有更好的解决方法没?答案有的。
先说一下,当前我们这边的代码管理方案:
当前的项目源码,所有的源码工程师都是有下载读的权限的,如果要想得到项目的修改写的权限,需要SPM正式的邮件通知服务配置那边,给哪些工程师开通修改写的权限。

此方案一直执行,没有发现任何什么问题。

那么现在的应用APP的源码,应该来说对于我们是默认没有任何权限,如果想要下载读和写的权限,那么不好意思申请吧。

为什么一个公司,同样的源码会有不同的管理机制,为什么同样的一件事情不同的人会有不同的区别对待?

这就是此问题的关键所在。

我们的解决此问题原则是:
只对事,不对人,也就是所有的人遵守同一个规则。

解决此问题的方案A是:
公司所有的源码对于工程师是默认有读的权限,如果是要申请写的权限,请SPM或项目负责人发正式的申请邮件,确认后开通对应的写的权限。

解决此问题的方案B是:
公司所有的源码对于工程师是默认没有任何的权限,如果是要申请读或写的权限,请SPM或项目负责人发正式的申请邮件,确认后开通对应的写的权限。

看到没,解决此问题的二个方案没有任何创新,只是针对所有的工程师执行同一个标准,就完美的解决了此问题,然后如果此标准后续使用出现问题,及时的调整就可以了,我真他妈的是个天才!

这个非常有必要性,因为我们公司现在是大公司了,有台湾,上海,南京,深圳,南昌等团队,如果各个部门都是这样一个各自为政,各个团队都是这样打着自己的小算盘,那么以后代码管理方案一定是百花齐放,多姿多彩,代码山头一定是林立。

至于什么应用变现的机密这种借口,来阻止应用源码的开放。这种源码机密问题,真的是太容易解决了,将其核心的变现代码打开jar包或者lib就可以解决此问题啊,不但提高了源码了安全性问题,又可以提供接口的共用性,多好啊。

我现在特别担心,这个什么应用变现的机密只是调用了一下三方提供的广告点击统计接口,没有什么任何技术含量,只是一个借口。

所以,强烈要求将此种应用变现的技术做为一个专题来在公司内部针对核心员工进行分享,如果真的是好的高深的技术,更应该让此技术在公司内部推广,让更多的员工和部门掌握,装其推广到更多的应用和部门,让公司老板赚更多的钱,多好啊。如果是假的什么高深的技术,只是一个简单调用三方的接口,那么,哦吼,西洋镜拆了,牛皮破了。

哈哈,我太坏了,当然,这绝对不可能!

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

后记

最后,在给oppose_XXX1邮件正式申请android 7.1的Launcher应用源码的二个星期后,在oppose_XXX1积极领导下,在一大波领导的积极参与,精诚协作之下,在邮件满天飞,太极神功运用的惊天动地,眼花缭乱之下。最后,得出了一个非常科学,合理的结论:

互联网应用的源码不开放

也就是说我没有要到源码。

这个结果其实早就在预料之中,一点都不惊讶,只是自己有一点小伤感,为什么这种剧情偏偏让我预料到了,为什么还偏偏是最坏的那种结果啊,为什么领导觉得自己水平非常高,而我偏偏觉得他们水平这么low啊。

跟着这帮大爷混,是没有前途的,对,一定是的。

观点之争,本质就是利益之争,就是权势之争,所以必将是生死之争!所以各路大神必将是赤膊上阵,使出各种招数置对方于死路,基于什么面子,道理,公正,正义那真的是一些无所谓的东东!

我忽然感觉古代的那些改革家,他们真的非常不容易。在一个公司,要一个源码都这么难,还何况是在一个国家进行各方面的改革。要一个源码,只是动到了一部分人的利益,就遇到了这么大的阻力;在一个国家进行改革,可以想象得到这是要触动到多少既得利益者的利益,那这个阻力,反对声,甚至这个殊死搏斗是要多么的强烈啊!

所以,改革者,必将是一群内心无比坚强,意志无比坚定,化阻力为动力,排除所有的艰辛困难,将自己对芸芸众生的怜悯和博爱,化为各种理念,方针,政策,律条造福于大众。

原创粉丝点击