致新人,差距是如何产生的(02)


致新人,差距是如何产生的(02)
Hansen

先从一个故事讲起:

一个师傅带两个学汽修的徒弟,都从喷漆开始。一年后,师弟都会调悬架了,师兄连轮胎都不会换。师兄问师傅,为只教师弟不教自己。师傅说,为了把漆喷好,你师弟请教了几个老师傅,查了不少资料,每天晚上都自己花时间尝试各种想法,半个月就可以自己做好了。你呢,每天看似很努力,但一个问题出了几次还不知道为什么,三个月后还是只能处理最简单的刮擦,怎么教你新东西?换轮胎不是我教的,我带你俩出去修车,都遇到过爆胎。你师弟看过一次,第二次就主动要求试试看。你呢?我换车胎的时候,你在抽烟玩手机吧?。。。

总结一下也就是: 性痴则其志凝。故书痴者文必工,艺痴者技必良。世之落拓而无成者,皆自谓不痴者也。

以下内容节选自《平台组动员会议2017.ppt》:
自主学习
2016年你学到了什么?读了几本书?看了多少教程?读了谁的博客?在StackOverflow上回答了几个问题?GitHub上贡献了几行代码?LeetCode上通解决了几个问题?是否接触过新的语言?
考个证?拿个学历?参加个会议?参加个培训?
2017年,你的学习计划是什么?是不是要重复2016年做的事情?你的2016年是不是在重复2015年做的事情?
Google还是百度?英文还是中文?

什么是高原反应?
什么是努力,知道迈特凯、洛克李、迈特戴吗?
如何提升自己?请用5%的休息时间来提升自己。

主动思考
支付宝有几种支付方式?微信有几种支付方式?为啥需要这些支付方式?
全家移动支付的时候,需要收银员做什么操作吗?为什么?
滴滴打车,司机抢单算法是如何计算的,你知道什么是滴米吗?
手机定位有几种方式,必须要GPS才能定位吗?手机计算你走了几步,是怎么实现的?
什么是Java?Java常用框架的原理是什么?Tomcat是怎么工作的?JVM究竟是做什么的?Dubbo怎么实现RPC的?
软件哪里可以优化,哪里应该改进?我的代码哪些地方有些问题?

Stay hungry, Stay foolish。

做喜欢的事情,还是应该做的事情?
随着一个人的成长,这是一个人必然会遇到的问题。(你父母希望你先写作业,还是先看电视?你希望自己的孩子怎么做?)
任务分配的时候,是应该把业务流程讲解清楚,还是让他、她自己去看去理解?
代码注释应该怎么写?
单元测试应该怎么写?
SVN代码提交的时候,注释应该怎么写?
代码提交之前是否应该通过单元测试?流程是否应该跑一遍?
程序发布之前,是不是应该自己先测试一下?还是直接扔给测试或实施?

如何提高员工的归属感


如何提高员工的归属感
Hansen

1、物质奖励(除了薪水,还要有适时的激励和奖惩)
员工工作,就是为了更好的生活。一切只谈理想而不谈待遇的企业,都是在耍流氓。
但要知道,物质奖励可以留着员工的人,但很难留住员工的心。
这和追女朋友是一个道理的。

2、让员工知道自己的职业道路,以及上升空间
一个没有进步空间的岗位,是留不住人的。

3、让员工提升对自己工作的认可,其实就是提升对自己的认可,从而增加员工的自信
人对自己做的事情认可了,才能坚持下去

4、管理层应该去了解你的员工,去关心你的员工,增加团队粘性
团队关系良好,是很强的粘合剂
有些员工带有自来熟的属性,也是很合适的粘合剂。
可以参考海底捞。

5、良好的企业文化
重视每一个员工,和谐的人际关系
重视员工的权利,明确员工的义务
增强员工话语权,让员工一同参与出谋划策,增强员工的使命感及荣誉感

6、管理层的示范作用
要起到带头做用,勇于担当
让别人喜欢你,让别人认可你,让别人信服你

7、公平考核制度及竞争环境
you can you up. no can no bb.

8、要对员工进步,并提供相应帮助
让程序员永远在同一层次上,重复同样的工作,是留不住人的
要求员工自学、积累、创新,并给与教育、培训的机会
看看很多从外包企业出来的哥们,在外包做了十年,重复了十年,最后把自己荒废了。

