用 Safari 11+、Firefox 70+ 浏览效果最佳
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/22 登录/0

导致软件开发失败的三大“杀手”

阅读数:15.1K
基本

概要


至理名言(就像某人说的):失败并不可怕,可怕的是不知道从失败中吸取教训。

软件开发为什么会失败,又为什么会成功?这无疑是软件工程研究中两个永恒的基本问题。张恂认为:

  • 需求问题
  • 迭代问题(或者说过程/工艺流程问题,比方说误用了风险极大的传统瀑布开发模型)
  • 架构问题
大概依次是现阶段导致国内软件开发项目失败的、排名最靠前的“三大杀手”。不知是否与您的估计相吻合?

软件开发项目为什么会失败?是啊,这个经典问题软件工程界至少已经问了 40 年!市面上也有成千上万个案例可供参考。在通往罗马的大道上,陈列着数也数不清的标本,难道可以对它们视而不见吗?二十一世纪的今天,这个问题的答案又有什么新变化?

软件开发项目为什么会失败?这个问题,张恂差不多问自己也问了十多年,几乎每天都在问、都在想,正可谓十年如一日。失败的原因当然有很多,码起来可能有好几打,但概括起来,可能出奇的简单。

毫无疑问,软件开发中最重要的因素,也就是决定性的因素,是 —— 人(Human),所以要探究软件开发的成功与失败,我们最好多从人的本性,人性(Humanity)的本质、弱点和缺陷上找原因。一言以蔽之,正如这世界上的许多事情一样,软件开发失败的最根本原因是因为软件人(包括开发者、管理者和用户/客户等等在内)的“多自症”:自以为是、自作聪明、自命不凡、自恃过高 ... 造成的。如果归根结蒂,用一句话、四个字概括,那么我的答案是:

自以为是,是导致软件开发项目失败的根本原因

也就是说,我们原本以为它们应该而且能够成功,可是它们却出乎意料地失败了。

“多自症”的一种最直接症状表现是,无视软件开发当中的科学规律,无视前人积累的无数宝贵经验,不讲工程,不讲规范,不讲智慧,总是胸怀着那一股舍我其谁的英雄豪迈气概,披挂着唐吉诃德式的盔甲,拎着一根丈八蛇矛,向着伟大的焦油坑义无反顾地踏马奔去。

以上,是我对导致软件开发失败根本原因的思考。以下,本文列举、分析了这些年来,张恂收集到的若干比较典型的软件开发失败案例,这里只是其中的三篇,后面还将陆续补充。其他相关案例,您还可以参考 案例分析主页

第一篇 来自网友的一封来信,谈到了他所遭遇的 一个失败项目

第二篇 在网上发现 laohan 的 一份软件项目的失败报告 很不错,这样的案例非常小,却很典型。我也很喜欢这篇报告的写作风格,言简意赅,一目了然,没有弄文青年的那么多废话。麻雀虽小,五脏俱全,感谢 laohan 向大家贡献的这只案例!

第三篇 来自 海东的技术资料,他列举了导致软件项目开发失败的 11 个原因,并给出了初步的解决方案。

网上还有一篇 Liu Hang 的《软件产品开发,为什么失败》,也写得很好,很客观,谈到了作者自己亲历的几个项目(物流和教育行业的),建议大家不要错过。两位作者的观点和看法我大多是赞同的。这里我打算把这两篇相关的、探讨软件开发失败的报告或文章合在一起评述,借此表达出一些自己的更深入的观点和看法,与大家一起分享经验所得。

分析


在网上发现海东有几篇博文写的很好,很有意思,所反映的情况在国内的软件开发项目管理中实属非常典型,种种现象背后折射出的其实是一些更深层次的问题。感谢海东允许我转载他的这几篇文章:

在项目开发总的一些感受,希望大家共同来探讨项目管理中的一些看法

项目开发经验谈(一)

项目开发经验谈(二)

针对案例项目中的这些问题,有没有好的解决办法?我想当然是有的,答案应该到现代软件工程方法中去找。

在文章中,作者首先深刻分析了案例项目失败的主要原因,主要有 11 项,而后给出了具体的解决方案建议。一方面,我觉得海东总结得很好,这些失败原因确实非常重要,许多解决措施也是必要的,另一方面,我并不完全赞同文章中的某些观点和结论,而且从总体上看,这些文字并没有完全反映出过去 10 年来软件工程界所取得的重要成果和进展,比如敏捷迭代的开发思想方法,所以我觉得在这里有补充说明和进一步探讨的必要。

看到这些案例分析,我的感受是很复杂的。

该项目失败的 11 大原因有:

1)需求调研阶段做的不够细;
2)对客户现有系统分析和研究重视不够
3)合同签订的问题
4)没有《功能规格说明书》
5)前期项目开发人员投入过少
6)项目管理人员的问题
7)一味追求快速开发赶时间进度
8)没有确定系统边界
9)对前期调研和设计重视不够(包括数据库设计)
10)客户意见不一致
11)用户参与不够

我这个人有删繁就简、追求简化的习惯。在以上原因列表中,原因 1、2、4、8、9(一部分)、10 其实都可以归纳为需求方面的原因。从严重程度上看,原因 4、8、1 和 2 都是致命的。致命的意思是说,这样的项目根本不可能在预定的时间和费用内完成以达到预定的目标,因为你连预定的目标是啥都不清楚麽。可以说这样的项目从一开始就注定了是一个死亡项目、死亡之旅(还记得 Yourdon 大师的 Death March 吗)。

话说回来,这样的软件开发项目有可能成功,起死回生吗?说实话,有的,唯一的办法就是:赌一把,祈求天助神佑(有关如何求得财神爷、灶王爷、土地爷、观音菩萨、元始天尊诸等各方神圣、各路大仙显灵造福的技术已超出了本文讨论范围,请查阅有关文献),还有当然就是靠领导、客户开恩了(上帝啊,拜托、拜托 ...)。

我觉得,这些案例的真正价值,恰恰在于它们的真实性,而且就发生在公元二零零七年!这一事实本身难道不足够震撼吗?

我关心的一个问题是,这种对于软件工程的无知、愚昧的事例是不是孤立的,在我国的软件行业中到底具有多少普遍性?依鄙人之愚见,形势恐怕不容乐观。现阶段,我们既有像中兴、华为这样年营收达天文数字的软件工程、通信工程、电子工程、结构工程、网络工程、传输工程、移动工程 ... 等等系统工程的国际级企业,恐怕也有不少视商业软件开发为儿戏、规范软件工程为粪土的草莽程序员和项目管理者,可见各类软件开发机构之间的软件工程普及、发展和成熟程度的不平衡性、差异是非常显著的。

可能我们真的有必要做一个排行榜,列举一下软件开发项目失败的十大原因。

(待续)
在不久前与网友的一次交流中,谈到了他所了解的一个软件产品开发失败项目,其中有这样的描述:“开发的时候基本是重写,谈不上什么设计,写出来的软件奇差,bug 不断”。这让我很好奇,于是我问他: 我很想知道,你为什么说“奇差”,具体差在那些地方;为什么 Bug 会不断?

他在给我的回信中总结到:

1、我们的软件对界面要求变化比较大,我觉得最低的限度是要做的界面与逻辑分离,但是当时 在开发时候的项目经理并没有意识到这一点。

2、也许是当时对面向对象理解太肤浅的关系,开发人员过于依赖像 Delphi 这样的开发工具,写 代码更像一种'凭直觉'的行为,设计是很肤浅的.我觉得 Delphi 这样的工具做完全的面向对象 开发是有困难的,但是至少可以面向数据表,把数据库表的设计放在一个比较重要的位置,用数 据表和表关系来驱动开发过程,至少会好很多,遗憾的是我们并没有做到。

3、项目经理没能把握项目进度,工作分配也很不合理,因为模块分配不清,所以整合时候遇到了 很大的麻烦(预计整合3天,结果整了几个礼拜,然后再抓虫抓了几个礼拜)。

4、大量使用未检验和不易安装的第三方控件(只是为了界面效果),结果使维护变得非常困难, 控件的选用缺乏一个标准。

5、没有使用任何版本控制和源代码管理,版本过多变得混乱。另外因为需要制作多国语言版本, 由于没有想到好的方法把语言文字独立出去,只好为每种语言维护一个版本,当 bug 发生在一个 版本的时候,不得不去改动所有的版本。

6、软件面向的客户群是对电脑不太理解的用户,所以对于电脑操作应该要尽可能的简单,比如 升级,安装,语言切换等等,但是这些都没有达到实际要求。

案例:一份软件项目的失败报告


(首发于 2005 年 9 月 16 日)

原文:《一份软件项目的失败报告

案例项目是:一个在线考试系统(为方便起见以下简称 OTS 系统)。OTS 项目的一些基本数据:规模为 4 人月,工期设定为一个月;需求为六大功能,即在线考试、用户管理、题库管理、试卷管理、教师批改、分数统计分析等;团队有 4 名开发者,包含一名 Team Leader。

结果怎么样?

很多人看了这个项目会发笑。是的,这个项目太小了,简直不值一提!OTS 成员好像在拿软件开发当儿戏。但是,我分析这个案例的目的也是为了举一反三,大家千万不要小看这只麻雀带给我们的教育意义。

关于 OTS 失败的原因,老汉总结得很好,我再补充几点。

