关于了解并理解客户需求（一）

停网三天，没办法更新博客。今天开始接着写，说一个小插曲：

停网时打了无数电话要求修理好，每次只得到敷衍，说马上就能好，可结果是停了三天网站还没恢复正常，投诉也没有用。无奈警告他们，我有朋友在电视台当记者，如果今天内再不弄好，你们就等着在电视上曝光，十分钟后，网站恢复正常....

好了，接着更新博文吧....

之前引用了一位在微软做PM的关于项目管理的文章，在项目管理过程好比就像是装修房子，而首步是了解客户需求。

谈到客户需求，我想把通常的项目需求分为三大类：

第一类A：从界面（Interface）到功能（Functionalities)到Non-Functional Requirements甚至软件环境等都界定得十分明确的specs或者RFQ；

第二类B：只有一个大体的功能或者界面描述说明；其中许多细节部分待确认；

第三类C：任何文字都没有，需要乙方与客户交流过程中自己收集提炼需求；

  

下面，我就基于这三大类谈谈自己应对这些不同项目需求采取的一些的办法：

  

对于A类项目，大部分人都喜欢读这样的项目需求文档，因为提供这类项目需求的客户本身对项目的各方面规划已经比较明确，客户需求变动的一般不会太大，最多是一些细节的变动；谈到需求变动这一块，顺便说一下，我和我一些在这个行业工作的朋友深有体会的是，项目需求变动是常有的事。有一些离谱的项目，最后提交的版本和最开始给的需求文档描述的项目相差甚远甚至是两个项目。所以，很多客户和我在谈项目的过程中很喜欢“Agile”的项目管理方式，感觉他们把之当成一种自己项目需求变动的保障。

对于这种情况，一般我们自己首先得有一个心理准备，遇到客户项目需求变动，不要觉得这样很不可思议，但这样并不代表退让。

这就是我接下来提到的需求确认的重要性了。关于确认需求，我们一般走这几步：

 

一、分析文档：

拿到A类需求文档，我一般会把需求文档发给团队每一个人，每个人先自己把整个文档仔细过一遍，对于有疑问或者自己不能理解的部分要求在文档中标注出来。接着整个团队可以开一个小组会议，大家一起把项目需求过一遍过程中把自己对需求不理解或者觉得有疑问的部分提出来，会议中一般会指定一个人（可以是PM）做记录大家总体出的问题。

二、与客户进行确认：

大部分项目需求拿到后，我都会和客户相关负责人约一个时间进行Conference Call，（因为时差问题，我们一般把开会时间定在10pm-12pm)，对于英国的客户，我们有时候也在下午开会。在电话会议过程中，和客户一个一个确认我们在前面小组会议中列出的问题，有时候一次电话会议还不能完全确认这些问题，（客户有时候自己在某些方面没考虑好，需要再去确认），我们会提前约好下一次电话会议的时间，直到需求基本确认及理解清楚。

 

三、发邮件确认conference call确认的内容：

这点本来属于第二条，但我在这里独立再列出一次，强调其重要性。与客户确认需求时一定要记住一点，千万别相信什么口头的确认。哪怕是在conference call大家都很明确的一些问题，你也得在邮件中列出，这是我们在上次会议中确认后我们的理解..... ，最后来一个，right? 等客户在后面批注一个：Yes!

尤其是一些你在会议中可能还没完全理解透的问题，还待客户进一步确认的问题，一定要在邮件中列出来，不要觉得这是多余的，因为这将成为以后产生分歧的“呈堂证供”，在客户需求变动时，你可以把这个邮件的内容copy上回复过去，这是我们在#月#日已经确认的，所以，如果您一定要做这样的需求变动可以，但我们需要增加时间和开发费用，另外deadline也会向后拖##天。

 

对A类项目需求，我想举一个手机项目为例，顺便提一下在需求分析过程中应该注意的一些问题: