需求那点事

需求那点事

---测试部 张树臣

关于需求,我们常常有这样的苦恼:

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):用户根本都没有此需求,提供后用户满意度反而会下降。

用卡诺模型区分产品需求

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

A 尽量避免:无差异品质、反向品质

B 至少做好:必要品质、一维品质

C 努力做好:魅力品质

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


 


不提供此功能


喜欢


理应如此


无所谓


可以忍受


不喜欢


提供此功能


喜欢


/


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. 你希望我交付的结果是什么?
时间: 2024-08-06 04:35:41

需求那点事的相关文章

《软件需求最佳事件》-阅读感二

首先介绍了需求相关败因总结简要分析.第一是需求不完整 .那么什么样的需求是完整的呢,显然用户代表要比开发人员更适合对完整性进行评价,,但是软甲需求规格说明书中去充斥着数据字典管理.报表子系统新增客户之类的以技术唱主角儿字眼与结构,显然将用户排除在有效读者群之外,书中介绍了可以用“业务向导”的组织结构,还有就是利用树形层次结构将宏观信息与微观信息进行有效的剥离,树形层次结构应该面向不同的层面:决策者,事务管理层,操作层,需求验证的本是需求质量关,其目标是暴露出更多的错误,也就是我们要的不是签字而是

一次部署HTTPS的相关事件引发的思考

前言: 上周五快要下班的时候,突然收到通知客户希望了解一下部署HTTPS的流程,这种事情谁听了都会有几分诧异的.因为这件事虽然和工作有一定的相关度,但平时不会走这个方向,实际上也较少接触.此外,客户手下应该不缺人,做运维和开发的肯定比我更懂这个,但情况却和我想的不一样. 正文: 客户有需求,就应该尽量满足!因此,尽管之前对Apache.Tomcat的一些配置不熟,也未有过自己部署HTTPS的经验[当然失败的尝试还是有的],便趁着周末了解了一下相关的东西,在本地搭建了环境.实践表明,当你对一个东西

面对对象总结

1. 基础概念:1.面向过程:认识事物和分析解决问题的方式,强调解决问题的流程化                          功能行为,缺点就是不能很好地适应需要的变化c/c++                        2.面向对象:认识事物的方式方法,全面认知事物(属性,方法),将有联系的功能打包放入一个对象里,基于面对过程                       3.面向接口编程:抽象对象身上的属性,方法.通过接口的实现类创建接口对象(contactdao cd=new co

危机的元凶——“大乘佛法三藏”现代文精解

特别声明: 本文是在响应中央改革的号召,也是一个普通公民学习"邓小平理论","摸着石头过河"的一次小结. 本人是辨证唯物主义者,不是形而上学的唯物主义者,更加不是唯心主义者.本文紧扣事实,观点明确,逻辑完整,请勿断章取义.若不能完全理解,请勿效仿. 摘要: 本文试论述经济危机产生的根源,并从根源的角度提出根治经济危机的解决办法. 正文一.<狮子吼>现代文版:依据事实,简要论述经济危机发生发展的过程. 正文二.<六道轮回心经>.<法华经&

读《乔布斯的NeXT和苹果之间,隔了这两个创业常识》

原文链接:http://wwww.huxiu.com/article/114950/1.html 前言: 当今硅谷风头最劲的风险投资家马克·安德森曾说,硅谷每年大约诞生15-20家真正值得投资的公司.不管他的说法是否精确,有一点可以肯定:中国科技业每年诞生的优秀公司只会更少.我曾略做统计,过去三年间中国网络业崛起的非游戏项目不过15个: 2010年:新浪微博.唯品会.美团.聚美.91手机助手2011年:微信.聚划算.天猫.小米.美丽说.蘑菇街.海豚浏览器.豌豆荚2012年:唱吧.陌陌 作者注:时

One take,可望而不可即

One take,是几年之前看综艺节目听林志炫提到的一个词,就是说录制一首歌曲一次性完成,无需后期的各种修音.这个概念听起来就很酷,对不对? 作为一个程序员,我经常也希望能够One take:一次性把事情做好,不用反复.但逐渐发现,追求One take是很难的. 本文地址:https://www.cnblogs.com/xybaby/p/9607331.html 关于读书 坦白的说,我看书不多,不管是技术书籍还是人文.除了本身不够热爱.不能坚持的主因,忙碌是不可忽视的客观原因,现在大家都提倡碎片

测试感想

做了这么久的软件测试工作,一直没写过博客之类的.一直以来,都感觉没什么可写.直到最近找工作,不是那么顺利,才突然发现自己的欠缺的很多. 之前总以为自己懂得不少测试技术,找工作那还不是轻轻松松.现在回头想想,这个坑好深,自己沉浸在其中,沾沾自喜,更可悲的是,自己竟毫无所觉. 我想,在这个坑中的人,大有所在.所以今天突然觉得自己该写点什么了,以此来警醒自己,也让那些看到此文的同僚,有所体悟吧. 一.未认清工作的本质 我想,说到软件测试的本质,也就是测试目的,很多人能够脱口而出,那就是“发现更多的缺陷

第28件事 挖掘用户真实需求的6大撒手锏

如何挖掘用户的需求,即如何挖掘出用户想要的是什么,这是所有产品经理的必修课,也是最难修炼的一门课,这门课需要极高的悟性. 1.人性法在第27件事中,对用户的人性进行了一些剖析,用户的人性主要表现在矛盾.虚伪.贪婪.欺骗.幻想.疑惑.简单.善变.好强.无奈.孤独.脆弱.自私.无聊.变态.冒险.好色.善良.博爱.诡辩.懒惰.快乐.好玩.猎奇.嫉妒.执著.恐惧.欲望等方面,本质上来说,人其实还是一种“高级动物”.获取用户需求的传统方法很多,比如调查问卷.用户访谈.焦点小组等,但是这些方法显得有些过时了

软件系统开发之前要做的事—需求调研框架

近期在做的一个软件需求调研,从以下一些方面进行了了解,当然这些只是初步的一个需求框架,还打不到设计开发的基本,只是让软件公司能够对软件需求有一个总体的了解而方便对软件有一个大概的估算. 公司情况 实现的根本目的 现有软件情况(现有应用.架构部署情况.使用技术:技术文档.是否需要进行数据对接,需对接方是否提供技术支持) 涉及人员 业务类型 业务流程 业务规则 关注重点 其他非功能性需求 数据规模 数据频率 应用环境