OTS 项目为什么会失败?我的结论:主要是源于对软件工程的无知,而且这种无知达到了滑稽的程度。用 CMM 的话语说,这是一个成熟度很低(同义词:幼稚)的项目。

观察一个项目,我首先会看这个项目采用什么样的开发(生命周期)模型,是瀑布式,还是迭代式。据本人初步估计,70-80% 的软件项目失败都与开发团队采用了错误的/不合适的开发模型/工艺有关,该因素的影响几乎是决定性的。不是说瀑布式一定会失败,而是说它的失败概率和风险很高。当然,这是有科学依据的。尤其是作为一名管理者,如果你竟然连自己负责的项目现在为什么要采用瀑布式(或者那种既非瀑布也非迭代的、不伦不类的过程模型)的理由也不清楚,那么你的团队将会引爆项目地雷是完全可以期待的,这正是英文中所谓 blind-minded 的情况。

那么,OTS 团队采用的是迭代式开发吗?No。整个项目一共才四周,第一周设计,第二、三周编程,第四周测试,这是标准的瀑布模型。我们知道一个迭代相当于一个微型的项目,需要经历需求、设计、编程、测试和发布(内部或外部)等步骤,而 OTS 项目计划完成这些任务的时间正好是四周,等于这一个项目才一个迭代。只有一次迭代、一次发布的项目能叫迭代式开发吗?不能,那叫瀑布!可见,迭代式开发必然要求一个项目至少有两次以上的发布(内部或外部)。

其次,我会观察这个项目是如何处理需求和计划的。在这方面 OTS 的缺陷也是相当严重的。在 OTS 项目里真不知是客户忽悠了开发商,还是开发商忽悠了客户。凭什么双方都认为 OTS 项目可以在一个月之内完成呢?而且还有六大功能。

在任务分配上,有什么问题吗?

OTS 项目唯一的亮点好像就是所采用的架构技术,DAO -> MVC,Hibernate -> Spring -> Struts -> JSP + JSTL + DWR,相当时尚和性感,足以吸住客户的目光。

按道理来说,像 OTS 项目这样的规模、这样的特征,本来是非常有条件采用敏捷迭代式开发的。如果采用敏捷方法,我们将如何做?

(待续)

项目开发的失败原因


来源:海东的技术资料(经作者同意,我对原文作了一些改编。)

项目的成败是变数多多,既有技术的,也有管理的,也有关系的,既有自身的,也有客户的,但是只要我们把我们可以控制的做好了,至少这个项目成功了一半。

项目的需要变化是肯定有的,而且变化一般都很频繁,怎么应对客户的这种需求变化呢,以不变应万变。首先在前期的需求调研要做好,尽可能的替用户考虑,达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认,这样既能保证我们所理解的需求就是客户所要的,也使得项目末期跟客户验收时有据可依。

根据我自己做项目的经验,由于客户一般对计算机不是很了解,和他们交流用我们行业的话,他们根本就不懂,如果用文档也很难把需求写的那么明白,而且文档很多的话,客户都看烦了,很不直观。如果让客户一看就可以看出这个就是他们想要的,我个人认为最好的方式就是做系统原形。系统原形应该在需求分析的时候开发人员在分析师的指导下完成真实环境中的开发,当然开发只是界面的功能模拟,没有底层代码的实现。这样做的目的有三个好处,一是客户很直观的看到他们的系统是什么样子的以及怎么操作,二是这些开发的成果是可以二次利用的,三是可以更好的激发客户的需求。

在项目中期是发生需求变更是很常见的,这时要做好需求变更管理流程。需求变更表,小的变更自己掌握,客户要求的变更有开发人员和设计人员共同商讨后提交项目经理,项目经理预估变更损耗工程时间,在一定阶段一起提交给客户,大的变更直接提交客户,并且要把需求变更对项目产生的影响让客户知道,把球尽可能的踢给客户,让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级,关键部分不能改动的做特别确认(如系统架构等,如果改变等于从头再来)。同时完成客户签字确认,当然如果能将这部分写成合同细节中去是最好,但国内的合同好像都是在打单时是基本上都承诺,也不会到细节,在合同签订后启动后才发现问题。但合同中可以写明如果需求变更什么级别的怎么样,多少钱等;签订合同也是一个很高的技巧,建议把系统的边界及功能范围和解决方案与合同一起签署,这样客户提出的新功能就可以暂且搁置。当然这就需要项目经理很高的经验和技巧了,不是光通过学习就能掌握的。

下面结合一个我所了解的具体软件开发项目失败案例,分析一下该项目失败的几大原因:

一、需求调研阶段做的不够细。调研的时候几乎是一个单位半天的时间,收集一些报表,根本就没有了解用户的需求。

