起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何在產品層面把控MVP項目實施
最近，我們組織了一次MVP項目實施。項目還在進行中，但我希望盡快跟大家分享一下相關情況。
一.
先描述一下項目背景。
我們是做汽配物流業務的，現在業務的大體流程是：汽配商將要配送的貨物送到我們門店，我們的前臺負責進行錄單，將一個發車班次內多個汽配商的貨需要配送到同一家汽修廠的需求合并為一個訂單，然后我們的配送員根據訂單信息進行逐個配送。
現在的主要問題是，因為要錄單，我們需要安排至少3個錄單員來負責，再加上我們目前需要進行貨款墊付，現金收款，所以還有付銀員和收銀員。這樣的結果是，我們門店產生了大量的外圍服務人員，導致我們這項目業務的人力成本過高。
所以很明顯，我們需要減人。
二.
我們調研過同行競爭對手，他們做了至少10年之久。他們一般是都是只配送部分區域，占據少量幾條線路進行競爭。做為個體戶，他們的業務流程很簡單：汽配商將貨物送到門店，1個前臺收單（據），配送員到點后取單配送。沒有錄單，也沒有系統。人員角色也只有1個前臺和N個配送員。非常簡單。
因此，我們提出一個假設，我們是否也可以讓配送員見單就送？這個“見單就送”并不是說不要錄單和系統了，是指能根據汽配商給的貨品清單信息就能送達客戶。
這里說要一下背景。雖說是配送，但跟其它物流和快遞不一樣的是，我們配送是沒有客戶地址的。汽配商送過來的貨物清單上只有客戶名稱和電話號碼，有的甚至連電話都沒有。
我們一直以來的做法是，自己在系統中建立汽修廠的客戶信息，如名稱，電話，地址，位置定位等。在我們錄單時，會將貨物清單上的收貨單位名稱與我們系統中的汽修廠對應起來，這樣配送員送貨時其實拿到的是經過我們錄單員“轉換”過的客戶信息進行配送，大大方便了配送員。看，我們畢竟是有著互聯網基因的公司嘛……
但現在的問題是，錄單這個流程讓我們產生了不少人力成本，而且產生了新的問題，比如有些收貨單位只有名稱，沒有電話。而且在我們系統中是找不到對應數據的。這樣的情況對于我們現有的流程是走不通的，然后錄單員就要求汽配商確認好信息后再過來。這樣汽配商對我們產生了極大的不滿。因為別家都能收能送，但唯獨我們不行。另外，送貨高峰期集中錄單也造成了排長隊現象導致工作效率低下。
三 .
面對這些問題，我們討論出了新的運作思路。
- 錄單由汽配商自助完成。類似順豐的微信掃碼填單。
- 錄單時只是簡單的記錄信息，不再進行貨單合并。即使是送到同一家汽修廠的多單貨物，也同樣單獨視作為多單。
- 配送員根據原始貨單進行送貨，如果不知道地址的，自行通過電話聯系汽配商或汽修廠進行確認。
如果上面的設想可行，那就解決了錄單人力，排隊問題，同時也解決客戶信息不全無法送貨的問題。
但新的問題來了：汽配商是否配合？畢竟競爭對手沒有這樣的要求。另外我們的配送員是否能夠達成我們的要求？第一個問題，我們可以考慮上門注冊這樣的方式與汽配商進行溝通，告訴他們可以解決排隊的問題。第二個問題，其實問題不大，內部人員，只要提出強制要求，肯定是可以推行的，主要考慮是否會有新的未能考慮的不好解決的問題出現。待正式推行時，我們需要提前做好準備。
老板覺得這個思路可行，開始干吧！然后提出了此新模式正式切換上線的時間點。
但這完全是設想，而且這么重大的調整，如果沒有事先的驗證就貿然開發上線，則可能會帶來的不可預知的重大風險。這種后果是我們斷然不能接受的。
于是，我們決定在正式上線前，做一個測試驗證版，以MVP的方式實施。盡可能地降低業務風險。
四.
洋洋曬曬鋪墊了這么一大段，終于進入正題。
要保證真正做好這個項目，需要我們對項目的整個環節進行層層把控。作為產品經理，首先我們得從產品層面進行把控。所以接下來就是本文的重點。
作為前提，我們要明確一個問題：我們是否真的需要通過產品開發的方式來驗證我們的設想？
MVP項目的產出，并非一定是一個軟件產品，它可以是一個不影響驗證問題的任何東西。比如一張調查問卷，一個概念視頻，一個公眾號等等。如果以上這些可能已經能夠滿足這個要求，那我們為什么要去做產品開發？因此，在做產品開發之前要認真問問自己這個問題。
對于我們這個案例，則必須需要進行產品開發。因為所有的假設驗證都基于線下業務運行在產品之上所產生。
當我們必須通過產品開發的方式來驗證問題時，那我們就得切實做好如下幾點：
1、與目標無關的需求點，如能以非產品方式解決，則可去除，極力縮小需求范圍
我們的線下配送業務相對復雜，除了核心的業務流程之外，必然還存著很多相關的分支流程需要支撐。比如退貨。而退貨又分為兩種，一是客戶收貨時當場要求退貨，二是結單后發起退貨。對于后者，因為這是跟我們核心業務流程不相關，所以是可以去除的，讓線下團隊用產品之外的方式先行解決。但對于前者，因為跟我們的主流程是一體的，必須要處理后才能完成整個配送環節，因此，我們還是需要進行支持。
還有就是汽配商付運費的情況。我們目前在當地的主流模式是汽修廠付運費，而我們的產品流程也是配合著這種方式進行設計的，因此讓汽修廠在收貨后進行貨款和運費的合計支付是更為簡單方便的。對于少數的汽配商自己付運費的情況，我們考慮是讓線下運營團隊自己處理，如收取汽配商付的運費后，給到配送員，汽修廠照常支付整個訂單，然后配送員再返還汽配商預付的運費到汽修廠。這個環節雖然在線下執行時有一定的麻煩，但對于簡化我們產品需求的復雜度是非常有利的。
2、允許“漏洞百出”的需求設計，只要關鍵業務流程能跑通即可
在這種項目階段，我們不需要過多地考慮產品的完善性和嚴密性。我們在通常的產品設計中，會考慮在產品層面進行一定的邏輯條件約束，避免產生bug，這是應該做的。但在做MVP項目時，這個則不是必要的。
嚴密的邏輯條件約束，在最大的程度上避免了產品邏輯問題。但帶來的則是復雜的需求分析和成倍開發工作量。這對于我們希望快速進行產品驗證的目標是背離的。因此，我們需要在這個方面把握一個度。
對于簡單的，基本的條件約束是必要的，不然可能造成產品流程的混亂。比如，貨單被掃碼裝車后，狀態變更為“已裝車”，此時是不能再被其他人再次掃碼裝車的，否則兩個人同時裝了一單貨，這完全是不合理的。這種情況在線下運作時是有可能發生的。而像其它的，如果發生的可能性不大，而且考慮進去入會變得相當復雜的情況時，則可以忽略它。要真是發生了怎么辦？到時再說嘛！
3、實施時，挑選實施條件較好的，破除與核心目標無關的影響因素，創造條件保障目標驗證的集中有效性
在進行產品設計之前，就要考慮到后面的實施環節中的問題。既然是驗證，那就可以在小范圍中進行，因此，我們準備挑選其中兩條線路進行實施。
但挑選線路也是有講究的。我們有些線路的單量比較大，但有些線路的單量還比較小，所以我們會優先選單量較小的進行。因為既然在驗證過程中出現問題，也不至于影響太大。還有些線路因為配送線路過長，范圍過大，所以進行了中轉設置，而這就涉及到了中轉流程。這樣的線路運作流程就會復雜一些，因此我們會避開這種線路。沒有了中轉流程， 我們的產品需求和開發都更加簡單。
最后，我們選擇了這樣的兩條線路進行測試：A線路單量少，首次測試時啟用。B線路單量稍多些，作為后續平穩后進行加強測試時使用。兩條線路均無中轉設置，且兩條線路的負責人均為老司機，與我們產品團隊的接觸較多，關系融洽。這樣，完美的測試環境便完成搭建。
五.
作為產品經理，我們在日常的產品工作中，通?？紤]的是如何把握用戶需求進行產品設計，如何提高用戶體驗。但如果你身處創業公司或創業項目中，特別是前期，產品的工作核心可能完全不是這樣。
在業務模式和商業模式確定下來之前，用戶體驗型的產品迭代都是毫無意義和不必要的。作為創業項目的產品負責人，你可能需要面對頻繁調整的產品方向甚至是業務模式。不管如何，這都會對你的工作帶來極大的不確定性甚至是麻煩。
身處創業公司，產品負責人應該最大化地理解老板的焦慮。產品方向和業務模式的調整是老板對項目認知不斷迭代的一種表現。而我們要做的，便是義無反顧地順應這種工作常態，并用合適的方式策略去支持這種變化 。
這便是MVP，最小化可用產品。
MVP不是一個產品，它可以是一種任何可以驗證疑問的方式方法。MVP的目的也并非是快速地開發產品，而是快速的建立起一套有效的業務運作模式或者是商業模式。
作為創業公司的產品負責人，首先要拋棄產品思維，不要處處以產品開發的角度考慮問題，而是要發散思維，以更經濟更快捷有效的方式去獲取產品實施前所要確定的答案。
在創業公司或者創業項目里，你應該掌握MVP，并頻繁使用。老板們并不會告訴你某個項目需要以MVP的方式來做，只會告訴你什么時間點，他要什么。是否要考慮采用MVP項目實施策略，作為產品經理，你是第一責任人。
我們的老板對于這種方向性的調整，時間要求都比較急，都希望能盡快地知道思路是否可行，如果可行，希望能盡快全面轉換，時間就是金錢。而對于屬于重大業務調整的項目，本身就蘊含著巨大的風險，再加上時間緊追，最終就只會讓這個項目充滿了挑戰和難度。
對于這樣的項目狀況，我們應對的策略便是采用MVP方式進行項目實施，以驗證的思路進行展開。但時間緊，業務復雜都將極大地拉高了MVP項目實施的難度和成功概率，因此需要層層把控。
本文由 @星思維 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基于 CC0 協議
最近面試被問到MVP的問題，各種查資料，這篇文章算是踏踏實實的解釋了mvp，非常好
支持 支持
希望有更多這樣的實例。
堅持實例講解分享，歡迎關注
有意思，啟發思維
開心就好