9、培养并激发员工的兴趣
包括工作相关和工作无关的兴趣。

这样的产品你会用吗?


这样的产品你会用吗?
作者:Hansen

首先,让我们来看一个小故事。

节选自:
龙枪编年史||,第三卷,第05章

人物介绍:
浓修:一个喜欢发明机械装置的侏儒
泰斯:一个喜欢游荡的坎德人
费资本:年迈老法师

前情提要:
泰斯和费资本要通过侏儒的投石机装置,从1楼飞到15楼

正文开始:

“三十五层楼高!”泰斯惊讶地重复。“住在顶楼不就倒霉了?这样得爬多少层阶梯啊?”

浓修吸吸鼻子。“我们早就舍弃了这种原始的装置。”他比着手势,“如果你不介意看看这些我们所制造出来的可怕科技成果吧——”

“我看到了。”泰斯把视线重新技回地面。“你们大概正准备打一场大规模的仗。我从来没看过这么多的投石器——”

坎德人硬生生吞回去接下来的话。正当他看着时,一声哨音响起,投石器把一个侏儒射出去。泰斯看见的并不是武器,而是一种取代楼梯的装置!

大厅的最底层放满了投石器,几乎含括了每一种侏儒制的投石器。有弹簧做的、十字弓形的、蒸汽机驱动的(还在实验阶段,他们在调整水的温度。)

投石器上下左右缠绕着数百里长的绳索,每一条绳索都连接着某种齿轮和机械装置,发出机器运转的声音。

  地板、墙壁、投石器上尽是各式各样的拉杆,成群结队的侏儒正努力地拉上拉下。

  “我想,”费资本听起来十分的无奈,“这个检验室应该不会在一楼吧?”

浓修摇摇头。“检验室在十五楼——”老法师发出一声心碎的叹息。

  坎德人听到一阵令人牙龈发酸的声音。

  “啊,他们准备好了。快来——”浓修说。

  泰斯快快乐乐、一跳一跳地跟在他后头,走向一个巨大的投石器。一名侏儒不耐烦地向他们打着手势,比了比后面一长串正排队等候着的侏儒。

泰斯跳上了投石器,满怀期待地看着天空。他可以看见许多侏儒从各楼层往下看,身旁环绕着各种机器、齿轮和说不出名字的装置,最容易分辨的是一种挂在墙壁上、类似棒子的东西。

浓修站在他旁边,皱着眉头。

  “敬老尊贤,年轻人,所以赶快离开让老人家坐上来。”他以他惊人的力量将泰斯从位置上拉下来,“魔法师优先——”

“喔,没关系啦!”费资本抗议,一个不小心,往后跌进一团绳子里。“我——我好像想起了一道可以让我飞到上头去的法术,浮空术,那是怎么施——施展?给我几分钟想一想……”

“一直叫我们快一点的是你那——”浓修生气地看着老法师,后头排队的侏儒开始鼓噪起来,彼此推挤。

  “啊!拼了啦!”老法师大吼,迈步爬过座位里,浓修在一边帮着。

负责发射投石器的株儒喊了一具不知道什么话。

  浓修指着上面,喊回去。“第十五层!”

技师走到五个拉杆之前,这里延伸出几近无限长的绳子。费资本哀怨地坐在投石器上,挣扎着要回想起他的法术。

  “预备!”浓修大喊,把泰斯拉近,好让他能看得更清楚,“用不了多久,技师就会给我们信号,对——就是这个信号——”

技师拉了拉一条绳子。

  “那有什么用?”泰斯插嘴。

  “这条绳子连接到第十五层的一个铃上,告诉他们有人要上来——”

“万一铃没响怎么办?”费资本大声地问。

  “会有第二个铃声提醒他们第一个铃没有响——”

“铃声没响底下会怎么应变?”

“就啥也不做。那是第十五层的事,不是你的问题——”

“万一他们不知道我要来了,这就变成我的问题了!”费资本大喊。“难不成要我就这样跳过去给他们一个惊喜吗?”

“啊!”浓修骄傲地说,“我跟你说——”

“我不玩了……”费资本表示。

  “不,等等。”浓修说,说话速度因为紧张而越来越快。“他们准备好了——”