二、对客户现有系统分析和研究重视不够。开发的系统是客户已有的系统,他们已经用了多年,在使用的过程中他们已形成了自己的习惯。而且他们的老系统也有他存在的优点,也是在使用的过程中逐步完善的,可是开发商在开发过程中完全忽略了老系统的存在。

三、签订合同也是非常重要的。具体内容我在上面已说过了。

四、没有《功能规格说明书》。这个是该项目中最大的失误,致使后来客户的改动让开发商很被动。《功能规格说明书》反映了客户提出的所有需求功能,开发人员也是按照《功能规格说明书》来开发的。后期客户的变化都可以和《功能规格说明书》对比,具体怎么变更按照变更流程来做。

经验教训:《功能规格说明书》作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。并且注意以下几点:完整性、正确性、可行性、必要性、划分优先级、无二义性、 可验证性、一致性、可修改性和可跟踪性。

五、前期项目开发人员投入过少。项目周期越长,对开发商越是不利。主要有以下几点:

1、时间越长,客户的需求越多,变化也越多,风险就越大。

2、在长周期中往往会有政局的变动,例如客户领导的变动等。

3、项目周期太长容易造成人员流动的扩大以及工作效率的降低。

经验教训:前期多投入人力,尽早完工,降低我方的风险。

六、项目管理人员是项目成败的关键人员。企业对这个职位的人员的综合素质要求非常高。为什么这么说呢,首先从项目经理所做的工作说起,项目经理要承担项目的前期调研、需求分析、架构设计、质量的保证、计划的安排执行和跟踪、掌握行业知识、人员的管理、技术支持、风险的预测以及数据库的设计等等工作。而在大型软件公司中这些工作至少是有 3 年以上本专业经验的 2 人来做,一个项目经理和一个软件架构设计师。一个项目在前期的这些工作就是一个错误的话,后面有再强大的开发团队也是白搭。开发商还是一个年轻的团队,很需要这样的人才,需要公司来培养,如果遇到项目,再招人员来担当这样的工作,风险是可想而知的。而且这样的人员肯定是从项目实战中成长起来的,不是有非软件项目管理经验的人员或者市场人员转过来就可以做好的,更不是从书本或者参加某些培训就可以学到的。

七、一味的追求快速开发,赶时间进度。软件公司好多都是想把项目尽快做完,但是我知道用友不是的。做项目和孕妇怀孕一样,没有捷径可以走的,必须一步一个脚印走。公司往往为了赶进度,省略了某些工作,最终结果是后面付出几倍省了那些时间的代价去弥补,更严重的是前期的工作白做了,用个成语形容就是“投鼠忌器”。

项目中有个不变的金三角法则,即时间、功能和资源。他们永远是相互联系和相斥的。怎么去平衡他们,需要我们根据实际项目的情况去分析解决。作为开发人员也不愿意在一个项目中有过多的时间,他们也想早点结束项目。开发人员在一个项目中的时间太长,他们会变得非常的烦躁,工作效率也会降低,最严重的风险是他们选择走人来解脱自己。

那么怎么解决这个问题呢?我个人的意见是,用开发商实际能力按照一个正常的进度去做,如果一个项目在功能、时间和资源一定的情况下,需要 10 月才能完成的情况下,如果一定要在 5 个月完成,那和一个孕妇怀孕 5 个月生个孩子的后果是一个样的。

八、没有确定系统的边界。所谓系统边界就是我们做的项目到底要做哪些功能点,以及这些功能点具体要做的什么程度。这些不确定或者和用户不说清楚,以后我们就是有永远做不完的工作,用户会不断的提出新的需求和新的功能,开发商已经无法控制。

九、对前期的调研和设计重视还是不够,包括数据库等的设计。开发商总是害怕客户提出需求,总是不敢去更深的去挖掘客户的需求,害怕工作量增大,后果是在开发好后,给客户一看说:“这不是我们需要的,我们想要的是这样的”。在代码和数据库设计中时间投入很少,这些工作本来就是比较抽象的,需要不断的研究和推敲才能设计好的,但是开发商为了时间进度,很快就出来了,后果是客户的一些小的需求变动,由于设计不好,导致前期的工作白作了。

十、客户意见的一致性。在调研的时候过分相信领导,项目真正的使用者不是领导,而且广大的员工,领导只是看数据的。调研对象主要是最终用户,尤其是在大型项目中,可以说是领导很多,各有各的想法和意见,到底他们谁的是对于错呢,其实这个根本没有对于错。而开发商吃亏的一点就是他们的这些领导提出意见的时候都不在一起,他们也没有开会研究过,谁提意见就按照谁的改,后果是开发商的重复工作不知道做的多少。这个就是在开发商内部也发生。

