mvp方法如何准確採集產品需求

㈠ 產品思維（4）利用MVP快速解決用戶痛點

MVP(Minimum Viable Proct)最小可用產品，創業前期資源有限，經常會有很多創意因為這個而夭折，在有限的資源和市場極大不確定的情況下，利用MVP驗證產品需求是否存在，市場是否能夠接受，是否能夠創造盈利。

MVP讓我們能夠去試錯，不停的驗證，不停的優化，找到最大的用戶爆發點，將痛點挖掘出來，痛點是核心需求的直接體現。

在很多產品經理剛開始的產品設計中，經常將產品設計的面面俱到，而運營起來找不到重點，找不到定位，首吵很多app都是因為這個導致的用戶流失。

在殘缺與可用性之間找到平衡點是最關鍵的一步，那就利用排除法，最好在猛芹讓用戶調研後將不必要的功能去除，盡可能用手動替代程序開發自動處理的功能，減少用戶決策與填寫。

在知道用戶的痛點之後，要繼續深挖需求，快速迭代，和枝局做市場業務類似，發現一條渠道十分有優勢，不斷的制定策略，完善細節，專攻實現業務量爆發式增長。

在實現過程中，技術所需資源上，前期盡可能的使用第三方組件、框架、平台，先輕資產，不要將眼光放的太長，驗證最後才不斷把核心競爭力攥到自己手裡，減少依賴的風險。

㈡ 如何藉助「敏捷開發」快速實現MVP

在敏捷實踐體系中，迭代交付模式是敏捷開發的核心要素。敏捷開發方法有很多，Scrum提供了迭代管理和持續改進的框架，如圖5-15所示。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。

圖5-16 用戶需求列表（產品功能需求）

步驟2. 召開計劃會議和制定開發計劃（計劃版）

Scrum Master負責組織召開計劃會議，產品經理和團隊一起根據需求的重要性、開發量來確定開發優先順序，做工作量預估，制定迭代開發計劃（從需求列表中挑選出高優先順序 Story（用戶需求）[張樂飛3] 作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog（迭代代辦事項）[張樂飛4] ）。開發團隊一旦接受這些開發任務，就應該准時完成，不得修改交付標准。

步驟3. 執行迭代計劃（任務板）

首先，你需要確定每次Sprint（開發沖刺）[張樂飛5] 的周期，短的周期可以更頻繁的發布產品版本，因此可以從客戶那裡更迅速地收到反饋，修正錯誤。這個周期一般為1~4周，當然，你可以根據團隊成熟程度或迭代任務確定一個合適的迭代周期，比如2周。這樣可以讓開發人員更投入地工作。

所謂Sprint，就是在一定時間內全身心投入開發。這個階段通常用看板來管理需求，每個卡片[張樂飛6] 就是一個開發任務，工作完成後，可以將卡片移到下一個階段，用看板管理需求，如圖5-17所示：你也可以使用專門的軟體來管理看板，例如國外的Jira、國內的明道。

圖5-17 敏捷開發項目管理看板

在沖刺中，每一天都會舉行項目狀況會議，被稱為「每日站會」。會議在固定地點和每天的同一時間舉行，對於遲到者團隊常常會制定懲罰措施（例如罰款，做俯卧撐，在脖子上掛橡膠雞玩具）。不論團隊規模大小，會議被限制在15分鍾。所有出席者都應站立，每個人都必須發言。會議的目標是討論當前的任務的狀態，一個推薦的匯報形式是：我昨天已經做了什麼？我接下來准備做什麼？現在遇到什麼阻礙和問題？注意在會議中團隊成員不必要針對每個問題進行探討，只是作為一個重要信息的反饋通道，具體問題相關成員在會後私下當面溝通解決，這樣更加高效，避免浪費問題無關成員的時間。

步驟4. 產品測試和演示

因為每次的Sprint目標就是交付一個可以用的產品特性，所以測試工作非常重要。有不少方法可以減少測試周期，比如，你可以減少需求數量，或者讓開發參與測試。當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行演示會議，也稱為評審會議。產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum團隊的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）。

步驟5. 回顧會議和下一個Sprint計劃

