为什么我们从来没时间把事情做好,却总有时间返工呢?

有资料显示:产品中发现的缺陷有40%~50%是在需求阶段埋下的“祸根”,需求阶段的问题不但造成了大量的无效工作,也间接影响了团队的士气,降低了产品质量和业务价值。

为什么会出现这种情况呢?

我们可以试着从需求的定义来找一找原因。

关于需求的定义,有两个比较有代表性:

 

 

无论是哪个定义,需求涵盖了来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。正是因为接口和过程的多样性,给需求管理带来了不确定性和含混性,而产品开发是一门精确的学科,如果我们自己都不知道想要什么。那么开发过程越精确,其结果偏离越大。


  本文结合自己踩过的坑,汇总一下探索需求的过程,以及如何尽量减少需求分析过程中含糊不清的地带,达到「明白自己在做什么」的目标。

有四个部分可以概括探索需求的内容,本文主要讲人性因素、含混性来源和消除含混性的方法。

 

一、人性因素

 

在产品和系统开发方面有经验的人可能有这种体验,产品成功的关键越来越依赖于人的因素,所以他们会花更多的时间来与人打交道,而花较少的时间在技术任务上。

 

人与人不同

 

需求的产生,我们可以理解为:某些人会提出一些想法,并觉得某些特性应该设计到产品中并通过技术手段去实现。在这个过程中,如果是我们自己的一个想法或许不会产生什么问题,但因为「人」来自不同的群体,针对同样的事情看法可能截然不同,认识到这个差异性是我们探索需求的起点。

比如,有一名大学院长说:“我们需要吸引更多的学生”,如果仅仅理解字面意思,“更多学生”可能是指学生数量,也可能意味着招收更多的优等生等。实际上院长需求背后的动机是,提高申请者的拒绝比例来增加拨款。

我之前遇到过一种情况,领导和客户代表沟通后说,希望通过一个智能分析算法实现道路车流量检测,统计出一定时间段内道路通行车辆计数功能。

然后工程师就把分析算法当做核心工作开始了开发,等做得差不多了的时候去和客户再次沟通,才发现:客户并不关心算法,他关注的是统计出的数据能给他带来什么分析和推论,按照这个思路往下走,实际上数据处理、分析和深度挖掘,才是这项工作的真正需求。

 

人的知识不完善

 

在需求分析及探索过程中,负责需求的人员见识和技能的不同,结果也会存在较大的差异。在需求调研的开始阶段,用户访谈是比较常见的方式之一,但一个错误的假设或者错误的问题顺序,会导致你给客户的每个解决方案都是正确的,但解决的都是错误的问题。

而在产品开发过程中,人的知识不完善体现得更加明显。没有人是全能的,结构工程师很大概率不懂电气,那在机电结合的环节,就存在一个隐藏的含混性。

之前的项目中,结构按照自己的设想设计了一款外观得到所有人称赞的方案,但实际安装环节,发现结构和电气设备之间的配合问题比较多。还有硬件和嵌入式,假如嵌入式想实现一个创新算法,其对硬件的运算速率、有效存储往往有要求,但如果在项目开始前不把这些含混的地方讨论清楚,最终的结果往往是更改设计方案或者被迫放弃新的功能。

 

群体无意识

 

个人一旦进入群体中,他的个性便淹没了,群体的思想占据统治地位;而群体的行为表现为无异议、情绪化和低智商。

 

——勒庞《乌合之众》

 

我们在需求分析过程中,经常会遇到这样的情况:拿着一份需求分析报告,在和同事、领导沟通的过程中,在尖锐的问题、不同的观点交相碰撞中败下阵来。

 

 

比如:一款产品,按照设计路线图,可能需要三个版本才能实现的一个功能,领导可能要求在第一版就实现。这中间就缺少了过渡和缓冲,就如婴儿出生与成长一样,很多事情需要时间和成长空间。

有一个故事是这么说的:

 

“给我们用最低的成本解决。”

 

