如何进行有效需求分析?(一)
1069
2019-11-07 10:38    文章来源:晓庄同学产品笔记 原创:啊庄
文章摘要:左脑喜欢逻辑,右脑喜欢故事;最好的陈述一定是起于故事,终于逻辑。

你有没有因为需求分析四个字,而感到头发日渐稀少?你有多少个失眠的夜,是在思考领导说的「把系统优化一下」这句简单的话?你又有多少次面对客户无休止的需求变更,而想要拔刀相向的冲动?

这一切的背后,到底是人性的扭曲,还是道德的沦丧?朋友,你的福音到了,欢迎来到大型情感类专题:如何进行有效需求分析!从此告别脱发烦恼,并且让你做到,将乌黑的发尾盘成一个圈,缠绕着领导以及客户对你的眷恋!

1.png

左脑喜欢逻辑,右脑喜欢故事;最好的陈述一定是起于故事,终于逻辑。今天的内容,就让我们从一则生活中的故事开始吧。

 生活故事 

有一天夜里,资深需求工程师老余刚忙完一个重要的项目,带着放松的心情进入了梦乡。这时他年仅 3 岁的小孩夜里醒来,吵着要吃饼干。孩子的妈妈首先被吵醒,带着情绪训斥了小孩:「半夜三更吃什么饼干,好好睡觉!」

没想到小孩不依不饶,继续哭闹着,不久老余被吵醒了... 他安静地走到客厅,找了一小会儿,果然没找到饼干!他随手拿了两块吐司面包走进卧室,脸上掠过一丝自信的微笑。

「小子,没有饼干了,吃点面包填肚子吧!」老余边说边把吐司塞到小孩手中。果然,小孩接过面包后就不再哭闹了,吃完一片就乖巧地躺下。不一会儿,老余家又归了平静。

 分析 

从故事中我们可以看到:小孩子提了一个需求,即要吃饼干;而妈妈考虑的是,家里没有饼干了,并且是半夜,想要实现这个需求的话,肯定还要起床下楼,并且找到 24 小时营业的便利店,这个实现成本太高了,于是断然拒绝;而爸爸则透过现象看本质,小孩子半夜要吃饼干,这并不一定真的是想吃饼干,极有可能是饿了,这样的需求,可以通过其他更易实现的方式更好地解决,于是,随手的两块吐司面包,就让这个家庭又重归了平静。

典型的三类人群

孩子=客户

那你也许会问,为什么小孩子不能够直接说「我饿了」,而是一定要「吃饼干」呢?因为,这就是典型的客户思维方式!我们先给出这样一个结论:在方案级的探讨,客户是感性的;而在问题级的探讨,客户是理性的。

你是否有过这样的经历:客户说,xxx 功能我们想要(可能就是因为参观大厂时,看到了这个功能界面,并且觉得特别流弊~),你给我们加一下吧。这样看似非常明确的需求,但往往很容易发生颠覆性的需求变更,即到最后,客户自己明确说明的这个功能,自己又把它给亲手砍掉。原因可能很简单,也许就是三个字,不好用。

这种经历,能给我们带来什么样的启发呢?这句话很关键:客户是问题专家,而非解决方案专家,他提出的方案未必能够完美地解决他遇到的问题!

小孩子提出想吃饼干,这是一个方案级需求,这极有可能是因为小孩子脑海中突然回忆起了饼干的味道,并且小孩子才 3 岁,客户的感性思维,在这里体现的淋漓尽致;而小孩子饿了,这是问题级需求,这才是需求的本质。我们可以看到,以「吃饼干」这样的方案来解决「饿了」这样的问题,显然是不合适的。

我们再来说客户的理性一面。当你跟客户沟通这样的话题:「在当前工作中,有哪些方面你会觉得有困难呢?」这个时候啊你会发现,客户表达出来的内容,就像滔滔江水、连绵不绝,如黄河泛滥、一发不可收拾,并且还会加上各种事例来佐证他的观点,如果可以,他可能更希望拿个 U 盘,把他遇到的这些困难直接传到你脑子里。而这些内容,往往都是理性的,都是客观存在的事实。当然,这也是我们需求分析的突破口,我们后面也会提及。

妈妈=程序员

典型的技术思维,关注的是「方案级需求」,即吃饼干这个方案能否实现。

我们脱离这个故事,在我们的实际工作中,究竟什么是技术思维呢?