解决方案:在调研和需求改动修改一定要和客户确认好,等他们内部意见一致才能改动,包括开发商内部也是一样。调研也要指导调研的真正对象,不能太相信客户的领导。

十一、用户参与。在项目的开始和结束用户是需要一直参与进来的,每做个可以运行的功能等就需要和用户交流,这样可以避免很多风险也可以尽早发现需求的误解的等等。

项目开发经验谈一


来源:海东的技术资料(经作者同意,我对原文作了一些改编。)

1 项目过程

1.1 签订合同

项目的合同内主要写的很模糊,范围可大可小,致使在后期的工作中项目越做越大,但是项目费用是不变的。在国内的合同好像都是在打单时是基本上都承诺,也不会到细节,在合同签订后启动后才发现问题。但合同中可以写明如果需求变更什么级别的怎么样,多少钱等;签订合同也是一个很高的技巧,建议把系统的边界及功能范围和解决方案与合同一起签署,这样客户提出的新功能就可以暂且搁置。

1.2 团队建设

在立项后尽早确定该项目的负责人及项目经理,这个人员非常关键,需要很强的综合能力,尤其的人格魅力方面。尽最大的努力将客户的人员加入到项目团队中来,这个人也是将来和客户联系的统一联系人,客户指定一个人和项目组进行沟通,不能是张领导、王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了,所以,项目的最初就要定好规矩,项目组只认一个的意见,有什么要求你们内部先统一再和项目组谈,我们不想卷入客户内部业务部门之间的矛盾和政治斗争之中。

很多项目经理都没有自己选择组员的权利,那么,就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同,相差较大,很难有什么具体要求,但是,一定要有精通客户业务的人,很多小项目里,这个人就是项目经理本人,大项目里会配备行业专家(Industry expert),这样和客户沟通起来才不会鸡同鸭讲,双方才可以相互理解。项目经理需要了解每个组员的情况,用就要用每个员工的特长。软件行业是个非常特殊的行业,从项目的管理以及人员的管理都有它的特殊性。

作为项目经理,其实脑子里就是几样东西:做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想,这四个方面都是相互矛盾的,属于典型的又要马儿跑,又要马儿不吃草的类型。考虑问题的轻重缓急方面,往往是把快放在第一位,各方领导都会给你最后期限,所以保进度是第一位的;省是第二位的,企业的根本目的是盈利,如果收入不能增加的话,至少费用要控制住;好是第三位的,没办法,谁都想精益求精,但是,没有强大的资源保障,质量只好先牺牲了;最后是多,客户的要求源源不断,如何降低客户的期望值,让他们从理想回到现实也是项目经理的分内工作。

1.3 需求调研

在需求调研分析阶段,项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题以及调研工作做的不够细,客户参与程度都不高,客户方相关责任人不明确或对范围和需求责任心不强,提出的需求具有随意性,项目前期对需求的确认不够积极;多个用户代表各说各话、昨是今非但同时又希望软件尽早交付;主要注重领导的需求,基本上都是领导说什么就是什么,致使开发出来的功能在实际使用中不是真正的使用人所需要的,项目后期需求变化随意,造成项目范围的蔓延,进度的拖延,成本的扩大。

需求调研很关键,很多公司只是概念上认为该阶段重要,需要投入的时间长,但是实际上很多公司做不到这个,总想很快进入编码阶段。而且为了赶进度总想省做某些工作,少写某些文档,使得无法拿出客户需求以及后来功能变化和原先功能之间的对比度。

造成上述现象的原因是没有全面了解所有项目干系人的需求以及对需求调研的重视程度不够。软件开发是没有捷径可以走的,省掉的工作后面会有更高的代价回报。全面的需求来自所有项目干系人,不同的干系人其愿望和追求的目标往往相差甚远,因此对项目干系人的愿望进行平衡可能是相当困难的事情。

软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响,使其尽可能地参与项目,则可能因为项目开始时项目范围和一些具体需求不够完整清晰,也可能因为某个项目干系人后期因为认识的变化而提出新的需求,造成工期的延长,成本的增加,甚至项目的完全失败。因此,应当从项目的启动开始,需求分析员及其项目成员就要分清项目干系人包含哪些人和组织,通过沟通协调对他们施加影响,驱动他们对项目的支持,调查并明确他们的需求和愿望,减小其对项目的阻力,以确保项目获得成功。以下是一些有效的措施:

1、尽快熟悉项目干系人全貌

有些项目在做需求调查时,由于受进度要求等客观因素影响,需求分析员与建设单位的技术部门交流较多,向业务管理部门和实际使用者调查不够深入,造成软件试用后不得不再对需求做较大调整,"从头再来"的部分比例很高,大大超过进度要求时间。因此,熟悉项目干系人全貌是进行需求调查的第一步,也是需求调查的基础。在定制开发项目的项目干系人中,最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系,以便在他们之间的需求出现矛盾时能够进行合理的取舍。

