Debug≈MVP

編輯導語：產品經理需不需要懂技術？也許每個人都有自己的答案和見解，而了解更多的技術屬性，也許在一定程度上可以幫助產品經理更了解產品本身。本篇文章里，作者結合其自身的技術實踐經歷，發表了他的看法，讓我們一起來看一下。

最近撿回了代碼這門手藝，上線了一款微信小程序。

表面上看研發崗和產品崗需要掌握的知識和工作流程都不一樣，從近期實踐中通過一些技術理念聯想到一些產品感悟，下面和大家一起聊一下一下技術和產品有哪些“共性”。

一、Debug（代碼調試）≈ MVP（最小可行性產品）

開發5分鐘，調試2小時，這是我最初寫代碼的真實現狀。

因為當初不懂如何去debug，寫了一大坨代碼，然后自信點擊運行控制臺顯示報錯，如果用的比較舊的IDE編輯器光靠瀏覽去發現代碼問題，效率非常低下。比如變量名拼寫錯誤、部分語句出現中英文符號等，可能找個大半天。debug能夠比較快速地定位代碼問題，控制程序的運行節奏，確定程序的運行路徑，不斷縮小范圍，找到出錯位置，最終修改成功運行。

做產品有沒有像代碼debug一樣，能夠一步又一步的加以驗證？特別是做C端的朋友一定經常遇到以下的情景。

一頭小馬跑到河邊，剛抬起前蹄，旁邊的松鼠就大叫了起來，你不要命啦！小馬說，讓我試試吧，它下了河，小心地趟過去。

原來河水既不像老牛說得那么淺，也不像松鼠說的那么深。

很多事情只有自身去做了，才會有感受。否則聽從他人建議或反饋都是相對的，最好的做法就是先做一個最小可行性產品（MVP），一步一步加以驗證去達到產品與市場契合度（PMF）。

在企業組織上字節跳動的部分業務線也是追求快速獲取結果，而結果需要盡可能是好的，如果不好就迅速調整。首先會保證管理及執行的人在能力預期上沒有問題，其次目標清晰，如果結果不如預期就立馬更換下一批頂上，組織的快速調整有助于始終讓團隊走在正確的沖刺道路上。

所以在外界還有另外一個風評，說字節是靠“迭代中高層管理”來推動進展的企業。

不管是代碼的debug，利用產品MVP找到PMF，還是字節跳動的管理調整，本質都是通過小步驗證測試重復性調整，來達到提高容錯，達到成功。

二、Code review ≈ 產品復盤

Code Review可以理解為一群人對一坨代碼基于某種規則下進行審查，找出違背相關規則的代碼塊提出解決方案，既能夠提高代碼的質量還能夠提升個人成長，這算個人及整個研發團隊極其有效的進步方式之一。

產品團隊也有相似的進步方式，針對項目/版本做有效復盤，也能得到快速的成長，具體怎樣才算是有效，包含以下3個結論：

• 什么不該做；
• 什么繼續做；
• 什么開始做。

以“積分體系”為例。

現在積分體系是很多產品的標配，在幻想著上了積分體系就能提高用戶活躍和留存，但現實給你來了一大嘴巴子。

在復盤時找準關鍵要素和預期目標，如積分體系可以按“任務完成度”和“是否貼合業務目標”來來進行復盤調整。

• 對于完成度低且業務無關的任務盡可能地剔除；
• 對于完成度低且是核心業務的任務，適當降低任務難度并且提高完成任務獎勵（縮短任務路徑，自動領取）；
• 對于完成度高且與業務目標影響不大的任務，盡可能剔除或者降低完成任務獎勵。

什么不該做，比如發現點贊完成度非常高且占比積分來源很高，但點贊與被點贊對平臺和用戶均無有效作用時，是否可以考慮刪除。

什么繼續做但需要調整，比如“邀請好友”是一個核心任務，但完成度比較低，是否應該提高獎勵還是降低難度門檻，但如果深挖發現“邀請”過來的用戶均是非質量用戶，此時是否重新平衡一下邀請難易度，如好友注冊后登錄獲得X、次日登錄獲得Y。