“谁准备好了?”费资本愤怒地问。

  “第十五层!他们把网子放出来了,你知道——”

“网子!!!”费资本脸色发白,“够了!”他一只脚踏了出去。

  但在他逃出去之前,技师已经伸手拉下了第一根拉杆。一阵机械运转声后,投石器开始在轨道上移动。运转的震动又把费资本摔了回去,帽子遮住眼睛。

  “发生什么事了?”泰斯大喊。

  “他们正在就发射位置。”浓修大喊。“经度和纬度已经计算妥当,可以把乘客发射到预定的位置——”

“你给我说清楚网子是怎么一回事?”泰斯扯开喉咙大吼。

  “法师会飞上第十五层——喔!我向你保证,相当的安全——我们做过研究,事实上,研究结果证明了飞行比走路还要安全——等他飞到了轨迹的最高点,正要开始落下时,第十五层会伸出一张网,像这样抓住他”依修用一只手示范,啪的一声抓住一只蚊子,“然后把他丢——”

“这时间可得算得很准罗!”

“时间铁定准,因为我们研发出一种钩子来进行这项艰巨的任务,不过,”浓修嘟起嘴,皱眉说,“有些时候是投石器会出现误差,不过我们有个委员会——”

侏儒拉下拉杆,费资本尖叫着飞上天空。

  “喔哦!天哪!”浓修瞪着天空。“看来——”

“什么?什么?”泰斯大叫着想要看清楚。

  “网子又太早打开了——”浓修摇摇头,“第十五层今天一天已经发生了两次,这可得提案到安全网公会去讨论,并且不能让它再度发生——”

泰斯张大嘴,看着费资本的身影划过天空,借着投石器巨大的力量不断地往上飞。刹那间,坎德人终于懂了浓修在说些什么。

  第十五层的网子并没有在法师飞过第十五层之后张开而是在费资本飞越之前就张开了。费资本像是被打扁的苍蝇般贴在网子上。

  有短短的一瞬间,他手脚并用地小心抓着网子,然后……就掉了下来。

  钟声和锣声齐鸣。

  “别告诉我——”泰斯哀怨地说。“那就是网子失效的警告声。

  “你猜对了,但不用太紧张(自鸣得意地笑着)”浓修咯咯笑道,“因为这个警铃会触动第十三层的网子,正好可以——唉呦,看来好像迟了一步,不过没关系,我们还有第十二层——”

“快想想办法!”泰斯尖叫道。

“别穷紧张好不好!”浓修生气地说。“不然我根本没有机会说完我刚刚正要提到的最后后备安全系统,喔,来啦——”

泰斯惊讶地看着第三层墙壁上伸出了六个大筒子,底部打开来,掉出无数的海绵,铺在第一层的广场上。这是为了——显然的——预防所有的网子都没有接到。

很幸运的,第九层的网子没有失效,正巧来得及将法师捞起,之后网子随即收拢,把他甩到一个阳台上,侏儒们听见他不停的咒骂声,有点不大敢放他出来。

  “这下全部妥当!该你了。”浓修说。

  “最后一个问题!”泰斯坐在座位上对着浓修大喊。“万一这个后备安全系统也失效了怎么办?”

“好问题——”浓修高兴地说,“如果这些海绵掉下来不够快,那么另一个警铃会响起,将一大桶水倒到广场中央,然后呢——正好海绵这时候也该倒了下来——要擦干净地上的血迹就很简单了——”技师拉下了拉杆。

是不是很好笑?

问题是,我们是不是有一些产品,给到用户的时候:
1、一开始就做了很多错误的假设,用了错误的原型?
2、团队任务分工不明确,相互之间不Care?
3、不去预防问题发生,而是尝试各种Catch问题?
4、用了先进的技术,而忽略了用户的问题?
5、用户用差异的眼光看着你的时候,你仍自信的感觉那是称赞?

写在博客500篇

最近做了一些改变,删除并合并了几篇文章,把几篇非技术文章移到另外的网站,最近又重新整理了一下分类。

今天发现,经过了几年的努力,已经发布了499篇博客了,加上这一篇,已经500篇。

虽然没有什么高深的内容,访问量也不高,但一路坚持下来也并没有那么容易,还是有些成就感的。

