任务:引发项目干系人请求
此任务描述了如何从项目干系人那里引发他们对于希望系统提供的需求的请求。
用途

此任务的目的是:

  • 了解谁是项目的项目干系人。
  • 收集关于系统应该满足什么需求的请求。
  • 划分项目干系人请求的优先级。
关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
主要描述

从现有的来源积极引发和收集项目干系人请求,以获得项目的不同项目干系人(客户、用户、产品推介人)期望或想要系统包含的内容的“希望列表”,以及项目如何考虑每个请求的信息。

步骤
确定需求的来源
目的 确定将在“扩展的项目团队”中充当项目干系人的个人。
确定需求的来源并划分其优先级。 

对于现有的系统,此任务中的第一个输入集将是延期的扩展请求的集合,这些请求已经作为正式的变更请求管理流程的一部分在产品的整个生命周期进行了收集。这将提供一个有价值的起点,从此起点开始可以收集数据并进一步优化项目干系人请求集。

收集了这些初始信息后,请寻找可以代表您的项目干系人的合作伙伴、用户、客户、领域专家和行业分析人员。确定您要与哪些个人合作收集信息,要考虑他们的知识、交流技能、有没有可能与您合作以及他们的“重要性”。 这些个人将充当您的项目的项目干系人 - 实际上是“扩展的项目团队”。 一般情况下,最好有一小组人(2 到 5 个)能够在项目的整个阶段陪在您的身边。而且,扩展团队中的成员越多,就要花越多时间来管理他们并确保您能有效利用他们的时间。 这些人不是全职在这个项目中工作的 - 他们一般在先启和精化阶段参加一次或几次需求收集研讨会,再参加后来的复审会议。

找一个方法,看看其他人是怎么做您想做的事情的。如果您正在开发软件产品,这就意味着收集竞争信息。如果您正在开发新版本的内部信息系统,您就需要安排实地访问,看看人们是怎样使用当前的系统的,并找出可以作出哪些改善。

一个重要的来源是要使用系统的组织的现有说明。这些说明可以是按结果业务建模或业务流程再造生成的业务模型,或者是任何其他形式的业务定义。

收集信息
目的 确定哪些问题需要回答。
收集和记载信息。 

演示图板

演示图板是可用于收集信息的有用技术,它将生成故事板。关于更多信息,请参阅指南:演示图板

面谈

收集信息的一个最有用的方法是与选择的一些关键项目干系人进行面谈。一些可能要用到的问题和方法样本可以在指南:面谈中找到。对于可收集哪些信息来记录项目干系人请求的特定建议,请参阅为工作产品:项目干系人请求提供的信息。

问卷

这是个广泛使用的方法。在开展了数次面谈后,您可能会认识到同样的信息一再重复出现。这类信息可以收集为一组问题,并附带可以从中选择的典型回答,然后发给更多的项目干系人。用这个方法,可以更好地收集为所列问题给出的答案的正式统计值。但是关键是形成问题的方法可以让这些统计值真实地反映您的项目干系人的真正需要。

项目干系人也许能够通过因特网回答问题并将结果发回给您。这样您所涉及的人的范围就比直接面谈大得多,但是对结果的控制却没有直接面谈那么好了。因为您不能当面直接与回答问题的人交流,不能说清问题,也不能澄清误解。 问卷可能是非常强大的工具,但是它们不能代替直接面谈。同时还有这样的假设:有关的问题可能提前就确定了,您的措辞可能会让读者按照您意图的方式理解这些问题。

开展需求研讨会
目的: 让项目团队与项目的项目干系人见面。
从项目的项目干系人那里收集综合的“希望列表”。
根据参加研讨会的项目干系人,划分收集的需求的优先级。 
指南:

评估结果
目的 比较不同需求研讨会的结果。
确保您收集了正确的信息。 

特别是如果您开展了多个需求研讨会,项目团队就最好能养成通览结果的好习惯,并且:

  • 确保每个请求都设定了优先级。
  • 确保有请求的来源(物或人)的信息。
  • 注意并澄清请求间的明显不一致的情况。

需求研讨会的结果需要在复审或后续会议中展示给选择的客户或用户小组。在这个会议中,您将识别是否有什么需要澄清的问题,这接着就意味着您将识别要完成的任务,并将这些任务分配给人员。

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息