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

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


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

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

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

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


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



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

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

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

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

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

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


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


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

评论

24 楼 dongbin 2007-06-09  

centgo 写道

引用

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

深有同感，不能进行重构的原因太多了，新功能工期紧，系统要求稳定等等。
重构需要时间，时间就是金钱。这是一个长远利益与眼前利益平衡的问题。

恐惧能够扼杀一切创造力。生的伟大，活的憋屈。这是你自己的选择。

23 楼 centgo 2007-06-09  

引用

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

深有同感，不能进行重构的原因太多了，新功能工期紧，系统要求稳定等等。
重构需要时间，时间就是金钱。这是一个长远利益与眼前利益平衡的问题。

22 楼 JJYAO 2007-05-27  

LZ写的很好,非常真实.
有很多复杂的因素会导致一个上点规模的公司出现这种问题.一般大家私下会讨论很多,老板也不是不知道,但大多时候也不能随便乱动,大家就慢慢熬吧.

引用

降低复杂度？会不会延长开发周期？。。。
会？那么被否定
往上爬？会不会更加努力？
会？那么肯定
出去开公司？会不会跑路？
会？趁他没走多用用他。。。

PS：如果一次次被否定你还会研究么？如果一次次被打击你还会努力工作么？

首先你自己要认为你是对的,保持一颗清晰的大脑,并在必要的时候站出来,向大家(你的领导,上上级领导,资深开发人员都可以)清晰的表达你的观点,我相信大多数领导和设计人员都能比较客观的看待问题

21 楼 keete 2007-05-27  

fins 写道

人和人之间的差距是在8小时之外拉开的.

这句话好像就是在说我。我现在就是通过8小时之外，制造差距的。
人在江湖，身不由己。

20 楼 sun113 2007-05-22  

沟通很重要--日本人称水平沟通！

19 楼 umbrella 2007-05-19  

做管理未必要技术很全面吧，甚至连技术都可以不懂.

18 楼 ahuaxuan 2007-04-26  

CosmicWind 写道

Allen 写道

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

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

顶～～～～，我是做外包的，客户的公司开发人员没有下40岁的，有一牛人65岁了还是做coding,思维逻辑非常细腻，当我跟他聊天的时候，他说他已经coding了28年了，以前是一个医生，按理说美国的医生职业是非常好的，但他说他喜欢coding.公司把他当宝贝一样，谁说35岁以后不能coding我会强烈鄙视他，如果你喜欢coding，就坚持下去吧，但如果你想去做管理也可以，请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!

长见识了，这种人很少，从来没有亲眼目睹过呀，不过写代码也是我的爱好，步管怎么样，我也要坚持下去，提供国内的软件氛围就要从自己做起

17 楼 抛出异常的爱 2007-04-26  

CosmicWind 写道

Allen 写道

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

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

顶～～～～，我是做外包的，客户的公司开发人员没有下40岁的，有一牛人65岁了还是做coding,思维逻辑非常细腻，当我跟他聊天的时候，他说他已经coding了28年了，以前是一个医生，按理说美国的医生职业是非常好的，但他说他喜欢coding.公司把他当宝贝一样，谁说35岁以后不能coding我会强烈鄙视他，如果你喜欢coding，就坚持下去吧，但如果你想去做管理也可以，请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!

我的第一个师父大约50岁以上。。。
他是外国回来的。。。
在公司干了6年，一直带新手，手中还有公司股份。
写程序，用软件，写PPT，用VBA写工具，
反正是哪样东西他都能很快的上手，之后再教我
我惊为天人。。。

16 楼 CosmicWind 2007-04-26  

Allen 写道

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

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

顶～～～～，我是做外包的，客户的公司开发人员没有下40岁的，有一牛人65岁了还是做coding,思维逻辑非常细腻，当我跟他聊天的时候，他说他已经coding了28年了，以前是一个医生，按理说美国的医生职业是非常好的，但他说他喜欢coding.公司把他当宝贝一样，谁说35岁以后不能coding我会强烈鄙视他，如果你喜欢coding，就坚持下去吧，但如果你想去做管理也可以，请务必打好深厚的技术背景。我坚信国内的软件氛围会慢慢的变的规范和务实!

