文章探討了創新項目的輕量化站位選擇的話題，并對輕量化展位進行了全方位的梳理分析，與大家分享。

公司里面喊MVP已經喊了很多年，也有越來越多的PM在踐行MVP，我今天想聊聊MVP的前序環節。

01 什么是輕量化站位？輕量化≠MVP

輕量化我指的是你選擇下手的位置，我叫他站位，是這個項目在整個系統中的準備放在哪兒，站位的不同需要解決的問題不同，MVP方案的設計和方案覆蓋的范圍也不同。

所以我們需要在開始MVP方案設計前，充分的想清楚項目的站位在哪里。爭取找到輕量化的MVP方案，才能真正最大程度的做到“最小”&“可行”

02 選擇輕量化的原則

我總結了4條原則共大家參考：

1. 有輕量化的時候盡量選擇輕量化方案

輕量化會降低很多系統層面打通的成本，團隊協作的成本，調整的成本……所以如果有輕量化，近況選輕量化方案。之所以說盡量，是因為你還要做下面的三個判斷。

2. 輕量化方案到完整方案是演進的關系不能是推倒重來

輕量化方案不是指臨時方案，不是說驗證了可行，然后推到重新從常規路徑重新進行建設的方案。如果是這種臨時方案，就違背了做輕量化真正追求最小、可行的初衷。并且會造成資源的浪費。

3. 輕量化的方案不會對其他的上下游造成嚴重的影響

輕量化站位站在哪兒要充分的考慮是不是會對上下游產生影響，會不會在這個點上看起來輕量化了，但是往更大的盤子看，對其他環節的影響的總和是不是可能比常規方案還復雜，資源占用還更大？所以，在判斷的的時候，一定要在更高的層面做完整的判斷，如果自己無法判斷，就請相應環節的產品、研發的負責人參與進來。提前規避掉會對上下游造成嚴重影響的方案

4. 不傷害用戶體驗以及需求本身的目標

輕量化是站位的選擇，選擇不同的站位更多的是從系統層面出發，所以這一點寫在最后卻最重要，輕量化與否都不能以犧牲用戶體驗和影響需求本身目標為代價。存在這種代價的方案不能被視為合格方案。

03 如何找到輕量化站位？

1. 充分了解全鏈路產品方案及系統是前提

找到合適的最有的站位的前提是你需要對全鏈路有足夠多的了解，一方面在于對系統的熟悉度，另一方面需要請更多的角色參與到方案的制定中，幫你找到最優站位；

2. 放寬視野，組織內部是不是有成熟的系統可以復用？

選擇如何最輕量化，除了在系統層面尋找，還應該嘗試尋找大團隊內是不是有現成的解決方案，能不能通過共贏的利益分配的方式直接獲得這些能力的使用權，特別是在大公司，很多時候解決方案有現成可復用的。

它山之石可以攻玉，用已有的成熟解決方案比自己造輪子快的多，也讓自己少走別人走過的彎路。

3. 不要拘泥于現有的技術分工

團隊中要建立“突破現狀”的文化，如果打破技術分工的界限，可以讓整個的項目成本明顯減少，就應該去挑戰打破，讓項目站在最合適的位置上。當然第二點中提到的原則不可被打破。

做這件事要主動聯動技術主動尋找更有的承接方案，要讓技術合作方同樣清楚的認知到分工是為了業務更好的發展而不是為了阻礙業務發展。

舉個例子：

現在要為公司的商品分類做一套打標系統；整個系統從生產到銷售有非常多的系統。這個分類標簽系統應該做在哪兒？

在最前置的生產環節打標，是可擴展性最強的選擇方案，但是需要打通到展示層面需要做多個系統的改造，投入大時間長；直接做在展示層的服務端，鏈路短了，時間和投入都降下來了，但是擴展性需要面對各平行不耦合的系統打通，實際是把成本后置，甚至后置成本還有增長。

該怎么辦？一個完全解耦的可以直接服務于展示層服務端的標簽系統如何？新獨立系統與其他系統打通難度大概率比成熟系統間的互相打通要容易，而且縱向也不需要打通生產流程的太多環節？

再舉個例子：

你公司的系統原本為簡單層級的庫存而設計，現在接入了一個重要的供應商，提供的產品庫存結構比你現在的產品復雜。我們該怎么辦？為一個供應商重新建設一套庫存體系，看起來并不是ROI非常合理的事兒。

但是如果這個時候其他業務線有合適的庫存接口可用，是不是我們只用開放入口，讓商家在合適的地方上單，我們和提供系統的業務線溝通清楚利益分配，這件事兒就可以被解決~？用戶的體驗并不會被影響，上下游也不會因為接入新的產品類型而被影響。

04 找不到輕量化站位方案的創新要怎么辦？

啟動標準的衡量各公司的規模不同，行業不同，項目面臨的情況不同，所以無法簡單的用一條線來界定，但是原則上的判斷是：至少有多少參與，這件事才有嘗試的意義，達到了就可以開動了。

這個事兒的意義在于我們要充分思考并排除那些無法達到邊界的無效需求占用大量的業務資源，影響真正重要的項目。當然，如果無法達到邊界要求卻找到了充分降低成本投入可以快速嘗試的方案，也不是一定不能嘗試。核心還是在于避免無效需求占用大量資源。

以上是我對于創新項目站位選擇的思考，最后附上我的大綱腦圖，供大家參考。歡迎收藏、評論、關注、轉發~！謝謝大家~~

作者：Adam；產品專家

本文由 @Adam 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議