什么需要開始做，比如發現積分持有人數和數量呈兩極分化，即沒有養成新用戶獲取積分習慣，有一個1積分就能兌換的禮物，感受到積分的價值后是否能讓新用戶養成活躍持續留存。

失敗從來不是成功之母，高質量的復盤才是。

三、代碼追求可復用 ≈ 產品追求架構最優

可復用指的是一段代碼可被多處地方調用執行，而不需要重新編寫一遍。

如點擊跳轉至新聞列表和在新聞列表下拉刷新，兩個動作在代碼邏輯本質上都是獲取最新的內容數據，如果在點擊跳轉處和列表下拉分別寫上兩段獲取內容數據的代碼，顯得代碼冗余且維護不便，一旦涉及變動則兩處地方都要修改。如果把獲取內容抽象成一個方法，供點擊跳轉和下拉請求時調用，則變得十分友好。

為什么有些產品給人感覺十分笨重，有些產品給人感覺流暢清晰的體驗，除了產品本身的業務復雜性外，產品架構也有優秀和平庸之分。

張小龍在2021年微信公開課末尾提到的微信依舊保持簡單和“小而美”，很多人會把微信占用手機存儲空間或者安裝包大小來進行反駁。如果以存儲空間或安裝包大小來衡量產品是否“小而美”，恐怕只有鬧鐘、備忘錄這類應用符合大家胃口。

簡單和小而美由微信產品架構帶來的結果。簡單建立在易理解性上， 確保用戶方便找到和輕易使用,如微信內有多個掃一掃入口，并沒有追求絕對簡單只保留一個掃一掃入口。小而美建立在高拓展性上，如果拓展性弱產品只會越做越臃腫。

從更高維去看，其實代碼可復用程度和產品架構高度掛鉤，優秀的產品架構能夠讓多處代碼得到復用的可能，同時如果意識到多處代碼可復用，能有效遏制不良的產品架構，這也是為什么研發人員的架構能力比產品人員的要更強一些，因為考慮到了技術架構和拓展性。

在微信自帶開發者工具中會提醒wx.showLoading和wx.hideLoading必須配對使用，這是為了避免程序進入“死循環”，因為在調用wx.showLoading時會顯示 loading 提示框。需主動調用 wx.hideLoading 才能關閉提示框。

為什么有開發會對產品貼上“不靠譜”標簽，據了解多數都是因為在對接中產品需求邏輯不夠完善，一些異常流程經常性忽略。因為產品經理在設計流程時都往好的一方面去思考，沒有考慮到較差的一面。有發布成功的結果就會有發布中狀態和發布失敗的狀態。

關于產品人員需不需要懂技術，該懂多少這一話題一直有兩種聲音，有人認為產品經理最好的情況是不懂技術，這樣才能突破邊界。恰好又有人覺得如果懂技術，可能會限制產品本身。

個人認為，明確自己邊界比突破邊界更為重要，因為大多數產品設計是需要在邊界認知內完成。

產品人員不能光有天馬行空的想法，需要在一定的事實之上，否則只是在無效的工作上浪費時間。如果熟悉前端組件的相關屬性以及對應屬性的值可以快速得出決策。

以調起相機為例， 閃光燈和攝像模式等都是相機組件的屬性，而屬性又有對應不同的值，比如攝像模式是掃碼還是拍照/錄像、閃光燈是開啟還是關閉等等。

知道相機有那么多屬性不影響突破產品邊界，更不影響做出一款好的相機產品，反而如果不知道則無法評估實現預期和成本。

#專欄作家#

動物園園長，微信公眾號：首席吹牛官，人人都是產品經理專欄作家。互聯網圈十八線作詞人，國家一級退堂鼓表演藝術家。顏良而文丑，歡迎交流。

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

題圖來自Unsplash，基于CC0協議