为什么我们总是说不清「需求是什么」

在产品开发团队的我们,是否都遇过以下状况?

每天面对超多产品反馈、需求申请,花很多时间厘清、沟通?
参加无数的会议,冒出各种需求,发散的无边无际?
终于提出产品路线图,面对各方质疑,结果改到四不像?

这些收集、整理、协商需求的过程,是不是很令人头痛,又消耗我们宝贵的时间?不仅难取得共识,我们最怕的更是产出无法推动成效?

为什么需求描述这么难?


究竟卡在哪里?归纳出以下这几种状况:

状况一:描述需求时语意不清,没有厘清的过程,产生误会
状况二:针对相同的功能、接口、流程,因为每人代表不同用户,或遇到不同情境,提出互相独立的需求,产生冲突
状况三:针对相同需求,因为负责不同目标,或站在不同的解读角度,产生僵局

因为以上三种状况,导致我们必须反复沟通,消耗很多时间,也难以确立目标、推动成效。

举例 | 运营电商网站的团队讨论:如何优化商品详情页

状况一

市场 Abby:我们要提供更多商品照片,我看电商网站的时候最爱看照片了。

  • 语意不清:「商品照片」是指主商品的照片,还是相关商品的照片?为什么需要照片,能达成什么效果?
状况二

工程师 Bob:放大图片的接口也很难用,点击图片还另开分页,又不能切换图片。
图片设计师 Cindy:但我觉得是排版有问题,很难找到信息,令人生气,我朋友因此干脆不买了。
图片客服 David:可是 ,顾客说「商品评价」最重要,又说我们的评价功能很难用,不能筛选评价。

  • 情境差异:同样针对商品资讯页,在「什么情境」,觉得放大照片、或产品资讯、或商品评价,很难用?
状况三

市场 Eddie:我觉得最重要的是降低跳出率,因为这是站上流量最高的页面。
图片工程师 Fiona:我们不是有首购优惠吗?可以在商品页上强调,吸引顾客购买!
图片业务 Greg:对对对,卖家一直跟我说「优惠券功能」很重要,希望显示各种优惠,在商品旁边。
图片工程师 Henry:如果可以让顾客分享优惠给朋友,说不定还能带进更多流量!
图片市场 Iris:说到分享优惠,购物季要到了,可以完成「分享优惠」和「赠送购物金」的功能吗?

  • 目标或角度差异:同样针对商业需求有关的「优惠」显示,但各自期待达成什么目标?这些目标分别遇到什么挑战、哪些限制?

如何改进?


知道这些问题后,我们该如何努力,朝什么方向改进呢?

  • 面对状况一,我们希望:降低「描述需求」时「语意不清的情况」;
  • 面对状况二,我们希望:降低「沟通需求」时「被自身立场、情境侷限的情况」;
  • 面对状况三,我们希望:降低「提出需求」时「遗失或误会个别目标的情况」。

如果有一套语言结构,除了让我们朝以上方向改进,还能额外产生以下效果:

  • 减少建立方法时花费的时间或遭遇的排斥,融入现有方法,相辅相成;
  • 减少叙述需求时花费的时间,口头沟通时可浓缩成 3 句话,文字沟通时可浓缩成 1 页 A4 文件;
  • 减少依情境重置沟通素材所花费的时间,可以有弹性的重组、合并、拆分。

那是不是很令人期待呢?

为了介绍这个语言结构,我们先回顾一下「需求」的本质。

需求与设计的本质


引用 《设计思考怎么改变世界? 》的这段话:

设计就是「现况」到「目标」的过程。在这里我为了好记,简单的说,设计就是 A→B

如果我们认同以上这段话,那么反过来说:

因为「使用者处于一个情境」,进而「希望达成某个目标」,所以产生了「需求」

先有「产生需求的过程」,我们才能「捕捉需求」,并依据需求来设计。符合「需求驱动设计」的「用途理论」,基于一个重要的假设:

人是「目标导向」的行为者,而「情境」会影响目标,但「手段」并不会

为了捕捉、描述需求,我们基于以上假设,产生了各式各样的工具,都为了达成以下子目标:

  • (A) 降低团队「理解顾客情境」所「花费的时间」或「认知门槛」
  • (B) 减少团队「描述目标」所「花费的时间」或「误解的情况」
  • (C) 降低团队「沟通产品方案」所「花费的时间」或「误解的情况」
  • (D) 降低团队「验证方案」所「花费的时间」或「经济成本」

举例来说:用户旅程地图、用户画像、故事板、同理心地图、价值主张画布等等,多少都希望能达成以上子目标 (A)、(B)。而辅助产品设计与开发的工具中,PRD、用户故事、用户流程图、线框图、流程图等等,都希望能达成子目标 (C)。

若我们野心更大,希望达成子目标 (D),则需要众人通力合作,进一步导入原型图、可用性测试、A/B测试等方法。

然后我们就发现,这也是一个「工具氾滥」的时代。我们有「上千种工具」,协助我们厘清「上万种需求」,听起仍然让人无奈?在工具氾滥的时代,我们如何抓取「团队有限的注意力」,传达最重要的信息?如何给一个有效的摘要,快速复盘上次的阶段成果?有没有通用的框架,可以串连众多工具?

终于,我认识了「用途理论」,以及一套精简的「结构化语言」工具。

结构化语言工具


工具一:任务规格书 Job Spec
工具二:任务故事 Job Story
工具三:期望成果 Desired Outcome

简单的来说,我们可以这样运用三个工具:
口头沟通时,先传达期望成果,再用任务故事补充,厘清目标和顾客需求;
短文沟通时,以期望成果任务故事开头,放在 PRD 或产品/功能提案中;
长文沟通时,把期望成果任务规格书融入现有的研究报告中,搭配 UX 工具箱中「浓缩研究成果的图表」,图文并茂、相辅相成。
在期望成果、任务故事、任务规格书中替换相同内容,善用三者类似的结构,快速重组、合并、拆分。

下一期,小编将继续为大家详细介绍这三个工具,并进一步说明他们的神奇之处。

本文作者: Jason HOU
文章来源: Medium


>> LigaAI 往期精彩阅读 <<

技术分享 | Javaer 如何做单元测试?

敏捷实践 | 做优先级排序时使用最多的三个模型

故事点数vs工时,研发工作量到底怎么算?

译文 | 四张画布教你判断「产品开发优先级」

产品经理该如何确定优先级?

了解更多敏捷开发、项目管理、行业动态等消息,关注我们的团队博客或点击 LigaAI-智能研发协作平台,在线申请体验我们的产品。