如何将产品需求转换成技术开发能听懂的语言

为什么预先知道不确定程度很重要?

假设三种情况(大部分产品开发过程中都会经历这三种情况)。在每种情况下,我们产品团队都需要进行数据跟踪,以便更好地了解用户的注册情况并最终提高注册转化率。让我们看看当我们改变不确定性的程度以及改变处理不确定性的方法时会发生什么。

方案1:确定环境中的执行

比如:创业公司新开发一款APP,通常会将注册量作为指标,而作为产品负责人,我们就需要分析分析每一个用户行为以提高注册转化率。一般有经验的产品经理,都会对提高注册转化率有很丰富的经验。能分析跟踪数据并从中提出有价值的见解的看法。

根据以前的经验,我们对所涉及的步骤具有相对的把握,并且对任务将花费多长时间有了很好的了解。如果CEO表示,他希望在两周内完成注册数据跟踪。我们会制定了一个相当详细的计划,并非常准确地估计需要三个星期。我们可以证明为什么需要花费额外的一周,并且可以对CEO承诺在一定期限内完成任务。

由于整个项目的不确定性较低,因此我们产品团队可以立即开始工作。去实施注册数据跟踪,并在截止日期之前完成注册转化的渠道分析。

我们实现了目标并为公司创造了价值。我们与管理团队建立了信任,这不仅仅是因为我们达到了目标而已,还是因为我们在达到目标的过程中,展现了对时间的把握。我们创建了一个计划,该计划可以用作管理团队的可靠锚点,以跟踪团队朝着正确方向的进度。

总的来说,预测未来是困难的-但上述情况并非如此。

为什么?

因为不确定性较低,我们知道所有不确定因素以及如何确定成功,我们可以对实现目标需要交付什么以及何时可以实现做出正确的预测。结果,我们团队无需花费大量时间去探讨该如何进行工作。

当面对不确定性的程度很低时,我们很容易朝着自己的目标迈进。

方案2:不确定环境中的执行

当我们很少或根本没有完成任务的经验,会发生什么?在这种情况下,我们无法确定地说出涉及哪些步骤以及将花费多长时间。

当CEO要求您在两周内完成注册数据跟踪时,我们会感到有压力,因为要遵守这一期限,我们首先要写连自己都不确定的需求,然后将其交给开发工程师,工程师很有可能也难以理解这个需求。

然后随着截止日期的临近,我们意识到自己不会成功,然后就拼命的去熬夜试图挽救这个项目,我们会对现在不可能完成的任务感到沮丧和愤怒,士气低落。

最后,不仅注册数据跟踪分析的不完整,而且CEO也会不高兴,我们也失去了团队的信任。

我们可能面临高度不确定性,这可能是由于缺乏经验或技术知识所致。但是致命的缺陷不是我们缺乏经验,而是缺乏需求分析,没有评估需求的时间周期。相反,我们应该提前进行需求分析,至少要检查技术可行性,而不是直接从执行开始。

如果产品目标更加复杂(例如要我们改进百度的搜索结果,使用户获得更相关和个性化的结果)会怎样?

在这种情况下,也许没有人真正了解用户想搜索什么。或者没有人知道如何构建一个可以为数百万用户进行个性化的搜索引擎(技术可行性的高度不确定性)。这项工作可能要花费数月甚至数年,而且如果执行不当,没有产生实际效益,很容易打击人的信心。

方案3:在不确定环境中先进行需求分析

让我们探讨在执行阶段之前,面对不确定性进行需求分析时可能发生的情况。

我们回到团队,并对我们期望的数据进行用户分析的讨论。团队中的每个人都有机会发表他们确定的事情(从过往经验中)和不确定的事情(没接触过)。

然后,我们开始写下认为对实现目标至关重要的所有假设。根据重要性和不确定性程度评估假设。

我们会很快发现产品可行性是最大的未知因素,对成功至关重要。但是我们对如何为移动平台实施注册数据事件跟踪了解得很少。因此,我们决定进行产品调整,这大约需要一周的时间。

四天后,我们团队已经对产品可行性有了很好的了解,因此我们估计可以在三到四个星期内达到目标。