希望自己可以保持初学者的心态、有一颗平常心;
希望自己可以保持自己的好奇心、求知欲;
希望自己可以保持自己积极、乐观的心态;
希望自己的生活可以变得更美好:)

希望后面可以慢慢加入一些比较深入的内容,如果有时间的话。

不知道博客何时可以达到1000篇,希望自己可以继续坚持下去。

公司SOA架构演化

最开始的时候,公司没有采用任何SOA架构。
(虽然用到了COM,但没有用到DCOM)
(用到了SOAP,但仅仅是做接口使用)

2011年,开始用EJB,但只在一个项目使用了EJB。

2012年,突然涌进了大量的接口,于是求救于ESB,成为了下面的样子。
ESB+SOAP
ESB+HL7
ESB+REST

2015年,开始向RPC框架求救。
ESB+Dubbo+(SOAP/REST/HLU)

如何向外行解释产品经理频繁更改需求为什么会令程序员烦恼?读后感

前几天在微信朋友圈中看到了这篇文章,立即就转发了,看完后感触还是很多的。

作者“猫爱吃鱼不吃耗子”,以餐馆点餐为例,说明了定制化产品在研发过程中遇到的种种问题,这些问题,在实际过程中都或多或少的遇到过,但如果在一个产品中,全部遇到,那真是“我日了狗啊”。

这篇文章主要描述的是,一个不懂开发、没有产品经验的需求管理人员(产品经理),在遇到奇葩客户的时候,虽然积极应对需求变更,但忽略了客户的实际需求,没有了解需求后真正的原因,最终产出了看似达到用户需求的产品,但用户各种不满意,开发人员不满意,产品经理各种挫败感。

neohope原创(apps.neohope.org)

如果换一个有经验的产品经理,差不多是这个样子的:

你去饭店,坐下来。
“服务员,给我来份宫保鸡丁!”
“好的!我们店的宫保鸡丁做法是。。。”
——————根据客户实际情况,介绍自己的产品,客户越不了解自己的需求,这里越重要,要明白客户要什么,要知道,不少时候客户其实是想要鱼香肉丝。引导用户,搞清楚真正的需求。

服务员:“您是否有其他要求?咸淡?是否加辣?”
“最近没食欲,加点儿辣椒”
“微辣,中辣,还是重辣?”
“中辣好了”
。。。。。。
——————逐步细化用户需求,开工前一定要确认。有经验的产品经理+有经验的用户,这里是最快的,比如用户很可能直接说(“来个宫保鸡丁盖浇饭,只要一半饭,中辣,打包”)。用户没有经验时,这里是要下工夫搞清楚的。

服务员:“要米饭吗?来点儿啤酒不?”
“来两碗米饭,要开车不能喝酒”
。。。。。。
——————了解自己有哪些产品,可以一起卖给客户,组合套餐全家桶

服务员:“现在用餐高峰期,根据您的要求,30分钟之内上齐,加米饭共30元”(其实会预估为20分钟)
“不能快点儿吗,饿了”
“好的,尽量给您催”
——————与用户沟通工期,给自己留余地,取得用户理解(客户催促时,告诉他已经沟通过工期,而且你自己还有一点儿余地可以退让)

厨房:
“宫保鸡丁一份,中辣,不要花椒,米饭两碗,客户要20分钟上齐”
厨师:“好滴”
——————要描述清楚需求,多多沟通

餐厅:
“服务员,我想在菜里加腐竹”
“以前也有客户加腐竹来自,我自己尝过,难吃的要死,要不您来份本店的凉拌腐竹,小碟免费”
“那好啊”
——————要清楚自己的产品线及成本,通过其他案例的经验教训,引导用户到正确的道路上来,提出合理的解决方案。腐竹这类凉菜,相当与公司成熟的小应用,解决具体的实际问题。但要考虑成本的,成本低没问题,但如果客户要个肘子,不好意思,加钱。

餐厅:
“服务员,我要在菜里加花生,去皮的,必须加”
“那我问下厨房”
——————总有新需求无法拒绝,自己清楚的可以许诺,但不清楚的要和研发沟通

厨房:
大厨:“花生去皮要先泡,先吃不上,要不换腰果,但口感不一样,而且要加钱咯”
服务员:“我去问问看,你先别下锅”
——————多方沟通,获取可行解决方案,并进行评估

