21天敏捷打卡-用户故事地图

标签：方法   打卡   工作   构建   手写   计划   为什么   博客   传统   

     上图是基于敏捷故事的一个看板或者说敏捷流程中的一种，没有什么比亲身投入的效果更好。用户、组员需求方通过自身的投入、表达以便于让团队成员更加了解其想法和统一组员的想法。用户故事是一种思维，通即故事思维，运用故事的元素进行思考和设计，解决问题、达到某种效果。用户故事设计中核心是通过故事传递信息，引起共鸣，决绝问题。

     讲故事不是一个简单工作，需要优秀的组织能力，清晰的表达方式，达到听众清晰明了我们想表达的。这里笔者建议，如果平时和人交流的时间太少，可以通过书写博客等方式，组织自己的中心思想，让听众知道我们要表达什么。

    产品在设计中，容易偏向几个极端：1.领域专家；2.用户、需求方，3.偏向研发方。偏向领域专家那么产品的使用门槛太高，无法普及，偏向需求、用户产品过于算乱，没有聚焦性（用户有可能不知道自己到底想要什么）；偏向研发方产品可能会出现水土不服。

这时，就需要一群人：客户、专家、用户、研发等在一起，定义和提问，产品要面对的场景是什么？通过产品可以解决那些问题？产品能给公司带来的回报率有多高？为用户带来什么价值？产品的开发，用户的需求会很多、很多，像是一个庞大的地图，而”用户故事“擅长聚焦构建晓得特性，专注小的细节，通过上节课的例子就可以看出，不同的公户故事块容易出现不相匹配的产品部分，所用，有一种新的方法”用户故事地图“出现了；

通过地图可以解决以下问题：

1. 让我们更容易看清pro backlog的全貌；
2. 为新功能筛选和规划优先级提供了更好的工具，帮助我们决策那些backlog放入TODO；
3. 便于使用头脑风暴和其他协作的方式产生用户故事，即如何在故事作坊中更有效的产出；
4. 帮助我们更好的进行增量式的迭代开发，还记不记得，上节课中”必须有、应该有、可能有、不会有“这几个概念？
5. 为传统的项目计划提供了一个更好的替代工具，从被动到主动参与的转变；
6. 允许我们从不同的维度进行项目规划，并确保不遗漏每个不同的想法，避免独裁式。

如何创建故事？

1.前期准备：

召集几名产品核心人员，最好是奇数，方便做决定。从用户、产品经理、业务分析师、架构师等组成，因为每个头衔都代表了项目项目中主要角色的看法，所以创建的故事地图后，来以后的全体计划中可以避免许多不必要的辩论。准备白班、电子手写板、各种贴纸、胶带、咖啡、烟、打火机和一个相对独立的办公室。

2.整理创意框架

定义和提问，产品要面对的场景是什么？通过产品可以解决那些问题？产品能给公司带来的回报率有多高？为用户带来什么价值？

统一答案，把明确的目标写在便利贴上，按照优先级排好顺序。*这一步很重要，一定要让每个人都回答；笔者经历过，调研一款产品时，所谓的需求方（公司内部人员），专家给的答复是不知道，你自己想办法搞定。产品上线后，马后炮的人们就来了，集团会之中这些”专家“的建议就来了.....相当的苦恼，还好几个大客户比较认可，总算啪啪啪打了某些人的脸，出口恶气。

3.刻画用户画像

参照之前写的文章，不过多介绍；

4.从最重要的用户入手，编写大故事，注意不是史诗类型的。

5.深挖、深挖细节：从用户画像的角度入手，例之前的”叶海龙“厂长，他系统中，基于某个流程，他会最什么？是否还有其他的选择？符不符合他的使用习惯？问题出现时，他希望、他会如何处理？

6.划分MVP发布计划：为什么要划分MVP？思考一下。

21天敏捷打卡-用户故事地图

标签：方法   打卡   工作   构建   手写   计划   为什么   博客   传统   

原文地址：https://www.cnblogs.com/atun/p/12088658.html