说说项目管理的那些事儿

在我们的开发团队里,每一个带过项目的人都成了优秀的员工.
这不是偶然,领导别人才会明白如何被领导,有句话叫”没有当过老板的员工不是好员工.”五年前听说这句话的时候还很不理解,等到自己做了项目负责人才真真切切地体会到这一点.

今天想谈谈自己管理项目之后得一些体会.总体分了几大块.

人员管理:

人最大的问题有三个:
No.1 把自己的安排放在集体安排之前
从1.0到3.0开发时间相对较长,做项目做得有点烦了,晨会的任务并不能激起大家开发的兴趣,这些活干与不干对于自己来说都没有什么,每个人更希望通过视频的方式去学习,自然就松懈了开发.各系统组长也忙自己这块的业务,很少去各个组员那里转.每个人都像一个死结点,没有连通.整体说来,就是项目代入感不强.大家思想认识上还不知道真正的学习和经验其实是来自项目.

No.2 信心不足
有些人觉得自己进度比较慢,总想专心致志地看视频提高自己的水平.这是一种心理上的坎儿,而且会持续很长一段时间,信心不够的同时在跟其他人交流开发过程中的事宜时,理解不了问题关键所在,实在又不能放手大干.对于这种情况,我觉得就像3.1一样,来个快速的版本,让更多的人先看看猪跑,再细吃猪肉,或许是个好办法.

No.3 交流不畅.
人与人之间的交流应当是友善的,言简意赅的,人应当对自己说的话负责.可事实上,大家总很难摆正心态,将个人情绪夹杂进来,经常埋怨别人,火气大了,就冲着脾气好的人发火.唉!
我很认真地问过金阁,为什么我态度不好的时候他会听着却不反驳我?
他说,他站在我的角度看,我说的有理,他改进就好了,没什么可争的.
大多时候我看着他,便想,技术如何不重要,做人的境界上一般人还真未比得过他!

另一种交流就是关于项目本身了,有些事不清楚怎么干就不能口头交代,比如先做外部接口还是内部业务还是并行开发,要有计划有顺序地去实施,更多的交流应当是落实到文档上,保证我们有”文档”可依,有”文档”必依,违”文档”必究.

交流的目的是共同进步,要进步就要分享,我们总有技术是不会的,总要向别人学习,自己懂了还要愿意花时间讲给别人,算是杜绝小农意识吧.周响一直做的很好.

时间管理:

对时间的利用最大的问题是没有控制地加班.
1.0-2.0 系统开发期间,几乎每周四都白天加班晚上休.时间上能保证,效率我评估不了,因为处于初期,要研究和学习的东西很多,功能开发的不完全也不尽完善都是可以理解的.

3.0 再提加班的时候,加过班的人坚决反对.3.0开发期间,因为作品展及后续事情让整个班都近乎丢掉了开发的热情.去保定读研究生前才稍有好转,保定10天归来,开发又跌入低谷.随后便是一阵研究热潮,有的人早出晚归效率大大的,有的人则慢慢退出了开发的圈子.

3.1不得不说加班加到疯狂,效率高吗?不管高不高,我建议珍视生命,加班有度.过犹不及!
如果能把项目计划安排的妥妥的,哪里用得着加班呢.就算安排的妥妥的,满满的也完不成,那延期也是正当的.

项目计划:

计划被严重打乱.
计划是给变化用的,出现偏颇很正常.但有前面的负责人指导,我们如果能再谦虚一点,聪明一点,借别人的脑袋撞得头破血流增长自己的经验.多听听建议,减少些建议来了不知如何抉择的情况.

任务管理:

项目组长应当有一定的前瞻性.安排任务有目的性.
我们总会出现一些做了无用功的现象,这就是因为项目组长前瞻性不够,所以每一个重要的决定都要有规划有审批,任何超过半天的工作都必须严重对待,因为公司成本不允许推倒重来.

接口管理:

各系统提出接口要有统一的格式,要明确自己要什么接口,根据什么查什么,返回什么,返回什么类型,都要用专业的语言描述清楚,最直接的就是写一个没有实现的方法,加上注释说明是什么业务.就像UML图,有了这些就避免了千言万语的形容,关键在于描述不清.挨个落实又是数不胜数地口头打交道,耽误开发时间.

当调用接口的各系统开发人员,发现调了基础提供的接口有问题时,问题包括查不出数据,有返回值但取不到等要及时和相关负责人联系,并一查到底,如果调不到就直接使用了假数据继续自己的开发,那就屏蔽掉了发现这个接口多种可能性问题的途径.我们存在这么一个现象,接口所在模块是A负责的,这个接口是B开发的,使用接口的是C,当C发现接口有问题时可以向本系统负责人D反映,由D和接口提供负责人E联系.这样一个流程如果没有良好的管理形成环路,就会造成接口成为死接口的后果.AB觉得接口没问题,C觉得接口有问题,DE不知道.于是一直都用的假数据.为了不耽误开发人员C的进度,应当由两位负责人进行处理.

代码管理:

代码最大的问题是公共代码缺乏维护,各人出现问题时都调各自的,而不去想整理公共的部分.

2.0时底层封装了公共js,是common.jsp, pagetools.jsp和searchbox.jsp.这里面封装了一些公共的方法和样式,其中会固定调用一些方法或使用一些固定名称,如dataGrid就叫queryArea.各系统引用这些页面就得符合这些命名.而当时只有基础系统推行了这一公共样式,就是所谓的百度框.到3.1大家写页面的时候,用了这个样式去不掉,去就会影响其他页面的样式.大家就各自调试.这样做的结果是各个开发人员开发的页面样式不再统一,费时费力改完了自己的代码,公共引入的那些代码得不到改善无法继续复用.

如果说时间紧,保留原样式也是其中一个原因吧.这些问题倒是可以在优化中去解决,有没有从集体的角度去考虑,这是一个问题.

一个好的开发团队氛围应当是积极向上的,项目组长要带领大家一起拥有狼一样的合作精神,天使般的美丽心情.