概述
软件从来都不会被真正完成，软件开发的两个真理：
- 想要开发的功能，总是比你能投入开发的资源多
- 加快开发速度并不能解决问题
- 聚焦于系统外的预期成果来决定系统内需要什么功能
- 排列优先级：聚焦于特定的目标成果，以产品发布后用户能使用的感知的东西切分发布计划
- 以成果而非功能排列优先级
- 最小化输出，最大化成果和影响
干系人优先级模型：
- 差异化功能：显著区分于其他竞争对手的功能
- 搅局功能：针对竞争对手的差异化功能
- 降成本功能：降低组织运作成本的功能
- 基础功能：进入市场竞争所需要的基础功能
最佳解决方案来自于需要解决问题的人和有能力解决这些问题的人彼此协作。我们在一起讨论用户故事，力求对要解决的问题达成一致理解并努力找到可以解决问题的最佳方案。
使用敏捷方法和故事，需要做到在每几周一次发布的同时，对产品全貌保持健康的理解和讨论。用户故事地图是一个模式，团队对整个产品或整个特性达成共识，将大的用户故事进一步拆分。
- 使用用户故事的目的并不是为了写出更好的故事，而是为了达成共识
- 用户故事不是需求，关注的是解决方案
- 用户故事之所以叫故事，因为它是要讲的而不是要写的
- 边讲边记,避免讨论蒸发掉
- 产品开发的目的也并不是开发出产品，而是为了解决问题
- 共享文档并不代表达成共识
- 达成共识：沟通各方对彼此所想的内容及要解决的问题达成一致的理解
- 更有效的达成共识的方法是通过视觉呈现，通过讨论和碰撞，调整每个人的想法，形成一致的理解
- 最重要的不是文档中写了什么，而是我们在看文档时想起了什么（讨论中的细节、过程）
- 好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么
- 共享文档并不代表达成共识
MVP并不是粗糙的产品，而是可以产生预期成果的最小产品发布。最小可行产品是为验证假设而做的最小规模的实验，MVP=“最小”+“可行”。
产品发现
理解假设出发并验证它们，从客户和用户面对的问题，到形成对应的解决方案。所做的每一步和开发的每一个功能都有一个明确的目标。验证性学习策略是精益创意思想的核心理念之一。
- 这个大想法到底是什么？
- 客户是谁？哪些公司会采购?
- 用户是谁，采购的公司中，哪些人会用到该产品，他们会用它来解决什么问题？
- 购买和使用的动机？解决了哪些客户和用户当前无法解决的问题？使用之后能获得什么样的收益？
- 为什么要开发这款产品？如果开发出来并获得成功，公司会得到哪些收益？
对产品故事的首次讨论应聚焦于如何具象化产品的机会。
- 理解现状
- 清楚要解决的问题
- 清楚要解决哪些客户和用户的问题
- 清楚自己心中的方案只是假设
- 验证性学习：产品发现不是找一些东西来开发，而是学习我们是否在开发正确的产品
- 验证问题：验证产品要解决的问题是否真的存在
- 与交互设计师等一起做调研、访谈
- 在设计原型过程中学习
- 描述场景
- 线框图等描述想法，具象化解决方案
- 原型和用户测试，验证产品方案的价值
- 在开发过程中学习：最小可行产品实验
- 做只解决特定问题的比最小可行产品更小的产品
- 每次发布都是一次实验，验证并学习改进的方向
- 迭代至可行
敏捷计划和交付
艺术家和作家以迭代的方式工作，建筑工人以增量的方式工作。要运用迭代思维持续评估和打磨产品。
迭代的两重含义：
- 重复同样的流程
- 评估和改变：运用增量思维做加法，不止增加新元素，同时修正原来的
产品不同时期的计划策略：
- 开局策略：聚焦于必备功能和用户步骤，重点关注技术挑战和风险，所有开发只要满足跑通主流程就好
- 中局策略：补充周边功能（主流程之外的可选流程），开始测试非功能需求（性能、扩展性、可用性）
- 未局策略：打磨发布，更高效更完美，关注生产环境中的真实用户反馈
计划过程：
- 达成一致：故事地图要做到能够有效支持沟通的程度
- 团队所有成员达成一致的理解
- 团队成员需要能够指出设计方案中的问题和改进点，并对工时进行估计
- 成功估算
- 最靠谱的估算，来自于真正理解自己在估算什么的工程师
- 达成一致的理解是成功估算最大的秘密
如何创建故事地图
三级方法定义用户故事：
- 高等级的使用步骤
- 分解步骤为每个用户的角色对应的活动
- 细分活动为具体的用户故事：作为<角色>，我想要<功能>，使得<价值>
用户故事的3C原则：卡片（Card）、交谈（Conversation）、确认（Confirmation）
让故事生效最重要的两个事情：
- 使用文字和图片相结合的方式辅助讲故事，达成共识
- 不能只谈论开发什么功能，要关注于哪些用户会用，为什么这样做就能以最小投入获得最大的产出
用户任务：描述用户如何使用软件达成他们的目标的动词短语，构建故事地图的基本模块
细节、替代、变化和异常，构成故事地图的主体。写故事地图的步骤如下：
- 分步骤写出故事
- 使用目标层级的概念，可以帮助汇总小任务或分解大任务
- 组织情节
- 故事地图通过自左向右的叙事流来组织
- 补充情节
- 探索替代故事
- 提取故事地图的主干
- 活动组成故事地图的主干
- 切分地图，找到达成特定目标需要完成的任务
故事地图六步法：
- 厘清问题。用户是谁，带来什么价值？
- 构建全景图。广度优先，而非深度
- 探索。向深度拓展，使用画像、原型和实验不断优化解决思路，尽量改变和完善故事地图
- 制定发布策略。聚焦于业务目标的达成和目标用户
- 制定学习策略。通过假设与验证，使用故事地图和讨论，发现风险，不断学习真正对用户有价值的东西
- 制定开发策略。去掉所有不必要的东西后，根据实现的先后顺序，将最小可行方案进一步切分。早期需聚焦于关键技术问题和开发风险
如何把故事讲得更好
故事真正的价值不来自于卡片上写的内容，而在于我们在讲故事过程中所能学到的东西。
- 不要把大故事切到大计划中，把大故事切小，做小计划
- 缺点：每一块看起来和最终的交付物都不太像;为了组合起各块，需要做一些重写和适配工作
- 好处：迟早暴露风险，尽早试用;尽早开始评估和学习
- 从用户角度看，大小规模恰当的故事，是一个可以满足某一需要的故事
- 对话是拆分故事最好的工具之一
- 组建一个核心团队来协助产品负责人，包括用户体验专家、设计专家和技术专家
- 一定要避免“甲方-乙方”反模式，结局必然是多方共输
- 提升故事地图的更新频率，可以使故事地图更好地反映项目的实际情况
- 在故事地图中增加风险故事，以管理风险
提升讨论效果的检查单：
- 讨论用户角色
- 讨论要做的功能
- 讨论为什么
- 讨论软件之外的东西
- 讨论异常情况
- 讨论问题和假设
- 讨论更好的解决方案
- 讨论方案如何实现
- 讨论开发周期
故事卡片上通常包括如下信息：
- 简短的标题
- 描述信息：who,what,why
- 故事序号
- 估算、规模或预算
- 优先级
- 度量
- 依赖
- 状态
- 日期
用户故事地图可切分为三个部分：
- 跑通整个流程：得到一个端到端可用的软件，用于发现技术风险
- 完善产品：接近于可发布的标准，发现性能、稳定性等“可以预计的不可预计因素”
- 进一步打磨产品特性，使其接近于完美
机会探索
针对机会展开对话，可以讨论五个方面：
- 它们的对象是谁
- 我们正在解决什么问题
- 我们的构想是什么
- 我们为什么要做这个
- 开发时间大小的再估计
使用机会画布考察产品机会：机会评估模板
用户旅程地图是用户参与主要活动流程的图形化展示，需要将每一个机会都加入这份地图。检视用户参与的每项活动以及这项活动的频次，发现用户喜欢和抱怨的地方，发现用户痛点和产品完善点。步骤：
- 一份容纳所有内容的地图
- 对每件事提出问题
- 设定场景
- 排练
- 重建地图
- 疼点和收获
- 观察
- 收获
探索不是开发过程，而是一个学习的过程。在此过程我们询问和回答类似下面的问题：
- 我们正在解决的问题是什么？
- 什么解决方案对公司有价值？对客户购买和接受产品有价值?
- 有用的解决方案看起来是什么样的？
- 在时间和资源限制下，开发哪些是可行的？
机会探索过程：
- 同理：亲身体验你想帮助客户解决的困难
- 聚焦：聚焦于一个或多个问题并加以详细阐述
- 形成想法：针对问题构思若干个可能解决方案
- 制作原型：制作简单的原型进行探索，得出最好的解决方案。制作有一定保真度的原型，让用户可以评价方案是否真的可以解决他们的问题
- 测试：检查方案有没有真正解决用户的问题，并根据用户反馈不断迭代和完善
机会探索的4个核心步骤：
- 从业务角度来组织想法：提出一个待探索的产品想法
- 理解客户和用户，搞清楚怎样才能帮到他们：选择可以从该想法受益的人
- 轻量级的用户画像
- 组织画像
- 用地图描述用户目前的工作方式
- 把自己的解决方案呈现出来：利用这一产品想法创建一个案例集，创建地图和旅程
- 使用地图呈现解决方案
- 将用户界面可视化，力求建立对解决方案的共识
- 简化并计划找到最小化的可行方案及其具体开发方式
- 如果保留下来的想法超出扔掉不用的想法，就说明探索工作可能没有做对
- 可行意味着对特定商业策略、目标客户和用户都是成功的
优先级评估注意事项：
- 避免先为功能设计优先级
- 要先为特定的业务目标、客户和用户确定优先级，然后再为他们的目标确立优先级，最后才是功能
- 我们大多数时候是错的：“交付垃圾越快，得到的垃圾就越多”
在精益创业中，学不到东西通常才是最大的失败。精益创业思想的产品设计过程：
- 从猜测开始
- 找出可能有风险的假设
- 设计和一发一个小型测试
- 测试客户和用户，以便进行度量
- 重新思考解决方案和假设
可采用金鱼缸协作模式，避免强制沟通导致的逆反心理
参考
版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