一、焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。

二、引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。

两者相同点是都由主持人把控，最大的区别是引导式研讨会是跨职能部门的。因为，引入了跨职能部门的干系人参与，研讨会能够比单项会议更早发现问题，更快解决问题。

三、制约因素

对项目或过程的执行有影响的限制性因素。

需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件。例如，客户或执行组织事先确定的预算、强制性日期或进度里程碑。如果项目是根据协议实施的，那么合同条款通常也是制约因素。

四、假设条件

在制定计划时，不需验证即可视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。

在项目规划过程中，项目团队应该经常识别、记录并确认假设条件。

在识别风险的时候要进行假设分析，检验假设条件在项目中的有效性，并识别因其中的不准确、不稳定、不一致或不完整而导致的项目风险。

制约因素和假设条件的区别：

n 制约因素是可观存在，必须遵守，不然会造成麻烦。

n 假设条件是指在制定计划时，不需验证即可视为正确、真实或确定的因素。

n 两者最大的区别是：制约因素是确定的、客观存在的，而假设条件是当前不能确定的。

五、只有团队组建是WBS创造过程的直接结果，即根据WBS定岗定编。

六、关于假设条件：是一些被看做是真实、正确或已经确定的因素、假设条件会带来风险、假设条件需要被不断确认。

七、碰到已经验收即将交付的项目，但是从内行角度看知道某个地方有bug的情况，咋办？

直接正式验收，就没有遵从保护客户最佳利益。最好的方式是与客户讨论这个问题。

八、你从领导层收集需求做出来的东西，结果底层客户经理使用发现不是他们想要的咋办？

提变更：一个变更请求是处理客户实际想要的和管理层认为他们想要的之间的分离的最有效方法。

九、问题日志主要是书面记录并帮助监控谁负责在目标日期内解决某个特定问题的文件，主要是用来记录和监督问题的解决情况。

十、确认范围-输出-验收的可交付成果，符合验收标准的可交付成果应该由客户或发起人正式签字批准。

十一、你刚刚收到客户对项目的正式确认，你下一步应该把接受到的确认文件分发给其他的项目相关方。

十二、工作包延期咋办？在采取具体的行动前，应该首先确认这些延误的工作包是否在关键路径上，而所有具体的进度压缩技术，都是针对关键路径上的关键活动。

十三、范围说明书中包含“制约因素和假设条件”。一旦题目涉及预算灵活和必须交付日期等就是在说制约因素。立马想到范围说明书。

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。

十四、制约因素会限制项目团队的选择，假设条件不会。

十五、在项目分解中我们使用启发式是80小时。不管项目团队成员是多么有经验。为有效管理项目你需要这个层级的报告。

十六、确认范围过程的关键方面是可交付成果验收。

十七、范围管理包括：收集需求、创建工作分解结构、确认范围。

十八、需求跟踪矩阵用于确认范围和控制范围过程，来跟踪需求的实现情况。

十九、收集需求方法中故事版属于原型法。

二十、项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个 范围，包括项目和产品范围;详细描述了项目的可交付成果;还代表项目相关方之间就项目范围所 达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。 项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变 更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的 有效程度。详细的项目范围说明书包括以下内容(可能直接列出或参引其他文件):

1.产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。

2.可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或 服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述 可略可详。

3.验收标准。可交付成果通过验收前必须满足的一系列条件。

4.项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管

理相关方的期望及减少范围蔓延。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目 章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在 项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。

二十一、工作说明书（SOW）

百度文库是这么说的：

工作说明书statement of work是对项目所要提供的产品或服务阐述性的描述。对于内部项目而言，项目发起人或项目投资人基于业务需求，或产品或服务的需求提供工作说明书。对于外部项目而言，工作说明书作为文档的一部分从客户那里得到，如：邀标书、投标的信息、或作为合同的一部分得到。

主要说明功能点或可交付物或使用方法，不用描述的特别详细，通常功能的一两句描述就够了。当然，你也可以整理一个属于自己的SOW，当一个大并复杂的项目，可以通过它可以故意让某方面的专家来参与工作。

 通常在项目计划期间，范围说明之后编写SOW.用来定义将要做的工作，因此它必须在工作被计划或者工作被分解之前写。

  与范围说明书区别如下：

1.SOW是对项目提供可交付成果的说明，是一份概要，在很高层次上说明项目用途、范围和途径，是客户、发起人等关键干系人之间的高层次共识，是项目最初的输入，由项目外的发起人或客户提供；

2.范围说明书由项目团队制定，干系人共同认可；可详细描述可交付成果、及提交这些可交付成果而必须开展的工作。

二十二、WBS不直接作为排列活动排序的输入。

WBS参与制定项目管理计划、定义活动、估算项目成本、确定项目预算、识别项目风险、执行定性风险分析、确认项目范围。

二十三、纠正措施是变更请求，是变更控制的输出。

权变措施是对未识别的风险或问题的一种反应。

二十四、WBS词典提供了所有这些信息--连同里程碑和合同信息--然后交叉引用每个工作包与相关工作包信息。

二十五、范围管理计划提供了有关项目范围变更的详细说明，项目经理可以据此计划来监控项目范围。

二十六、需求跟踪矩阵可以帮助项目经理跟踪和监控每个项目需求的所有特征。它有助于沟通需求的状态和完成状况，并记录每个需求的所有注释或评论。

二十七、范围管理计划可以基于模版。

对于记录，WBS和项目范围变更控制表单也可以。

二十八、名义小组技术 & 头脑风暴

头脑风暴：本技术用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。 头脑风暴由两个部分构成:创意产生和创意分析。制定项目章程时可通过头脑风暴向相关方、 主题专家和团队成员收集数据、解决方案或创意

注意：不包括所识别的创意的排名。

名义小组技术：名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意， 以便进一步开展头脑风暴或优先排序。