项目需求开发与管理.pdfVIP

项目需求开发与管理 随着对项目管理理解的深入，自己对项目管理的两点有了深刻理解：需求开发与管理、项目组织结构。 一、需求开发与管理 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地 说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了 需求，那是自欺欺人。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污 染了，那么整条河流也就被污染了。 我们经常看到的是：人们并不清楚究竟该做什么，但却一直忙碌不停地 开发。 需求开发与管理面临最普遍的问题是：用户说不清楚需求。 有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。例如，早期的政府信 息化项目用户通常只有一个朦胧的信息化感觉而已，需求分析中会这样写：总之，要实现那种能够想到就能 做到功能。。如果开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消 费”。 有些用户虽然心里明白想要什么，但却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚，但很难用语 言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。一些企业的信息化项目，每个子 部门对自身的需要很清楚，但不知道如何从系统角度来要求。 因此，我们可以说项目开发最困难的部分也就是准确说明开发什么。最困难的概念性工作是编写出详细的需 求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害， 并且以后对它修改也极为困难。为此，需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发 工作，否则会连累整个开发团队的。 业内来看，一个成熟、成功的项目，通常它在前期需求、系统设计投入的工作量比例会大于 30%。 1、需求开发 与分析 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。根据需求调查和需求分析的结果，进一 步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》 开展系统设计工作。 一个良好的需求说明书，应该有如下特征： 1.1 正确 需求规格说明书应当正确地反映用户的真实意图，开发者和用户自己都不明白用户究竟“想要什么”和“不 要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。 1.2 清楚 清楚的需求让人易读易懂，包括文档的结构、段落等是否清晰。 1.3 无二义性 “无二义性” 是指每个需求只有唯一的含义。 1.4 一致 “一致”（Consistent）是指各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 1.5 必要 开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应 当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。 1.6 完备 “完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求，比如是否覆盖了所有的功 能、性能、交叉、安全等需求。 1.7 可实现 《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。 “可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。 1.8 可验证 《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验 证的，那么用户就无法验收软件，可能会发生商业纠纷。 1.9 确定优先级 需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和 开发方共同确定需求的优先级。 1.10 阐述“做什么”而不是“怎么做” 开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。他们经常在整理需求的时候 习惯性将如何实现的信息涵盖在需求中，导致需求可读性、可验证性无法保证。 2、需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制 需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达