15 楼 thinking 2007-04-23  

项目发布了，但是如果开发人员感觉很累，不快乐，没进步，这个项目还是失败的。

14 楼 抛出异常的爱 2007-04-19  

cozone_柯中 写道

抛出异常的爱 写道

KKND 写道

我身边的一些同事，不想着怎么把方法的复杂度降到O(N)，而是每天想着怎么往上爬、或者怎么出去开自己的公司……

当然了，在领导的眼中，我们这些人没有什么区别，都只不过是随时可以牺牲掉的小卒……

如果可以的话我认为会先牺牲掉你。。。。
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。

我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己

降低复杂度？会不会延长开发周期？。。。
会？那么被否定
往上爬？会不会更加努力？
会？那么肯定
出去开公司？会不会跑路？
会？趁他没走多用用他。。。

PS：如果一次次被否定你还会研究么？如果一次次被打击你还会努力工作么？

13 楼 cozone_柯中 2007-04-18  

抛出异常的爱 写道

KKND 写道

我身边的一些同事，不想着怎么把方法的复杂度降到O(N)，而是每天想着怎么往上爬、或者怎么出去开自己的公司……

当然了，在领导的眼中，我们这些人没有什么区别，都只不过是随时可以牺牲掉的小卒……

如果可以的话我认为会先牺牲掉你。。。。
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。

我觉得这样也未免绝对了吧, 谁都有给自己考虑的时候,自是他曝漏了自己

12 楼 lintomny 2007-04-18  

抛出异常的爱 写道

cozone_柯中 写道

抛出异常的爱 写道

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

为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?

为节约点钱让闲着的java程序员去写flash...

这样的老板，实在。。。。难怪你要抛出异常了。

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

KKND 写道

我身边的一些同事，不想着怎么把方法的复杂度降到O(N)，而是每天想着怎么往上爬、或者怎么出去开自己的公司……

当然了，在领导的眼中，我们这些人没有什么区别，都只不过是随时可以牺牲掉的小卒……

如果可以的话我认为会先牺牲掉你。。。。
前两种在干活时没什么太多的麻烦
而你在干活时太用心了。。。

10 楼 KKND 2007-04-18  

我身边的一些同事，不想着怎么把方法的复杂度降到O(N)，而是每天想着怎么往上爬、或者怎么出去开自己的公司……

当然了，在领导的眼中，我们这些人没有什么区别，都只不过是随时可以牺牲掉的小卒……

9 楼 cozone_柯中 2007-04-18  

抛出异常的爱 写道

cozone_柯中 写道

抛出异常的爱 写道

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

为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?

为节约点钱让闲着的java程序员去写flash...

这个确实有点抠门了..我都搞了快6年flash了,还好我们领导没有叫我去写flash

楼上说的一语中的

8 楼 adamzhao 2007-04-18  

cozone_柯中 写道

抛出异常的爱 写道

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

为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?

领导有两种，
一种是外行领导内行的，他知道分多种才怪呢；
一种是象你说的一步一步作出来的。不过绝大多数领导无法摆脱“屁股决定脑袋”的规律。既然做到领导这个位置，就不用考虑那么多了。

古人讲“千军易得，一将难求”，古人还讲“主将无能，累死三军”。

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

cozone_柯中 写道

抛出异常的爱 写道

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

为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?

为节约点钱让闲着的java程序员去写flash...

6 楼 cozone_柯中 2007-04-18  

抛出异常的爱 写道

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

为什么领导不知道呢? 难道领导不是从我们这样一步一步做出来的?

5 楼 cozone_柯中 2007-04-18  

引用

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

引用

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

我们公司有交流, 培训少, 每天都要开会交流.

个人觉得在大环境下,搞开发的大部分略显浮躁, 因为都想着怎么出来自己发展.
导致吧经历用在了其他地方