需求那点事

                                                                                           

关于需求，我们常常有这样的苦恼：

1.用户需求太多，几乎不可能在合同约定的日期内完成；

2.团队成员对需求理解不一致、不到位，做出来的产品跟用户需求不匹配；

3.用户需求一直在变变变 。

。。。。

我就此类问题谈谈自己的看法

          说起需求，脑海里总会闪现出上图中的画面，它用一种形象但夸张的方式描述了需求在传递中的失真。不知是否有人特意计算过因为需求理解有误而耗费的成本，我想一定是不低的。而这种“状况”屡见不鲜！本着“做任何一件事，绝不要重复两次而不意识到或质疑这其实是个问题”的原则，我对需求管理做了一点研究。现将近日心得诉诸纸面，希望可做他山之石。

         从需求获取开始，需求管理的过程贯穿于整个项目周期，为便于阅读，我将自己的收获和看法按照项目阶段来进行探讨。

 

需求调研阶段：

         怎么做需求调研？如何跟客户沟通？

         这问题貌似很简单。如果这样问一些跟客户做过需求调研的同事，我想他们中的多数都会回答：去跟客户聊聊他们想要什么，然后让设计人员做个Axure，最后带着效果图（可能还有蓝图）跟客户确认一下即可。

         事情真的这么简单吗？

         如果进一步问：“客户在表达需求的时候，你会跟客户提一些他们没有想到的功能吗（特别是开发时间紧的情况下）？ 或者说你会提一些尖锐的问题吗？”我想多数回答是：“这个时候我们主要是倾听，把客户提出来的弄清楚即可。时间太紧，客户没提的就不要自己主动挖坑了。”再问为什么？ 我想多数回答会是：“这是明摆着的事嘛，而且前辈们都是这么做的。”

         这种“理所当然”的行为真的对吗？或者说不提问题能降低项目风险吗？我们能保证在开发的过程中客户不提新想法吗（也许这个想法在调研阶段我们就已经想到但没提）？不提问题我们就能如期交付项目吗？

         依我之见，讨论需求的时候应当尽可能深入，多提一些尖锐的问题，让困难提前出现。

理由：

1. 深入沟通可以发掘隐形需求，确认客户的真实意图，这有助于我们摆正方向；
2. 深入沟通，即使导致增加功能，但我们可以选择做或者不做，如果客户要做，那我们可以排优先级、申请更多的工作量
3. 越早提出问题，修正的成本越低。 

需求分析阶段：

         为什么要做需求分析？

         有人说是为了弄清楚客户的意图，有人说是为了评估技术难点和项目风险，也有人说是为了安排任务估算工作量。。。这些说法都对，不过我觉得更重要的是项目负责人应该通过这段时间的工作做到胸有成竹。

         郭教授常说，项目不是练兵场。要想把项目做出色，做之前就得胸有成竹。正如一个画家在画竹子之前，心里就有了竹子的形象，画家所做的，只不过是把心里所想的东西，誊到纸面上而已，当然可以做到驾轻就熟、游刃有余了。同理项目成员如果在项目开始之前就知道怎么做，知道怎么做才最好，那这个项目想不成功都难！反之，那这个项目做起来就有点碰运气、期待奇迹，不是吗？

怎样才能胸有成竹

         想做到在项目开始之前即胸有成竹，经验、知识技能、思维缺一不可。经验可以让我们复制过去的成功，或者避免重蹈覆辙。知识技能让我们对项目的理解更深更广，能举一反三触类旁通，亦能发现项目难点潜在问题。思维，指的是对客户需求的理解程序、解决问题的思路。

         一个项目的核心无非是做什么、怎么做和资源这三个方面，如果这几个方面都清楚明白了，都在掌握之中了，那我们也就大致上做到了胸有成竹。如果还是不确定的话，好吧，那我们再围绕这三个中心，再试着问自己六个问题，把这些问题好好的想一想，都能回答出来吗？ 

          这个阶段最让项目经理头疼的问题之一是需求太多，逻辑太复杂，项目时间又紧张。  我看过一些项目的WBS，我发现无论功能逻辑多么复杂，工作量都能神奇的压缩在合同约定完成日期内---实际上，这几个项目开发过程中并没能按照WBS来核查进度，当然最后也多数拖期了。

         我觉得在这一点上我们必须应该改进。提供一个需求分析的神器---卡诺模型

需求分析神器 卡诺模型。

         任何一个互联网产品，即便是一个最简单的活动页面，也会涉及到非常多的需求，每个需求都会引出相关的功能逻辑，需求一多，特别是很多需求交叉覆盖，产品的逻辑就会变得非常复杂。

卡诺模型也叫做狩野模型（Kano Model），它是由日本品管大师狩野纪昭（Noriaki Kano）博士于1984年所提出的。卡诺模型的核心是将产品品质分为四个部分：

A 无差异品质（Indifference）：无论提供或不提供此品质，用户满意度不会改变，换句话说，这种品质用户根本不在意；这种品质是产品设计中需要尽力避免的。

B 魅力品质（Attractive）：用户想象不到的品质，如果不提供此品质，不会降低用户的满意度，一旦提供魅力品质，用户满意度会大幅提升。

C 一维品质（One-dimensional）：一维品质又称为线性品质，若品质好，客户满意度高，反之，品质差客户便给予负面评价。

D 必要品质（Must-be）：这是产品的基本要求，无论必要品质如何提升，客户都会有满意度的上限，但不提供此需求，用户满意度会大幅降低。

E 反向品质(Reverse)：用户根本都没有此需求，提供后用户满意度反而会下降。

 

用卡诺模型区分产品需求

上面简单说了几种品质，我们做产品设计时，需要尽量避免无差异品质、反向品质，至少做好必要品质、一维品质，努力做魅力品质。

• 尽量避免：无差异品质、反向品质
• 至少做好：必要品质、一维品质
• 努力做好：魅力品质

在分析产品需求点时，将所有已经确定的需求进行分析，按照：喜欢、理应如此、无所谓、可以忍受、不喜欢，进行评定。然后根据下表得出各需求属于什么类型。

			不提供此功能
			喜欢	理应如此	无所谓		可以忍受		不喜欢
提供此功能	喜欢		/	B	B		B		C
	理应如此		E	A	A		A		D
	无所谓		E	A	A		A		D
	可以忍受		E	A	A		A		D
	不喜欢		E	E	E		E		/
A无差异品质		B魅力品质		C一维品质		D必要品质		E反向品质

 

        

需求传达

         同一个项目团队，成员对项目的理解不一致是常事，如果对需求理解不深刻，做出错误的功能是“理所当然”。提供一个思路如下：

         项目负责人应该跟团队成员说明的：

1. 为什么要做这个项目？谁提出做这个项目？
2. 电梯演讲，如果只用三十秒来描述项目，应该说什么？
3. 创建否定清单， 我们要知道项目应该做什么，也要知道不应该做什么。
4. 如果要宣传我们的项目，应该是怎么打广告？
5. 谁是我们的同行或竞争对手？
6. 解决方案（技术架构和蓝图）是什么？画出蓝图有助于确保专注于同一件事情上。
7. 风险是什么？ 找到那些使我们夜不能寐的问题，讨论并找到避免的方法，能有效降低相关问题带来的影响。
8. 项目周期？需要的资源？
9. 我们要舍弃什么？项目可以用时间、范围、预算和质量等杠杆来调控，那么在本项目中，最重要和最不重要的是什么？

 

重点介绍一下电梯演讲- -优秀的电梯演讲对项目大有裨益。

（1）它能带来清晰的思维。

         不必面面俱到，电梯演讲迫使团队只回答产品是什么，为谁而做这类最尖锐的问题

（2）它能迫使团队从客户角度考虑问题。

通过将注意力集中于产品的功效和理由，团队会深刻的理解产品的魅力所在、客户为什么要首先购买其产品。

（3）它能直达要点。

电梯演讲好似一束激光，可以穿透并直达项目的核心。这可以帮助设置优先级，更有效的捕捉关键需求。

现在看一下对演讲有所帮助的一个模板：

对于【软件用户】而言

他们【需要追踪建筑场地上所做的工作类型】

而【CSWP*】

是一种【安全工作许可证系统】

它能够【创建、跟踪并审核安全工作许可证】

不用于【现有的纸质化系统】

我们的产品【基于web并随时随地可以访问】

 *CSWP: 建筑安全工作许可证

 

电梯演讲的方式不止一种，我喜欢杰Geoffrey Moore的著作《Crossing the Chasm》中提到的一种方式，即上面这几句话。

• 目标客户--解释项目为谁而做或者谁会从其应用中受益。
• 需求或机会-详细阐明客户必须要解决的问题或需求。
• 产品名称-给项目起个名，赋予其生命力。名字很重要，因为他们可以传递意图。
• 产品类别--解释产品或者服务到底是什么或者能做什么。
• 主要优势--解释一下产品的核心竞争力
• 主要的竞争产品--解释为什么我们没有用其他现成的产品。
• 主要区别--区分并解释我们的产品有何不同，与竞争产品相比有何优势。

 

项目启动

在项目启动前，我们每个项目成员都要对自己作如下提问：

1. 我擅长什么？
2. 我如何执行？
3. 我看重什么？
4. 你希望我交付的结果是什么？