关注点:实现方式、技术架构、技术价值、开发成本。

定义:从功能和工程实现出发,在满足产品需求的同时,寻找可复用技术架构和低开发成本。

爸爸=产品经理

典型的产品思维,关注的是「问题级需求」,即小孩子遇到的本质问题是饿了。

同样,我们看一下在实际工作中,产品思维是怎样的定义?

关注点:用户价值、使用场景、商业价值、业务闭环。

定义:从用户价值出发,在满足商业战略和业务目标的同时,寻找产品路径满足用户需求。

 需求打开的正确方式 

通过开篇生活中的故事,我们可以体会到,要做好软件需求工作,业务驱动需求思想是核心。而作为产品经理或者是需求分析师,我们不是简单的「需求传递者」,我们是「问题解决者」的角色。那么在与客户进行沟通时,需求打开的正确方式是怎样的呢?

澄清问题—>了解背景—>建议并确定解决方案

1. 澄清问题

(1)想要解决谁的,什么问题?

(2)用户现在遇到这个问题会采用什么样的解决方案?

(3)这个问题中有需要进一步细化和明确的概念吗?

2. 了解背景

(1)该需求谁使用?什么时候使用?具体怎么做?

(2)有需要澄清的业务术语吗?它们的格式是什么?

(3)不做谁生气?多久生气一次?多久用一次?

3. 建议并确定解决方案

(1)要解决这个问题有哪些可行的解决方案?

(2)这些方案的实现成本分别有多大?

(3)你觉得哪种最合适?

(4)该解决方案对用户而言有什么优缺点?

(5)有其他需要挖掘的需求吗?

 需求全景图 

写到这里,不由地想起之前面试的经历。

面试官问我,一个产品研发完整流程分为几个阶段,每个阶段的占比是多少。我当时做了这样的回答:一个完整的产品研发流程中各部分的占比,大概 50% 做需求,30% 做开发,20% 做测试。

然后面试官紧接着问我,既然需求分析占比这么高,那说一下需求分析的方法论吧。我突然发现自己对于这方面方法论的研究几乎空白,只知道最终的产物,是利用 Xmind 列一个功能清单,但至于这个功能清单是如何得出来的,我当时的认知是具体问题具体分析...

当我看到《有效需求分析》这本书中,提出了「需求全景图」的概念时,真犹如哥伦布发现了新大陆一般,不禁惊喜万分。

需求全景图,包含了诸多内容,但自己感触最深的还是「功能主线」这一项,毕竟我们每天都在与「功能」打交道。回到我面试的那个问题,最终的功能清单是如何得出来的呢?

最好的思考角度,就是厘清系统中的所有功能是因何而存在的,这也正是我们前面所说的,需求分析的突破口。功能主线的梳理,无外乎以下三个角度:

1. 业务支持

(1)固化优化业务流程,因此业务流程是核心;

(2)业务延伸到新的通道(诸如手机端),这从本质上来说也是一种流程的重构,核心还是业务流程;

(3)将个人能力转化为组织能力,这种能力存在于具体的业务场景中,因此「专家场景」是核心。(后续的文章会详细论述)

2. 管理支持

(1)事前风险避免,通过增加管理流程;

(2)事中风险控制,通过「规则」和「审批」;

(3)事后总结优化,通过「数据分析」。

前两种通常会在业务支持分析中统一处理;第三种则应该独立进行分析。

3. 维护支持

系统投入使用之后,还需要对其进行维护,最典型的包括初始化、配置、排错等,而这些运营维护场景也都需要有相应的功能来支持。

当然,功能是我们的最终落脚点,但需求分析不单单是功能,这里先把需求全景图展现给大家吧:(自己手动码出来的图呀~)

2.png

 结语 

需求不是一场简单的头脑风暴,也并非高深的诸如马斯洛需求层次理论,更不是领导交代的任务、运营提供的方案或是客户要求添加的功能,需求是一项系统的工程,更是一门生活的艺术!我们经常在电视中看到,古代的那些位(lao)高(jian)权(ju)重(hua)的大臣,几乎每一个都是需求分析高手,没事就在那犯嘀咕:「皇上今天说的这句话是什么意思呢?」

由此可见,需求分析不仅仅是软件领域的方法论,更是存在于我们生活的方方面面,让我们一起探索需求全景图的奥秘吧!


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)管理咨询有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)管理咨询有限公司将追究其相关法律责任。

评论