“在最短的时间内搞定。”

“我们必须尽可能以最好的方法完成。”

放在健康人身上,优化神经收到这些请求后,会给嘴发送一个脉冲,让它回答:“那你愿意牺牲什么呢?”

可在群体中,这部分神经通路被切断了,嘴里就会吐出一些扭曲的话语,比如:“好的,老板。我马上去办,老板。”

 

探索需求的方法论和原则

 

和其他很多事情一样,在探索需求的过程中,人几乎是一切问题的根源。站在个人的角度来说,我是我大多数问题的根源。

探索需求需要遵循的原则离不开人性因素,如果一开始就想到了人与人之间存在差异,个人力量有限,我是引起大多数问题的原因,在群体中容易陷入对权威的无意识跟随。那么在需求探索的过程中,我们就可以有针对性地去避免这些问题。

有一个方法是将自己保持为“初学者状态”,对初学者而言,所有的事物都是平等的、新奇的、不可能的。

 

二、含混性来源

 

在我们日常工作中,需求的获取方式主要来自访谈、工作坊、焦点小组、观察、问卷调查、系统接口分析、用户界面分析、文档分析等。

结合第一部分介绍,需求含混性的来源非常多,比较常见的有以下几种:

 

     

  1. 观察和回忆错误(需求调研前后,对用户行为的观察和回忆错误);

  2.  

  3. 解释错误(看到一种现象,用自己的观点而非客观事实来解释);

  4.  

  5. 错误来源的混合(比如:设计一款产品,不仅仅需要考虑直接用户,还需要考虑投资人的期望,需要关注产品上下游维护和现场支持人员的功能及非功能需求。如果我们把需求方弄混淆了,或者把用户的需求嫁接到投资人身上,其结果往往南辕北辙。);

  6.  

  7. 人们交互的作用(我们在分析问题时,鼓励相互独立,但在听到一个不同的见解或新的问题解释,我们改变了初衷。但这种初衷的改变并不是提高了观察力,而仅仅是被他人影响。);

  8.  

  9. 问题陈述的含混性,有一类案例比较有代表性:玛丽曾经有一只小羊羔,这是今年我看过的最好的电影,我真的没有骗你。试试把重音放在不同的词语上,带来的结果差异。

  10.  

 

在参与需求工作时,我们可以采用直接使用回忆启发的方法来验证含混性。只要简单地拿走书面的需求文档,再请每个参与者根据记忆写出其中所指的内容就可以了。那些有回忆差异的地方就是文档中有含混性错误倾向的部分。

这一步非常重要,因为几乎很少有人会在工作中实际参考那些需求文档,他们更喜欢根据他们记忆中的文档内容来办事。因此,易于正确回忆起来的文档很少会带来设计错误。

 

三、消除需求含混性的方法

 

需求带来的模糊地带如此之多,有什么好方法能够尽量减少错误的发生呢?

我们可以从两个方面来提升:

 

 

下面选几个不同阶段的方法讨论一下这个过程。

 

找到相关人员

 

在开发活动中最为常见的单个错误,可能就是在过程中遗漏了某个必需的人物。所以第一个需要问的就是“谁是客户?”

客户决定产品的外部属性,比如:产品值多少钱。

其次是找到产品的使用者,使用者是真正使用产品的人,产品的成败由他们决定,我们身边有非常多的例子。有分析指出:很多公司购买了各种软件工具,但70%被束之高阁,除非产品找到了真正的使用者,否则一切都是镜花水月。

一种方法是我们先列出所有可能的使用者,利用我们的“共情能力”,对用户立场和偏好进行深刻理解,理解他们的关注点,然后根据设计方案将使用者群体分为「对他们非常友好」、「忽略他们」、「对他们非常不友好」几类。这些角色的定位除了对单一功能点的分析有价值外,也会决定需求的优先级。

<p style="font: 17px/30px "PingFang SC", "Lantinghei SC", "Helvetica Neue", Helvetica, Arial, "Microsoft YaHei",