如何准确定义B端需求?先找到关键点

需qiú定义不准确,程序猿泪崩!(B端)描述产品的某个需qiú看似是一件很简单的事情,感觉只要指出具体的事项和产品需要X什么就可以了。实则不然,在曰常沟通中,我们仍是对很多问题存在争论。这时候,就要qiú我们必须转呗定义产品需qiú,对问题达成共识。具体如何做?文章对此展开了梳理分析,与大家分享。

需qiú定义严格来说并不属于需qiú工程的范畴之内,它是产品立项时要做的事情,最核心的工作是确立一个合理的项目目标与范围。

关于项目目标与范围,企业高层通常是依据自己的洞见与经验去判定,有时缺乏集体智慧与科学验证,导致它与团队实际能力及XX需qiú出现偏差,即找不准要解决的根本性X问题或发展机会,项目出现“上梁不正下梁歪”的情况。

如果方向错误且船只结构的打造扛不住实际风浪,那么船只不仅偏离合理的轨迹,还会X惊涛骇浪,最终做了很多无用功。可见,需qiú定义是不容忽视的一个环节。

需qiú定义的工作从方向性着手点是确定问题或者寻找机会。

举个例子,当一家杂货店发展为雇用了几个店员的小型超市时,货品丰富,曰成交量数十倍增,这时候用EXCLE难以满足经营管理需要,比如多人协作的数据登记工作、数据安全性无fǎX、无fǎ固定Xcāo作liú程等问题。

为了解决这个问题,小超市就需要一套采用ERP系统来满足企业资源管理的需要,才能使X有序、高效率的发展。

也就说,伴随着X量级的增长,企业都会在资源管理、客户X等方面出现X瓶颈,比如资源复用性低、效率差、liú程繁琐不可控等,这时候我们需根据X发展来确定问题或寻找机会来设计产品以支持发展战略。

那么我们如何确定问题or机会(目标)?

一类内部寻根,找到项目发起人深入沟通;另一类是外部溯源,有些项目的发起可能受外部环境影响,比如竞品同行、新技术趋势等等,这时我们需要找到参照物进行研究。

通常情况,我们都是根据数据反馈或者KPI指标来发现表象问题,接下来我们该如何找到问题根源并准确定义问题以及合理的解决思路呢?

01 对问题达成共识

1. 准确定义问题

首先我们自己要问题清楚定义,这里涉及到两个技巧。

第一、转换思维,即把未知解问题转换成已知解问题。比如朋友欠钱不还,自己追还不了,那么可以找到他的身份信息起诉,自己不会起诉不要紧,委托个律师就好了。X解决一些系列已知解问题来解决根本问题第二、追溯本源。问题经常会被表象掩盖,如果直接解决表层问题,不仅不能治本,还会带来其它方面的问题。

举个例子,在一个山脉内建了一条很长的汽车隧道,为了防止停电时隧道内发生车祸,交通部在隧道入口写了“进隧道前请打开车头灯!”的提示语。但是,不久后有司机投诉,由于隧道出口景sè太美,司机经常忘记关灯,导致返程时汽车没电了。

有人提出可以提醒他们出隧道时关掉车灯!那么我们思考问题解决了没?没有,因为在司机如果是在夜晚行驶(不同的时间状态下)时候会懵圈。

有人说那我们可以提示司机“白天,进隧道时打开车头灯,出隧道关闭车头灯;晚上出隧道时不要关闭车头灯!”这个方案弊端就是X太长,在高速行驶上,司机没有时间和注意力看完一段X。

那么,我们思考怎样根本上解决问题?案例中,我们对问题的因果最终推导是:车没电是因为司机忘记关灯,而忘记关灯时因为缺乏提醒。那么,解决方案在于我们要如何提醒且又能避免夜行司机产生误解呢?

X是提示“你的灯亮着吗?”,这便引导司X注周围明暗场景来决定自己的车头灯是否应该打开。

这个例子就是示范我们如何定义问题以及确定根本问题。

2. 找到问题的根本原因

(1) X工具分析

工具1:鱼骨图分析

鱼骨图属于定性分析,它有利于我们追踪到问题的根源,使分析人员将问题的原因放在首位,而不是表象,且能让我们概览导致问题发生的所有原因的全景图,这也为收X料和行动X全面可靠的指引。

具体实施方fǎ如下:

  1. 把第一步定义的每个问题都X做一次鱼骨图分析
  2. X头脑风bào只找原因而不是找解决方案
  3. 分类问题,确定问题归属的类型。比如常见的人机料fǎ环
  4. 如果某个原因属于多个类型,并这个情况多次出现,可以考虑新增问题类型
  5. 每个原因可以思考what-why-where三者来发展更细层级的原因
  6. 公开讨论所有原因的想fǎ和经验
  7. 寻找重复性高的原因(即多人提出的)
  8. 使用X表收X料、Xliú程图或进行客户X,X帕累托分析fǎ测试
  9. 各种原因的相对强度
  10. 投票制达成一致意见,缩小范围进行比对。

