MVP最小閉環
MVP之所以能成爲最小閉環，一定是經過化繁爲簡的過程。繁，是在每個流程上窮舉過無數種可能，要達到這個效果，又需要查閱大量信息，諮詢大量專業人士。簡，是經過分析每種可能的利弊，最後不斷刪減得出的結果。我們當然要考慮完成閉環所需的時間，只是比時間更重要的因素是，刪減後的結果是你要的業務最小閉環嗎？
只看皮相，不究內裏，終會活成糊塗人。
以下內容均爲參考鏈接處文章，學習後整理的，作爲個人學習筆記。
如有興趣，可直接查看參考鏈接原文。侵刪！
這個最小閉環是炎大神提到的高級的東東。在關於思維啥的文章中略帶提到了這個。
感覺是個好東東，需要單獨好好研究一下。
以下內容，只是爲了瞭解什麼是MVP，以及使用它的栗子，由於這東東的說法版本很多，畢竟這是一種思維模式，在不同職業，不同需求，不同的人 得出的結果也都不一樣，這裏做個整理，與我個人的看法。
什麼是MVP
百度：Minimum Viable Product – 最簡化可實行產品。 MVP是一種產品理論，這個概念聽起來複雜，不過你可以把它想像成是一部電影的劇情大綱，或是一部漫畫的角色介紹。它的重點就是製作的成本要極低，但是卻能展示最終產品的主要特色。
MVP：通過輕度的開發投入（最小的人力和資金），先驗證市場，以最小的代價去試錯，根據用戶反映實時調整。
"最小"：就是投入足夠小，成本足夠低
"可行"：再小的試錯方式，都要保證走完最小的業務流程，在一個小的場景下，形成小閉環。
誤解的地方
在一些實操過程中， 最小化產品的定義沒有被正確理解 ——很多人只是把它當成一個時髦詞，或者直接曲解成是產品上線的1.0版本。
MVP就是邊驗證邊學習，它應該完全以用戶問題爲中心，而不是以解決方案爲中心。 因爲用戶不關心你的解決方案，就算你的方案有趣又好玩，與他也不直接相關。所以首先我們要明確“MVP”的定義。
所謂最小化可用產品，是讓開發團隊用最小的代價實現一個產品，以此最大程度上了解和驗證對用戶問題的解決程度。
這裏最爲重要的點在於瞭解和驗證,而非其他，甚至這個產品本身就只是個假的頁面。
即使是MVP，也是有成本的，不代表沒有成本，只是比較小而已，但是累計多了，也是不小的成本。
但是有時候，市場可能不會有太多的時間給你去試錯，窗口期可能很短，這就是商業現實的殘酷性。
也是很多時候，對於需求主導的項目無法使用MVP的很大原因。
栗子1
假設你需要寄一百封信，每一份信都需要寫地址、貼郵票、裝信、縫合，怎麼做是最快的。你或許想到拆分流程，先寫好一百個地址，再貼一百張郵票，以此類推。這樣的效率的確很快，但要我說，以貼完一封再貼另一封，這樣的速度是最快的。爲什麼呢？
因爲你擁有最及時的反饋，一旦有問題，你可以立馬察覺，立馬糾正，而如果你採取拆分流程的方法，當你最後一步縫合信封的時候才發現郵票貼錯了，那就等於一百封信都錯了，於是得重來，那將是一場噩夢。
以一封信爲最小單位，而不是拆分流程，及時找到問題，及時解決，這就是最小閉環。
MVP中的核心：反饋循環
MVP作爲最小可行的版本，是爲了以最小的代價去試錯，並邊驗證邊學習，然後快速迭代。而這些所依賴的則就是反饋循環。
就像這個樣子，【構建：開發，創建項目，測量：用戶使用情況等，學習：迭代調整更新項目】“開發MVP-通過用戶驗證”是創造好產品的第一步。接下來就是用“構建-測量-學習”的方式，在限量測試或者正式運營中，對產品進行循環迭代。
作爲產品的創造者，你可以是驕傲的、品位非凡的、目光長遠的，但請不要忘記，在產品的成長旅程中，你的用戶始終是旅程的重要部分。沒有人用的話，弄的好也是個垃圾╮(╯_╰)╭
可以類比一下，程序員最快的學習方式是什麼：coding。就是試錯，反饋，調整，試錯。。。
【由於代碼運行是及時反饋的，這一次循環的時間非常的少。所以可以在很短的時間高速迭代，學習效率那是灰常的高的 [](￣▽￣)* 】
栗子2
![]()
假設你現在創業，你的產品目標是——有史以來最好的甜甜圈！
產品團隊用最快的速度幹了一張原型圖，程序工程師快速吐出一團代碼，編譯工程師把原型圖和代碼揉成麪糰扔進鍋裏炸熟，開發出了一套味道普通的甜甜圈——這就是你們第一個最小化可用產品。能吃，能用 （謎之作用） ，但可能還不是有史以來最好的甜甜圈。這時候，你的產品團隊就要抓緊時間，問用戶一些問題。比如說：
你們覺得這款甜甜圈哪最好？
如果你可以選擇加配料，你會加哪些？
你喜歡什麼甜甜圈造型？切開的還是一體的？金黃炸透的還是脆嫩相間的？……
有了這些通過種子用戶得到的驗證結果，產品團隊精神大振，立馬操刀做了一套更好的甜甜圈。根據用戶的反饋，產品團隊總結出了不少實施細節：
在一些特定情況下，用戶會喜歡加一些七彩糖珠；
一些特定的市場和特定的用戶更喜歡巧克力甜甜圈；
如果是海外用戶，他們可能更喜歡草莓甜甜圈。
栗子3：
比如說，有一個手電筒工具軟件，第一版做出來就需要實現：能快速打開，能亮。解決了基本的需求，這個思路不就是MVP嗎？用戶有需求的時候，第一反應是先實現我這個需求，使用了之後，才發現，這個電燈不能調節亮度啊，於是手電筒工具的開發者就增加了調節亮度的功能，然後不斷的迭代，最終變爲一個萬能手電筒。
如果不採用MVP的設計思想，產品經理，不可能只是憑腦子就做出來一個萬能手電筒。好的軟件，不都是靠產品設計+用戶反饋才累積出來的嗎？
必要性分析
知乎的提問：
這幾年，MVP（最小可行化產品）在互聯網產品界，似乎被奉爲經典。
但我之所以這麼提問，是因爲突然想起兩位名人的話：
喬布斯：用戶根本不知道自己要什麼。
亨利福特：如果我最初問消費者他們想要什麼，他們會告訴我要一匹更快的馬，而不是汽車。所以，如果是一個全新的產品，用戶其實並不知道自己要的是什麼，就算原本產品理念很出色，但MVP作爲一個不成熟的產品，冒然呈現給消費者，可能帶來的數據反饋是極其不理想的。
那MVP還有意義嗎？我們真的需要去做MVP嗎？
如果是以全新的產品進行分析的話，用戶不瞭解自己的需求點的情況下。要考慮的就不是這個產品是否成熟，而是控制成本和控制風險啊！！！
是必須要做MVP。否則你準備一開始就把產品做到10.0再上線麼？產品都是不斷堆砌不斷優化而來的，羅馬不是一天建成的。
MVP 肯定不是必要的，不乏有大量商業在早期並沒有什麼 MVP。
但 MVP 絕對是成本與風險控制的最佳手段。
做一年才發現這個產品滿足不了用戶的需求，或者市場需求量很小，這是早期產品絕對存在的風險。推倒重來重新做，又要花費很多時間和金錢，這是成本。
想不犯錯，要麼運氣很好，要麼只能通過科學的方式來規避錯誤，提前發現道路上的陷阱。
MVP與完整項目對比
完整項目：
- 試錯的成本高【全功能開發消耗太多，週期太長，一旦出差錯，就沒法回頭，補救代價大】
- 試錯的週期長【無法更快的跟上市場的變化】
MVP：
- 成本低，週期短。甚至不一定要立項開發。
- 你並不一定真正懂用戶的需求，很多時候，只是“你以爲”罷了。
- 你並不知道市場的大小和未來走向。
- 驗證的的目標要明確，不一定非得是實際的開發產品。
栗子4：
以一個簡單的資訊客戶端App作爲案例，大體來做個時間成本評估吧。
第一階段：需求初步確定。 至少3天
第二階段：從需求到產品原型 原型圖，改幾次，5天
第三階段：產品原型到UI設計稿 UI確定風格，設計，調整，定稿 7天
第四階段：從設計稿到能跑起來的程序 前端後端服務器，框架設計，第一版本，測試，修改，文檔。最快一個月。不改需求的情況。
總體投入：
1.最少10萬左右的錢
2.半年以上的時間
如果這個時候，產品投入到市場，發現效果不好，不是用戶需要的，或者需要的用戶很少，那麼問題就大了。
這個APP如果是做MVP，小杭我個人的想法：
- 確定核心需求內容
- 已H5的形式直接製作demo，甚至只是貼圖【與產品，設計一同】
- 已H5APP的形式發佈，內容甚至都是靜態隨機或公共數據接口的。
- 看看下載使用的情況。
以上的情況所花費的時間，人力等成本都是不高的。
之後H5的內容轉向小程序端進行開發，APP後續驗證項目成立再開始開發。
栗子4，的完整開發的花費是很高的。辣麼MVP呢？以上我個人的想法還是很片面的，畢竟作爲程序員我也只能想到這麼多了 ε=(´ο｀*)))唉
栗子5：
看看就好，這個我也看不懂
典型代表爲生產銷售集一體的企業，其進銷存的基本業務流程，主要表現爲物料的採購（進）—>入庫（存）—>領料加工—>產品入庫（存）—>銷售（銷）的動態過程。
這兩種類型，基本可囊括現階段各種企業類型的進銷存產品的業務流程，但私以爲仍不夠簡潔。細心對比業務流程，兩者是具有共性通用的流程，在對物料加工的流程歸納到庫存管理當中後，即可再度簡化爲「進-存-銷」流程（見圖）。
本業務流程圖，適用且通用於任何企業一，甚至是周邊的一家超市，一家夫妻店。
完整的進銷存產品功能模塊，一般涉及基礎數據和業務數據兩大方面的數據結構，涵括採購，庫存（含生產加工），銷售，結算在內的四大模塊的業務流程化定製，解決供應鏈的問題。
看看圖就可以了，對比一下，意思一下就可以了的。
辣麼，下面看看常用的MVP方法吧，應該可以比較容易看出來，成本差在哪裏了。
MVP的方法
重點：不一定非得是實際的開發產品
這些大多是產品方向的MVP，作爲程序員，做個DEMO，做個靜態頁面試試，做個假的app啥的纔是我們的MVP
作爲程序員對項目的看法；
【不做爲產品方向的觀點】【X】表示我認爲不適用的方法
【√】表示我認爲推薦使用的方法
1.問身邊的人 【X】
準備好問題，詢問身邊的人，看是否有需求。如果有30個以上的人，有需求，那麼就可以考慮進行下一步的產品試驗工作。樣本量不能太少，一兩個人的需求，容易矇蔽我們的眼睛。
2.A/B測試【√】
在產品方向不明確的時候，可以做兩個甚至多個分支出來，讓部分用戶選擇體驗，也就是灰度測試。然後分析數據，做出決策。
3.衆籌網站 【X】
利用衆籌網，國內像京東衆籌、淘寶衆籌等，將自己的想法和思路，放在網站上，有沒有人給你砸錢，就知道有沒有需求了。
4.功能入口【√】
在現有的功能頁面裏面，增加一個並未開發的功能，但是提供一個入口。然後統計用戶點擊的比例，進行分析判斷。當然，點擊的時候，給用戶一個友好的提示，也是很有必要的。
**5.微信公衆號、博客等社交媒體 **【X】
利用公衆號、博客等，寫明自己的想法，收集用戶的反饋。不過前提是，你已經有一定的流量了。否則樣本用戶太少，可能沒有什麼效果，達不到目標。
6.做個Demo 【√】
自己做個小Demo，尤其是有編程能力的人，是一個不錯的方式。如果不具備開發能力，可以畫出設計稿，不開發成產品。只需要在手機或者電腦上，能演示，能讓人大體瞭解和體驗，也是可以的。關鍵是收集用戶反饋。
7.問卷調查 【X】
可以用問卷的形式，電子的或者紙質的都行，讓用戶做選擇，然後根據數據，進行進一步的工作。
8.視頻 【X】
如果你善於做視頻，可以將產品的預期功能或者想法做成視頻，然後放到視頻網站上或者網站上，看有沒有人跟你互動，有沒有足夠的瀏覽量，有沒有人過來註冊你的網站。
另外需要注意的地方：
真實性：獲取到的反饋信息，必須是真實的。
有反饋：一個方案，一定要有反饋指標。
樣本量：採集的樣本要到一定量級，否則僅僅一兩個人的需求，未必能形成市場，支撐起一家公司。當然樣本是越多越好，自己根據實際情況做確定。
栗子6：
https://www.zhihu.com/question/315980175/answer/627932464 有哪些MVP案例（產品開發最小化）？ 灰常有借鑑價值 ，做個假的產品，收工後續操作就行了 哈哈啊啊
栗子7：
再舉些最小閉環的例子。我不喜歡看長篇小說，因爲太長了，看一部小說得花一個星期甚至更久，但我卻很喜歡看短片或者幾百字的文章，因爲幾分鐘內就可以看完，看完還能有收穫。再比如，最近抖音很火，其中一個原因是，抖音具有最小閉環的特性，它不像電視據那樣冗長，內容也通俗易懂，你可以在短短幾秒鐘得到滿足。
最小閉環的特點是：時間短，反饋快。這對於長期學習來說是不利的，因爲有時人的進步很緩慢，緩慢到自己懷疑自己的付出。 【這不是跟寫代碼一樣嗎 哈哈哈哈 超級及時的反饋】
最後想法
MVP，學習最小閉環，項目最小閉環，好像還有個認知最小閉環的樣子【太高級，延後學習】。
可以用到很多的地方，無論是哪個行業，職位，都可以學習一下。作爲控制陳本，控制風險，提高效率等還是有很大幫助的！！！！！！
項目MVP方面，小公司可能會遇到的情況是：需求，反饋，成本，都不是產品經理決定的，這就很尷尬了 .
而作爲普通的程序員，好像，額。。。。沒有啥是我能決定的。 (╯‵□′)╯︵┻━┻
ε=(´ο｀*)))唉
資料
- https://baike.baidu.com/item/MVP/3714440#viewPageContent 百度的簡單說明 不準確 MVP是一種產品理論，即最簡可行化分析
- https://teambition.kf5.com/hc/kb/article/1324727/ 好像是一個不錯的視頻資料 項目管理最小閉環 【？？】
- https://www.jianshu.com/p/7bb004f8023a 認知閉環資料 從閉環認知模型，來看人生算法的底層邏輯 太高級留着以後看
- https://zhuanlan.zhihu.com/p/24157592 MVP最小可用品，快速低成本試錯必備
- http://www.woshipm.com/pd/634271.html 以MVP思維，解析最小可行的進銷存產品 看看與完整的對比
- https://www.zhihu.com/question/321598316 MVP 是否必要
- https://www.jianshu.com/p/1970979e7bce 好幾個說明什麼是最小閉環？的小例子
- https://baike.baidu.com/tashuo/browse/content?id=242a1308b6ecedde411c4571&lemmaId=3714440&fromLemmaModule=pcBottom 百度推薦
2020-02-29 小杭