每一個沖刺完成後，都會舉行一次沖刺回顧會議。回顧會議也稱為總結會議，會議的時間限制在4小時，以輪流發言方式進行，每個人都要發言，哪裡做得好、哪裡不好都可以提出，總結並討論改進的地方，放入下一輪Sprint計劃。

㈢ 如何通過「敏捷開發」模式開發MVP產品

敏捷開發以用戶的需求進化為核心，採用迭代、循序漸進的方法進行產品開發。在敏捷開發中，產品項目在構建初期被切分成多個子產品，各個子產品的成果都經過測試，具備可視、可集成和可運行使用的特徵。換言之，就是把一個大產品分為多個相互聯系，但也可獨立運行的小產品模塊或功能，並分別完成，在此過程中產品一直處於可使用狀態。

在2001年，17位敏捷方法論的擁護者和倡議者聚集在猶他州的雪鳥滑雪場，起草了一份陳述敏捷組織原則的文件。這份文件基本上代表了不同敏捷方法論的共同點，我們稱之為「敏捷宣傳」，也叫做敏捷軟體開發宣言，是指導以人為中心的迭代軟體開發方法，具體四個核心價值內容如圖5-14所示。

圖5-14 敏捷開發宣傳

1. 個體和互動高於流程和工具

項目是通過人來完成的，流程和工具可以幫助人，但絕不能自行完成工作。雖然，過程和工具都是好東西，但是它們有時也會成為障礙。面對面的直接溝通，比一些流程性的文件和工具溝通，效率要高出很多。當然最好的是，在溝通後就多方達成的共識形成一個簡要性的文檔備錄。

2. 工作的軟體高於詳盡的文檔

可用軟體的價值是很重要的，因為軟體是為業務目標提供支持的，是可用軟體(而不是文件)為客戶和也會[張樂飛1] 傳遞了高價值。一般來說，一個敏捷項目的進展情況是由開發了多少可用軟體來跟蹤和報告的。但不是說文檔一無是處，適量的文檔在絕大多數的項目中是有益的和必要的。敏捷通過尋求「剛好足夠」的文檔來避免這種情況。其中的原則是任何文件的創建都應與為客戶創造的價值直接掛鉤，且不論該價值體現在現狀還是將來。

3. 客戶合作高於合同談判

這個[張樂飛2] 價值觀的核心是越接近你的客戶越好。客戶最清楚他想要什麼，即使在需求明確過程中也會包含一些試驗和錯誤。在合同談判期間，試圖避免所有的嘗試和錯誤不發生是不現實的，也是徒勞的。定位你與客戶的關系很重要，你是選擇對抗你的客戶還是選擇與你的客戶一起為接近方案努力而使每個人都受益？敏捷團隊更願意和客戶在同一方向一起使勁而不是把力氣花在背離客戶的方向。

4. 響應變化高於遵循計劃

任何一個曾在軟體項目工作過的人都知道這些項目的本質就是變化。即使底層的技術也在快速變化，新的途徑和可能性在不斷的被打開。對變化響應的速度就決定你在市場上的靈活性，循規蹈矩的做事將被市場甩在後面，永遠慢市場半拍，慢慢你的市場會被蠶食掉。

當你讀到這個宣言，你會發現它具有最高原則性，因為敏捷方法論在最高層面上是一致的，但到具體細節上每種方法都會不同。除了敏捷宣言之外，還有12條准則的支持文件，為敏捷宣言提供了更多的擴充細節。

l准則1：我們的最高目標是，通過盡早和持續地交付有價值的軟體來滿足客戶。敏捷團隊可以很快將可用軟體交付到客戶手中，並且是開放式地快速更新，給客戶帶來優先順序最高地價值。

l准則2：歡迎對需求提出變更，即使在項目開發後期；要善於利用需求變更，幫助客戶獲得競爭優勢。傳統項目管理中地一個原則是設法去影響和控制會導致變化地因素。敏捷項目管理預期到需求會發生變化，並在實際過程中歡迎擁抱這些變化，即使這些變化發生在項目後期。迅速應對和適應變化能給客戶帶來顯著地競爭優勢，從而應對新的機遇。