餐厅:
“花生去皮的话,要多等半小时,我们厨师建议你换腰果试试,就是贵点儿”
“腰果就腰果,还没吃过这样的呢”
“好的,我去说一下”
——————与客户沟通可行方案,但要有主有次,有引导性

餐厅:
“要不我还是要带皮的花生吧”
“对不起,菜已经下锅了,我们大厨说了保证好吃”
“那好吧”
——————客户在某一功能点摇摆不定时,帮助他坚定信念

餐厅:
“上菜咯,外加米饭两碗”
“还不错,上菜挺快,腰果也不错吗”
——————尽量在约定时间内给客户解决问题

在实际做项目的时候,首先要了解清楚用户的实际需求,然后多方进行沟通,避免返工及重复劳动,完成自己对客户的承诺。这才是向合格的产品经理迈进了一大步呢。

其实,真正做项目的时候,都有无法预知的问题,但产品经理就要见招拆招,知道自己的底线在哪里,沟通沟通再沟通,这样才能保证事情顺利进行。

如果任务不可行的时候,那就应该说不可行,宁可不做,也不要把团队带入需求的泥潭。长期在泥潭里,士气会很快低落,人心散了,队伍就没法呆了。

加油吧!

===============================================================
上面说的是定制化产品开发,但大家有没有考虑过成熟产品是如何处理的呢。

你去KFC点餐。
“服务员,给我来个香辣鸡腿堡套餐,打包!”
“好的!”
——————成熟的产品,都是定位特定人群,通过配置而不是开发来达到用户的目的的。其通用性会很高,一半通过搭配,可以解决绝大多数客户的问题。但对于少数用户的奇葩需求并不会处理。而这些也是通过长期的积累,把经验变成了需求,变成了产品的一部分来做到的。

在这里,实施人员成了KFC的配餐员,产品经理是KFC新产品的需求采集人员,研发人员是设计出这些产品的幕后工作者,销售人员是新产品的推广者。

具体情况,大家可以看看Google、MS、亚马逊、阿里的一些开发流程,会发现不少好玩的事情呢。

好啦,先写到这里啦。

如何向外行解释产品经理频繁更改需求为什么会令程序员烦恼?


如何向外行解释产品经理频繁更改需求为什么会令程序员烦恼?
作者:猫爱吃鱼不吃耗子(转自知乎)

你去饭店,坐下来。
“服务员,给我来份宫保鸡丁!”
“好嘞!”
——————这叫原始需求

大厨做到一半。
“服务员,菜里不要放肉。”
“不放肉怎么做啊?”
“不放肉就行了,其它按正常程序做,不就行了,难吗?”
“好的您稍等”
——————中途需求变更

厨房:
大厨:“你大爷,我肉都回锅了”
服务员:“顾客非要要求的嘛,你把肉挑出来不就行了吗”
大厨:“行你大爷”
然而还是一点点挑出来了
——————改动太大,部分重构

餐厅:
“服务员,菜里能给我加点腐竹吗?”
“行,这个应该简单。”
——————低估改动成本

厨房:
大厨:“你TMD,不知道腐竹得提前泡水?炒到一半才说?跟他说,想吃腐竹就多等半天”
服务员:“啊你怎么不早说?”
大厨:“早说你MLGB我怎么知道他要往宫保鸡丁里放腐竹”
然而还是去泡腐竹了
——————新需求引入了新研发成本

餐厅:
“服务员,还是把肉加回去吧”
“您不是刚说不要肉吗”
“现在又想要了”
“…好的您稍等”
——————某一功能点摇摆不定

厨房:
大厨:“日你啊,菜都炒过火了你让我放肉?还好肉我没扔”
服务员:“客户提的要求你日我干嘛?”
大厨:“你就不能拒绝他啊?啊?”
服务员:“人家是客户嘛。”
——————甲方是大爷

餐厅:
“服务员!服务员!”
“来了来了,你好?”
“怎么这么半天啊?”
“稍等我给您催催啊”
——————改动开始导致工期延误

厨房:
大厨:“催你M催,腐竹没泡好,我还得重新放油,他要想吃老的也行,没法保质保量”
——————开发者请求重新排期

