Please enable JavaScript.
Coggle requires JavaScript to display documents.
User Story Mapping, 思考，讨论，记录, MVP Minimun Viable Solution 最小可行产品, Output 和…
User Story Mapping
User story mapping 使我们专注于用户和用户体验，产生更好的沟通效果， 最终做出更好的产品
对于我来说， 我的用户是谁？怎么能专注于用户和用户体验？
我的用户有两个，conti 的管理团队和最终客户
怎么做？ :question:
从左到右讲故事
自顶向下拆分细节
怎样 正确的撰写User story
User Story 的目的是达成共识
有了详细的User Story 并不代表达成共识
User Story 应当包含一切有助于达成共识的素材，比如图片，比如Videos 。。。。
好的User story 必须包含图片和其他一切有助于达成共识的信息
最重要的不是我们在文档（User Story）里记录了什么， 而是我们在看到文档（User Story）的时候，想起我们曾经达成的共识
卡片应该使用动词短语
用户故事地图做到什么程度？以能够支持有效沟通为限（达成共识）
要让所有团队成员都清楚（共识）
怎样正确的使用User story
错误的使用User Story
用户故事聚焦于构建小特性， “只见树木不见森林”
这一点和 mindmap很像，看完一本书不知道讲什么，把mindmap画一下思路就清晰很多。感觉mindmap 跟 user story map很像
过于关注细节，容易迷失
什么时候可以发布产品， 完成开发？不清楚
过于专注于验收条件，对做什么取法一直的理解
错误的撰写User Story
追求细节清楚，可验收，可以评估developer 的产出
我觉得这是错误的用法
User Story 是用来沟通的，而不是用来衡量developer的表现和产出的 :red_cross:
Scrum Point 的本意是什么？ :question:
该不该使用scrum来评估 成员的表现？ :!?:
追求细节清楚，可以验收，是对团队成员不信任的结果。
如果真的不信任，没有必要呆在一个团队里，没有必要组成这个团队，
失去了scrum “拧成一股绳”精髓
:tada:
PO的困惑
怎样跟stakeholder 沟通， 对产品达成一致，对目标达成一致。 :question:
好的用户故事讨论的为谁做和为什么要做，而不仅仅是做什么（YangMing：这对应SMART原则中的R）
PO的要务：最小化输出，最大化成果和影响 :!:
对于我来说，输出，成果，影响是什么
输出，每天的工作报告 -- 要最小化
成果： 产品
影响：信誉
ticket 完成率
交付质量
用户故事地图是什么？ :question:
用户故事地图，就是在讲大故事的同时进行拆分
用户故事地图，是一个模式，一种使团队对整个产品或者整个特性达成共识的模式
正确使用用户故事
思路宽广，细节有度
聚焦于故事的整体，不要过早陷入细节
卡片应该使用动词短语
当开始细化用户故事的时候，会发现细节越来越多，产品特性越来越多，造成需求蔓延
需求蔓延，这个说法或许是不正确的，今天发现的“需求”总是存在的。 今天不发现，明天就会发现。早发现总比晚发现好。
早发现是“需求” 晚发现是“坑”
细节越来越多，“需求”， “特性” 越来越多，下一步就是优先级排序。
发现细节了，发现需求了， 优先级排序才是有效正确的。
聚焦系统外的预期成果来决定系统内需要什么功能。根据客户需求来决定内部需求，（内部需求的优先级排序）
聚焦于成果，即产品发布后，用户能使用和感知的东西， 切分发布计划应该以成果为导向
聚焦于特定的目标成果，是排定开发工作优先级的秘密。
思考，讨论，记录
边讲边记，不要让讨论蒸发掉
通过写卡片或者便签来具体化你的想法
你在讲话， 别人在点头，但这并不代表别人已经完全听懂了你在讲什么。
讲故事之前先打个草稿
一边思考一边记录
当我专注的听别人讲的时候， 他们讲的内容会激发我的产生新的想法。轮不到自己发言的时候，会憋不住打断别人（不好的行为），憋着这些想法不说，自己便无法专心听别人讲。这时候需要把想法先记录下来 :!:
MVP Minimun Viable Solution 最小可行产品
错误的看法： MVP是粗拙的产品。 :red_cross:
可产生预期效果的最小产品发布（方案）
最小可行产品是为了验证假设而做的最小规模的实验
Output 和 Outcome
Output 输出
如果一个文档不能让我我们想起什么，那么这个文档就是一个output （无效输出）
Outcome，成果，有效输出
文档作为输出，如何使其成为成果
文档
最重要的不是在文档中记录了什么，而是我们在阅读文档时能想起什么
文档一定要有有效输出 :red_flag:
文档是用来备忘的
User Story
User Story 不是另一种写需求的方式， 讲述用户故事，在过程中使用图片和文字辅助讨论，这是建立共识的一种机制
用户故事不是需求， 用户故事是关于问题解决方案的讨论，目的是我们要对开发的功能达成共识
PO的工作不是更快的开发功能，而是使那些投入精力开发的工作能在成果和影响上最大化
一个好的产品经理
努力说服你，而不是简单粗暴地说 “上面就要这么干”
共识
不仅告诉你做什么，还要告诉你为什么这样做
SMART 原则中的 R
同意你关于一些细节的建议与修改