l准則3：要不斷交付可用的軟體，周期從幾周到幾個月不等，且越短越好。不同的敏捷方法論採用不同的迭代周期，但都是相對較短的。關鍵是能快速把可用的軟體交付到客戶手上並能利用軟體獲得有意義的回報。較短的迭代周期可以使團隊持續關注客戶的價值。[張樂飛3]

l准則4：在項目過程中，業務人員、產品經理與開發人員必須在一起。敏捷項目管理，讓業務人員、產品經理和開發人員彼此靠近，並時常讓他們在同一個地方一起工作，通過這樣的方式讓業務人員和開發人員之間沒有隔閡。是因為業務人員和開發人員的共同目標就是通過可用的軟體向客戶傳遞價值。

l准則5：要善於激勵項目人員，給他們所需要的環境和支持，並相信他們能夠完成任務。傳統項目管理，常對員工進行微觀管理，不僅告訴他們要做什麼，還告訴他們如何做，無意間形成自上而下的管理方式。敏捷項目建立了一支強有力的團隊並積極避免微觀管理，要求一個自律的團隊，自發告知開發人員做什麼。提供相關資源，給予鼓勵，相信團隊能夠完成任務。

l准則6：無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。非正式口頭的溝通在敏捷項目管理中遠比正式的書面溝通更普遍。其想法是兩個人坐在一起為一個解決方案努力會比他們用郵件來來往往或交換文件更有效率。面對面溝通是敏捷項目管理的精髓。這種溝通是公開的，任何團隊成員都可以自由參與對話。

l准則7：可用的軟體是衡量進度的主要指標。計劃和文件可能是有用的，但是當最根本的目標發生變化時，它們就可能失去應有的價值。傳統項目往往極其糾結的是，項目的不斷更新使得文件成為一種負擔。真正的價值是通過結果來表達的，結果又是通過可用的軟體來呈現的。

l准則8：敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。可持續開發的焦點是在團隊身上，他們會努力保持一個穩定的可持續的進展速度，從而使得團隊成員不會在迭代周期的尾端匆忙趕工。理想的目標是保持一種可持續的速度，使團隊成員不會感到過度的壓力和筋疲力盡，而是能夠保持在一個理想的強度下工作。

l准則9：對技術的精益求精及對設計的不斷完善將提升敏捷性。設計的越完善，維護起來就越簡單，即使遇到變化。穩定和優質的項目會比劣質的項目更加允許團隊快速應對變化。

l准則10：要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術，被所有的敏捷方法所擁護，尤其是精益方法。[張樂飛4] 關鍵點對客戶價值保持關注和毫無猶豫的削減不增加價值的活動。保持簡單不只是一種願望，它使最基本的原則。

l准則11：最佳的架構、需求和設計出自自我組織的團隊。自我組織是敏捷團隊的核心元素之一。當一個團隊是自我組織型的時候，說明該團隊自己去決定工作如何分配及誰去做某個特定的工作，而不是人力資源部門或管理層來決定。不僅小團隊是自我組織的，較大的跨職能團隊也可以是自我組織的。

l准則12：團隊要定期反省如何能夠做到更有效，並相應的調整團隊的行為。敏捷項目中最可預見的事情就是變更。傳統項目里當項目或階段完成時開會總結是最常見的做法。而敏捷試著通過更頻繁的回顧來完成這項工作。在一個回顧活動中，團隊查看各迭代周期中已完成的工作或發布，並評估下一次如何改進他們的做法。每日站立會議即每天簡單碰頭15分鍾是另一項協調團隊努力方向、團隊自我評定和自我調整的重要方式。

敏捷開發的業務目標是更早的交付價值，價值的交付不僅僅是早晚上線兩天的問題，而是更早上線能夠給自己和客戶帶來更大的價值越晚交付，價值越低。更快不是絕對速度的快，而是指時間上的早，即通過迭代交付實現分批和更早的交付。同時靈活地響應變化，當今世界跨界顛覆的案例數不勝數，一個企業的核心能力不再是已有的能力有多強，而是靈活響應變化，快速學習的能力有多好。