在跟負責直播課的產品負責人溝通護照的某個功能如何到達給用戶使用時，產品負責任人卻皺起眉頭說：“無法想象產品是什么樣子的。”為什么會出現這樣的問題？
1. 兩種截然不同的產品開發方法
之前團隊一直都遵循的流程是：產品經理整理需求，討論需求并確定要開發的功能之后，交付產品需求文檔給交互和UI出圖。然后再由技術設計架構，完成功能開發與測試并最終發布，即瀑布式開發。
瀑布式開發是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。
這樣的流程就不會出現上面的問題，因為在需求整理階段到交互以及設計出圖的過程中，相關方是全程參與并且清楚的知道用戶交互界面是什么樣的，并在這個階段針對不合理地方提出修改意見之后在交付技術開發。
但是這種產品開發方法無法應對在創業過程中產品是不斷變化的，耗費了大量的時間做出來的產品，發布之后才發現用戶不需要這樣的產品。一切推到重來，在這種情況下瀑布式開發這種方法付出的代價太高，基本上是不可行的。
我們需要保證產品盡早到達用戶，通過有持續的供給，獲得用戶反饋并進行迭代。
這也是我們選擇敏捷開發Scrum的原因，傳送門：
敏捷開發Scrum，一個教育創業團隊的嘗試
2.產品負責人和團隊對故事的理解不一樣
-
技術故事
技術故事指的是需要完成但又不屬于可交付的功能，跟任何故事都沒有直接關聯，甚至不會給產品帶來直接的價值。
由于技術故事不會給產品帶來直接的價值，所以從sprint會議開始小伙伴們都傾向于先完成一些可以看得見摸得著并且能交付給用戶使用的功能進行沖刺。作為開發人員，從心里肯定是很反感和抵觸的，因為在我看來Scrum Master根本不能對技術故事做出正確的權衡，并且技術上的東西在ta們的決策優先順序永遠都是最低的。
但是從創業的角度來看這個問題的話，也就能想通了。創業初期，產品沒有成型，寫業務代碼的情況占大多數。所以什么牛逼的架構，先進的技術、重構又或者安裝持續構架服務器等等都別扯。TM你的產品就沒人用，根本無法解決用戶的問題或者用戶拿來不知道怎么用，又或者操作比較麻煩，再牛逼的架構和技術也是扯蛋，更別談持續構建和重構了。
所以基于此，我也找到了平衡點。
盡量避免技術故事，把技術故事變成可以衡量業務價值的普通故事，保證持續到達用戶。
-
將故事拆分成若干小任務
故事是可以交付的東西，是產品負責人所關心的。任務是不可交付的東西，產品負責人對它也不關心。
比如：“ 作為孩子，我希望可以改變密碼、頭像、昵稱……以讓護照個性化。”
這樣的故事，我一開始認為是大家的理解肯定是一致的，理所當然的覺得不管怎么樣大家都使用了那么多的互聯網產品，這個功能全部都有，大家的理解肯定一樣。
但是做出來之后，小伙伴一使用。嗯？怎么樣是這樣的？默認讀取了我的微信用戶信息，不是可以改的嗎？我說你把微信的頭像和名字改了咱們護照不就自動更新了嗎？小伙伴們心里一萬個臥槽！
基于此，為了大家能更好的想象產品是什么樣子的，以及防止小伙伴們對故事的理解不一致。可以將這個故事拆分成任務的話可以分為：
- 用戶可以上傳 / 更新個人頭像
- 用戶可以增加 / 編輯個人信息
這樣將故事拆分成任務后，大家對于故事的理解基本上是能保證一致了。如果還有疑問的話，那也只能在白板手畫模型展示給小伙伴們看了。
