我们应当怎样做需求调研：初识

很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。

在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，相互寒暄，介绍与会人员，拉拉家常。逐渐地，会议开始进入了正题。初次接触客户，对于项目团队意义重大。对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。然而，在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。为什么这么说呢？过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。

正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。

人与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。起初的唯唯诺诺，客户说啥就是啥，必然造成客户不再关注你的意见，对你发号施令就可以了。相反，起初展现出一位技术专家的姿态，能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。

同时，这样的会议又是一个项目启动会议。客户方领导要在会议上传达给与会代表一个清晰的信号，那就是与会代表今后要积极配合我们完成今后的工作。这时候，我们要弄清，客户方有哪些角色，谁是这些角色的需求提出者与决策者。这是什么意思呢？在软件项目中，特别是管理型软件项目中，客户都代表的是一个群体，而不是个人。他们代表的可能是一个单位、一个集团，甚至是一系列组织机构。在这样一个群体中，他们按照职能被划分成了不同的角色。拿一个单位来说，横向可能划分成不同的部门，财务部、销售部、采购部、生产部••••••不同的部门，由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。同时，纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，理解这些方面格外重要：

[b]1. 高层领导[/b]
高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，都应当与高层领导谈。他们关系的都是宏观的问题，因此不要与他们谈那些细枝末节；

[b]2. 中层领导[/b]
中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节；

[b]3. 基层人员[/b]
基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。而他们关心的则是每项操作的细节。

划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。另外，如果客户方是一个集团、一个多组织机构的政府机关、事业单位，需求的多元化问题必须引起我们的足够重视。什么是多元化问题呢？比如同样一个业务操作，在同一级别的A单位是这样操作的，而在B单位却是那样操作的。需求的多元化往往会给今后的软件开发带来巨大挑战。因此，我们要在需求调研阶段降低软件的多元化需求。要解决这样的问题，首先应当从高层领导着手，提出规范化管理的口号。同时，在进行需求调研时，尽可能地召集各个单位的代表在一起开会讨论。同时，应当有高层领导，或者指定一个负责人，在出现分歧的时候最终拍板决策。这些都需要在项目启动的时候事先规划好。

最后，与客户方领导制订出软件目标，是相当重要但常常被我们忽视的一个步骤。软件信息化管理不是包治百病的神药。很多项目的失败都归因与项目目标不明确造成的项目范围的失控。因此，这时讨论项目目标，既重要又适时。

也许在此之前我们已经做足了功课，对业务需求进行了一番详细的整理，有了一大堆疑问急需解答。但是，在这时，不是解答具体问题的地方，这是我们常常会犯的一个毛病。在这样一个会议上，我们应当询问客户方领导对这个项目的期望，渴望达到的项目预期，而我们应当描述的，是对达到这些预期的整体解决方案，凡此等等。

俗话说：万事开头难。如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研：初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研：拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研：研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研：需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研：迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研：需求捕获（上）[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研：需求捕获（下）[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析：功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析：业务流程分析（上）[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析：业务流程分析（下）[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析：用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析：查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析：子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析：行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析：业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析：原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析：领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析：非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认：需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认：一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认：快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认：需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认：评审与签字确认会[/url]

（续）