产品经理在业务领域中的通用语言

编辑导语:在产品经理的曰常中经常会听到这几个词:需qiú、场景、故事、用例,那这几个词到底是什么?又有什么作用呢?估计很多小伙伴会有一些疑问,本文我们就来聊聊这个事情,希望对大家的曰常工作中有所帮助。

一、背景

首先我们看下这几个词的具体定义,nòng清楚这几个到底是什么东西。

需qiú这个词,在经济学有一个明确的定义:一种商品的需qiú是指,消费者在一段时间内、在各种可能的X水平下、愿意而且能够X的该商品的数量。

显然这个定义和我们在做产品的过程中的需qiú定义差异甚大,但对这个定义往下钻时,我们可以获得以下两个衍生概念:“动机”、“需要”。

  • 从心理学的角度很好地理解“动机”:动机是由一种目标所引导的,激发和维持个体活动的内在心理过程或内部动力。
  • 心理学中的“需要”是什么:需要,是人们X内部的一种不平衡的状态,表现在人们对内部环境或外部生活条件的一种稳定的追qiú,并成为活动的源泉;这种不平衡状态包括心理的和生理上的不平衡。

仔细分析这两个概念,我们发现与我们曰常中对“需qiú”的理解比较接近;由此,我们可以对产品曰常工作中“需qiú”的概念能够有更全面的理解:用户X商品的数量、使用产品的意愿、用户的动机、用户的需要我们都可以使用需qiú这一概念进行表达。

我们再来看看场景,从百度中我们找到场景的定义:场景,指戏剧、电影中的场面,泛指情景。

影视剧中,场景是指在一定的时间、空间(主要是空间)内发生的一定的任务行动或因人物关系所构成的具体生活画面;相对而言,是人物的行动和生活X表现剧情内容的具体发展过程中阶段性的横向展示

对场景的定义主要用于影视行业,在X行业逐渐兴起后场景一词在IT团队中也越来越“时髦”;任何一个用户需qiú一定要找到用户场景才能发挥价值,没有场景的需qiú绝大多数都是伪需qiú;而在描述场景时,我们一定要清楚:什么时间什么地点发生了什么事,人物心情怎样,接下来他X什么,会有什么动作,为了达到什么目的。

接下来我们看看用户故事,用户故事描述范式:作为一个<用户角sè>, 我想要<完成活动>, 以便于<实现价值>;用户故事就是从需qiú/场景中提炼出who、why、what三要素。

最后我们看下用例的定义,从百度获取的定义:是软件工程或系统工程中对系统如何反应外界请qiú的描述,是一种X用户的使用场景来获取需qiú的技术。

Use Case的定义是:在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。

用例这个概念本身是在软件工程中产生的,其核心是对用户和系统的交互过程的描述,一个用例能够清晰的表达用户使用一个功能的完成过程,包括:功能描述、步骤、前置条件、后置影响、特殊需qiú、异常处理等。

在对以上的概念做了初步整理后,我们再来看看这些概念如X实际工作中进行使用。

二、在B端产品工作中如何使用

X行业的重心从消费X逐渐向产业X转变,在产业X时代X与传统软件逐步进行融合,在企业中B端产品X越来越复杂、架构也越来越复杂、参与系统建设的人员范围也越来越广泛;如何高效的在这么复杂的环境中进行有效沟通显得极为重要。

而在这种环境中产品经理是作为需qiú方和IT团队的纽带,如果把产品岗位负责的X进行领域划分大体可分为两个大的领域:需qiú域、实现域。

  • 需qiú域需要解决的核心问题是X产品方向的正确性,包括:调研、收集需qiú、培训、产品理念宣导等;
  • 实现域需要解决的核心问题是高效、正确的把产品实现出来,包括:需qiú分析、评审、验收等。

产品经理在X领域中的通用语言

在把产品的工作分为两个大的领域后我们在不同的领域中进行沟通时需要使用大家都可理解的通用语言,在于需qiú域中的各个角sè开展X时 我们需要从需qiú、场景的角度出发;而在实现域中我们则需要使用故事、用例进行说明,以达到系统被高度实现出来。

在于X方进行沟通时,大多数X方不具备IT经验,其无X解系统背后的实现逻辑,只能描述自己在实际X开展的过程中遇到的问题,或者是基于自己的经验、见识而提出的解决方案;这种解决方案往往只是X方短期遇到问题而想要,是否是其X的需qiú还有X证。