熟悉建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析准备了必要的资料, 同时可以熟悉用户方的各类人员,并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨,收集必要的原始资料,保证需求调查的完整性、正确性。

建设单位只是项目干系人中的一部分(当然是主要的部分),为了更好地了解项目干系人全貌,还应当在建设单位组织结构图基础上全体项目干系人结构图,以便更好更全面地进行需求调研分析。

2、详细描述各项业务,以利于让所有客户确认

尽可能全面详细地调查并且描述原有系统(这点非常关键,需要调查清楚原有系统的不足以及优点,以及用户在这些系统中的操作习惯)和用户希望将来系统具有的各项业务的流程,并将这些业务流程文档化后与客户进行讨论,对描述错误或不准确不精确的进行修改,最终让客户进行确认。从个人认为,对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是查增删改传,但具体业务都是分为若干步骤,每个步骤都有其业务名称,同一步骤可能对多个数据集进行不同操作,需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件,使开发出来的软件更受欢迎。当然在进行软件概要设计时,要尽量排除业务流程的制约,即把流程中的各项业务结点工作作为独立的对象,充分考虑他们与其他各种业务对象的接口,在流程之间通过业务对象的相互调用实现其业务流程,这样,在业务流程发生有限的变化时,就能够比较方便地修改系统程序而实现新的需求。

对于各项业务的调查可以通过对以下资料的收集整理分析,这些资料来自各种各样的项目干系人:遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。

3、可视化需求调研,引导各种客户挖掘他们的需求

很多客户因为自己缺乏计算机知识,无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想,不要害怕用户的需求多,不但要确定明确的需求,还要善于用启发的方式与用户探讨隐含的或潜在的需求,并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务,从而能够站在用户的立场看待软件需求,想用户所想,做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求,并且使需求更加全面完善。

对于高层领导,可以提供系统总体框架图;对于业务管理人员,可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员,可以用数据流图、实体关系图或 UML 中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户,画出用户界面图来进行需求挖掘,是个比较有效的沟通方式。

这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任,当然客户自己对界面有特别提出要求的除外。但是,如果把它提前到需求调研时(紧接着原有系统调研分析和系统模型完成之后)与客户进行讨论,则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念,或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。

从我们的项目先做界面和用户交流的经验看(系统原形应该在需求分析的时候开发人员在分析师的指导下完成真实环境中的开发,当然开发只是界面的功能模拟,没有底层代码的实现),画出用户界面草图与客户进行讨论,可以大大激发他们提供更为准确全面的需求,而且这些界面在后期的开发中也可以利用。原来收集资料,描述业务,说明系统模型到了山穷水尽的时候,这种方法可以达到柳暗花明又一村的效果。因此,所谓需求就是“当你按下各种相关按钮(或输入各种相关命令)时系统做什么”,所谓设计就是“当你按下各种相关按钮(或输入各种相关命令)时系统怎么做”。需求的最终目的实际上是完整准确地描述系统需要的各种接口或“界面”,及它们的相互关系或与外部环境的关系,如界面中的某个按钮按下去时,可能产生新的界面、新的按钮、或者调用其他软件硬件完成某些功能。自顶向下,把这些界面及涉及到的数据描述清楚,就是一份不错的需求。

4、与其他项目小组成员共同协作、持续完善系统需求

需求文档完成之后,并不是万事大吉,把它扔给后面的设计人员就了事了。作为项目干系人之内的项目组其他成员,对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分,但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目,上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受,其有效性、合理性也要被下一阶段的工作所检验,通过检验有时也有必要对上一阶段的工作结果进行相应的调整,需求更是如此。因此,无论是同一阶段不同人员之间,或是不同阶段人员之间都应根据需要相互协作,相互配合,共同完成软件开发任务。

5、《功能规格说明书》,这个是项目中最大的失误,致使后来客户的改动让开发商很被动。《功能规格说明书》反映了客户提出的所有需求功能,开发商也是按照《功能规格说明书》来开发的。后期客户的变化都可以和《功能规格说明书》对比,具体怎么变更按照变更流程来做。《功能规格说明书》作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。

并且注意以下几点:

(1) 完整性

每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息,用“待确定” 作为标准标识来标明这项缺漏。在开始开发之前,必须解决需求中所有的“待确定”项。

(2) 正确性

每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源,如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性,这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法:“那些毫无意义,这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

(3) 可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求,最好在获取需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作,由他负责检查技术可行性。

(4) 必要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如使用实例或别的来源。

(5) 划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要,那么项目管理者在开发或节省预算或调度中就丧失控制。

