软件开发中低估这些东西太多会影响了报价

软件开发 2019-04-30 12:24199未知admin
软件开发中低估这些东西太多会影响了报价
软件开发工作中有些项目时常被低估,许多开发上问题的根本多源自于这些低估。想要克服开发时的许多问题,就得明白这些项目容易被低估、而且意识到自己可能低估了。该做一些评估修正,才更有机会规避到这些问题。
 
  开发范围设定不够周延
 
  首先是容易被低估的,是软件开发的范围。简单来讲,也就是说,究竟要做多少功能,其实是容易被低估的。
 
  通常,在开发软体之前,会先从主功能发想起,因此,容易以为想像中的关键功能就是占绝大多数的功能,当然也就容易以为完成关键功能,就大概完成了软体。但是,一个完备的软体需要很多配套的措施,有些功能时常在评估时会被忽略,但对软体来说是重要的,像是设定功能、自动更新功能、……
 
  低估了软件开发的范围,就会低估需要投入的工时,进一步就会低估需要的开发时间,当然也就低估了需要的开发成本。
 
  愈是接近需求提出端,就愈容易低估开发的范围。因为,需求提出者不见得自行会做完整的需求分析,他们会把焦点放在自己关注的事情、也就是心中想要的主要功能,但他们时常不会想到软体要运行的全貌。所以当需求提出端和开发团队协商开发时程及开发成本时,便时常因此出现明显的落差,不是觉得开发团队所估算的时程太长、就是开发成本太高。
 
  而且,一旦低估了范围,就容易让开发专案的基础想像和评估产生严重的偏差,但最后开发还是会回归它原先该有的现实,回归到该有的时程,耗去该有的成本。
 需求变更的程度与频率也容易被忽略
 
  除了开发范围容易被低估之外,需求的变更也时常被低估。需求提供者会低估自己在开发过程中变更需求的程度及频率。他们时常会以为自己在开发初期即掌握了绝大多数的需求,设想了绝大多数功能的运作方式。但是,很遗憾地,这件事并不容易办到。随着软件开发步伐的进展,需求提出者和开发团队的讨论、互动日渐密切、日渐增多,甚至随着含有部份功能的软体逐渐可以运作,需求提出者会逐渐对自己想要的软体愈来愈了解。他们时常不能在开发之初,即了解自己需求的全貌,而是透过和开发团队更多的讨论,以及实际可运行的软体,才愈来愈明白需求是什么。这么一来,当一开始设想的需求和之后所意识到的需求有所差异时,就必须透过需求变更来修正。
 
  软件开发,网站设计需求变更的程度及频率时常被低估。不论是需求提出者或是开发团队,都容易有个错觉,即开发之初所提的需求,多半就是所有的需求了,殊不知愈到开发后期,需求变更的情况会时常发生,不见得是巨大的变更,但频率不低。这使得开发团队,需要花上比预期更多的时间来完成软体。
 
  除了需求提供者会低估需求变更的程度及频率之外,开发团队也会低估这两件事。这使得开发时程及成本,也都会因此而低估。
 
  忽视软体测试时程与成本
 
  在开发时程及成本的预估中,还有一项容易被低估,那就是软体测试阶段所占去的时程及成本。许多人在观念上太轻忽测试的重要性,总以为程式写好了,就距离软体完成不远了,只需要略加测试,就可以准备发行了。但事实上,软体测试是最省不了的环节,除非,你能够接受软体以差劲的品质状态来发行。
 
  偏重程式撰写而轻忽测试,是很常见的通病,但是,这也会带来对时程、对成本的严重低估。明明程式就写得差不多了,软体应该也差不多要完成了吧?这多半是许多人心里的共通想法。但事实上,在测试修正的阶段所花的时间,通常不亚于撰写程式的时间,甚至更长。
 
  测试的时间及成本取决于好几个因素,但是,一般来说,大概起码和撰写程式的时间等长,更有人认为可能会到两倍于撰写程式时间之谱。
 
  这么长的测试修正时间,恐怕超乎不少人的想像,但实情的确是如此。看起来程式都有个样子,软体也基本上可以运作了。许多人都会认为即便有些地方会出错,但距离完成应该不远。但偏偏测试及修正十分耗费时间,找到一个臭虫所需要的时间,通常是数倍、数十倍于写下该段程式码的时间。而且,往往需要长时间的侦错,反覆不断地执行验证、重覆产生,才能找到让该臭虫发生的情境,此时也才能予以修正。
 
  测试和修正,在许多人心里可能是很没有生产力的一个阶段,但它绝对是必经的重要阶段。并不是把程式码写好了,开发工作就接近尾声了,测试修正的工作,一样占据着相当长的一段时间,并且没有太多的灵药可以缩短测试时间,因为品质最终还是会自己说话。
 
  低估了测试修正的时间及成本,就会连带低估整体开发的时程及成本,而这一项也正是很多人时常会低估的,而且在观念中很难扭转的。
 
  最后要提的一个时常被低估的项目,是开发工时的单位成本。前面几项容易被低估的项目,它们都是影响到工时,进而影响到整体时程及成本。而最后要提的这一项,则是每个开发工时的单位成本。
 
  做一个软体需要多少钱呢?它除了和总共需要多少工时有关之外,它同时也和每个工时需要花费多少钱有关。
 
  对于一个公司内部自行开发的软体来说,单位工时约略是投入人力的人力支出,也大概是薪资成本加上相关保险及福利的支出,这边的疑义并不大,但对于一个外包专案来说,很常见到单位工时被低估的情况。
 
  当我们将一个开发专案利用外包方式,委由外部的开发团队来开发时,开发的报酬常常是基于工时预估的基准来做报价的。而委外方很容易用内部人员的薪资来做工时的单位成本估算,例如,委外方可能会以自己内部人员的薪资为基础(例如一个月六万元),来做为评估委外时人月工时的单位成本,因为心里通常会想着,「如果我自己养人的话,大概需要付的就是这些钱」。但对承接方而言,不仅要考虑到人员的薪资、相关保险及福利的支出,也要考虑到必须要有利润,而不能只从人员的薪资来计算。
 
  倘若查询一些组织所订定的委外开发人员的报价基准,你会发现会和不少人心中的预期有满大的落差。这是因为这些组织所订定的报价基准是将种种环节,包括最后承接方应该要有的获利都予以纳入,而这才会是一个比较公平、合理的报价方式。
 
  不少委外方之前也扮演过承接方的角色,但是一旦转换成为委外方之外,就容易低估整体的时程以及单位工时的成本。
 
  明明在承接方角色时就知道,其实一个软体的开发需要的工时绝不会太短,而每个单位工时的成本也都不低;但转换成为承接方之后,因为角色、心态的转换,心里想的是自己成本的降低,对于时程低估、对于总工时低估,对于每个工时该有的成本也低估。
 
  在本文中,我列出了几个在软件开发专案中容易被低估的项目,这些项目低估的背后,都有一些既定的观念,唯有意识到容易做出低估,才能提醒自己不要低估,也只有尽可能不要低估,才可以使专案的进行,更符合现实会发生的情况。
                                                                                                                                                                    软件开发,网站设计

网站建设-网站制作-网站设计-武汉众成建站公司 Copyright © 2009-2019 DEDECMS. 武汉建站公司 版权所有 备案号:

联系QQ:326651279 邮箱地址:网站地图