项目上线了,一些项目完成后的感想

以下内容出自我给领导写的项目总结中的一部分
贴出来的目的希望里面的一些东西可以对大家有所帮助.
也许也有很多人的公司和我们有着同样的弊端与不足.
大家可以讨论一下该如何克服他们.


===========================================

项目开始时大家都说,我们这个项目必须成功,不许失败,也有人说,我们这个项目必然成功,不可能失败.
项目这东西对于公司来说 也许只有失败和成功两种情况.
但是我觉得还有第三种情况:没有失败,但绝对算不上成功.

在成功的完成了一个项目的开发之后,员工的个人技能、团队的战斗力、公司的凝聚力都应当得到提升.
而我们这个YWZC项目是否让我们得到了应得的提升呢?
项目完成后，我们当中,是因为自己的成长而感到兴奋的人多一些,
还是因为项目的艰辛感到疲惫的人多一些,还是那些感慨"总算完事了"的人多一些?
我想这三者的比例 最能直接反应出我们这个项目是否真的取得了成功.

从成功的项目再延伸一下，我们的团队是成功的吗 是出色的吗？
这个的衡量标准有很多,但最基本的一个就是,成员对团队的认同感如何.
如果团队成员自己都对这个团队不满意,那么这个团队不管做出了多么伟大的业绩,它都不是一个出色的团队.
当然,没有哪个团队能让成员100%的满意,但是有60%的成员表示满意应该是一个最基本的及格线.
我觉得我们的团队应该是达不到60%的.


提高员工认同感和归属感的一个重要手段是对员工进行正确的激励,这个工作通常应该由TEAM LEADER来做.
但是说实话,TL表扬开发人员10句 不如大领导的一句,
这到不是说TL的激励不重要,而是因为TL与开发人员太近了,成天被生活在一起的人激励,力度明显不够.
就好像陌生人对我们的认可往往比父母对我们的认可更让我们高兴一样.
所以,希望上层领导能多表扬表扬底层的程序员吧 呵呵.



再来说说我最关注的技术吧
坦诚的说,我们部门的技术已经落后于业内的其他出色的公司了.
原因我觉得大概有以下几点:

1 原先的技术骨干,逐渐走向管理层,在专研技术上所能分配的时间越来越少
而新的技术骨干没有成长起来,并且略显浮躁(例如我,呵呵.没办法,现在就是一个浮躁的年代.踏踏实实做学问的人越来越少了)

2 对于我们的系统,我们过分的追求了"稳定".很多代码还是很多年前留下来的,今天依然能用,那么我们就继续使用.
我们对代码的修改只是修改BUG,添加功能,很少进行技术上的重构.

3 对新技术的关注不够.
新技术常常被认为是"不可靠的,未经过足够考验的"不成熟的东西.
这样的观点有一定的道理,但是我们可以不使用,可以不去学习,但是不应该不去关注.任何技术都是从不成熟走向成熟的.
现在行业的竞争激烈,等到某技术成熟时,我们再去关注就太迟了.
而且很多东西,我们不去主动深入的了解他就很难做出正确的评估,仅仅是临阵磨枪,靠google来的一些介绍性文章是远远不够的.

4 开发人员良莠不齐
开发人员素质差异这个问题不可能避免,团队规模越大越是如此(总是有一些擅长面试和笔试的人可以顺利的混进公司).

5 开发人员之间的技术交流太少了.
我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.
很多员工似乎都只满足于"我的技能能完成领导交给的工作就可以,不管完成的快慢好坏",不愿意花业余时间来进一步学习.
我始终信奉一句话:人和人之间的差距是在8小时之外拉开的.
我想我们部门的每一位员工都应该牢记这句话.


6 我们部门以后也许要逐步摆脱低层技术,加强员工的设计能力和业务水平,编码的工作交给外包做.
这样的思路是有道理的,是可行的,但是宏观与微观的度应该把握好,太过注重宏观的上层的东西,忽视技术细节,后果就是我们会被外包人员牵着鼻子走.
举个极端夸张的例子吧,如果大家都专研设计 都搞宏观的,代码复查的时候,连外包写的代码我们都看不明白,那就糟糕了.


关于技术方面的想法我还有很多很多,有机会我再单独撰文吧,在这封信里就不多说了.
公司的口号是"超越技术" 但是在超越前,请让我们先"关注技术"吧

评论

4 楼 抛出异常的爱 2007-04-18  

领导不 知道程序员分很多种
我正在写flash的AS时就已经知道了

3 楼 fins 2007-04-18  

谢谢楼上2位的回复

to leondu
我们还真是大规模公司,我们部门就700多人 呵呵
外包这件事已经是领导定下来了
不过 说实话,现在这批开发人员要是真的成为了设计人员
那公司真就毁了

说句没什么意义 而且有点意气用事的话:如果我是领导,我们部门的人我至少会裁掉一半 太多在里面滥竽充数的了 看着就生气

2 楼 leondu 2007-04-18  

引用

项目完成后，我们当中,是因为自己的成长而感到兴奋的人多一些,
还是因为项目的艰辛感到疲惫的人多一些,还是那些感慨"总算完事了"的人多一些?
我想这三者的比例 最能直接反应出我们这个项目是否真的取得了成功.

同意，只有成员获得成就感，才能实现真正的可持续发展。

引用

1 原先的技术骨干,逐渐走向管理层,在专研技术上所能分配的时间越来越少
而新的技术骨干没有成长起来,并且略显浮躁(例如我,呵呵.没办法,现在就是一个浮躁的年代.踏踏实实做学问的人越来越少了)

感叹一下，不过现状就是这样，软件公司的技术人员大部分在做多几年之后，都自觉或被逼“上位”了。

引用

我始终觉得,开发人员之间的技术交流要比公司组织的技术培训对他们的帮助大.而我们部门这样的氛围不浓烈.

我见到的软件公司普遍存在这个问题，有培训，没交流。

引用

6 我们部门以后也许要逐步摆脱低层技术,加强员工的设计能力和业务水平,编码的工作交给外包做.

这个还是要看具体情况吧。其实也可以在公司内部形成梯队式的开发，有核心团队负责可重用基础组件的开发，有人做一些编码的工作。外包如果不是太大规模的公司，恐怕也不容易实现吧。

1 楼 Allen 2007-04-17  

人们正在直上天堂，人们正在直下地狱……

只要“35岁还在写代码就是人生的悲哀”这种思想还在盛行一天，我们就一天不得不痛苦的徘徊。