我们将其传达给CEO,团队便能够按照承诺实施注册数据跟踪。

这一共花了四到五个星期,但是每个人(无论是领导层还是团队)都对我们的处理方式感到非常满意。

这对我们的日常生活意味着什么?

注册数据跟踪是一个简单的示例,但是我们可以将相同的思维模型应用于所有目标。如果我们面临太多不确定性,则不应该直接开始去构建产品解决方案。

相反,应退后一步来了解不确定性的根源,并做出相应行动来证明是为了实现我们的目标。

在产品管理中,我们将这些行动总结为需求分析。在最佳情况下,我们可以将不确定性降低到可以开始构建解决方案的水平,来使我们更接近实现目标。或者,我们找不到任何理由来证明可以实现我们的目标的时候,可以在没有大量投资的情况下尽早停止。

这两种情况都是成功的,可以节省团队宝贵的时间并减少挫败感。

总而言之,不确定性程度决定了我们是否可以直接进行产品开发,还是需要先退后一步进行需求分析来证明我们可以进行产品开发。能够识别处于低不确定性或高不确定性的环境,对于实现目标的成功和效率有很大的不同。

评估不确定性并采取正确的措施

评估不确定性程度的一些实用策略和减轻风险的策略。

不确定性规则

不确定性规则的目的:帮助我们评估最大不确定性的地方。

马蒂·卡根(Marty Cagan)在他的《启示录:打造用户喜爱的产品》一书中谈到了四种不同类型的风险:

  1. 价值风险–人们会购买/使用它吗?
  2. 可用性风险–人们可以弄清楚如何使用它吗?
  3. 可行性风险–在我们现有的技术条件下,能否成功开发出产品?
  4. 商业可行性风险–解决方案能否创造商业价值?

在确定要开发产品之前,问问自己这四个问题,是否已经足够清晰。

如果我不知道所提出的解决方案对用户是否有价值,那么我需要进行需求分析以更好地了解用户所面临的问题以及他们真正的需求所在。

如果从用户的角度来看我不知道所提议的解决方案是否可用,那么这也会造成不确定性,在开始构建解决方案之前,应该通过可用性测试来解决这些不确定性。

实际上,对这四种风险的思考会引发了很多更为详细的问题,这些问题有助于量化我们在开发新的产品时面临的不确定性程度。这些详细的问题构成下面的问题。

请记住,这些问题会根据我们当前的目标去调整程度,而不是一成不变。

尝试回答每个问题,并以1到10的等级对我们的确定性进行评分,其中1表示“我对这个问题有100%的把握”,10表示“我只是在猜测”。可能永远不会百分百确定任何事情,所以我们将收集大量的定性或定量数据来支持我们的主张。我建议我们不仅要给问题打分,还要写下详细的描述-描述用户或用户群,即我们要解决的确切问题。

如何处理计分的分数?

如果我们和我们的团队将每个答案标记为3或以下,则表明我们对自己的方向具有高度的确定性,可以开始进行产品开发。开发过程中我们能仍然会发现新的问题,但是我们需要一边调整一边去适应它-这就是我们使用诸如Scrum的敏捷方法的原因。

标记为4或以上的答案表示我们应该进行需求分析以减少不确定性的地方。在此阶段,最好找出正确的做法,而不是致力于结果。

一旦确定了需要进一步理解的地方,就需要引入另一个变量条件:影响程度。

我们可以把评分为4或更高的每个问题都可以视为假设(因为不确定)。

如果我们仅有一个假设,则可以跳过引入这个变量,直接进行实验。但是,如果我们确定自己面临的不只是一个假设,则必须优先考虑最关键的目标假设。通常,产品创建过程中假设的优先级为:用户->解决方案->资金->规模。

假设我们已经确定了在做正确的事情方面不确定性高的两个方面–最重要的用户利益和所建议解决方案的可用性。

谈到对当前目标的影响时,我们觉得至少在产品初期过程的这个阶段,确保用户利益比可用性更重要。因此我们觉得用户利益的影响很重要,而可用性相比而言就没那么重要。所以让我们填一下影响程度的分数:

接下来,将我们的假设绘制在下面XY轴上,其中x轴描述对目标的影响,y轴描述我们面临的不确定性量。我们的示例如下所示:

