对于居品司理而言,“需求”这个词并不生分,聊到居品设计要谈到需求,聊到功能开发要谈到需求,聊到用户画像要谈到需求等等。居品司理所设计的居品被视为团结企业与用户(也包括客户,为便于领路,长入称为用户)的序言,团结的重要点就在于用户需求的知足进度和先后轮番,因此居品司理需要具备针对需求的知悉和经管才略。
一、需求界说
1. 基本界说
需求是指由需要而产生的要求,更底层的开首是东说念主的空想。比如因糊口的需要,而产生饱暖需求;因精神共识的需要,而产生外交需求;因想领有愉悦的厚谊,而产生听音乐的需求;因想自在出行,而有打专车而非坐地铁的需求等等。
需求无处不在,畅达于咱们的责任、生活每一个具体的场景当中。其实仔细想想,咱们日常的每一个决策、动作,都是基于需求在背后的推动,只不外对于那些不错快速决策和响应的行径,偶而咱们我方都感知不到,而那些需要破钞脑力、元气心灵和时分的行径,咱们才会有清亮的感知。这就波及到东说念主类大脑的“系统1”和“系统2”,本篇文章不作念详解,感兴趣兴趣的话不错翻阅丹尼尔·卡尼曼的文章《念念考·快与慢》。
2. 需求的合感性
从用户,即需求产生者的角度动身,需求长久是合理的。在莫得外力的威迫下,每个用户淡薄的需求都是基于自身主不雅效用最大化而产生估的。
即使算作又名居品司理,基于一些感性的资本和收益分析,认为用户淡薄的需求是分歧理的,也不行篡改用户站在其自身角度动身,所认为的该需求是合理的领路。
反过来念念考,居品司理认为用户的需求“分歧理”,亦然居品司理把我方与其背后的企业放在全部,从往常的资本、收益动身才有的判断,这自身也带有主不雅偏向性。因为居品司理有我方的需求:为企业发展带来效益、为居品规画更好的往常的需求。
咱们常说居品司理需要有同理心,其实说的是居品司理需要学会与用户“共情”,让我方站在用户所淡薄需求的具体场景去念念考用户所抒发需求背后的真实原因,何况要去感受用抒发诉求时的厚谊反馈。我面前在作念B端居品,银行客户是咱们居品的磋磨客户群之一,偶而跟共事聊到居品的自若性就经常会提到一个场景:试想又名柜台责任主说念主员正在匡助客户办理取钱业务,然而用咱们的居品时却总在重要时刻卡顿影响业务的正常办理,而客户又急需费钱。若你是这位柜台责任主说念主员,你会奈何评价你所使用的居品呢?当你招揽居品厂商的调研时,你会摄取什么样的反馈呢?
固然每个东说念主的成长阅历、生活环境、领路水平都会有所不同,居品司理难以对每个用户反馈的具体需求都作念到置之不理,然而对于那些我方认为分歧理的需求,其实更应该花时分去了解和挖掘用户淡薄该需求的更深头绪原因,这种方式也很有可能会给居品的发展主见带来不测得益。
3. 需求的互异性
用户其实并非就是天然东说念主,更真实的说,应该是需求的聚拢,只不外现时所接洽的居品大多半都是为天然东说念主而设计的,因此风气性的将用户领路为天然东说念主。但其实咱们也有好多居品是为其他生物设计的,比如为猫狗专门设计的饮食器等。
天然东说念主自身具有异质性的特色。
因此,针对并吞类需求,不同的用户之间也会存在互异。同样都是通过饮食来知足饱暖的需求,但有的东说念主偏向于辛辣口味,而有的东说念主偏向于酸甜口味。
放在互联网居品中亦如斯,比如音乐类的居品是知足用户的听歌诉求,但不同的用户对于听歌的音效喜好是不同的,有的可爱 live 场景,有的可爱音乐会场景,还有的可爱宽绰环绕等。
对于居品发展来说,基于需求知足的用户量袒护来计划,要优先明察用户的共性需求,这类共性需求是保证更多的用户使用居品的基础,不错为居品带来可用性价值。当居品逐步趋于谨慎,用户量足以撑持为知足个性化需求所插足的资本时,再作念共性功能的拓展或其他个性化需求的补全。
用户算作天然东说念主而存在,需求产生的配景是多种万般的,因此用户淡薄的需求并非是都不错已矣的,十足知足扫数用户的扫数需求的居品亦然不存在的。
4. 需求的周期性
如果以时分为维度,一年可分为四季、12 个月、365天,一天可分为 24 小时。用户在不同的时分所需要知足的需求是不通常的,就像对于衣着购买的需求,也会有旺淡季一样。对于各样居品而言,履行上亦然在提供劳动,这种劳动仅仅区别了传统委用形态,但目的仍是知足用户的诉求。
浅显例如,以天为单元时,用户对于消磨碎屑化时分的需求省略率会集结在 8:00-9:00、18:00-19:00 之间,其他时分可能忙于责任、陪同家东说念主、畅通健身等。此时,如果去不雅测居品的数据统计情况,日活跃度的时段散播亦然有剖析特征的。将时分周期放大到月、季度、年,亦然一样的风趣。再例如一款户外居品,在周末的平均活跃度高于责任日,在春秋季的活跃度高于夏冬季。
掌抓这些时分法规,不错匡助居品司理更好地了解用户使用居品时的各样景色条目,包括用户的内在情绪景色和外皮物理环境,进而能更好地设计居品,以知足用户需求。
5. 需求的不可已矣性
用户需求千千万,但真实不错被知足的需求是少量数的。好多需求注定是无法被已矣的,意志到这一丝很重要,固然听起来似乎有点狂暴。因为需求是用户空想的一种抒发方式,而空想是无尽的。
对于居品司理而言,即使有着要知足用户扫数需求的志在四方,也要意志到客不雅现实对于用户需求知足的放置性。
知足扫数用户的扫数需求并不是居品独一的得胜方式或测验法度,礼聘知足大多半用户在更常见场景下的基本需求,且提供精粹的居品体验,为用户带去主不雅效用的最大化,才是需要重心计划的。一步时势去了解你的用户,带领你的前进,稳当断念那些在现时条目下不可已矣或廉价值的需求。有些需求也许现时不具备可已矣性,但跟着条目的篡改(如新时间的出现、国度政策调理等),会让那些过往不可能已矣的需求成为可能。
意志到需求不可已矣性的客不雅现实并不是让咱们融合,而是为了让我方具备更感性的决策念念维。
以上都是对于需求的一些基本特色先容,了解需求的特色并采纳其实并不是一件容易的事情,因为这些特色看起来像是在给居品司理的责任制造壅塞:有些特色让居品责任无法规可循,有些特色嗅觉又让居品落地受到放置。
然而这亦然居品司理责任的乐趣之一,于稠密内在和外皮身分之下,不断摸索需求知足的最优解,为用户、为企业、为团队、为我方带来正反馈的均衡决策,是居品司理的价值体现方位。
二、需求麇集
了解了需求的特色之后,再来聊一聊需求的开首,需求的开首有好多,比如用户反馈的需求、运营部门的需求、研发部门的需求、指导的需求、竞品分析梳理的需求、也有居品司理自身领路所产生的需求等等,重心聊一聊用户反馈、表层指导和自我领路所产生的需求。
1. 用户反馈
居品因为用户自在为其需求得到知足,而付出对应的资本(财富、时分、元气心灵等)而存在,是以某种进度上不错说用户就是居品的“衣食父母”。非论是各样互联网居品,照旧电影、脱口秀、音乐、饮食等传统劳动,在交游模子上都是访佛的,因此居品或劳动的价值也就体面前知足用户的需求上。
用户在使用居品的过程中,都会带有我方的心智体验感受,这种感受会转动为厚谊体验,如自在、一般、不自在等。在不同的厚谊体验上,用户会有不同的反馈。以使用APP 为例,舒应时,用户可能会提高居品使用时长、购买升值劳动等;合计一般时,用户可能会反馈一些渴望增多的功能;发火时,用户可能会坐窝卸载 APP,以至还会去欺诈商店上给一个低评分。
对于用户反馈要增多的功能,仅仅其需求得到知足的一种外皮阐扬形态,因此居品司理需要严慎评审,更多的挖掘用户渴望增多的功能背后所荫藏的底层需求,一个高质地的用户反馈是居品司理可贵一遇的“矿藏”。
2. 表层指导
每个企业或团队中都有不同的岗亭和变装单干。在对行业领路明察以及居品主见规画上,表层指导时常不错给出相对更准确的决策论断,至少是全局条目下空洞计划更合适的,这是由指导层在行业信息掌抓进度和领路进度决定的。
只不外表层指导所提供的需求时常是比拟深广的一种想法、理念或磋磨,还需要居品司理将这些想法具象化,进而推动落地。
例如针对现时居品近况和磋磨,梳理出居品的发展道路图,凭据接洽阐述的道路图再进行居品的意见设计、详备设计等,直到最终不错转动为研发、测试、设计等共事进行责任的产出物。需要谛视的是,居品司理在进行居品具体规画的同期,还要计划居品的运营、市集推行、售后等扫数波及居品上线委用的全链条责任。
这是对居品司理全局视线的要乞降培养,坊间流传“居品司理是CEO的学前班”,亦然不无风趣的。
3. 自我领路
基于自我领路而挖掘或规画需求是最难的一丝,因为需要居品司理历久插足对于居品和行业的学习资本,且多作念名堂和操心复盘积聚,还需要个东说念主对居品的嗜好,插足心扉,最终酿成行业的居品领路体系,包括但不限于对行业的领路、对居品专科才略的领路、对资本收益评估的领路、对用户需求的领路等等。
从职场发展来说,自我领路的高下亦然居品司理的中枢竞争力之一。
当自我领路成体系酿成后,便不错换取居品的发展规画,也不错匡助用户去发现他们我方都未发现的需求,进而让居品赢在起初上。天然,除了上述需求开首,前边提到还有来自公司运营、市集、研发等部门的内在需求,也有来自对皆外皮竞品的需求等。至于何种需求才是具有生命力的,那就需要每个居品司理基于公司和居品近况和往惯例画作念空洞计划,需求自身的业务价值、插足的资本、收益反馈周期等,也都是需要计划的身分。
需求是用户与居品的团结点,对于需求的挖掘、分析、规画都可能径直影响到企业在市集竞争中的地位。
在了解了需求的基本特色和麇集之后,接下来最重要的事情就是需求价值分析,进而通过需求优先级和研发资源情况来进行居品迭代规画。
4. 场景化分析
“无场景,不需求”,需求都是在具体场景下产生的,因为用户生活在具体的场景当中。居品司理招揽到需求反馈时,最初要作念的就是明确需求所发生的场景。如果用一句话来需求,就是:什么东说念主在什么场景下需要用到什么劳动来知足我方的什么诉求。
对于需求的场景化分析,最好的门径就是到用户中去,例如对于外卖骑手来说,他们对于派单语音播报的音量大小风气,是坐在办公室中处于舒服念念考景色下的居品司理容易忽略的。
只须真切了解用户责任或生活的环境、消费风气、收入开首、外交关联等信息,才能愈加精确地纠合具体场景来分析需求价值,进而规画居品主见。
5. 用户故事舆图
用户故事舆图是用户在具体场景下为寻求需求的知足,所发生的一系列行径动作的旅途。当咱们想将麇集到的新址品需求全部已矣时,需要在史诗(无为是与特定扫尾密切有关的原始想法)层面进行多种已矣,史诗是一个大的故事,在敏捷开发中称之为“史诗故事”。对于史诗故事来说,已矣的资本和委用时分都更长,对于团队以及利益有关者来说并非是最好的。此时,不错拆分红许多小故事,拆分故事的颗粒度,最终成为一个又一个具体场景下的用户故事。
不外需要谛视的是,用户故事的斟酌法度并非是将功能浅显拆分,合理的用户故事应该具有顽固性、针对性、安逸性这三个特色。顽固性是指该用户故事有安逸的委用价值;针对性是指该用户故事只针对特定的用户群,确保劳动的磋磨用户对象清亮,多用户群的需求时常存在互异性;安逸性是指该用户故事不与其他故事相互依赖,不然无法进行委用。
用户故事舆图的重要作用就是让用户在具体场景下的需求变得愈加清亮,亦然最终居品委用时,用户对于使用居品来科罚具体场景下的需求愈加清亮。
6. 最小可行居品
将用户需求都纳入到不同的用户故事里,将大故事拆分红有价值的小故事进行安逸委用,也就是咱们常说的 MVP 居品(最小可行性居品)。
其实MVP 居品不一定是通过软件代码开发出来的运行在各样开采上的软件居品,可将视线扩张到其他行业当中,比如:在旅店行业,MVP居品可能是一套理睬来宾的快捷劳动进程;在餐饮行业,MVP居品可能是一套中枢上菜进程等等。
MVP的磋磨是在早期阶段考据居品的中枢假定,并得回用户反馈和市集考据,以便进一步创新和迭代居品。既考据需求的真实性,也考据居品有缱绻的知足进度。
在强烈的市集竞争中,霸占时分就是霸占市集,计划到插足资本和委用周期,企业为了后续决策的正确性,时常会礼聘先通过推出一个 MVP 居品插足市集,然后不雅测用户使用数据和反馈,用以校准下一次的居品决策。
非论是指导下发的计谋性需求,照旧用户反馈的场景化需求,抑或是运营部淡薄的居品营销行为类需求,都有其非常的价值,然而企业所领有的资源是客不雅稀缺的,无法知足扫数变装淡薄的扫数需求。
居品司理的价值体现之一,就是在空洞扫数身分之后,制假寓品的迭代次第,在插足产出比上创造价值。
7. 需求分类
对于所濒临的稠密事项,东说念主们无为会采选重要进击四象限来进行辩认,以此来制定事项处理轮番,更好地分拨元气心灵,确保空洞扫尾能达到我方预期。面对稠密纷纭复杂的需求,也不错采选同样的门径进行归类。经典的需求归类模子是 KANO 模子,将需求辩认为:必备型需求、渴望型需求、魔力型需求、无互异型需求、反向型需求,体现的是居品功能与用户需求匹配度的一种关联。
浅显地领路,必备型需求就是提供知足用户刚需的居品功能,如果莫得此功能,用户则会毁掉该居品,这是居品初期最需要关怀且插足资源去完成的责任。
渴望型需求则是用户有所期待的需求,当居品提供了知足该类需求的功能,用户对于居品的好感度会直线高潮。然而居品即使莫得知足该类型需求,在其他居品不具备同等功能之前,用户一般也不会离开该居品。历久来说,这是擢升居品继续竞争力的重要一环。
魔力型需求指的是用户自身也没计划到,然而居品司理基于我方的领路等身分,挖掘出了用户更履行的一些需求,并赐与了知足,让用户有一种“喜从天降”之感。用户也会因此成为居品的诚笃粉丝,并向其他非居品用户保举居品。无互异型需求指的是从用户侧来说,非论是否提供知足该类型的需求,都不会影响用户对于居品的使用和评价。开发此类需求,对于企业来说,是属于资源浮滥型插足。
反向型需求指的是破裂用户运行意愿,开发与用户在各场景下的需求相悖的功能,此行径最为不可取。
8. 需求品级
为了更好地将需求优先级赐与体现,还需要一些量化门径对需求进行象征, 常见的如P级制、 百分制、MSCW、高中低等。
P 级制是将需求优先级从高到低为P0、P1、P2、P3、P4 级 别; 百 分 制 是 按 照 100、80、60、40、20 等进行辩认;MSCW 分别代表 must(必须作念)、should(应该作念)、could(不错作念)、won’t(不会作念);高中低等则是最直不雅地将需求分为高优先级需求、中优先级需求、低优先级需求。对于居品经管来说,采选何种方式进行辩认象征不是最重要的,而是并吞个名堂团队里,对于所及第的品级辩认门径是明确且达成一致的。扫数的器具门径自身都没成心旨,只须使用者对其的使用创造价值,才为其赋予了意旨。学会优先级的辩认不仅适用于责任,同样也适用于生活。每个东说念主的资源、元气心灵、时分都是有限的,要学会“把好钢用在刀刃上”。
三、需求经管
麇集需求、拆分需求都是前置责任,居品司理还需要一些经管器具或者说门径来让麇集到的需求为后续的责任劳动。
1. 需求池
居品司理将扫数麇集整理的需求进行汇总归类、辩认优先级之后,需要进行长入的戒备经管,这就是总需求池。总需求池主若是为了幸免需求遗漏,不错从全局上空洞评估扫数需求的相对优先级,进而作念出更正确的居品迭代内容决策。
同期,每个居品都有我方的生命周期,需求是可继续性的,因此对于每次规画的居品迭代也需要单独戒备一个迭代需求池来经管。主若是算作这次居品迭代的需求限制而存在,与时间、测试等团队达成最终居品验收的一致领路。
对于需求池的形态,不错用市面上的需求或名堂经管器具来戒备,也不错通过线上表格等器具来经管,重心是便捷信息更新时可即时同步到团队成员。
2. 居品有缱绻
居品司理招揽到需求之后,时常并不需要坐窝伊始作念居品原型的设计。
扫数的需求都是为了知足用户的需求而存在的,而用户需求的知足不一定是通过功能的开发,也许通过一些劳动流的程创新也不错知足。
用户也可能会针对我方的需求,把我方放在居品司理的角度,提一些“竖立性”的居品功能设计有缱绻。就像之前张小龙说每天都有一亿用户在教他奈何作念居品一样,这些用户固然有我方的具体的使用场景,然而繁重一种全局不雅。同样的,这些居品有缱绻也许具有其参考性,但其参考的价值亦然倒推到用户为何有此需求,渴望我方的何种空想得到知足。
而居品司理要作念的是将用户需求与居品近况相纠合,寻找其最合适的衔尾点。
例如计划用户需求被知足的功能设计时,还需要计划该设计有缱绻对于居品已有架构的调理进度,这就波及到资本问题;可能还需要计划功能上线后,奈何作念推走时营,这就波及到功能的盈利问题等。
空洞而全面的计划用户需求,进而淡薄合理的居品有缱绻才是居品司理需要作念的事情。
3. 居品需求文档
一般来说,对于现时的互联网居品来说,以界面型需求居多,例如通过触摸屏点击来已矣交互,那就是波及到界面的。
天然也有些不波及到界面的,例如现时好多居品中的保举算法、排序章程等,不外这些算法章程之后,亦然通过界面展示给到用户的。
对于界面型需求来说,居品司理时常需要输出居品原型,也就是常说的居品需求文档(PRD)。
对于开发、测试等共事来说,最忌会的就是来自居品司理的“一句话需求”。
一份优秀的居品需求文档,应该是不错径直知说念开发、测试的责任,而不需要他们来反复找居品司理作念内容阐述的。
4. 低保真
对于居品司理而言,用来与开发、测试、设计等东说念主员进行需求评审的居品有缱绻采选低保真原型(即线框图)文档即可,其上风就是对于居品司理而言,不错快速将念念考的居品有缱绻具象化,进而与参与评审的共事快速对皆领路。
固然低保真原型文档不要求像高保真一样的“养眼”,然而也需要谛视最终呈现出来的效率,对于阅读者(开发、测试、设计等)而言,缩短他们的领路资本。
5. 居品需求文档
最初,对于界面型(即用户作念操作之后,与原先页面有互异之处的页面)的需求都需要通过原型来抒发。
因为由于每个东说念主领路不同,如果不直不雅地将扫数界面绘画出来,便会出现“一千个读者有一千个哈姆雷特”的情况,每个东说念主所设计的都不同,到最终居品有缱绻推行阶段,便举步维艰。
其次,专科的东说念主作念专科的事。
在设计低保真原型时,主题色采选是曲灰即可,目的就是不影响与居品司理配合的设计师进行居品高保真设计。
使用是曲灰进行低保真原型设计时,也要谛视颜色尽量长入,若采选万般各样的灰或者黑,最终的低保真原型呈现出来的效率也会欠安,建议每种面容最多界说两种,用于不同的页面元素上即可。
再者,在居品有缱绻设计时,还需要计划页面多景色的情况,例如对于电商居品的订单功能,需要计划有订单和无订单的景色;再比如对于升值劳动,需要计划用于购买了升值劳动和未购买升值劳动的情况等。由此产生的各样数据流转情况,也要同步赐与说明。
同期,还有一些“荫藏性”的需求,亦然需要在居品有缱绻中进行说明的。
例如存量数据的处理、排序章程的界说等,这些都是无法通过原型页面直不雅抒发出来的内容,然而对于居品的最终上线效率,具有举足轻重的意旨。
另外,这部分需求与时间可行性有关,居品司理可稳当寻求时间同学匡助,全部商议有缱绻,确保最终居品有缱绻可落地推行。
终末,亦然曲常重要的需求标注内容。
需求标注是对设计的居品原型的施展说明,就绝顶于是开发、测试等共事在履行责任推行中时的“居品司理代言东说念主”,承载着将居品原型对应的需求章程进行清亮明确的重负。
还有一些内容,如全局说明、配景先容、交互释义、展示章程等内容,亦然需要与低保真原型文档组合在全部,最终酿成一份居品需求文档,也就是常说的PRD。
6. 纠正记载
由于领路偏差的客不雅存在,居品司理最终用于需求评审的居品有缱绻时常都不是最终稿,而需要进行纠正。
为了让居品名堂组与居品需求文档有关的扫数东说念主员不错清醒每次纠正的内容,需要成就一个纠正记载模块,专门用于记载居品司理对于这次居品有缱绻的调理内容。
如斯,便不错在名堂组内保持信息的即时性。
团队在领路一致的基础下进行合作,对于责任效率、质地产出,以及团队的责任服从、契合度都是具有要紧意旨的。
居品司理基于需求,与研发等共事作念了初步接洽,设计出居品有缱绻之后,还需要组织名堂组有关东说念主员进行居品需求评审,进而鼓吹下一步的居品研发责任。
需求评审的磋磨是对需求内容达成一致领路,从擢升需求评审通过的角度来说,不错将需求评审分为三个阶段进行,分别是:迭代价值、业务进程、居品需求,是一个从宏不雅到微不雅的过程。
7. 迭代价值
从责任进程上来说,研发、测试、设计等变装都是依托于上游的居品司理需求来鼓吹责任的。某种意旨上,居品司理的需求迭代规画决定了他们的责任内容和强度。因此,若但愿扫数这个词名堂团队中的成员不错有用的进行居品的开发迭代,最初要作念的就是与团队成员明确迭代价值,从宏不雅愿景上达成一致领路。
常见的迭代价值如公司计谋规画要求、用户反馈的高频需求、B端客户反馈的高价值买卖需求、数据分析得出的居品优化点、新时间要素催生的买卖模式探索等。
将迭代价值与团队成员作念了明确,且得到认同之后,扫数这个词需求评审便已得胜了一半。因为计谋已定,而剩余的战术则是容易完成的事情。
8. 业务进程
版块迭代价值达成一致领路后,下一步等于对具体的磋磨下的业务场景和进程进行素质。
业务素质的目的是为了让有关东说念主员了解后续所素质需求的配景,而研发、测试等东说念主员都是具备较强的逻辑性念念维的,因此在作念业务素质时,不错提前准备好业务进程先容的内容,如业务进程图。
在素质的过程中,将具体的业务场景纠合多变装的进程流转进行说明,便不错将需求中枢功能逻辑素质明晰。
以至对于一些有教养的开发东说念主员来说,后续的页面样式、功能特色都在这个阶段都一经在心里有了个初步的雏形了。
天然,如果有东说念主员淡薄针对某些复杂的业务进程作念具体说明,也不错准备对应的任务进程图来补助说明,让扫数这个词进程素质愈加清亮。
业务进程与团队东说念主员达成一致领路后,终末的居品需求就是一个补助说明的作用了。
9. 居品需求
终末的居品需求主若是针对所设计的居品原型、需求章程等进行说明,也就是最终的具象化的需求。
这一阶段的素质是为了将前边的迭代价值、业务进程作念一个在居品阐扬层的说明,促进最终居品需求的落地。
对于居品开发迭代来说,最终发布验收的照旧居品功能、交互、元素展示是否与居品需求文档一致。居品需求文档亦然算作居品、研发、测试、设计等变装都独一共同认同的法度。
由于个体领路偏差的客不雅存在,需求评审偶而并不是一轮评审就不错敲定的,时常都会有一些留传待阐述内容。居品司理需要在评审会上进行记载,会后将内容阐述之后,从头同步有关东说念主员。如有必要,还要连续发起二次评审,确保将歧义内容都在迭代伊始之前进行明确。
作念好需求经管,用居品价值为公司的发展奠定坚实基础。