最近撿回了代碼這門手藝，上線了一款微信小程序。表面上看研發(fā)崗和產(chǎn)品崗需要掌握的知識(shí)和工作流程都不一樣，從近期實(shí)踐中通過(guò)一些技術(shù)理念聯(lián)想到一些產(chǎn)品感悟，下面和大家一起聊一下一下技術(shù)和產(chǎn)品有哪些“共性”。如果你恰好對(duì)宇宙/火星感興趣，也可以訪問(wèn)我做的微信小程序“每天看宇宙”，里面可能捕捉不到天鵝座的來(lái)信，但能看到NASA漫游者號(hào)回傳過(guò)來(lái)的火星表面。 Debug（代碼調(diào)試）≈ MVP（最小可行性產(chǎn)品）
開(kāi)發(fā)5分鐘，調(diào)試2小時(shí)，這是我最初寫代碼的真實(shí)現(xiàn)狀，因?yàn)楫?dāng)初不懂如何去debug，寫了一大坨代碼，然后自信點(diǎn)擊運(yùn)行控制臺(tái)顯示報(bào)錯(cuò)，如果用的比較舊的IDE編輯器光靠瀏覽去發(fā)現(xiàn)代碼問(wèn)題，效率非常低下。比如變量名拼寫錯(cuò)誤，部分語(yǔ)句出現(xiàn)中英文符號(hào)等，可能找個(gè)大半天。debug能夠比較快速的定位代碼問(wèn)題，控制程序的運(yùn)行節(jié)奏，確定程序的運(yùn)行路徑，不斷縮小范圍，找到出錯(cuò)位置，最終修改成功運(yùn)行。做產(chǎn)品有沒(méi)有像代碼debug一樣，能夠一步又一步的加以驗(yàn)證？特別是做C端的朋友一定經(jīng)常遇到以下的情景。一頭小馬跑到河邊，剛抬起前蹄，旁邊的松鼠就大叫了起來(lái)，你不要命啦！小馬說(shuō)，讓我試試吧，它下了河，小心的趟過(guò)去。原來(lái)河水既不像老牛說(shuō)得那么淺，也不想松鼠說(shuō)的那么深。很多事情只有自身去做了，才會(huì)有感受。否則聽(tīng)從他人建議或反饋都是相對(duì)的，最好的做法就是先做一個(gè)最小可行性產(chǎn)品（MVP），一步一步加以驗(yàn)證去達(dá)到產(chǎn)品與市場(chǎng)契合度（PMF）在企業(yè)組織上字節(jié)跳動(dòng)的部分業(yè)務(wù)線也是追求快速獲取結(jié)果，而結(jié)果需要盡可能是好的，如果不好就迅速調(diào)整。首先會(huì)保證管理及執(zhí)行的人在能力預(yù)期上沒(méi)有問(wèn)題，其次目標(biāo)清晰，如果結(jié)果不如預(yù)期就立馬更換下一批頂上，組織的快速調(diào)整有助于始終讓團(tuán)隊(duì)走在正確的沖刺道路上。所以在外界還有另外一個(gè)風(fēng)評(píng)，說(shuō)字節(jié)是靠“迭代中高層管理”來(lái)推動(dòng)進(jìn)展的企業(yè)。不管是代碼的debug，利用產(chǎn)品MVP找到PMF，還是字節(jié)跳動(dòng)的管理調(diào)整，本質(zhì)都是通過(guò)小步驗(yàn)證測(cè)試重復(fù)性調(diào)整，來(lái)達(dá)到提高容錯(cuò)，達(dá)到成功。code review ≈ 產(chǎn)品復(fù)盤Code Review可以理解為一群人對(duì)一坨代碼基于某種規(guī)則下進(jìn)行審查，找出違背相關(guān)規(guī)則的代碼塊提出解決方案，既能夠提高代碼的質(zhì)量還能夠提升個(gè)人成長(zhǎng)，這算個(gè)人及整個(gè)研發(fā)團(tuán)隊(duì)極其有效的進(jìn)步方式之一。產(chǎn)品團(tuán)隊(duì)也有相似的進(jìn)步方式，針對(duì)項(xiàng)目/版本做有效復(fù)盤，也能得到快速的成長(zhǎng)，具體怎樣才算是有效，包含以下3個(gè)結(jié)論以“積分體系”為例，現(xiàn)在積分體系是很多產(chǎn)品的標(biāo)配，在幻想著上了積分體系就能提高用戶活躍和留存，但現(xiàn)實(shí)給你來(lái)了一大嘴巴子。在復(fù)盤時(shí)找準(zhǔn)關(guān)鍵要素和預(yù)期目標(biāo)，如積分體系可以按“任務(wù)完成度”和“是否貼合業(yè)務(wù)目標(biāo)”來(lái)來(lái)進(jìn)行復(fù)盤調(diào)整。對(duì)于完成度低且業(yè)務(wù)無(wú)關(guān)的任務(wù)盡可能的剔除
對(duì)于完成度低且是核心業(yè)務(wù)的任務(wù)，適當(dāng)降低任務(wù)難度并且提高完成任務(wù)獎(jiǎng)勵(lì)（縮短任務(wù)路徑，自動(dòng)領(lǐng)?。?/span>
對(duì)于完成度高且與業(yè)務(wù)目標(biāo)影響不大的任務(wù)，盡可能剔除或者降低完成任務(wù)獎(jiǎng)勵(lì)
什么不該做，比如發(fā)現(xiàn)點(diǎn)贊完成度非常高且占比積分來(lái)源很高，但點(diǎn)贊與被點(diǎn)贊對(duì)平臺(tái)和用戶均無(wú)有效作用時(shí)，是否可以考慮刪除。什么繼續(xù)做但需要調(diào)整，比如“邀請(qǐng)好友”是一個(gè)核心任務(wù)，但完成度比較低是否應(yīng)該提高獎(jiǎng)勵(lì)還是降低難度門檻，但如果深挖發(fā)現(xiàn)“邀請(qǐng)”過(guò)來(lái)的用戶均是非質(zhì)量用戶，此時(shí)是否重新平衡一下邀請(qǐng)難易度，如好友注冊(cè)后登陸 獲得X 次日登陸獲得Y。什么需要開(kāi)始做，比如發(fā)現(xiàn)積分持有人數(shù)和數(shù)量呈兩極分化，即沒(méi)有養(yǎng)成新用戶獲取積分習(xí)慣，有一個(gè)1積分就能兌換的禮物，感受到積分的價(jià)值后是否能讓新用戶養(yǎng)成活躍持續(xù)留存。失敗從來(lái)不是成功之母，高質(zhì)量的復(fù)盤才是。代碼追求可復(fù)用 ≈ 產(chǎn)品追求架構(gòu)最優(yōu)可復(fù)用指的是一段代碼可被多處地方調(diào)用執(zhí)行，而不需要重新編寫一遍，如點(diǎn)擊跳轉(zhuǎn)至新聞列表和在新聞列表下拉刷新，兩個(gè)動(dòng)作在代碼邏輯本質(zhì)上都是獲取最新的內(nèi)容數(shù)據(jù)，如果在點(diǎn)擊跳轉(zhuǎn)處和列表下拉分別寫上兩段獲取內(nèi)容數(shù)據(jù)的代碼，顯得代碼冗余且維護(hù)不便，一旦涉及變動(dòng)則兩處地方都要修改。如果把獲取內(nèi)容抽象成一個(gè)方法，供點(diǎn)擊跳轉(zhuǎn)和下拉請(qǐng)求時(shí)調(diào)用，則變得十分友好。為什么有些產(chǎn)品給人感覺(jué)十分笨重，有些產(chǎn)品給人感覺(jué)流暢清晰的體驗(yàn)，除了產(chǎn)品本身的業(yè)務(wù)復(fù)雜性外，產(chǎn)品架構(gòu)也有優(yōu)秀和平庸之分。張小龍?jiān)?021年微信公開(kāi)課末尾提到的微信依舊保持簡(jiǎn)單和“小而美”，很多人會(huì)把微信占用手機(jī)存儲(chǔ)空間或者安裝包大小來(lái)進(jìn)行反駁。如果以存儲(chǔ)空間或安裝包大小來(lái)衡量產(chǎn)品是否“小而美”，恐怕只有鬧鐘、備忘錄這類應(yīng)用符合大家胃口。簡(jiǎn)單和小而美由微信產(chǎn)品架構(gòu)帶來(lái)的結(jié)果。簡(jiǎn)單建立在易理解性上， 確保用戶方便找到和輕易使用,如微信內(nèi)有多個(gè)掃一掃入口，并沒(méi)有追求絕對(duì)簡(jiǎn)單只保留一個(gè)掃一掃入口。小而美建立在高拓展性上，如果拓展性弱產(chǎn)品只會(huì)越做越臃腫。從更高維去看，其實(shí)代碼可復(fù)用程度和產(chǎn)品架構(gòu)高度掛鉤，優(yōu)秀的產(chǎn)品架構(gòu)能夠讓多處代碼得到復(fù)用的可能，同時(shí)如果意識(shí)到多處代碼可復(fù)用，能有效遏制不良的產(chǎn)品架構(gòu)，這也是為什么研發(fā)人員的架構(gòu)能力比產(chǎn)品人員的要更強(qiáng)一些，因?yàn)榭紤]到了技術(shù)架構(gòu)和拓展性。在微信自帶開(kāi)發(fā)者工具中會(huì)提醒wx.showLoading和wx.hideLoading必須配對(duì)使用，這是為了避免程序進(jìn)入“死循環(huán)”，因?yàn)樵谡{(diào)用wx.showLoading時(shí)會(huì)顯示 loading 提示框。需主動(dòng)調(diào)用 wx.hideLoading 才能關(guān)閉提示框。為什么有開(kāi)發(fā)會(huì)對(duì)產(chǎn)品貼上“不靠譜”標(biāo)簽，據(jù)了解多數(shù)都是因?yàn)樵趯?duì)接中產(chǎn)品需求邏輯不夠完善，一些異常流程經(jīng)常性忽略。因?yàn)楫a(chǎn)品經(jīng)理在設(shè)計(jì)流程時(shí)都往好的一方面去思考，沒(méi)有考慮到較差的一面。有發(fā)布成功的結(jié)果就會(huì)有發(fā)布中狀態(tài)和發(fā)布失敗的狀態(tài)。關(guān)于產(chǎn)品人員需不需要懂技術(shù)，該懂多少這一話題一直有兩種聲音，有人認(rèn)為產(chǎn)品經(jīng)理最好的情況是不懂技術(shù)，這樣才能突破邊界。恰好又有人覺(jué)得如果懂技術(shù)，可能會(huì)限制產(chǎn)品本身。個(gè)人認(rèn)為，明確自己邊界比突破邊界更為重要，因?yàn)榇蠖鄶?shù)產(chǎn)品設(shè)計(jì)是需要在邊界認(rèn)知內(nèi)完成。產(chǎn)品人員不能光有天馬行空的想法，需要在一定的事實(shí)之上，否則只是在無(wú)效的工作上浪費(fèi)時(shí)間。如果熟悉前端組件的相關(guān)屬性以及對(duì)應(yīng)屬性的值可以快速得出決策，以調(diào)起相機(jī)為例， 閃光燈和攝像模式等都是相機(jī)組件的屬性，而屬性又有對(duì)應(yīng)不同的值，比如攝像模式是掃碼還是拍照/錄像，閃光燈是開(kāi)啟還是關(guān)閉等等。知道相機(jī)有那么多屬性不影響突破產(chǎn)品邊界，更不影響做出一款好的相機(jī)產(chǎn)品，反而如果不知道則無(wú)法評(píng)估實(shí)現(xiàn)預(yù)期和成本。增長(zhǎng)黑客實(shí)戰(zhàn)五步曲
微信紅包封面熱潮的背后
