专题：“我的项目为什么总是做不好？——需求篇”
公司活动剪影 – 为杭州诚道科技公司举办需求培训课
===“我的项目为什么总是做不好？——需求篇” ===
2002 年，美国的产品大师 Don NORMAN 被邀请拜访一家有名软件产品公司的主要开发团队，考察这团队主正在开发的现有主要产品。
但是他发现产品的功能虽然很多却不好用，连日常需要都没有满足。
当他把这些产品问题一一列出，并和设计团队讨论时，发现设计团队认为他的这些问题很新鲜有趣。
为什么要到 Norman 来拜访才暴露出产品的这些问题？
现在大陆不少的软件公司，尤其是软件开发，也遇到类似的情况。
我评审过一个为生产线开发自动化系统的开发组，当问他们的产品功能是如何制定出来的？他们的回答是依据同行同类产品定出。当问他们为什么不去生产线去观察和了解需求（它们母公司是生产商），工程师觉得我的提问很奇怪，他们从未想过需要探讨客户是如何使用这些产品。
如果你问一些软件公司管理层：“软件开发的最大困难是什么？”大概 90%（或更高）会说最大的问题是需求常常变。为什么需求这么难把握？因很多时候都缺乏沟通，工程师都是从自己的角度去猜客户要什么，这样很危险。工程师有很多新的概念和思维，但是却不一定是客户需要的。
那么我们软件公司应该用什么方法去获取客户的真正要求？有人会说：
“平常我们已用很多不同的方法– 如问卷调查、市场调查、小组讨论、头脑风暴.......。” 但为什么在验收时还是不少需求变更和返工？表明这些方法不能有效地解决问题。
有更好的方法吗？
其实在国外，已经有很多以客户为中心的开发的方法和技巧，经历十多年的发展，已经非常成熟，如：到客户现场去调查、观察客户如何工作。
观察用户很重要，如要整个观察和访谈有效，我们必须有一系列的准备。一般需求的流程图：

跟所有项目一样，一个需求调研的项目需要有启动和明确的项目目标。确定明确目标后，要制定项目范围：在定义范围时，工程师容易范的错误是：把业务的范围定得较小，会导致最终变成一个简单的流程自动化，最终给客户的价值有限。我们通常强调一个需求人员要从业务分析师的角度来看整个业务流程，从启发的业务事件开始，不仅仅局限在 IT 系统范围。无论用什么需求调研的方法，我们首先要识别谁是关键的利益相关者；然后选定哪些关键对象要用学徒式访谈来挖掘需求，了解现在的流程。