您的位置:首页 > 其它

杂谈(一)

2011-02-14 11:52 26 查看
  在工作中,我们总看到有些同事喜欢拿公司的项目作为自己学习某项自己不熟悉的技术的“小白鼠”,藉此项目的压力,获得自己短时间内学好此技术的动力。

  诚然,这种精神很可贵,学习是我们20-30岁这个年龄阶段“必须的”的事情,甚至在我看来是:最重要的事情。必须在自己最年富力强的时候,要为自己今后二三十年在这个社会上立足攒足本领。以前看过一篇文章至今有些记忆,说的是中国现在还没有经历到“老龄化”社会,现阶段的老龄人,都因为国家之前的计划经济,由国家在负责着这部分人的养老;而现在,更多的人工作在在民企,私企,随着合同雇佣的结束,企业将不存在“连带”责任,那我们的养老,怎么办?可能,这有点悲观,但实际上,我觉得这不是杞人忧天,甚至不用等到老,一次足够大的经济危机足以,每个人都应该思考自己今后如何独立生存立足于这个社会(特别希望那些每天都在添加qq应用的同事或者同学都能问问自己)。

  但是,回头发现,我们在追逐自身成长的同时,给项目也带来了很多的风险。新技术的引入,本身存在很大的未知数,而项目中,不同成员的理解、学习能力差异不同,对技术的使用也会出现很多不一致。往往发现,这种项目最后,总是会延期或者在发布到用户那里之后,还源源不断的发回bug记录,造成不好的影响。

  随着这几年的锻炼,我感觉自己对技术的追崇度开始慢慢减少,越来越追求做出一个好的项目,一个好的产品,一个可以贴上自己标签的产品,一个做完后可以自豪的产品。最开始触动我开始这个思考的来自于三年前。当时,我们做学籍项目,前面几个版本发布之后,客户总是有一些抱怨发到领导那里,领导又转发到项目组:“怎么回事?!问题出现很多遍了,一直没有得到解决?!”,往往,我们总是找出各种理由来回应领导:客户硬件条件太差,客户什么都不懂,客户没有按照规定来配置......而后来,我们单独立了一个项,不增加新功能,就是对现有的产品进行改进,优化,去掉一些我们沾沾自喜的“花哨”的功能(到客户那里,客户没有觉得好,反而一看就花了眼,这么多目录,条项,造成学习成本很高),两个月后发布给客户的版本,客户回头就给我们发了一封感谢信,说这个版本好多了,感谢感谢.....后来,创业的时候,接触到了一个做安徽移动项目公司的老总,他说“做一个成功的客户案例比十个0.9成功的客户案例更重要,更能给你带来标杆价值和后期效应”,还和一个生产机电设备的老总谈了几个小时,他说自己当年打开巴基斯坦和印度的市场,靠的是做一个客户,精通一个客户,成功一个客户。

  对于软件公司来说,功能的最终实现者还是落在了开发人员身上。开发人员有时候冒的风险,往往会延伸扩大到项目经理,测试,市场经理,产品发布出去之后,又在运行过程中可能给客户领导(比如项目的负责人、推进者)带来继续的压力,反作用回来,又给公司项目经理,市场人员带来负担。因此,从成本、风险的角度来说,项目技术选型,慎之又慎。

  同时,这几年,眼前“晃点”开发人员不少,但,大多感觉还没有上路。知道很多概念,有些新玩意,也能玩出个Demo,但,面试时,问问“你最得意的项目是哪个?”,就发现东扯西谈;而一起的同事,发现也有不少,整个项目粘合的参差不齐,随着项目的进行,碰到问题时着眼于当前问题,没有形成自己的“最佳实践”,对很多实现方案在选择上,没有自己的思考,项目做到后期,甚至有点像在“胡”,典型表现就是在编码上都没有统一的风格规范了。我的判断是,基础还不够扎实,对于技术,自我思考还不够。何以有如此判断?因为我个人也感觉自己几年前也是这个状态。这两年,反思多了,对以前的项目中技术的选择和运用的成败的反思,慢慢开始提炼了。但,终归,是需要开发人员在自己的实践过程中,要有追求精品的意识,每个项目都要做透,而不是在量上做多少。这种透,不仅仅是技术上的透,还要关注技术和产品的结合,如何是最终效果形成的是一个完整的整体,是一个晶莹剔透的水晶。只有这种经历多了,手下的代码和头脑中对产品的思考才能很好的实现一致。当一个开发人员像产品经理一样思考的时候,也就是自己找到这个结合点的时候。

  
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: