2014跨年总结

一、14年简单工作回顾

13-14年度是忙碌而充实的一年

  • 组员离职
  • 角色转换
  • ump平台

14年初短时间内两位组员同时离职,工作强度,工作压力骤然增加,有过犹豫。挑战与机遇并存,一个很好的机会展现自己的能力14年是不同寻常的一年,梦想是美好的,现实是残酷的,高强度的工作,周围环境的压力,充满诱惑的外界环境,来自同学朋友的压力,坚持自己的选择有时候并不是一件容易的事。很庆幸能够一直坚持到现在。也很庆幸得到了很多人的支持帮助。

14年,有机会出任开发经理,新的起点,新的平台,新的挑战,近一年下来,感觉很有意思,站在另一个高的起点去看待问题是一个很有意思的事情。当然也体会到了开发经理并不是那么容易的事,要考虑的事情非常多,要做的事情非常多,压力非常大,因为责任。所有的问题止于我们部门,而所有的问题应该止于开发经理。以前当碰到疑难问题时可以找自己的导师,开发经理,而现在,不仅没人找还要被人找。对于新人要去观察每个人的特点给予不一样的安排,尽量让他们发挥自己的特长,给他们创造机会。总的来说,很有意思。

14年,另外一个重大的项目ump平台。很有意思的一个平台,很有意思的团队,10几个人一起开发,很难想象最终还是做出来一个东西。

二、关于部门工作氛围

来部门快三年了,部门的氛围依然和谐,但少了很多乐趣,少了很多交流,也许是部门大了。三大部门就像是公司的一个缩影,大家不知道自己在做什么,整天除了改bug就是改bug,刷问题数,部门之前的交流与沟通,就好比公司大部门之前的交流一样晦涩。很多人没有项目经验,在ump项目出现的时候没有人上心去做这样一个事情,我想肯定很多人是被迫参与,很多人并没有把项目当做一个真正的商用项目来做,学生气太重,很多人参与进来是想有人带,想有人交他怎么做,这种想法本身就是一个错误。

我想很多人没有自己的计划和想法,面对着外面互联网的大环境,很心动,但是没有信心走出去,这也是一种病态的表现。

人们总是误解一些东西,互联网最重要的是什么,我想是互联网思维。而不是你是否在一家互联网公司,做移动,商城,o2o才是互联网?我想不是。互联网核心是专注,极致,口碑,快。而最最核心的就是快。所以我们需要做的是改变我们的工作习惯和工作节奏,提升效率,提高竞争,加速响应。每个人都应该改变思想,把当下的环境变成互联网节奏的环境。提高精气神。我想留住部门人员的原因不仅仅是部门和谐的氛围,更是工作中的成就感。

三、关于现有的工作流程

目前的支持网流程从刚加入公司就这样,一直没有变化,顾问,支持换了几波人了,问题大家都清楚了,但是没有人去改变,也很难改变。期待今年的变动能够改变现有的情况。问题很明显,能力不均等,团队不够完整。各自没有做好自己的事情。我想在这方面我的工作作风是强硬的,甚至有点怨气,但是适者生存。

我在意pbc考核,跟钱过不去那是傻蛋,但是也不在意pbc考核,部门的考核是公平的也是不公平的,没有什么是绝对公平的,我曾说过如果我想刷pbc可以刷的很好看,但是没有什么意义,部门有刷pbc的现象,不过没关系,这也是一种能力,只要大的环境是公平的就可以了,所以还是很佩服老大。我这样的做法想法,也用到的团队管理中。大家做好自己的本职工作,同时发展各自的能力,让你有能力走出公司。不要过分在意pbc考核,尤其不要在意反复率,很多支持,顾问,经常无理由的退回问题,也有很多之前知道开发反复率,故意用这个刁难。我说过我的做法是强硬的,直接退回不与解决。脾气就是这样,谁没有点脾气。是谁的问题就是谁的问题,我没有义务帮你解决,有时间我看看书,听听音乐挺好,发呆也比帮一个小白强,因为不是我的工作。

