产品经理的日常主要工作就是与需求打交道,如何能够快速准确地洞察用户或客户的需求,让功能直击用户痛点是很多产品经理的愿望。而笔者就发现,利用用户故事,可以有效帮助产品经理解决产品需求策划的问题。

  前段时间看了一本书《敏捷软件开发:用户故事实战》,顾名思义,整本书大概讲的是在敏捷软件开发中,如何运用用户故事来开发和迭代客户需求。

  “故事”在百度百科的定义是:通过叙述的方式讲一个带有寓意的事件,或是陈述一件往事,侧重于事件发展时的描述。应用到软件开发流程中,用户故事,就可以理解为是叙述用户在使用软件功能时的过程。

  整本书所表达的思想就是:如何在敏捷项目中用用户故事思维做产品开发。所以,用户故事的方法适用于敏捷项目。

  换句话说,针对产品需求和目标明确的敏捷开发项目,使用用户故事更有益于开发出符合客户需求的功能。

  目前个人在实际产品工作中,处理需求的过程,会经常涉及需求场景梳理,看完本书后,感觉用户故事的一些思路和方法,有助于日常需求场景的梳理。下面就结合书中的理解,说说用户故事在实际开发过程中的流程以及使用方法。

  通过梳理识别该需求的用户,然后针对该需求角色进行用户角色建模,简单讲就是通过先发散再收敛的方法识别初始角色,然后聚合分类、去重,最后形成几个典型的用户角色,同时抽象出对应的用户画像。

  根据整理出来的用户画像,梳理各用户角色的用户故事,编写用户故事的过程其实也是发散到收敛的过程。

  如果公司有客户拜访和调研的条件,可以直接与客户进行沟通,那用户故事自然相对客观;如果不具备客户访谈的条件,那就只能发挥场景想象力来头脑风暴了。

  此阶段主要是评估用户故事,对梳理出来的故事清单进行评估,主要针对故事的理想实现时间、复杂性以及对于团队和客户的价值等方面。

  评估时可以赋予每个故事一定的估算值,来客观显示这些故事点的重要性。此阶段故事评估时使用的估算值,既可以排优先级,还可以估算速率。

  在创建发布计划时,需要确定故事优先级和迭代速率。优先级评估的方法和评估需求优先级的方法类似。书中讲的四种评估优先级为必须要有、应该有的、可以有的、不需要有,当然这不是随便决定的,而是根据故事评估阶段每个故事的估算值来排序,同时结合估算的迭代速率,即通过计算估算值来决定每次迭代多少个故事点。

  验收测试阶段主要测试发布的故事有没有完成,书中建议是最好客户可以参与验收,但实际对于大多数公司来讲,是不具备这个条件的。

  除讲述运用用户故事贯穿整个开发流程外,本书还顺便提到了技术开发时,可以使用结对编程,可大大减少返工率,并最大程度优化代码架构。

  总之,本书中描述的开发流程与互联网从0-1的产品开发是有区别,因为是敏捷开发项目,因此流程是建立在产品需求和目标明确的前提下,没有需求挖掘的过程,直接通过调研和规划用户故事的方法进行计划迭代。

  产品经理的日常主要工作就是与需求打交道,如何能够快速准确地洞察用户或客户的需求,开发的功能直击用户痛点是很多产品经理的愿望。

  平时在分析需求时,大多按照需求的三要素,用户/角色、场景、任务路径来梳理目标用户的核心需求。

  可产品目标用户的真实需求,往往就诞生在真实的业务场景里,这点体验在B端产品里尤为明显。因此接到需求后,在进入功能策划阶段之前,梳理完善的、核心的场景就显得至关重要。

  C端产品通常都有几个典型的用户画像,B端产品也不例外,也可以梳理出来自家产品对应的几个典型客户画像。

  按照2/8定律,虽然这几类典型的用户/客户可能只占全部注册用户的20%,但通常可以覆盖产品中80%的功能,或者说可以贡献产品收益的80%。永乐国际app

  梳理完核心场景后,再将核心需求从场景中提炼出来,此时的需求应该就是最接近用户/客户的真实期望了。将场景用文字描述出来,可以整理成表格清单,便于后续整理。

  产品需求在一定程度上可以理解为故事,用户在描述需求时,其实就是在描述用户期望的使用场景,可以理解为用户是在叙述他是在何种情境下,通过/使用何种物质,如何完成某个行为的。

  但我们在提炼出需求的时候,往往有很多一句话需求,关于这个需求的细节无法很好地体现出来。甚至很多需求点不一定就是功能点,往往需求只是目的,达到目的的方法却不止一个。

  因此就需要通过用户故事的方法来细化需求场景,便于充分拆解当前的需求,同时也有利于充实用户场景,在需求策划阶段的决策更有依据,功能设计也更加全面。

  确定目标用户画像和核心使用场景后,在策划具体功能之前,应梳理用户在使用该功能时的场景,然后以用户故事的形式罗列出来。用户故事可以用于针对某个需求功能做计划和提示,有助于充实使用场景的细节。后续可对用户故事清单进行优先级排序,用于决策哪些用户故事应该优先被实现。

  独立的:每个故事尽可能相互独立,相互依赖的故事可以合并成一个更大但更独立的故事;

  对用户或客户有价值的:是客户真正关注的,可以真正解决用户问题,满足用户需求的故事;

  可估算的:用于后续产品开发进行工作量估算,必要时要拆分故事点,便于项目管控;

  小的:单个用户故事尽可能可以被量化和评估,保证每个故事尽可能小,便于穷尽故事细节。

  了解了用户故事的价值和特点后,以“115”产品中的记录功能做个示例,当我们从核心场景中提炼出一些需求点后,就需要进一步将这些需求点展开,便于后续需求规划和原型策划。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。