阅读用户故事地图笔记,联合技术,管理,产品的融合经验总结
- 用户故事不是另一种写需求的方式,讲述用户故事,在过程中用文字和图片相结合的方式辅助讨论,这是一种建立共识的机制.故事即流程.
- 用户故事也不是需求,他是一种关于问题解决方案的讨论,解决公司的问题,客户的问题,用户的问题,目的是我们对要开发的功能达成共识.同一份文档,阅读的人不同,得到的信息也不一样.
- 你的工作不是开发更多的功能,而是使那些投入精力开发的功能在成果和影响上可以最大化.
- 用户变得开心是因为在使用我们的软件或网站或APP,他们可以用不同于以往的方式做事,这才是用户感到开心的原因.
- 实际上,你的工作是改变世界. 最小化输出,最大化成果和影响
- 如果我们要始终把握好整体,就要在抓住所有细节之前,先走一遍整个用户故事."思路宽广,细节有度".
- 软件开发中的一个基本事实:像做得功能,总永远超出你来得及做的.所以我们是努力缩小产品范围,找出最小可行产品集,只做必要事
- 划分发布路线图,增量发布.为目标成果排定优先级,而非功能.排优先级,只有做和不做,"没有他就无法工作"就做,其他的都先不做.先跑通主流程. 制定优先级的秘密:(1)讨论业务目标,(2)目标用户的目标行为,(3)功能
- 最小可行产品(MVP), 指可以产生预期成果的最小产品发布.或指为了验证假设而做的最小规模实验.MVP(最小化可行性产品)快速搭建:搜狐快站
- 滚动波式计划,越近开发越详细
事: - 基于验证的学习:**开发-度量-认知循环:打磨产品.**一次性就把事情做对是一个冒险的策略,尤其在软件行业.不要假设自己总是对的,不然最后一定很失望.要先降低期望最小化试错,迭代.
- 最靠谱的估算来源于真正理解自己在估算什么的工程师.达成共识是估算的法宝.大的项目要拆分,细化有利于度量.谁最了解完成一项任务的时间,任正非说:"离战场最近的人".
- 多年经验总结:开发分支的迭代周期为两周最合适开发.产品的开发是增量的,迭代的.早期目的侧重试错,后期目的侧重微调.
- 讨论和会议的人数一般情况下限定在5人以内
- 如何讲好故事,关键靠套路(也可用trello管理电子卡片),模板就是:
- 管理就是平衡干系人需求的艺术.做个演好戏的导演.
- 不要太好说话,要有眼光,有定见,有远见.要和干系人一起做决断,果断抛弃对预期结果帮助不大的机会.要维护自己在他人眼中是专家的地位.
- 世界那么大,总有你不了解的东西,一定要设定截止时间,及时停止.
- 敏捷团队最大的抱怨之一是开会时间太长,大家一直同意,并不是达成共识,只是希望早点结束拖沓,折磨人的会议.
- 常见的问责:"你为什么不能一次性把事情做好呢?"时,我们要努力解释每周的推进与改善.
- 总结要记住:发布之后的改进最有价值.项目成功是 质量,时间,成本的平衡, 干系人的满意..
- 最后送给大家的是:软件从来都不会被真正完成.