观察用户很重要，如要整个观察和访谈有效，我们必须有一系列的准备。

一般需求的流程图：

跟所有项目一样，一个需求调研的项目需要有启动和明确的项目目标。

确定明确目标后，要制定项目范围：

在定义范围时，工程师容易范的错误是：把业务的范围定得较小，会导致最终变成一个简单的流程自动化，最终给客户的价值有限。我们通常强调一个需求人员要从业务分析师的角度来看整个业务流程，从启发的业务事件开始，不仅仅局限在IT系统范围。

无论用什么需求调研的方法，我们首先要识别谁是关键的利益相关者；然后选定哪些关键对象要用学徒式访谈来挖掘需求，了解现在的流程。

总括而言，我们可以用下面典型的两天课程给大家一些概念：（为了简化，下面只列出两天内的主要小组互动练习）

课程是以课程实践为主，通过学习，学员可以初步尝试这些核心技巧。（因培训时间很有限，学员不可能两天之内便学懂。培训中的互动练习只可以让学员开始有些概念– 好比你去超市免费品尝一些促销食品一样。然后学员必须立即把技巧用在试点项目中，从实际项目中学习。）

课程主要目的：让那些偏技术的工程师理解什么是以客户为中心的开发，从一开始的启动、范围和一直到后面的页面原型确认的整个过程中，有哪些具体的方法和技巧可以使用。

[如果读者有兴趣了解更深入，可看我们的一个杭州案例分享。]

常见问题：

Q：我们公司过去一两年用了极限编程和敏捷(XP , Agile , Scrum) ，与你现在说的方法有冲突吗？

A：以上的方法是与敏捷这样快速、迭代的方法互补的。比如敏捷里的发布的策划(Release planning)，或每一次冲刺 / 循环的策划(Iteration planning)。例如：在这个过程中间，如果项目比较大和复杂时，或项目牵涉的业务的重组或更新时，但靠一些需求卡片（User Story Card）不一定可以胜任，极限编程和敏捷也没有很深入的说明怎样挖掘需求。

Q：这些方法能与公司的CMMI改进对应吗？

A：完全可以。以上的方法就是可以帮助公司实现CMMI的需求开发RD下的三个特定目标  (Specific Goals)：

• 挖掘客户需求 (SG1:Develop Customer Requirements) ——可以用学徒式访谈记录系统地体现出来；

• 产品的需求 (SG2:Develop Product Requirements) ——当我们做产品总图和产品场景时，经过分析后的一些需求展现出来；

• 分析与确认需求 (SG3:Analyze and Validate Requirements) –利用KJ分析，利用可视化总图(vision) /场景(Scenario) 与客户的确认、利用原型 (paper prototype) 与客户的确认，都是和这个目标对应。