如何决定需求分析与产品开发

在着重于可用性假设之前,我们应该着重于证明有关用户利益的假设。通常,我们应该从不确定性和影响都很大的地方开始。

有了一个优先级的假设列表,可以将其用作设计和进行实验的起点。

设计和进行实验

下一步是将我们的假设按照优先级转换为实验。根据假设的性质和业务环境,实验可能会大不相同。我们要经历很多最佳实践,从用户研究,到灰度测试,到可用性测试等等,都需要一步步的来。

回到我们的案例,那么现在的目标是设计一个经济高效的实验来降低实验风险。该实验应通过收集数据点来增加我们的信心,并使我们清楚地制定出最重要的用户利益。然后,可以关注可用性问题以及如何创建一个新的具有成本效益的实验,以降低围绕该假设的实验风险。

同时要为自己设定个具体的时间周期,例如:两周后,希望收集足够的证据以继续进行此工作。这在可以进行大量生成实验的早期阶段特别有用。设定自己的时间周期,去评估为一个特定的想法需要投入多少时间和精力。

我们可以并且应该在必要时重复执行所有三个步骤,尤其是当我们拥有新问题时。但是,一旦我们对所有重要因素都建立了足够的清晰度,就应该开始提供产品解决方案。

我很喜欢这样的一句话:“在做设计的时候,最大的阻力不是用户相关问题,而是内部的认知、利益点、看待事情方式的不一致。”;尤其是在推动产品及交互需求落地的过程中,感受最为深刻。对于一个产品或者交互老司机来说,内部推动需求落地没有任何问题;但对于刚入行的新人来讲就有点困难了,由于之前的没有或者缺乏此类经验,因此,经常会在推动落地需求过程中遇到各种阻力;比如,跟需求方及开发同学沟通不畅导致的撕逼等等;为此,笔者将通过自身实例来跟大家分享下,我是如何推动产品及交互需求顺利落地的。

一、设计流程介绍

由于公司还处在一个创业的阶段,对于设计流程的设计更倾向于简单高效;主要流程包含:需求收集、需求列表、需求设计、需求开发及最后的需求验收;迭代周期为两周一个版本,整体的节奏还是比较快的,再整个需求执行过程中也是采用一个瀑布加任务并行的方式进行设计方案的推进,只有这样才能按照迭代周期稳步前进,下图为我们处理需求的整个流程:

二、需求收集筛选

1、需求收集

就需求收集的重要性我就不多讲了,不管是做产品或者交互都要收集各种需求,来确定产品迭代的方向;所处的公司或者团队不同,收集需求的方式也不近相同;我们收集需求的方式主要有以下几种,其中最主要的方式还是通过数据收集用户反馈

  • 高层决策:也叫老板需求,主要来自于公司高层的战略决策;需求方包括CEO及各个部门的主要负责人;这个不多做解释,大家都懂;
  • 数据收集:通过APP内的数据打点以及借助数据分析平台来分析用户行为,得出具体的优化点或者突围点。对于数据收集,它是一种有效及靠谱的方式,但是对于中小型团队来讲,去做大亮的用户调研及原始数据积累是一件很难的事情,时间和财力成本都很高;所以适当的借助第三方数据分析平台是个很好的选择,准确又高效;
  • 用户反馈:用户反馈其实是一个很重要的需求收集入口,包括应用市场评论、APP端意见反馈及核心用户私聊等方式;
  • 种子用户群:对于一个有着一定用户群体的产品来讲,种子用户群的建立是必须的;我主要是通过建立QQ群的方式,来集中收集用户的反馈及意见;

2、需求筛选评估

