想要做好一个项目管理应以需求为核心

摘自PM圈子网—PM牛人聚集地

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。

以软件项目为例，经总结分析后，一般失败的原因主要有以下三点：一是需求的不断变化。二是开发的软件不能满足用户的需求。三是软件项目的管理问题，这包括两个方面：一方面是因为缺乏完善的管理项目风险的方法;另一方面是由于软件项目规模的庞大，项目的范围难以精确确定，从而在项目开发的过程中范围不断变更，过程控制的力度不够，因此导致成本估计难以精确，进度控制困难，可靠性无法保证。

如何做好项目需求，以保证项目范围的有效管理及控制呢？

1：六要素：时间、成本、质量、组织、范围、客户满意度。需求最显著的特点是“随着项目而改变、随着项目而渐进明晰”，项目管理的特点是随着进展而渐进明细化，可以看出需求管理和项目管理一样，这就意味着需求在项目的整个生命周期都可能存在的，这样项目管理的工程，也必不可少需求的管理。

2：获取需求

3：需求分析

　　1)建立需求关联图：需求关联图是用于定义系统与系统外部实体间的界限和接口的简单模型，同时它也明确了通过接口的信息流和物质流，通过关联图，对用户需求的约定和确认以及CCB的评审都是非常关键的。

2)创建开发原型：创建用户接口原型可以在如下应用如下情况：如果开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。通过开发原形，业主和集成商都可以相互了解业务，发掘潜在的信息，避免用户需求的不必要变更。3)分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍，这个主要用于内部评审和制定技术线路提供依据，如在什么情况下采用.NET技术,什么情况下采用J2EE技术,我们在2003年电子政务网上审批系统中充分对需求(业务、技术、用户操作人员需求、现有系统需求等)做整体提取分析来确定技术线路的选型。

4)确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

5)为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

6)编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

　　4：需求说明书

　　目前需求说明书有固定的格式和要求,可以从专门介绍需求说明书的相关书籍中获得,在本论文中,我着重阐述需求说明书的经验，编写优秀的是没有公式化的方法的，这需要大量的经验，要从你在过去的文档中发现的问题学习。

1) 采用IT项目需求规格说明模版,要注意的是很多人拿来需求说明书模板就套用,这就有很大的风险,例如:会出现需求不全、需求范围界定不到位、需求分类不明确等因素，我们应该把需求规格说明书拿来后先罗列许多要点：约定、法律法规、需求分类、技术限制、采用的技术和工具等等全面考虑，与项目干系人特别是用户进行沟通，然后讨论，可以采用头脑风暴法和德尔菲方法来讨论，确定说明书大纲，而不能照本著书。

2) 附加文档的管理，值得注意的是需求说明书并非一成不变的，我们可以通过附加文档来跟踪用户的新的需求和需求变更，这样必须建立一个配套的文档集合，随时跟踪需求，保证开发团体步进统一，一般这些文件是要考虑的：《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。这样做的好处是对需求时实监控，保证项目的安排，同时让用户知道变更是一件很严肃的事情，可以防止个别人提出无法界定的需求(因为现实IT项目中，很多问题是其他系统的遗留而又超出本项目技术线路可以弥补的问题等)。3) 编写需求说明书的时候，可能还会遇到一些解决不了的需求，我们也一定用专门的章节要罗列出来，防止漏项，同时也利于我们在做实施计划的时候来采取那种措施，采购其他设备、投入相关人力或其他办法。

4) 需求必须要客户确认，许多项目，可能开发商为了保护自己的“利益”很多事情都没有得到客户的确认，其实在需求阶段，我们的需求是要跟客户确认的，比如数据字典、界面选型、技术线路、功能模块等，这样做的好处是防止需求把握不得当，缺少了用户必要的功能，另一个就是防止了开发商需求镀金，提供了不必要的功能。