Profiel van dan学习的空间Foto'sWeblogLijsten Extra Help

Weblog


    11 augustus

    需求分析为何困难!

    有几种原因使需求分析变得困难:(1)客户说不清楚需求;(2)需求自身经常变动;(3)分析人员或客户理解有误。

    4.3.1 客户说不清楚需求
    有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设,这些单位的领导和办公人员大多不清楚计算机网络有什么用,反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观,以致产生很多贪污腐败现象。
    有些客户心里非常清楚想要什么,但却说不明白。读者可能很不以为然。就举日常生活的事例吧,比如说买鞋子。我们非常了解自已的脚,但没法说清楚脚的大小和形状。只能拿鞋子去试,试穿时感觉到舒服才会买鞋(居然也有神通广大的售货员,看一眼客户的手,就知道应该穿什么样的鞋)。
    如果客户本身就懂软件开发,能把需求说得清清楚楚,这样的需求分析将会非常轻松、愉快。如果客户全不懂软件,但信任软件开发方,这事也好办。分析人员可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户,他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸,那么沟通和协商都会很困难。

    4.3.2 需求自身经常变动
    唐僧曾说:“妖要是有了仁慈之心,就不再是妖,是人妖。”(《大话西游之大圣娶亲》)
    连妖都会变心,别说人了。所以喜新厌旧乃人之常情,世界也因此变得多姿多彩。
    软件的需求会变化吗?
    答:据历史记载,没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]
    让我们先接受“需求会变动”这个事实吧,免得在需求变动时惊慌失措。明白“需求会变动”这个道理后,在进行需求分析时就要留点神:
    (1)尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上,否则将会吃尽苦头。
    (2)在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊,日后扯皮的事情就多。要防止象韩复渠那样,在别人请他喝酒吃饭时他什么都点头(人家就更加献殷勤),吃完了他就宣布刚才答应的事都不算数,便扬长而去。

    4.3.3 分析人员或客户理解有误
    有个外星人间谍潜伏到地球刺探情报,它给上司写了一份报告:“主宰地球的是车。它们喝汽油,靠四个轮子滚动前进。嗓门极大,在夜里双眼能射出强光。……有趣的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全控制了车。”
    软件系统分析人员不可能都是全才。客户表达的需求,不同的分析人员可能有不同的理解。如果分析人员理解错了,可能会导致开发人员白干活,吃力不讨好。我读中学时候最怕写作文逃题,如果逃题了,不管作文写得多长,总是零分。所以分析人员写好需求说明书后,要请客户方的各个代表验证。如果问题很复杂,双方都不太明白,就有必要请开发人员快速构造软件的原型,双方再次论证需求说明书是否正确。
    由于客户大多不懂软件,他们可能觉得软件是万能的,会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。
    有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处,客户听得津津有味。最后,心动的客户对软件人员说:“好得很,就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上,我立即派人去做。”
    为什么软件系统分析员的工资要比普通程序员高?就是因为需求分析困难嘛。

    01 augustus

    [引]信息化建设的项目管理

    序言
    目前,电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明,这类信息化建设项目在国内外成功的比例都不是很高。正因如此,
    项目管理引起这个行业人士的普遍关注。同样,也有数据表明,西方国家的一些企业采用项目管理后,项目成功的比例有显著提高。
    作者根据十多年项目管理实践经验,以及研究、培训和咨询的知识积累写就这篇文章,相信对信息化工程项目的建设者会有帮助。
    本文涉及信息化建设项目管理的内容包括:项目经过的阶段;项目的计划、实施和控制;开发商对项目的管理;用户对项目的管理;项目的组织问题等。
    一、信息化建设的几个阶段
    信息化建设项目按时序划分,一般经过可行性研究、系统分析、系统设计、
    开发和测试、安装调试、运行维护6个阶段。
    1、可行性研究阶段
    可行性研究阶段段的主要任务是:识别需求,对项目产品进行描述,确定分阶段实施的进度,从业务、技术、经济效益等方面进行可行性研究,形成可行性报告。
    2、系统分析阶段
    系统分析阶段的任务是:对现行系统进行详细调查,分析业务流程,分析数据与数据流程,分析功能与数据之间的关系。指出现行系统存在的问题和不足之处,确立新系统的基本目标和逻辑功能要求,最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统“做什么”的问题。因此,这个阶段是整个系统建设的关键阶段。
    系统分析阶段的工作成果为“系统说明书”,这是系统建设的必备文件。系统说明书既要准确又要通俗易懂,用户根据系统说明书可以了解未来系统的功能,判断是不是他们所要求的系统。
    “系统说明书”一经通过,就是系统设计的依据,也是将来评价和验收系统的依据。
    3、系统设计阶段
    系统分析阶段的任务概括地讲,已解决了系统“做什么”的问题,系统设计阶段要回答的问题则是系统“怎么做”。也就是说,根据系统说明书所规定的功能要求,考虑实际情况,具体设计实现逻辑模型的技术方案,即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。
    这个阶段的技术文档为“系统设计说明书”
    4、开发和测试阶段
    开发和测试阶段是按物理设计方案付诸系统实现的具体工作,包括开发与调试程序,采购硬件。
    这个阶段的工作量很大。在这个阶段,开发工作要重视文档的建设,测试工作需要写出测试分析报告,包括功能“测试分析报告”和“系统测试分析报告”。
    5、安装调试阶段
    本阶段的工作包括:硬件设备与软件平台的安装调试,用户培训,数据文件转换,系统调试与转换等。
    安装调试阶段实现现有系统被新系统所替换,需要用户许多部门的参与或配合。为了使系统顺利转换,必须精心安排,合理组织,统筹调度和协调。
    6、运行维护阶段
    系统投入运行后,需要进行经常性维护和评价,记录系统运行的情况,根据一定的程序对系统进行必要的修改,评价系统的工作质量和经济效益。
    上述6个阶段,构成信息化建设项目的全(整个)生命周期。
    根据美国项目管理知识体系指南(PMBOK)的定义:项目生命周期开始于项目启动(例如签订承包合同),结束于项目收尾(例如按合同验收)。因此,信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。


    本文第二部分内容——项目计划、实施和控制,是基于项目生命周期来考虑的。由于项目管理其实是一种方法论,因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。

    二、项目计划、实施和控制
    1、整体计划
    整体计划的核心内容包括:范围计划、时间计划、成本计划和组织计划。
    1)范围计划
    项目范围由工作分解结构(WBS)界定。工作分解是一种以结果为导向的分析方法,用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件,因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为,没有包含在WBS中的工作是不应该做的。
    信息系统建设项目的工作分解结构,第一层通常是由前面所述的项目生命周期的4个阶段组成,第二层则包括每个阶段需要完成的可交付成果,第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果,…。
    工作分解结构层次的多少,以便于管理为划分标准。相同的项目,不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。
    2)时间计划
    时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法,可用来优化时间计划安排。由于有项目管理软件的支持,生成时间计划图表,以及用网络计划技术优化时间安排都变得十分地容易。
    3)成本计划
    ① 制订资源计划
    资源计划确定了为完成项目中各活动所需要的资源(人、设备、材料)。WBS
    是项目资源计划最基本的输入。
    ② 成本估算
    成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素,通过有关算法与工具(项目管理软件或电子表格)算出完成项目所需各种资源的成本估计值。
    ③ 成本预算
    成本预算是为了确定测量项目实际绩效的基准计划,而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。
    ④ 成本基准计划
    成本基准计划是一种按时间分段的预算,可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。
    4)组织计划
    组织计划是,利用责任矩阵确定WBS中各工作项的责任单位;利用组织图确定报告关系。但是,组织计划结果的具体形式受企事业单位的组织结构制约。(关于项目的组织问题,在本文第五部分解析)。
    2、项目实施
    项目实施总是一个阶段接一个阶段地进行的,前一个阶段的结果为下一阶段提供输入。信息化建设项目中,第一阶段的结果“系统说明书”,为第二阶段系统设计提供输入;第二阶段的结果“系统设计说明书”,为第三阶段的开发工作提供输入…。
    每个阶段实施工作也都要首先做个计划,这个计划是为完成WBS工作包而采取的行动计划,包括:基于各项活动的基准进度计划,角色、职责分配计划。类似于前面讲到的组织计划,角色、职责分配也利用了责任矩阵这种方法,只不过在这里是把职责分配到个人。
    项目子产品、产品实际上产生于项目实施过程中。
    3、项目控制
    项目控制包括绩效控制和变更控制
    1)绩效控制
    绩效控制目的是使工作结果与计划保持一致。
    上面讲到,项目子产品、产品产生于项目实施过程,因此在这个过程中必须持续测量相对于项目基准计划的绩效,以便将实际绩效和基准计划进行比较,并以此为基础采取相应的纠正措施。
    测量绩效的方法主要有两种,一是挣值测量,一是进度跟踪。而且,这两种方法通常是结合起来使用。
    ① 挣值测量
    挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量,帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值:
    l 计划值(PV):在规定时间内花费的获得批准的成本预算部分
    l 实际成本(AC):在规定时间内完成工作发生的实际成本
    l 挣值(EV):在规定时间内实际完成工作的价值
    不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状,所以通常称之为S曲线图。
    这三个值提供了评价工作绩效的测量尺度。包括
    l 进度偏差(SV):SV=EV-PV
    l 成本偏差(CV):CV=EV-AC
    l 进度绩效指数(SPI):SPI=EV/PV
    l 成本绩效指数(CPI):CPI=EV/AC
    ② 进度跟踪
    进度跟踪是输入实际工作进度,然后与基准进度计划比较,找出各项活动进
    度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。
    有了绩效测量结果,接着便是对偏差原因进行分析,进而根据分析结果决定纠正措施。纠正措施没有什么新东西,都是平时习以为常的一些方法,比如对进度偏差有赶工、快速跟进(有些书上叫做并行工程)等措施。理论著作上对这些方法的外延问题讲得很多,原因是在采取这些措施时,要考虑可能带来的许多问题,但这些都不是本文所要描述的内容了。
    2)变更控制
    变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。
    基准计划变更包括:范围基准计划变更,时间基准计划变更和成本基准计划变更。一般说来,只有项目范围变更才会影响测量基准。但是,在某些情况下,进度延误或成本偏差非常严重,需要“重新确定基准计划”才能提供
    测量进度或成本执行情况的切合实际的数据。
    基准计划变更是很慎重的事,应该:
    l 建立正式的变更程序
    l 由变更控制领导小组负责批准或否决变更申请
    l 定义正式文档变更的步骤
    前面已经讲了,一般情况下只有范围变更才会影响测量基准。而在信息化建
    设这样的高科技项目中,范围变更往往是因技术(功能、性能)要求的变化而起。项目管理中讲到的配置管理,讲的是项目过程中的技术管理问题。
    配置管理内容包括:
    l 识别工作项或系统的物理特征和功能特征
    l 控制这些特征的任何变更
    l 记录和报告这些变更
    l 审计这些工作项和系统以证实其与需求相一致。
    进行配置管理的目的是,项目过程中任何技术上的变更都要在范围变更中反
    映出来,并要得到有关各方的一致认可。
    三、开发商对项目的管理
    无疑,开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作,开发商都需要重视。
    计划方面
    信息化建设项目往往带有较多的创新成份和不确定性,项目成果在出来之前,并不确切知道它会是什么样子。因此,用户的需求和任务目标在整体计划中都不容易表述得十分具体,特别是对要实现的功能的规定往往有相当程度的灵活余地。
    由于这些原因,整体计划中的工作范围、完成各项工作(由WBS定义)所需的时间和费用都较难以准确估计,所以整体计划工作必定是一个反复修改的过程。实际工作中,人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为,项目管理的首要任务是计划!计划!还是计划!先哲说:“凡事预则立,不预则废”。因此,尽管信息化建设项目中存在诸多变数,但细致的整体计划工作是必须要做的。

    实施方面
    项目实施过程中,项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口(界面)。对于信息化建设项目,在系统设计与开发、测试阶段,对各种技术接口的管理极为重要。而在系统分析与安装调试阶段,协调组织界面是项目管理队伍的重点工作。
    实施过程中,项目队伍成员必须按计划做事!
    比较我们与西方人做事的习惯不难发现,西方人总是按文档(当然首推计划)规定去做事,而我们做事主观随意性较大。应该学习和接受西方人的做事习惯!
    控制方面
    挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目
    管理者粗放式管理惯了,不习惯于做较精细的管理工作。当然,在信息化建设这类高科技项目的管理工作中,对工作量完成百分比做比较准确的估计(这是使用挣值测量法的前提)有些困难,也是人们不愿使用这种工具的一个原因。但笔者的体会是:对工作量完成情况做个百分比估计,比不做要好;对于类似项目第二次做时,对许多工作完成情况的估计还是有较好的置信度的。
    变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素,这里不一一讨论了。

    四、用户对项目的管理
    在项目生命周期内,用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商,因此对成本的控制不是用户主要考虑的问题(当然,非固定总价合同情况除外)。而对范围、进度、质量等方面的管理是基于同样的标准的,即是说项目所有的技术和管理文档以及任何变更后的版本,都是开发商和用户达成一致意见后形成的。
    在项目生命周期内,用户项目队伍重在参与。在系统分析阶段,没有用户项目队伍的重要参与就不可能产生好的“系统说明书”,也就不可能有好的项目成果。在安装调试阶段,没有用户项目管理队伍的协调、调度,转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段,用户应着眼于未来的运行维护,派技术人员全程参与工作,其必要性有二:一是未来系统运行维护的重要责任,要求技术人员必须深度了解系统的技术情况;一是系统将来必然会不断升级,要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家,不可等同于一般维护人员,也不同于一般网管人员,这点应引起用户的重视。
    有些情况下,用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段,用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的,可能并不很清楚,这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段,从职能上说,项目监理与项目管理是差不多的。
    五、项目的组织问题
    对于信息化建设项目,多数开发商、用户单位的内部组织都是传统型(职能型)的,即组织的结构是按职能划分的。在这种结构体系里,对项目的组织往往是非正式的(用户方面更是如此)。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是,当认为某个项目很重要时,就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中,我们都能看到有这样的说法:信息化很重要,信息化建设工作应该由一把手亲自抓。
    对信息化建设的项目管理工作,由一个领头干活的人负责显然不行,但由一把手亲自抓的观点,也非常值得商榷。
    本文开头提过,信息建设工作是很复杂的事情。“复杂”体现在两个方面:一是把业务流程、规范、标准等搞清楚,并据此确定要建一个什么样的系统很复杂;一是技术实现上复杂。负责信息化建设的项目经理,应有这两方面的知识与经验。从开发商方面看,该项目经理应有很好的技术背景,同时要熟悉所服务行业的业务情况;从用户方面看,这个项目经理应非常清楚本单位的业务流程,同时对技术有一定的掌握。
    一把手是企业战略层面上的管理者,很难要求他管好信息化建设这样具体而复杂的项目。
    保证信息化建设项目的顺利进行,应从组织结构上着手。
    矩阵型组织(参见下图)是西方国家许多企业采用的一种项目组织类型。

    在这种组织结构里,职能部门经理承担职能性职责,项目经理承担项目职责。所谓扁平化管理指的也是这个意思。
    从图中不难看出,项目经理需要在全公司内整合资源来完成项目工作。要做到这点,首先应赋予项目经理必要的权力。高层经理应充分认识到,负责=职责+职权。上图显示出,项目经理和职能经理的权力是平行的。要重视信息化项目建设工作,高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。
    这里应该强调的是,矩阵型组织是一种现代型组织结构,重视这种组织结构
    应用,其意义不仅仅局限在信息化建设过程中,对处在产品或服务转型期的各行业来说,都有重要的现实意义。
    结束语
    本文阐述了信息化建设中的项目管理。然而,在当今信息化社会里各行业都应重视项目管理。时代的变化已越来越快。产品生命周期短了,一种型号的产品推出后,很快就被功能更强、性能更好的产品所取代;对服务的要求更高了,与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项,服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此,我们不仅要在信息化建设中重视项目管理工作,还需要在广泛的社会领域中重视项目管理。

     


     

     
    *