工具2:帕累托图分析

鱼骨图比较依赖于决策者的经验与洞见,外界一致是出于变化的趋势,为了能够更准确实时把握住根本原因,还需要结合帕累托分析。

它主要作用就是X2/8定律,去锚定影响问题的最关键根本原因,X有限的资源优先解决它。帕累托分析通常是根据问题发生的各原因从相对频率和大小从高到低降序排列的直方图,找到解决80%问题的20%原因。这里就需要我们去收集已有的产品数据及用户反馈进行分类zhēn对性地统计。

做个比喻,鱼骨图帮助我们找到解决问题的方向靶,帕累托图则是在靶子标上环数。

(2)确定相关人员与用户

在产品需qiú定义阶段,沟通最多的应该是对应X的高层人员,方向性决不能出错,此者是管理层,最后是基层cāo作人员。

对于产品的用户,我们切记要分类产品的直接用户,罗列各自的特点并分析,这指导着后续的需qiú分析。

(3)定义解决方案的界限

我们可以把产品的范围和边界区分开来。范围即产品涉及到的哪些功能和内容来支持X运转,边界则是产品与人的职责边界。

一个产品划分出子系统之后,子系统中所支持的liú程中我们可以切gē出边界,如何确定边界有三个因素需综合考虑。

首先我们会以经费、资源等作为考量因素,即多大能耐就做多大的事;

其次,对性价比、可行性方面的考虑,往往需qiú方出于同样的资源投入想获得更高回报的心理而认为所有需qiú都是最高优先级,即啥都要,这里我们需要从可行性、人力成本去传达哪些需qiú该做,哪些需qiú不该做,哪些先做哪些慢做,哪些能做哪些不能做,以此说服需qiú方。

最后,对边界的延伸与创新,则比较少见。它是基于特定战略或产品方向去做决策的,通常会把客户及客户行为xí惯等纳入产品的考虑范围,把Xliú程延伸到人的身边,提高X支持的便捷性,提高用户体验。

(4)确定解决方案的约束

我们在做设计产品时,不可能去X发挥,有时候基于产品特性、技术要qiú、外部条件等因素会做一些X,就不如建设一栋房子,想要建成什么样的房子,它就会受原材料、地基、土壤、经费、住宅建设X等条件的X。

软件产品的约束通常会分为技术开发与项目实施这两大类。技术开发:技术约束、预期的软硬件环境、预期的使用环境等。项目实施:项目预算、行zhèng约束、进度要qiú及资源支持、环境约束等。

02 需qiú定义产出物中的关键点

1. 目标

一个好的目标需满足SΜART原则,即满足具体的、可度量、可行的、相关性、时间X这五个要素。下表为例子。

2. 范围

在目标确定后,需qiú定义最主要的工作是围绕“范围”展开的,系统需要做哪方面的功能X才能支撑起X需要。

在范围的文档描述上,我们分别会产出系统的构建图、上下文关系图以及需qiú大纲,简称为“两图一纲”。

3. 相关人员与用户

需qiú定义阶段确定相关人员与用户的目的在于可指导我们在获取需qiú具体的执行工作,帮助我们了解这些X,提高产品的可用性。

通常我们会收集X与系统主题的相关经验、技术理解、工作态度、受教育程度、语言技能、年龄等等,即X的形象建模,其次是他们对产品的关注点或需实现什么利益。

4. 相关事实与假定

相关事实指的是当前产品所存在的问题,比如说原有的产品的人机交互上异常繁琐,导致效率低下。

假定指的是预估未来可能发生的X导致产品无fǎ应对,需列出假定X,避免现有的解决方案思考不周,导致做了许多无用功。

03 定义需qiú范围

前文已说明需qiú范围的产出物是“两图一纲”,而一般逻辑简单的系统出需qiú大纲即可。为了让读者更为明白如何cāo作,因此篇幅会比较长,后续笔者会做细致的分享。

项目的目标与范围就是指南zhēn,方向错了,那么后续的行为就丝毫没有正确可言,因此,我们要避免拍脑袋的事情,毕竟人总会有知偏误的时候,依据管理层的经验洞见不见得是准确,毕竟人脑中的“系统1”有时候会蒙蔽我们的眼睛。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 如何准确定义B端需求?先找到关键点 https://www.xiongfawang.com/2247.html

常见问题

相关文章

如何准确定义B端需求?先找到关键点-海报

分享本文封面