餐厅:
服务员:“抱歉,加腐竹的话得多等半天,您别着急哈”
“我靠要等那么久?我现在就要吃,你们能快点吗?”
“行…您稍等”
——————甲方催活

厨房:
大厨:“我日他仙人板板,中途改需求又想按期交付,逗我玩呢?”
服务员:“那我问问,要不让他们换个菜?”
大厨:“再换我就死了”
——————开发者开始和中间人pk

餐厅:
“服务员,这样吧,腐竹不要了,换成蒜毫能快点吗?对了,顺便加点番茄酱”
——————因工期过长再次改动需求

厨房:
大厨:“我日了狗啊,你TM不知道蒜毫也得焯水啊?还有你让我怎么往热菜里放番茄酱啊??”
服务员:“焯水也比等腐竹强吧,番茄酱往里一倒不就行了吗?很难吗?”
大厨:“草。腐竹我还得接着泡,万一这孙子一会又想要了呢。”
——————频繁改动开始导致大量冗余

餐厅:“服务员,菜里加茄丁了没有?我去其它饭店吃可都是有茄丁的”
“好好好您稍等您稍等”
——————奇葩需求

厨房:
大厨:“我去他二大爷他吃的是斯里兰卡三流技校炒的宫保鸡丁吗?宫保鸡丁里放茄丁??”
服务员:“茄丁抄好了扔里边不就行了吗?”
大厨:“那TM还能叫菜吗?哪个系的?”
服务员:“客户要,你就给炒了吧。”
大厨:“MB你顺道问问他腐竹还要不要,我这盆腐竹还占着地方呢不要我就扔了”
——————奇葩你也得做

餐厅:
“服务员,还要多久能好啊”
“很快,很快…”
“再给我来杯西瓜汁。”
“…好”
“我再等10分钟,还不好我就走了,反正还没给钱。”
“很快,很快…”
——————黑暗前的最后黎明10分钟后

“咦,我上次吃的不是这个味啊?”
从厨房杀出来的大厨:“我TM就日了你的狗…”
——————最终决战

——————
你=客户
服务员=客户经理+产品经理
大厨=码农
请自行转换…
——————
注:以上场景已极度夸张,实际生产生活中码农和PM是和睦友好的相亲相爱的一家人
——————
注:对于做2C产品的公司,你=公司大boss

转自知乎,原文链接

产品管理模式演化

==========================================================
最开始的时候,公司产品管理比较混乱,几乎对每一个客户都进行了定制,出现了大量的分支。
后面发现维护成本太高,开始合并各版本之间的功能,但最终仍有十几个版本。

PS:后来公司换了老板,初期很多有经验的研发及实施人员都流失了,很可惜。

==========================================================
2009年,项目比较小,我们采用的是按功能划分的方式进行分工的,经常一个项目就一个人,或一个项目拆为几大块,每人一块来进行。这个模式持续了一段时间。

现在回过头来看这段时间的一些产品,产品功能不多,但需求做的很好,产品定位比较准确,符合客户要求,后期移交其他同事维护后,架构上和界面上都没有大的变化。对于小规模的开发,这种方式还是适用的。

==========================================================
2010年底到2011年,公司开始了电子病历项目的开发,投入了不少的人力。由于项目变的比较复杂,现在变成了十来个人一起扑到一个项目上。第一次引入了需求、测试人员。本人甚至客串了一段时间的美工+前端(惨不忍睹)。

这段时间是架构转型的时间,时间紧任务重,语言也刚开始学,加了很多班,好在项目最终验收了。

后来由于很多原因,整个产品线被砍掉了,又流失了不少人。

==========================================================
2012年,开始了平台项目,初期核心团队不大,产品已经有了原型,加上前面的积累,整个任务还算顺利,但仍然是加了很多班。

架构为简单的SSH,后台逻辑为主,前端现在看来惨不忍睹。

花了很多时间,补充平台应用。

==========================================================
2013年,团队人员增加了很多,引入了MVN,开始有了较好的任务分工,架构变的明晰。

花了很多时间,把其他缺失的部分补上来,逐渐形成了一个产品线。

开始使用快速原型法。

开始引入ESB。

==========================================================
2014年,团队人员再次增加了很多,同时加上很多水平不错的同事加入,有了较好的发展。

