Debug≈MVP

最近撿回了代碼這門手藝，上線了一款微信小程序。表面上看研發(fā)崗和產(chǎn)品崗需要掌握的知識和工作流程都不一樣，從近期實踐中通過一些技術(shù)理念聯(lián)想到一些產(chǎn)品感悟，下面和大家一起聊一下一下技術(shù)和產(chǎn)品有哪些“共性”。

如果你恰好對宇宙/火星感興趣，也可以訪問我做的微信小程序“每天看宇宙”，里面可能捕捉不到天鵝座的來信，但能看到NASA漫游者號回傳過來的火星表面。

 

 Debug（代碼調(diào)試）≈ MVP（最小可行性產(chǎn)品）

 

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

 

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

 

一頭小馬跑到河邊，剛抬起前蹄，旁邊的松鼠就大叫了起來，你不要命啦！小馬說，讓我試試吧，它下了河，小心的趟過去。原來河水既不像老牛說得那么淺，也不想松鼠說的那么深。很多事情只有自身去做了，才會有感受。否則聽從他人建議或反饋都是相對的，最好的做法就是先做一個最小可行性產(chǎn)品（MVP），一步一步加以驗證去達到產(chǎn)品與市場契合度（PMF）

 

在企業(yè)組織上字節(jié)跳動的部分業(yè)務線也是追求快速獲取結(jié)果，而結(jié)果需要盡可能是好的，如果不好就迅速調(diào)整。首先會保證管理及執(zhí)行的人在能力預期上沒有問題，其次目標清晰，如果結(jié)果不如預期就立馬更換下一批頂上，組織的快速調(diào)整有助于始終讓團隊走在正確的沖刺道路上。所以在外界還有另外一個風評，說字節(jié)是靠“迭代中高層管理”來推動進展的企業(yè)。

 

不管是代碼的debug，利用產(chǎn)品MVP找到PMF，還是字節(jié)跳動的管理調(diào)整，本質(zhì)都是通過小步驗證測試重復性調(diào)整，來達到提高容錯，達到成功。

 

code review  ≈ 產(chǎn)品復盤

 

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

 

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

 

• 什么不該做

• 什么繼續(xù)做

• 什么開始做

 

以“積分體系”為例，現(xiàn)在積分體系是很多產(chǎn)品的標配，在幻想著上了積分體系就能提高用戶活躍和留存，但現(xiàn)實給你來了一大嘴巴子。

 

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

 

• 對于完成度低且業(yè)務無關(guān)的任務盡可能的剔除

• 對于完成度低且是核心業(yè)務的任務，適當降低任務難度并且提高完成任務獎勵（縮短任務路徑，自動領(lǐng)取）

• 對于完成度高且與業(yè)務目標影響不大的任務，盡可能剔除或者降低完成任務獎勵

 

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

 

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

 

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

 

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

 

代碼追求可復用 ≈ 產(chǎn)品追求架構(gòu)最優(yōu)

 

可復用指的是一段代碼可被多處地方調(diào)用執(zhí)行，而不需要重新編寫一遍，如點擊跳轉(zhuǎn)至新聞列表和在新聞列表下拉刷新，兩個動作在代碼邏輯本質(zhì)上都是獲取最新的內(nèi)容數(shù)據(jù)，如果在點擊跳轉(zhuǎn)處和列表下拉分別寫上兩段獲取內(nèi)容數(shù)據(jù)的代碼，顯得代碼冗余且維護不便，一旦涉及變動則兩處地方都要修改。如果把獲取內(nèi)容抽象成一個方法，供點擊跳轉(zhuǎn)和下拉請求時調(diào)用，則變得十分友好。

 

為什么有些產(chǎn)品給人感覺十分笨重，有些產(chǎn)品給人感覺流暢清晰的體驗，除了產(chǎn)品本身的業(yè)務復雜性外，產(chǎn)品架構(gòu)也有優(yōu)秀和平庸之分。

 

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

 

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

 

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

 

 

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

 

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

 

 

關(guān)于產(chǎn)品人員需不需要懂技術(shù)，該懂多少這一話題一直有兩種聲音，有人認為產(chǎn)品經(jīng)理最好的情況是不懂技術(shù)，這樣才能突破邊界。恰好又有人覺得如果懂技術(shù)，可能會限制產(chǎn)品本身。個人認為，明確自己邊界比突破邊界更為重要，因為大多數(shù)產(chǎn)品設計是需要在邊界認知內(nèi)完成。

 

產(chǎn)品人員不能光有天馬行空的想法，需要在一定的事實之上，否則只是在無效的工作上浪費時間。如果熟悉前端組件的相關(guān)屬性以及對應屬性的值可以快速得出決策，以調(diào)起相機為例， 閃光燈和攝像模式等都是相機組件的屬性，而屬性又有對應不同的值，比如攝像模式是掃碼還是拍照/錄像，閃光燈是開啟還是關(guān)閉等等。知道相機有那么多屬性不影響突破產(chǎn)品邊界，更不影響做出一款好的相機產(chǎn)品，反而如果不知道則無法評估實現(xiàn)預期和成本。

 

 

往期精選：

好的產(chǎn)品需求文檔擁有6個共性

增長黑客實戰(zhàn)五步曲

微信紅包封面熱潮的背后