写出「完美的」需求永远是高不可攀、遥不可及的。《用户故事和敏捷方法》
前言
在 上一篇 我们讲到，每一个新产品的问世，都应该由一个 最小化可行产品 开始，逐步的去验证我们对于产品的种种 「假设」。在这个步骤中，我们实际上是在建立我们的第一个 反馈和验证 流程。
那么，从这篇开始，我们就来聊一聊这个流程里的东西。
开发 - 测量 - 认知循环
根据 《精益创业》书中的总结，这个流程应该是这样的：
- 一开始，我们对于产品有一些「假设」，基于这些「假设」，我们把产品 开发 了出来；
- 接下来，我们把产品交付给用户，观察和 测量 用户的使用，记录下相关的数据；
- 然后，我们根据用户反馈的数据，确认我们的「假设」是否成立，并据此修改我们的 认知 ；
- 最后，我们根据以上得出的结论，调整我们的「假设」，开始后续产品的开发。进入下一次循环。
需要注意的是，虽然流程的顺序是 「开发 - 测量 - 认知」，但实际开展工作计划时，我们需要进行逆向操作。
- 首先确认我们要获得怎样的 认知 ；
- 之后分析要通过哪些手段去 测量 ，才能得到这些认知；
- 最后考虑要 开发 什么样的产品才能得到需要的反馈数据。
了解了这个流程之后，我们就先来说一说 如何开发一个产品。
换一个方法试试
产品开发的过程，是一个由抽象到具体的过程。很多产品人在入行之后，都被教导过「要想把产品的工作做好，有这些必须要掌握的文档」。于是，越来越多的产品人埋头沉浸在文档的海洋里，开始四处找模版、套框架，很多人甚至根本没有想过，「文档的意义」究竟是什么。
由于产品的开发大多要跨越团队的多个成员角色，为了能够更好的与开发、设计、营销团队沟通，我们使用文档来进行记录。也就是说，文档只是一个「手段」，它们存在的意义，主要是为了能够更好的进行沟通。
只要能够达到沟通的目的，无论是使用怎样的「手段」都是一样的。
通过工作实践，我们很容易就可以发现「使用文档来进行沟通」有一些难以避免的弊端。
- 在和团队成员沟通之前，需要花费大量的时间和精力去撰写；
- 撰写文档时，为了确保其他人能够看懂，需要去考究格式、琢磨方法；
- 一个团队有一个团队的习惯，不同人有不同人的作风。之前定下的文档规范，下一次编写时还是会有人说看不懂，看不明白；
- 不管是因为不想去看，还是因为看不下去，总会有人对文档里写明的东西表示「我不知道」；
- 在沟通时总会发现有大大小小的遗漏和问题，需要对文档不断的进行维护和更新；
- ……
既然如何，我们为什么要执著于文档呢？何不换个方法试试？
今天我给大家讲个故事
用故事来代替文档，是一个可行的办法。
使用用户故事到底能带来哪些好处：
- 用户故事强调口头沟通
- 人人都可以理解用户故事
- 用户故事的大小适合做计划
- 用户故事适合于迭代开发
- 用户故事鼓励延迟细节
- 用户故事支持随机应变的开发
- 用户故事鼓励参与性设计
- 用户故事传播隐性知识
在开始阶段，我们可以快速的编写一些大的故事，对我们的「假设」进行相对具体的描述。这样，我们就可以让其他团队成员对我们要开发的产品有一个大体的印象。随着开发的进展，我们可以将那些大的故事逐步的细化，变成一个个长度合适的故事。根据这样的小故事，我们就可以更好的进行项目规划。
相比文档来说，故事更加易于团队成员之间进行沟通。我们讨论的不再是产品的特性，而是用户会怎么使用我们的产品，我们怎样才能使他们达成希望的目标。这样具体的主题，远比抽象的概念更容易理解和接受。
通过故事，我们不但可以让大家知道「我们要做什么」，也告诉了大家「我们为什么要这样做」。这有助于项目的推进，也更有利于集体智慧的发挥。大家从一开始就可以参与进来，共同完成我们的故事，而不是仅仅等待任务的分配。
同时，有了一个个具体的故事，我们可以更好的检验产品质量。经过故事的润色，我们可以不再费力的去理解各种术语，而专注于具体目标的完成情况。
用故事的方法，我们可以更好的进行产品的开发。接下来，就该对我们的产品进行正确的测量了。