开始推进单元测试,产品流程越来越规范,快速原型法使用的越来越多,大量使用交互稿。

很多地方开始务实,产品定位进行了调整,很多项目都开始使用ESB。

部分项目,前后端开始分离。

==========================================================
2015年,团队人员有些变动,核心团队还比较稳定。

开始推进高并发,更加关注代码质量。

补充了很多ESB的接口。

前端团队飞速成长,前后端彻底分离。

==========================================================
顺便说一下,我在2009加入公司时,研发中心除了总监,只有我一个人。初期从其他部门调来几个人员,加上招的一些人,也不足10人,现在研发中心已经接近150了。

致新人,差距是如何产生的(01)

今年,我们组来了很多的java新人(编程经验小于一年的小朋友)。

对于他们,我都会做下面的事情:

1、让他们自己列出自己的知识架构,从而告知其不断积累的重要性

90%的人只用过java语言,只知道SSH。

这里,我会结合他们大学课程、实际经验,给他们补充一部分知识架构,拓展一下视野。

并告诉他们如何去对比的学习新知识,如何找到一种适合自己的学习方式,并要找到适合自己的知识积累方式。

2、以一个很简单的例子,告诉他们应多考虑原理,而不只是用

在一个网站中,在只用了一个框架,比如struts2或spring mvc的情况下,前端登录页面的用户名、密码,是如何发送到后台,并返回验证结果到前台的。

所有人,都直接提到了action如何获取用户名及密码,但只有很少人考虑了,浏览器是如何找到服务器/容器的,也只有很少人知道,容器是如何定位到哪个应用、哪个action的。

然后,会告诉他们,希望他们可以在一年之后,用最复杂的解释,告诉我,这个流程是如何运作的。两年之后,把整个流程变简单,并可以自己去实现一个简单的框架。

3、送给他们一本《程序员的职业素养》,让他们自己去领悟其中的内容

4、探讨他们的职业发展道路

5、开始安排培训,并开始逐步解除新项目

因为,在我看来,程序员在前三年的时候,是个明显的分水岭,所用的学习方式,直接决定了他是程序员还是码农还是该转行。

2015至2016年会讲话

平台组的发言

2015年,对于我们来说是重要的一年。这一年中,一方面,我们积极配合前方的实施团队,力保项目顺利进行。在这里,需要感谢实施组、技术支持组与管理组的同事,给予我们大量的理解与支持(很多现场同事,利用了自己私人的时间,帮我们梳理流程、复现问题、复测程序,陪我们加了很多班),大家帮我们做了太多太多,我就不一一答谢了。我们计划在16年给实施、技术支持组的同事一份大礼,让大家的工作变得更加高效。

另一方面,我们在产品化及服务化方面,进行了大量的工作,并取得了一定的进展。
比如:为了解决横向扩展问题,我们引进了NginX、Redis、消息中间件。让单节点故障对项目的影响降到了最低;再配合虚拟化技术,这样可以更加高效的利用硬件资源;
再比如:为了解决文件检索问题,我们引进了NOSQL技术,(XML数据库、BSON数据库),正在引入大数据存储及计算技术,让互联网的新技术为我们服务,推动我们的产品进步,并最终让技术成为用户的价值。在这里很感谢PACS组同事,向我们分享了很多好的建议,我们有很多好的想法,都是从他们这边来的。
再比如:很感谢视觉设计组+前端组同事,改变了前后台开发的配合方式,帮我们承担了JS+CSS+HTML的调试工作,让后端的程序员专注于后端业务逻辑,让大家去处理各自擅长的事情,大量减少了后端程序员调试JS+CSS的痛苦。

很开心我们组很多同事都有了进步,有些是在技术上有了很大的进步 ,有些人成为团队的主力,有些人已经可以独当一面。这些是一点一滴积累起来的,可能自己还没有意识到。我相信,不积跬步,无以致千里;不积小流,无以成江海。我们做的每一件小事,都是最终引发质变的必要原因;我们遇到的每次困难,都是我们成长的精神食粮。我们真正需要的就是,用心做事,把事做好。不忘初心,方能长久。
我们软件人员大多很内向,话不多。但我感觉在咱们这个大家庭里,充满了温暖。能和各位一步步走来,一起进步,我感觉~真好。