10.0 瀑布与周期性项目管理 (第 3 部分) • 项目生命周期与结果

在整个项目的生命周期中,用户应该能够测试所有中间结果。 #

在整个定义和设计阶段,请客户尽可能精确地定义其需求。 这是具有挑战性的,原因有二。 首先,消费者对信息技术的潜力和不可能性了解有限。 他们不知道什么是可行的,什么应该是可行的,也不知道他们应该或不应该渴望什么。 其次,消费者往往对自己的商业流程缺乏透彻的了解。

许多 IT 举措包括组织当前业务流程的计算机化。 尽管消费者长期使用流程,但他们往往缺乏设计自己的业务流程的能力。 它们可能以自己的方式运作良好,但无法具体说明这种方式是什么。 在开发能够推动计算机化的软件之前,需要精确的流程定义。 由于必须解释当前的程序,客户的复杂性会上升。

确定标准 #

定义阶段产生的标准列表通常不完整。 程序员在实施阶段根据此部分列表创建软件。 当消费者遇到新软件的 β 版本时,额外的需求变得显而易见。 “它看起来不错,但你也许可以修复它,所以我不必不断输入我的密码? 程序员经常哀叹客户不确定自己想要什么。 客户断言,作为专家,软件开发人员应该在流程的早期确定客户想要什么。

为软件项目创建了一个全面的功能设计,其中包括对基于 Web 的服务的应用程序进行自动处理。 汇编了大量客户需求。 在添加了一些屏幕设计和流程图纸后,程序员就可以开始了。

管理客户和约束 #

可能是由于项目的时间限制,也可能是由于客户组织相当混乱,设计者忘记了由一个关键组成部分组成:人工管理。 该方案处理了申请。 由于申请要自动处理,程序员认为没有必要进行人工管理。 这一标准同样从功能设计中省略。

当程序被提供测试时,客户发现许多应用程序都有例外。 这些应用程序不能自动处理,必须手动处理。 然而,该方案完全自动运作。

瀑布项目管理要求在实施阶段结束时测试项目的实际结果。 这是一 个发展后期。 在定义阶段、设计阶段和实施阶段之间,可能会经过几个月甚至一年以上。 如果在项目的后期阶段发现设计缺陷,在不完全启动新项目的情况下修改方案可能代价高昂(如果不是不可能的话)。 鉴于几乎不可能事先确定所有标准,因此有必要采用一种工作方法,对(中间)结果进行测试。

分析需求 #

在比较一些潜在的软件公司时,客户询问了可能性。 一方犹豫不决,对客户的许多要求的可行性提出质疑。 对方由一名咄咄逼人的销售代理代理代表。

当客户询问具体请求的可行性时,销售人员呼叫了他的编码员。 “我们能否创建一个功能,使 X? 程序员主要从技术角度思考,他说从理论上讲,任何事情都是可以想象的。 程序员和销售人员都不关心 项目管理 的可行性(例如时间、资金、复杂性和风险)。

销售代表的兴奋表现优于对方克制的举止。 客户选择了销售代表的激进报价。 新收购的项目随后移交给了项目经理和一组程序员。

一段时间后,很明显,该项目没有达到客户的期望。 部分原因是,对于客户来说,这些程序比最初看起来要复杂得多。 在双方的激烈交流中,客户表示,销售人员”曾表示功能 X 不成问题。