但不管怎么样,这些问题、解决方案就是我们最常见的X方表达需qiú的形式;在处理需qiú时我们最好的方式就是尽量全面、完整的记录X方的表达内容,包括X语言描述出来的或未描述出来的(X方需qiú产生的环境、提出人的工作背景以及提出人所处X的情况等);对于需qiú我们最重要的要qiú是能够准确的表达用户的想fǎ,至于想fǎ是否正确、如何去解决者都不是需qiú本身需要去解决的。

在拿到用户的需qiú之后,我们即进入需qiú分析的环境,不管用户提出的需qiú是问题还是解决方案;在这个环节我们都不需要关心,我们需要X场景去还原用户的需qiú,我们需要知道用户是在什么时候、什么地点、什么情况下产生的需qiú,并且能够对客户的预期进行分析,设计对应的反馈机制。

一个需qiú往往能够分解成若干个场景,但哪些场景是X存在的、哪些场景是臆想出来的则需我们以曰常观察、工作经验、对用户的分析以及对竞品的分析为基础才能够判断出来;但即使做了充分的分析还是有可能抓不到X的场景,不过不要紧X不断试错、不断的调整我们肯定能够找到X场景;场景是对需qiú的转化,让需qiú更加的具体,以叙事的方式进行更细节的描述,场景是由产品经理输出能够让用户无障碍的了解需qiú中的细节,如果场景中有过多的X术语、有很强的逻辑推理则不适合。

需qiú更多的是客户提出的,场景则是产品经理经过一定的分析后对需qiú进行chāi解后的内容——这两部分内容的核心目是让我们能够和用户达成一致,确保产品的方向的正确性,X我们投入资源实现出来的产品或者功能是客户真正想要的;在和用户确定了需qiú、场景后我们就可以对其进行更加细节、X的分析了,把让用户能够理解的语言转化成让IT团队能够理解的内容,以让团队成员能够实施、落地。

首先我们需要用到用户故事,用户故事是有严格的格式要qiú的:“作为一个<用户角sè>, 我想要<完成活动>, 以便于<实现价值>”;它是以能够实现某种价值(用户能够获得效用)为标准去定义一件事的,不能交付价值的X是不能称之为一个故事的;这样表述的好处是能够让我们清晰的知道这个故事要解决的实际问题,为了解决这个问题我们需要设计一个或若干个产品功能(对应的就是要完成的活动),而用户则X使用这些功能就能获得预期的价值。

但一个完整的用户故事除了以上这些内容外,我们还需要清晰的定义设计的功能的验收测试标准,我们需要从正常、特殊、异常等不同情况下进行验收测试的定义;验收测试能够让我们清晰的定义出用户故事是否被完全开发完成,也能够让团队中的开发、测试同学更全面的理解故事,减少信息的不对称性。

X以上这些内容我们能够大体把要实现的需qiú表达的比较清晰,但以上这些还不足以让我们最终开发出一个完整的系统,我们最终需要X用例的方式把功能规格进行详细描述,在用例中我们更多是站在系统的角度考虑若何逻辑严密的把系统功能实现出来,我们需要考虑数据liú程、功能结构、页面交互、信息呈现等方面的所有内容。

系统中不会无缘无故产生数据,要不是人对系统进行了cāo作,要不是指定了规则让系统能够自动运行,那从数据的角度看我们任何一个字段能够产生值一定是有X触发,我们需要对这些X进行描述。

一个系统如果在功能结构、页面交互、信息呈现这几个方面设计的很糟糕,就像我们开车走到一个昏暗且指示标记十分混乱的停车场;即使停车场设备再先进、车位再充足,司机也是难以感受到、享受到这种功能和X,只有以符合用户使用xí惯的方式进行设计最终才能让用户方便、快捷的使用系统完成任务、享受X。

三、总结

X需qiú、场景、故事、用例让我们实现了“从用户来、到用户去”的过程,产品经理最重要的工作之一无疑是沟通;而我们要实现高效沟通,则必须要让团队在同一领域中使用X的通用语言,只有如此才能够让大家尽量做到无障碍沟通,实现信息最大化的传播、liú通。

以上的这些内容则是笔者对团队X的通用语言的一个整体想fǎ,希望能够对大家有一定的帮助。

#专栏作家#

不可分类者,微信X号:中台产品,人人都是产品经理专栏作家。专注于电商中台的产品设计,擅长产品规划及需qiú分析;热衷于研究中台、SaaS等领域的最新产品形态。

本文原创发布于人人都是产品经理,未经许可,jìn止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

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

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

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

雄发创业网 自媒体是如何赚钱的 产品经理在业务领域中的通用语言 https://www.xiongfawang.com/1391.html

常见问题

相关文章

产品经理在业务领域中的通用语言-海报

分享本文封面