<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          Debug≈MVP

          共 3012字,需瀏覽 7分鐘

           ·

          2021-06-26 17:45

          最近撿回了代碼這門手藝,上線了一款微信小程序。表面上看研發(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)五步曲

          微信紅包封面熱潮的背后




          瀏覽 76
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  国产成人精品视频在线 | 日韩在线,欧美,国产在线 | 高清无码视频免费观看 | 看大相交网站官方正版入口 | 日逼网站123 |