在跟负责直播课的产品负责人沟通护照的某个功能如何到达给用户使用时，产品负责任人却皱起眉头说：“无法想象产品是什么样子的。”为什么会出现这样的问题？
1. 两种截然不同的产品开发方法
之前团队一直都遵循的流程是：产品经理整理需求，讨论需求并确定要开发的功能之后，交付产品需求文档给交互和UI出图。然后再由技术设计架构，完成功能开发与测试并最终发布，即瀑布式开发。
瀑布式开发是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
这样的流程就不会出现上面的问题，因为在需求整理阶段到交互以及设计出图的过程中，相关方是全程参与并且清楚的知道用户交互界面是什么样的，并在这个阶段针对不合理地方提出修改意见之后在交付技术开发。
但是这种产品开发方法无法应对在创业过程中产品是不断变化的，耗费了大量的时间做出来的产品，发布之后才发现用户不需要这样的产品。一切推到重来，在这种情况下瀑布式开发这种方法付出的代价太高，基本上是不可行的。
我们需要保证产品尽早到达用户，通过有持续的供给，获得用户反馈并进行迭代。
这也是我们选择敏捷开发Scrum的原因，传送门：
敏捷开发Scrum，一个教育创业团队的尝试
2.产品负责人和团队对故事的理解不一样
-
技术故事
技术故事指的是需要完成但又不属于可交付的功能，跟任何故事都没有直接关联，甚至不会给产品带来直接的价值。
由于技术故事不会给产品带来直接的价值，所以从sprint会议开始小伙伴们都倾向于先完成一些可以看得见摸得着并且能交付给用户使用的功能进行冲刺。作为开发人员，从心里肯定是很反感和抵触的，因为在我看来Scrum Master根本不能对技术故事做出正确的权衡，并且技术上的东西在ta们的决策优先顺序永远都是最低的。
但是从创业的角度来看这个问题的话，也就能想通了。创业初期，产品没有成型，写业务代码的情况占大多数。所以什么牛逼的架构，先进的技术、重构又或者安装持续构架服务器等等都别扯。TM你的产品就没人用，根本无法解决用户的问题或者用户拿来不知道怎么用，又或者操作比较麻烦，再牛逼的架构和技术也是扯蛋，更别谈持续构建和重构了。
所以基于此，我也找到了平衡点。
尽量避免技术故事，把技术故事变成可以衡量业务价值的普通故事，保证持续到达用户。
-
将故事拆分成若干小任务
故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。
比如：“ 作为孩子，我希望可以改变密码、头像、昵称……以让护照个性化。”
这样的故事，我一开始认为是大家的理解肯定是一致的，理所当然的觉得不管怎么样大家都使用了那么多的互联网产品，这个功能全部都有，大家的理解肯定一样。
但是做出来之后，小伙伴一使用。嗯？怎么样是这样的？默认读取了我的微信用户信息，不是可以改的吗？我说你把微信的头像和名字改了咱们护照不就自动更新了吗？小伙伴们心里一万个卧槽！
基于此，为了大家能更好的想象产品是什么样子的，以及防止小伙伴们对故事的理解不一致。可以将这个故事拆分成任务的话可以分为：
- 用户可以上传 / 更新个人头像
- 用户可以增加 / 编辑个人信息
这样将故事拆分成任务后，大家对于故事的理解基本上是能保证一致了。如果还有疑问的话，那也只能在白板手画模型展示给小伙伴们看了。