(6) 无二义性

对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查,编写测试用例,开发原型以及设计特定的方案脚本。

(7) 可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法,如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证,则确定其实施是否正确就成为主观臆断,而非客观分析了。一份前后矛盾,不可行或有二义性的需求也是不可验证的。

(8) 一致性

一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究,才能知道某一项需求是否确实正确。

(9) 可修改性

在必要时或为维护每一需求变更历史记录时,应该修订文档。这就要求每项需求要独立标出,并与别的需求区别开来,从而无二义性。每项需求只应在文档中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

(10) 可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好的方式编写并单独标明,而不是大段大段的叙述。

项目开发经验谈二


来源:海东的技术资料(经作者同意,我对原文作了一些改编。)

1.1 需求变化

项目的需要变化是肯定有的,而且变化一般都很频繁,我们怎么应对客户的这种需求变化呢,以不变应万变。首先在前期的需求调研要做好,尽可能的替用户考虑,达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认,这样既能保证我们所理解的需求就是客户所要的,也使得项目末期跟客户验收时有据可依。在项目中期是发生需求变更是很常见的,这时要做好需求变更管理流程。需求变更表,小的变更自己掌握,客户要求的变更有开发人员和设计人员共同商讨后提交项目经理,项目经理预估变更损耗工程时间,在一定阶段一起提交给客户,大的变更直接提交客户,并且要把需求变更对项目产生的影响让客户知道,把球尽可能的踢给客户,让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级,关键部分不能改动的做特别确认(如系统架构等,如果改变等于从头再来)。同时完成客户签字确认,当然如果能将这部分写成合同细节中去是最好。

以下是我认为变更的步骤:

第一步:客户提出变更内容
  • 客户提交的变更必须基于书面形式
  • 客户提交的变更必须有充分理由
  • 如果变更被拒绝,对业务的负面影响
  • 如果变更被接受,对业务的正面帮助

第二步:为能否实现变更作评估
  • 从实现方式上考虑新的变更可否实现
  • 对于较复杂的情形,辅以简单的说明。欲详述,可作附件处理
  • 对于简单情形,例如页面布局更改,则无须说明

第三步:可以实现看进度
  • 进度几乎是绝大部分项目关注的第一要素
  • 对于活动级别的进度影响
  • 对于项目整体工期的影响

第四步:变更成本
  • 人力相关的变更成本
  • 是否需要额外的项目组成员
  • 项目组需要增加的工时数
  • 是否正常工时(工作日加班、节假日加班)
  • 项目工数报价
  • 非人力成本
  • 软硬件费用
  • 资料费用等

第五步:质量和风险
  • 变更对质量的多方面影响
  • 分阶段影响(需求、设计、编码、测试、维护)
  • 可靠性、安全性、可维护性、可用性等
  • 可能对团队士气的负面影响
  • 可能引发的间接任务对工期的负面冲击
  • 开发方的成本负担可能超出力所能及的范围
第六步:需求变化的确定

1.2 架构设计

撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西,需要及时的沟通,包括与客户的反馈,与其他项目组成员的讨论,这样有助于降低开发时偏离需求的风险。也就是说,在开发之前题,是建立在设计者的想法有客户的确认和开发人员的理解的基础之上设计撰写人必须与系统分析员反复讨论,以透彻理解用户需求;

一项需求可能有多种方式实现,设计者必须与系统分析员确定该需求将采用何种方式实现,将达到何种效果,以消除将需求映射为设计的歧义;讨论过程中还可能会发现需求有不完备甚至错误的地方,在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义,列明程序的各种执行条件与期望的运行效果,还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格,使用统一的术语或惯用语,使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。

就个人所知,一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的,他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛,对架构最为熟悉,他们最有资格评价现有架构是否能适应新的用户需求,采用何种方式实现需求对架构的冲击最小。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。

当任务比较集中的时候,设计者可能忙得透不过气,而负责实现的同事反而在等米下锅,比较清闲。于是为了让自己不成为拖累进度的“罪人”,某些设计者就会采用一种快捷方式来交付设计:他们会与系统分析员进行初步的讨论,然后撰写一份粗糙的但仍然叫做详细设计的文档,把它交付给负责实现的同事,再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备,他们不得不花费更多的时间和精力与负责实现的同事沟通;而且他们却很可能忘了把这些交流的成果更新到详细设计中去!(或许是他们太忙,没有足够的时间,又或许是他们认为既然产品已经实现,那么详细设计也就不必维护了。)其结果很可能是当产品开发出来后,才发现它跟用户要求的完全两样!原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来,而这时大家往往有木已成舟的感觉,改动的难度比设计阶段高数倍甚至十倍以上,毕竟任何再牛的人都有自己的局限。

