zoukankan      html  css  js  c++  java
  • 论软件项目的垮掉

    一直都想针对于软件项目研发,开发团队说点什么,可是每每拾起键盘又落下,因为愤世嫉俗的话一般都比较难听。

     
    公司不是慈善机构,公司存在的基本前提是盈利,或者至少有希望能够看到未来盈利。一个项目,如果一直都未盈利,而规模又在不断变大,这个团队就会渐渐失去投资人的信任,迟早有天会撤资。 

    软件项目的垮掉,首当其冲的是产品需求的不足性与不确定性,需求分析与产品需求做的是否成功,是产品是否成功的关键性因素,也是研发人员能否把东西做好的基本保障。
    从建设的角度来说,研发软件产品,和建房子异曲同工,先是有需求,再有设计稿,最后才开始动工建设,而某些开发团队,前期的需求与设计稿都还没做好,就草草的开始建设,而且早早的就招了一大批建设人员在等需求做,其后果就是养着一票人等着事情做。
     
    曾经经历过3,4个开发人员同时做一个页面的情形,每个人做该页面的一小块功能。先不说工作如何协作,代码风格如何统一,各人的开发能力是否等同,提交代码是否会冲突,但从中层管理对人员的分工来说,人员多需求少的情况很难处理,不给某个人分配工作,就会导致部分人没事做的情形。而上层管理人却一直觉得下面研发人员效率太低,进度太慢,又不加班,而却没有看到需求的不足性或者需求的不连续性。有时候看到技术人员不怎么加班时,首先应该去检查的是需求是否太少了。
     
    有人会问,为什么会出现这种情况?其根本原因是,前期开发人员过多,需求设计不足,产品设计人员缺少,或者产品设计人员能力有限,需求总是不能持续性的进行迭代,一个版本下来,总会停留一段时间。另一个方面,需求有些时候不能在原有版本上进行升级,而是几乎把原有功能完全推翻,重新做。这样经过几次折腾,开发人员心力交瘁,开发人员很多时候并不是不想努力赶进度,而是对于这种吃力不讨好,重复性的劳动,会觉得很厌烦。一方面感觉白忙活了一通,成就感受挫,另外一方面自己也会觉得没有什么成长与收获。
     
    有人说,需求不就那么几个吗,我要做成像某某产品那样,我要拥有某某产品同样的功能。说这种话的人,往往只会吹牛不干实事的人,如果做产品真有那么简单,IT业创业就不会那么艰难了。其实这里所说的需求,应该是将大需求细分成研发人员可以执行的产品需求,并制定为一个研发里程碑,而不是一个大概的功能,一个最终的结果。以结果为导向来考核研发团队,而不关注实现细节,其实是行不通的。
     
    产品处于探索期,不应该做的太大太全,而是应该选择一两个市场能够接受的点,先做精做完善。任何一个成功的公司,很多时候都是从一个很小的点慢慢做起来的。
     
    软件项目的垮掉,其次体现在员工工作分配的合理性以及对于工作效率质量的真实评估。
    如果一个创业团队处于探索期,在尝试不同的方向,加班很可能是没多大价值的,产品早几天晚几点发布或许真的意义不大,还会把团队成员搞的很疲惫,长此以往会失去信心。很多时候看到的加班是抽疯似的加班,为了加班而加班。
     
    很奇怪有些公司用加班的时间多少来衡量一个人工作的是否努力,却很少关注这个人加班到底在干什么事,工作时间又在干什么事,如果有些人加班只是在装模作样,玩游戏,看视频,刷微博,看新闻,这种人加班不仅不能带动工作气氛,反而会使得那些真正干活的人觉得很反感,虽然不说,但是心里肯定在嘀咕,凭什么我在这干活,你可以在哪里玩。久而久之,各种混时间的加班充斥在整个研发部门,效率可想而知。
     
    加班确实是提高效率的途径之一,但是有些时候为了赶进度,加班加点的做,但是这种东西做出来质量问题也会大打折扣,曾经经历过一个模块,3,5个技术人员连续加班一个月,最后技术主管辞职了,留下了一个漏洞百出的烂摊子,后面的人接手后改了数百个bug,用户觉得不好用也不敢用,大量功能都基本没什么用处,最后整个模块只能作为摆设,当然这里又跟前面提到的产品需求分析有关。

    软件项目的垮掉 ,还体现在人员组成上面。
    很奇怪一些公司怎么会招聘一些能力平平而又没责任感的员工,招一大批这样的人做开发,虽然说能够实现需求,但是这种人写出的代码,往往不够健壮,不会考虑太多扩展性,bug层出不穷,性能问题也经常出现。这种代码后期维护的代价是巨大的,我们都知道软件的成本包括了开发成本与维护成本,而维护成本有时候远远大于开发成本,一个漏洞百出的系统,其维护成本是无可估计的,尤其是当不同的人员来接手的时候,就会越改越乱,越改越难维护,做过开发的人都知道,改别人的代码是很痛苦的事情,还不如自己重写,重写的前提又是时间能否足够的问题。但如果不重构,整个系统就会陷入小心翼翼的运转阶段,一旦业务量剧增,很难保证还能正常运行。
     
    其实好的团队,应该是2个人拿3个人的工资,干4个人的活,这种机制,对于员工,对于公司都是有利的。好的程序员又何止以一敌二,《黑客与画家》中提到,好的程序员有些时候甚至是以一敌十、以一敌百,就如同一百个普通画家也敌不过一个梵高一样。
     
    一个团队,没有事业心的成员,没有责任感的成员,迟早都会被淘汰,至少在组织进行调整时,在只能选择一个留下的情况下,这种人肯定不会被优先考虑。
     
    软件项目的垮掉,最后体现在管理及团队建设上。 
    一个团队,如果激励到位,使得所有人都具有渴望成功的巨大欲望,个个都舍得付出,那这只团队的战斗力一定是同行里面最强的,就算目前做出的产品比不上竞争对手,长此下去,一定会超过所有的竞争对手,成为行业里面的NO1。
    研发人员在看待工作好坏的事情上,有时候并不一定是看只看工资,而更多是在工作量与薪水之间进行权衡,在成长性与薪水之间进行权衡,在自由与不自由之间进行权限,在工作环境之间权限。谁也不能忍受停滞不前的工作,停滞不前的能力,停滞不前的薪资,停滞不前的项目。
    管理人员更应该给员工提供更多成长的空间,使得项目与员工共同成长。
     
    愤世嫉俗的有点过了,待续……
     
     
  • 相关阅读:
    bzoj2959
    学习笔记::lct
    bzoj3203
    bzoj1319
    bzoj3625
    bzoj3992
    bzoj1565
    bzoj3513
    平常练习动归(1.胖男孩)———最长公共子序列
    2016 noip 复赛 day2
  • 原文地址:https://www.cnblogs.com/beceo/p/3475784.html
Copyright © 2011-2022 走看看