这就是大环境,适者生存。

我们每个研发都是逼出来的,顾问,支持一句不会,总部所有研发,服务都都得帮弄完。why?

权责分明是最好的解决方案。大家明确自己的工作,可以不会,但是不要不会的理所当然,我们研发也一样。

四、pbc考核

关于考核,我们部门的考核是透明而公平的,这一点让所有人信服,但是也是让人很难受的.我们都知道,考核跟工作方向是矛盾的,工作越努力,系统就越完善,问题就越少,pbc就会下降。这样就没了成就感。

我想是否可以在问题数和处理时间上取某种平均值来衡量,考虑所有问题的平均量,比如:所有问题的平均处理时间(举例而已)
而不要考量问题的量,大家就会积极的使自己负责的模块稳定,更愿意出通版,尽量让问题量下来,让更多问题止于网上搜索平台不要到我们这里来,这样我们也可以做跟多有意义的事情,比如解决疑难问题,而不是很多人在没有问题的时候反而恐慌

关于疑难问题,刚开始提的时候疑难问题是很正轨的,但是现在慢慢的又变成了刷分的工具,当然大部分是含金量很高的,但有的就不尽然,比如很多疑难问题很多人处理好几次,好几个点,像这样的解决就只能算一次,并且上一次的解决加入的工作量需要相应扣减,因为这种情况上一次就是没有解决彻底。

另外,确定疑难问题需要严格公示,现在太随意,我们既然要把疑难问题推到别的部门去说,而且要上创新,就应该规范化,让疑难问题的确定必须是疑难问题。而不是我这个月初提的疑难问题,下一个月另外一个同事一下就解决了,这就不能算。谁提的疑难问题,要严格说明整个问题的现象,还要说明提交人自己分析,甚至开发经理部门经理对整个业务场景,代码场景的分析情况。

对于疑难问题分级,这个提议我想很有必要,也很有意义,另外疑难问题评审匿名投票很有必要。

五、关于流程扁平化

扁平化是必然的趋势,在互联网时代,快,是立足之本,研发运营一体化的根本在于研发参与运营,让研发直接了解客户的需要,不要蒙头苦干,研发出来的产品,功能没人用,有什么意思。公司一直在做这样的事。当有客户提出一个个性化需求,而我们分析这个需求有意义,但是没人响应,我想我们要做的是立马成立项目组调研我们能调研的客户,询问是否需要这样的功能,如果超过一定百分比需要,我们应该在最短时间内做出来,作为一项功能去推广,可以签二开小合同,我想这才是互联网思维,而不是说,我要在下一个版本实现。

公司的流程且不讨论,三大部门内部首先要做到扁平化,所有人之间不应该有职位之分,谁能更好的解决问题我们就应该找谁沟通,以最快的有效的方式得到我想要的答案提供给客户,是我们应该做的,而不是先找普通开发,不会再找开发经理,再不会再找部门经理,最后开发经理跟部门经理得作用只是帮大家协调部门之间的交流协作,这样才是最好的效果。

六、关于个人发展

在部门,个人的发展是比较慢,就像人力评级,三年才能评高级,5年才能评专家也是不无道理,人的成长太慢。个人理解,一个人在一个岗位上完全适应,对于有工作经验的人来说,不用一年,对于没有工作经验的人来说顶多两年。如果不能胜任那就得辞退了,但是在公司技术的响应已经很落后了,一个人也许真的要三年才能解除很多核心技术。而且打的氛围很容易让人迷失,如果自制力不强,很容让你随大流。所谓的幸福企业,不仅仅是归属感,更是成就感,公司整个大环境已经没有了。

所以我时刻提醒团队的成员,让自己忙起来,在改问题至于有部门别的事情做,所以ump平台是一个很好的契机。

七、关于挑战

成就感来源于挑战,我们的工作有挑战吗?有,也没有,整天改bug有什么挑战。

所以我想我们首先要改变大家的想法,改bug有很多种,一种是真的改bug,一种是重构。我们应该要用重构的思维去看代码,读别人的代码,而不是用改bug的思维去改bug。读别人的代码是很有意思的事情,就像我经常重写自己以前的系统,以前觉得很牛逼的写法,现在回头看真的烂得一塌糊涂。

当有一天有能力去重构nc的代码,我想这个时候才是真的牛b的时候,当然,不是想当然的重构。

我们工作中发现了很多问题,代码没注释,废代码,接口定义不明确,没有文档,开发交接不规范,但是我们也没有去做这些事,当然我也没有,这受制于pbc考核,因为花时间去总结这些还不如多改几个问题,这是普遍的情况。

八、关于pbc考核的个人发展项目

pbc考核中有一项个人发展,我想这一项很有必要,经过这几年的讲座还是留下了很多资料,比如网报,两次业务,两次代码,足够新人在短时间了解。今年因为ump所以搞得比较仓促而已。当然问题是有,评分不够规范,有的人讲的好,分数确很低。有的人讲的一般,但是评分的都是熟人,分数就很高。

我想今年是否可以考虑项目组的情况,鼓励大家做项目,任何想做的项目都可以,当然与工作相关的更好,比如,邮件定时发送平台,git统计平台等,都可以作为实际的项目来做,大家平时任何时候,任何人都可以提出自己的项目,自己各自拉虚拟团队,写立项书,项目规划书,开发经理,部门经理,老大,牵头成立专门的评审委员会。评审通过的项目组成立。各自开发,在规定的时间内交付,搭建服务器给全部门使用,部门大会项目展示,按项目组评分,对于优秀的项目现金奖励,对于特别出彩的项目,可以邀请集团领导参加。

部门可申请专门的服务器资源,git资源等给各个项目组,每个项目组前期立项要完全按照实际商用项目运作,包括人员,时间安排,里程碑,交付文档等。

对于没有进入项目组的成员,仍然可以搞pbc讲座,但是需要要求,必须听讲座的人中有其他组,其他部门的人占的比例。这个需要讲座的人自己邀请,如果觉得自己影响力足够也可以直接发全员邮件,但是如果现场听的人比例不够,必须取消。打分需要匿名,现场听完现场打,安排非组员统计分数。

十、15年的工作建议

15年希望能极大限度的改变现有的情况

  1. pbc考核问题量的模式改变成平均量的模式
  2. 个人发展改成项目组的模式
  3. 疑难问题增加等级,提高疑难问题进入的门槛,增加提交人,组的详细分析说明
  4. 鼓励大家公事公办,权责明确,不要把时间花在不该花的地方
  5. 平时多组织活动,提高交流,部门内,部门间,
  6. 增加悬赏,鼓励大家做讲座开源架构使用,讲座人自己组织,邀请别人参加,参会人评级。奖励现金 50,100,150
  7. 增加新人交流机制,新人加入部门除了汇报,还需要组织座谈单人或者多人一起做主持人介绍自己,可以向受邀的人提问同时邀请本部门及其他想要邀请的人参加包括老大。
  8. 除了大部门联络员,每个部门需要增设单独的部门内联络员,定期制定活动方案,比如ktv,滑雪等供大家选择,当然。。。自费。时间可以是每月一次,或者两次,由总联络员定,可以跟其他部门联谊,甚至其他公司。
  9. 成立创新小组挖掘部门内的创新点,提交集团,可又部门联络员带组。(比如疑难问题悬赏模型可以作为一种管理模式提交创新平台评审,文案总结提交可由创新小组负责,这个小组可以作为个人发展中的一个项目组。也可以立项,说明自己的计划。)
  10. ump成立专门的小组,建议6人,一个负责人,一个项目经理,4个开发,真正的互联网项目运作,每天一报,快速开发。
  11. 疑难问题匿名评审
  12. 疑难问题增加连带机制,一个问题多个点,上一次解决加分相应扣减,或者本次评定加分级别降级