通过以上方式将需求收集之后,接下来会对这些需求进行筛选确认,过滤掉一些伪需求;我对于需求筛选的维度包含这么五个,包括:业务目标、性价比、重要度、影响用户数及真是与否。需求筛选之后,会将最终的需求放置在需求池中,一般需求池中存放四个版本迭代的需求,这样就不会在产品迭代过程因为需求不确定而手忙脚乱。

  • 业务目标:对于公司来讲业务目标永远是最要的,尤其是创业公司;当然要在用户第一的基础之上了;
  • 性价比:做一个需求再公司内部还是要考虑自身承受的极限的,要考虑时间、技术、人力及推广成本等等,尽量做到以最少的资源消耗达到自身产品的目的;
  • 重要度:一方面要考虑公司的业务目标,另外也要考虑用户的需求;至于那个最重要要视具体情况而定;
  • 影响用户数:这个维度对于有很大用户量的产品来讲,是很重要的一点,尽量避免影响的用户的范围扩大;
  • 真实与否: 有时候我们通过用户反馈或者其他得到的需求不一定都是真实的,还是需要二次的评估;

三、需求设计评估

需求评估结束之后,就进入到了需求设计阶段;在这个阶段要完成产品方案的设计,最终产出高保真原型图及需求文档。

1、参与者及产出

  • 产品经理:产品要输出产品流程图或者简单的页面结构图;
  • 交互设计师:交互要根据产品提供的流程图或者简单的页面结构图,梳理出产品的信息架构以及根据需要产出具体的交互动效;
  • UI设计师:UI根据交互原型输出最终的视觉稿,也就是用户最终看到的界面;待设计稿评估完成之后,设计师根据要求将界面切图标注;

2、交互文档细节

为了使开发人员能方便的开发,我们将产品、交互及视觉文档整合在一起输出;所以文档为高保真原型加产品及交互逻辑的集合,这样我们的技术人员只需看一个文档就可以了,能有效的节省沟通成本,提高开发的效率。对于交互文档,一定要细致将各种逻辑细节表述清楚,其中包含以下几个方面:

  • 页面布局:顶部标签栏、中部内容区及底部操作栏的功能释义,操作路径、显示样式等;
  • 手势及转场:操作功能或者界面用到的手势有哪些,例如左滑、右滑、上滑、下滑等;还有转场细节,比如左移入、右移入、上移入、下移入等;
  • 反馈效果:输入反馈、点击反馈、弹窗逻辑、错误反馈、刷新等;
  • 页面跳转:也就是转场逻辑;
  • 元素的规则定义:关键功能、关键信息等;
  • 其它细节:缺省页面、成功/失败状态、加载方式、刷新方式等;

出了以上通用的交互细节外,还是有就是动效文档的细节了,因为平时也会遇到交互动效的输出;所以,动效细节的标注也是蛮重要的,具体包含以下几个细节:

  • 动效名称:比如摇晃、哐啷、跳跃、弹跳等;
  • 动效参数:动效时长,一般以毫秒为单位;是否延迟,延迟多久等;
  • 触发逻辑:什么时候触发动效及多个动效出现的顺序等;

四、需求开发验证

开发结束之后,还要对需求进行验证/验收;我们验证的方式有以下三种:

  • 测试部门测试:这个环节当然是必须的,是保证需求顺利上线的重要一环;
  • 需求方测试:在测试部门测试的时候,需求方也会介入进行业务逻辑、产品逻辑、交互逻辑及视觉展示的测试;参与的有:产品、交互、UI、运营、市场等等;
  • 种子用户内测:在以上方式结束之后,会进入用户内测阶段,将最终的方案打包发给用户去体验,发现问题,然后进行修复;

等到用户内测结束之后,所有问题都修复解决了,才能最终发布上线,这样我们能保证整个的方案是可行的,用户在使用的过程中不会出现大的纰漏。

五、需求管理及开发沟通工具介绍

其实,在整个的需求落地过程中,用传统的方式管理需求和跟开发协作有点低效了;因此,我还是觉得使用协同工具比较方便高效,不论是管理需求还是跟开发沟通。对于这个问题我就不多说了

结论

创新意味着不确定性,但是适当地管理它会带来很大的不同。能够识别我们要处理问题的不确定性程度,可以使我们更加成功和高效地实现目标。如果现在将整个案例简化为一种产品原理,那么就是这样:如果我们面临的不确定性太大,请从需求分析而不是产品开发开始。

我希望这种结构化的方法对我们有所帮助,并在需要决定是开始构建产品,还是退后一步以找出适合我们的用户和企业的建议时为我们提供一些帮助。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3092.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息