对于以上问题我提出全员设计,全员设计的含义就是把详细设计的工作进行适当地分解,把它们分摊到小组内其它同事身上,让大家都参与设计。这可以说明如下:

当一组用户需求基本确定下来后,程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等,将该组需求分解为一或多项设计任务,并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得详细的用户需求,并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分,理解架构的设计理念,理解产品不同模块之间的协作关系,理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节,只要分析与即将开发的模块相关的内容即可。

一项设计任务,它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责,而业务逻辑组件则由另一位或另一组负责,数据库部分则又由其它同事负责。设计者必须考虑他们的立场,以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义,明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化,设计者并不熟悉相关的内容(比如某位C#程序员并不熟悉如何编写一个存储过程),他可以用描述性的文字说明该部分的设计要求,并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理,以更加确切地表达设计内容,更符合文档的书写惯例。

在设计文档完成后,设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作,不必是A审阅后才能B审阅。可以交叉审阅,即A的设计由B、C审阅,B的设计由A、C审阅等。审阅意见可以用多种方式(如讨论、即时通工具、电子邮件)反馈给设计者,设计者负责汇总这些意见并修正设计。以个人的经验而言,通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见,这时就可以由程序员实现了。

以个人的经验而言,一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿,极有可能是: a)需求尚未明确,各个方面(包括客户、系统分析员或设计者)对需求的看法不统一 b)技术或系统架构存在严重的限制,无法用较方便的方式实现

全员参与设计好处、风险与不适用的团队如下:

1.2.1 全员设计可以带来以下明显的好处

1.有助于平衡工作量,加快开发进度。详细设计的任务分解后,程序主管或核心程序员可以有更多的时间处理其它的事务,比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写,这将极大地提高设计撰写的进度,节约时间。

2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块,他必须从更高的层次考虑和理解设计。

3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通,实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益,有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责,他还要向其它同事的设计提供审阅意见或技术建议,彼此的工作是互相支持和依赖的,这有助于减少“只扫自家门前雪,不管他人瓦上霜”的想法。

1.2.2 推行全员设计的潜在风险

1.在某种意义上,全员设计可能增加交流的成本。两个人之间有一条交流途径,三个人之间最多有三条,四个人之间最多有六条。途径越多,信息量就越大,而这些信息不见得都是有用的信息。详细设计的任务分解后,不可避免地有更多的人参与交流和沟通,大家要花更多的时间来理解他人的想法,也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中,系统分析员反而可能成为另一个瓶颈了。但从总体上来看,在设计阶段花费适当的代价发现更多的问题,比在实现阶段或测试阶段再发现问题,仍然是划算的

2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写,他们考虑问题的角度和思维的方式不可能完全一致,这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则,也需要审阅者们尽可能找到这些不一致的地方。

3.并不是所有的程序员都适合参与设计。很明显,例如刚入职的同事就不适合参与设计,他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计,他们的工作方式可能无法保证及时提交设计文档与参与讨论等。

1.3 沟通

在项目的开发过程中,在团队中的成员之间以及和客户之间是一个不断的交流和沟通的过程。开发过程最好是一个迭代式的开发过程(尤其是国内的项目)。这样可以尽早发现开发出来的功能是不是符合客户的需求,以免开发完了,客户说这个不是我们需要的后果。

1.4 计划执行控制

制定系统得整个计划,任务的划分以及分配工作,跟踪任务的进度,使项目进度在控制范围之内。

1.5 风险管理

风险是随着项目的不同阶段变化的,不同的阶段风险是不同的,必须分析当前面临的风险的数量、影响程度等,以及怎么去解决这些风险。

1.6 测试

测试工作目前在国内的中小公司做的都不太好,但是做项目或者产品必须重视测试工作,把握好质量关。

1.7 验收为目的的思想

在开发过程中,内部管理还要注意的一点是时刻强调以验收为目的的思想,每个任务的最终可交付成果一定要是可以被检查的,比如,【界面要求:美观大方、简洁明快】,这个要求我就不知道如何检查。所以,给开发小组布置任务的时候就要考虑如何检查结果,比如我见过一个计划,里面有一个任务【开发人员熟悉 EJB 编程】,这个任务,除了让这些人去参加一些专业认证考试,否则,结果很难被检查。所以,时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情,我听说有些老项目经理拿到项目是倒排计划的,即首先看如何验收和验收标准,然后决定工作计划。很多项目开始了很久,还不知道如何验收,那么这个项目出问题的可能性就很大了。做项目就是为了验收,我们的角色不是研究机构,我们的目的就是在付出那么多劳动后得到结果

<帮助> <全部评论> 共 0 个主题 0 条评论 (WhyProjectFails)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2020 张恂 版权所有. 沪ICP备15017521号-2