需求的定义：

 

1，需求： 需求就是 "要什么" .。需求分析本质上就是问题分析，问题分析的方法论可运用到需求分析。

一般情况下，需求直观表达为谁在什么情况下想干什么。这里就涉及带了"目标用户" "使用场景" "用户目标"。

eg：

一个人饿了，想吃东西。--------------->这就是用户需求。

你给了他一包方便面。--------------------->这就是满足用户需求。

你给了他一块面包，然后告诉他，面包比方便面好吃，但是容易噎到，于是搭着卖了一瓶红茶。------->这是创造用户需求。

 

2，需求的的场景

是需要根据具体场景特点来分析如何满足需求。比如分析观看视屏用户在移动场景下的特点就是移动频繁、注意力不易集中、

流量有限等 ！ 那对应的视屏类产品设计原则就会考虑让交易单手操作、视屏简单而两点集中（如：万万没想到  等短视频的搞笑视屏）。

基于什么环境： 地铁/办公室/室内/公共场合/走路/夜晚/户外..........

基于什么用户： 具体什么特征，比如身份、收入、区域........

基于什么行为： 行为或操作流程，比如购物流程、操作习惯、行为认知..........

场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。

 

需求的分类

 

1、需求层次：
1）. 业务需求：业务需求是方案范围，经营范围，或者项目范围
2）. 用户需求：用户需求在互联网中的表现大多是在各种场景下，用户想做某件事情所遇到的问题，或所想满足的欲望。
3）. 功能需求：主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求。功能需求是为了满足业务跟用户而制定的。
4）. 系统需求：响应系统层面需求，例如：系统没有内存了，页面卡了

2、常规三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。
1）.基本型需求：用户认为产品“必须有”的属性或功能。当其特性不充足(不满足用户需求)时，用户很不满意;当其特性充足(满足用户需求)时，无所谓满意不满意，用户充其量是满意。
如果此类需求没有得到满足或表现欠佳，客户的不满情绪会急剧增加，并且此类需求得到满足后，可以消除客户的不满，但并不能带来客户满意度的增加。产品的基本需求往往属于此类。对于这类需求，企业的做法应该是注重不要在这方面失分。
我们一般停留在这个阶段
2）.期望型需求：耍求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连用户都不太清楚，但是是他们希望得到的;在市场调查中，用户谈论的通常是期望型需求，期望型需求在产品中实现的越多，用户就越满意;当没有满意这些需求时，用户就不满意。
此类需求得到满足或表现良好的话，客户满意度会显著增加，当此类需求得不到满足或表现不好的话，客户的不满也会显著增加。这是处于成长期的需求，客户、竞争对手和企业自身都关注的需求，也是体现竞争能力的需求。对于这类需求，企业的做法应该是注重提高这方面的质量，要力争超过竞争对手。
3）.兴奋型需求：要求提供给用户一些完全出乎意料的产品属性或服务行为，使用户产生惊喜。当其特性不充足时，并且是无关紧要的特性，则用户无所谓，当产品提供了这类需求中的服务时，用户就会对产品非常满意，从而提高用户的忠诚度。
此类需求一经满足，即使表现并不完善，也能到来客户满意度的急剧提高，同时此类需求如果得不到满足，往往不会带来客户的不满。这类需求往往是代表顾客的潜在需求，企业的做法就是去寻找发掘这样的需求，领先对手。

 

如何与客户高效的沟通需求

 

很多外包服务商都会有这样抱怨：客户的需求又改了，之前做的工程又返工了......。出现这种情况，很大部分原因在于：与客户沟通时，客户说出来的需求，与谈需求的乙方接受的“需求”，与最后工程师接受到的、真正实施的需求很不一致导致的。这就像多人传话的游戏一样，第一个人说出的话，与最后一个人所听到的，是截然不同的意义。
--------------------- 

同时除了信息沟通不到位之外，还有一个原因是：
一般面对客户谈需要的乙方角色都是销售或产品经理，而这类角色的人会有公司业绩压力的影响，在与客户谈需求时，内心的活动是：先把这个事笼下来，把我的业绩完成，至于是否能开发那是工程师的事；
而工程师他的主要服务对象是给他提出需求的人（产品经理等角色），他的工作任务是基本把需求开发完成；
由此以来，一个项目承接下来后，能对客户承担责任的人就少了，到工程结尾的时候，就不可避免的会发生各种改需求或返工的情况。
 

真正能有效、能开发出客户满意的系统，就应该在与客户沟通需求时，一定要有一个这样角色的人：即能作为产品经理，能比较迅速的梳理出客户的需求，同时也能作为工程师，能评估出项目的难易度和开发周期，同时也能作为销售，能与客户谈出一个双方比较合理的价格。

 

 

大体的流程是这样的：

1.先和客户沟通想要实现什么功能？

2.整理一份粗粒度的需求文档，并设计原型。

3.找客户确认原型，并在需求文档上签字画押。

4.循环上述步骤

   

该如何和客户进行交流？

    1.用户需要什么功能？用户提供了哪些数据？这些数据是否能够实现用户所需要的功能？

    2.注意聆听客户的要求，并用自己的语言重复给客户听。建议：录音保存后整理。

    3.软件的使用频率、使用周期、数据量是多少（比如：每月最多上传多少条记录），以便于后期优化。以及谁使用本系统？涉及到权限的管理。

项目如何开始：怎样和客户谈需求

三种客户类型：

1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值疑问和担心。能快速回答你的问题。

2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。

3 啥都不懂。 不给文档。能给你几个参考范例（打开数个网站，告诉你我要做成和它们一样的。）只能等着你来问100个问题。。。

四种合作方式：

1 创始人直接和你接洽：

交流结果的协商余地很大，需求不易反复，细节不会被过分追究。更容易统一想法，执行力高，你能对项目和产品产生更大的影响。但往往甲方会过于急进。

2 项目代表和你接洽：

这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表，负责汇总甲方的所有需求和标准和你沟通，他有过与外包方合作的经验，知道危险的环节所在，能承担翻译和桥梁的角色，帮助你阻挡和说服不恰当的需求。能集中地承担责任，也会积极地和你一起规避项目失败的风险。非常lucky！

3 专业部门和你接洽：

IT部门或技术部门的某个高级别工程师负责和你沟通，你们会比较有共同语言，甚至惺惺相惜。技术方面的合作会很顺利，但是涉及到产品和需求，他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后，很有可能在技术思路上产生分歧；如果在程序部分耽误了太多时间，而产品端被忽视，你有可能受到其它部门及上层的质疑。

4 市场部门（内容部门）和你接洽：

最好你先去烧烧香，准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后，切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事，写更多的文档，主动和专业部门联系，力争和决策层有沟通。

如果你面临了第3和第4种状况，

请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发：

需求 和 市场部门 沟通

功能 和 内容部门 沟通

软硬广告位或专题 等 和 销售部门 沟通（如果是改版类，广告位合同可能提前半年签订，一定要和销售协调好）

技术、系统、安全、统计问题等 和IT、网管、数据统计部门 沟通

某些问题 需要和 总裁助理、行政 等官僚部门沟通。

部分特别的内容 需要和 创意、美工、文案部门 沟通

当以后确定需求的时候，如果发现这些部门的人没有参与，请提前与之沟通。

第1和第2种状况可跳过上述步骤。

八步流程:

第一步：听听客户想要什么。

以及预计工期和预算（这两件事上一点都不要腼腆，这是关系项目成本最重要的素）。

第二步：提问。

1 项目的目的是什么。（品牌、渠道、流量、广告费、用户数、VC、其它商业模式）

2 甲方的优势和资源是什么。(钱，内容资源，人力大战，传统行业优势)

3 尽量提供可视的参照及借鉴对象 。（应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象）

4 其它工程的细节问题。

比如（工期上的上下限是什么？

是否会需要与现有系统整合、是否需要数据迁移？是否会需要甲方的工程师合作？

是否有开发平台的限制？

是否有代码规范及标准？最终需要哪些开发文档和源码 ）

第三步：取得共识。

与甲方取得共识非常重要，保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲，画出草图或框架图。有参考对象的，标注上，哪个部分会比较像某某。

然后请甲方确认， 这个框架是他们想要的。

第四步：给出工程时间轴。

到了这一环节，就需要你的项目经理组织所有团队成员坐下来讨论，先划分功能模块，然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾 系统搭建和系统整合的所需时间。

项目经理对工程耗时和可行性完全心里有数后，画出工程的时间轴。包括并行状况，里程碑节点、测试期、缓冲期等（如何画工程时间轴，甘特图，我以后会专门写一篇）。时间轴要实事求是，并且预留好充分的缓冲期（工程师估时*2*110%）。

第五步：需求做减法。

大部分情况下，时间轴表现的状况都会超出客户的预期。如果客户对工期没有要求，也要提醒客户考虑 项目可行性风险、市场等候成本、市场或战略变化导致的浪费。

韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。

所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期，落实只开发最基础和最必要的一期需求。

这时签订正式开发协议。

不要忘了计算 需求文档和产品方案 的费用。

第六步：撰写详细的需求文档。

《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。

《流程图》》下载西乔的模版。理出产品的逻辑关系。

《功能需求文档》》下载西乔的模版。 罗列 功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的 基础文档。

第七步：商讨需求文档

尽量召集甲方所有相关部门的负责人 一起召开这次会议，商讨需求文档。

在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。

更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。

所以这次会议是一场耐心和体力的考研。

文档作者需要 分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。

安抚情绪。解答困惑。控制需求变动。

第八步：定稿需求文档

分职能（部门）类建立表格文档。将会议协商中所有 分歧性意见和变动意见 都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。

所有会议中可能被提出但是未出现在此邮件文档中的 意见，不会列入需求文档中。当然允许可以书面反馈补充。

根据确认过的反馈回复，修改需求文档。直到需求文档定稿。

协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，搜集需求和文档定稿的 时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。

三种武器：

需求问卷：无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。

此时撰写一份需求问卷非常有效。

问卷里提出重要的全局性的问题，需要客户逐条书面回答。

某些问题可以提供多个选项答案，及补充区域。

某些问题 需要确凿的态度，Yes或NO。

不要提出需要客户写一大段表述性文字的问题。

需求问卷精简扼要，有针对性，重要，不要浪费客户的时间，不要把写字的工作量丢给客户。

书面确认：

书面确认 一方面包括 ：所有讨论结果、建议 和变更 都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。

另一方面包括：你要尽量提供书面的可视化的东西 来让甲方确认。

甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。

邮件抄送：

邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。

尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。

结语：

到此看起来，搜集和确定需求真是一件耗时耗力的工程。

其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。

当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。

 

一个全新的需求项目

思维导图：

第一步，需求确认

分析资源主要是两个注意的地方：
1、人力资源
有多少人能用，每个人的能力如何？
2、时间节点
这个需求要求如何？什么时候交付？
第三步，功能分析

================================================================================================================================================================================================

 

 

 

 

 

 

 

 

 

 

 

 

 

 

今天的文章 互联网项目开始时需要去谈的产品需求分析：分享到此就结束了，感谢您的阅读。