关于需求,我们常常有这样的苦恼:
  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):用户根本都没有此需求,提供后用户满意度反而会下降。