回覆列表
  • 1 # 新車小報告

    我們可以先將“產品的節奏”定義為“產品更新的時間間隔以及每次更新的內容”,以便讓大家對頻率有一個統一的概念。一個成長中的產品需要不斷根據業務需求和使用者需求來更新產品。形成穩定的產品更新節奏無論是對產品的成長、對使用者、還是對團隊都會有很大的益處。 對於使用者來說,以穩定的節奏感來更新產品可以:

    把團隊新實現的產品價值週期性地交付給使用者使用。

    讓使用者感知到產品的不斷成長,容忍暫時的不足,對新版本形成期待。

    重新啟用部分已經流失掉的殭屍使用者。

    對於團隊來說,穩定的節奏感帶來的好處也很多:

    保持穩定更新的責任可以督促團隊儘早展示新功能,避免閉門造車太久,走偏了方向。

  • 2 # DOA設計

    做產品就是在使用者需求的戰場上攻城略地,而節奏感就是每一次衝鋒時的默契。

    為什麼產品成長要有節奏感

    在開始討論之前,我們可以先將“產品的節奏”定義為“產品更新的時間間隔以及每次更新的內容”,以便讓大家對頻率有一個統一的概念。一個成長中的產品需要不斷根據業務需求和使用者需求來更新產品。形成穩定的產品更新節奏無論是對產品的成長、對使用者、還是對團隊都會有很大的益處。

    對於使用者來說,以穩定的節奏感來更新產品可以:

    把團隊新實現的產品價值週期性地交付給使用者使用。

    讓使用者感知到產品的不斷成長,容忍暫時的不足,對新版本形成期待。

    重新啟用部分已經流失掉的殭屍使用者。

    對於團隊來說,穩定的節奏感帶來的好處也很多:

    保持穩定更新的責任可以督促團隊儘早展示新功能,避免閉門造車太久,走偏了方向。

    產品經理可以不斷推出一些新功能給使用者做實驗,驗證猜想。

    團隊可以持續地收到使用者的反饋,好的反饋可以鼓舞士氣,差的反饋可以激發調整的動力。

    團隊內可以形成有默契的合作方式,產品經理、設計師、開發、測試都明確地知道什麼時候該做什麼什麼事情。

    節奏感應該怎麼控制

    既然剛才已經將“產品的節奏”定義為“產品更新的時間間隔以及每次更新的內容”,那麼控制節奏其實也就是這兩點了。確定產品更新的時間間隔相對容易。對於移動端的產品,由於每次更新都需要iOS版給Apple稽核,使用者每次更新都需要重新下載,所以定在3~6周釋出一個對外的版本比較合適(緊急修復嚴重bug不算)。如果產品處於快速增長期,這個時間還可以進一步縮短。比如“打車大戰”時的滴滴和快的,新功能晚一步釋出就是個死。

    更關鍵的其實每次更新哪些內容。如果定好4週一個週期,那就意味著一年也就12次更新的機會。產品經理的職責就是要想好如何帶領一幫兄弟們打好這12張牌。如果每次更新都像adobe reader一樣,淨都是些個讓使用者提不起興趣的bug fix,畏畏縮縮的,那這產品也還是不要做了的好。如何籌謀好每個版本,體現了一位優秀的產品經理運籌帷幄,決勝千里之外的掌控力。

    在規劃每個新版本的內容時,可以有兩種選擇:開疆拓土和持續最佳化。開疆拓土是指產品要完全開闢一個全新的疆域,覆蓋全新維度的使用者需求場景,野心勃勃,酣暢淋漓。剛剛把一塊地佔穩了後,這塊土地上還很荒蕪,後續還需要做很多持續改進的工作來搭建關聯輔助的功能,最佳化產品體驗,把這塊荒蕪土地上的生態系統建立起來。只要妥善處理好這兩種形式的新版本,讓它們相輔相成,產品成長的框架就有了。

    開疆拓土是最能體現一位產品經理創造性的地方。它往往意味著從0到1( Zero to One (豆瓣) )去創造出一個有價值、有市場、為產品帶來廣闊成長機遇的新空間。Facebook圈完關係鏈然後搞社交遊戲;GoPro先做運動攝像機,然後搖身一變成為媒體公司搞體育直播;滴滴/快的搞完打車再搞專車;微信先搞定了熟人通訊,然後用搖一搖來打陌生人加好友,接下來是朋友圈分享,再來搞公眾賬號、支付、遊戲分發。這些都是積極進取,從無到有創造價值的典範。同時,開疆拓土也意味著在走少有人走的路,沒有經驗可以借鑑,風險的坑遍地。千萬不要抱著“憋個大招,打磨完美再拿出來嚇死他們”的心態來做開拓性的新功能。務必遵照精益創業的思想,用盡量低的成本在短時間內先發布基本能用的版本,然後再看後續的反饋做調整。你看微信的對講機、影片聊天、小影片這些,不也都不溫不火的嘛。

    持續改進是從0到1之後的從1到n的過程。這部分比較簡單,因為只要前面從0到1這一步走對了,後面就可以根據使用者反饋來被使用者推著走了。使用者們缺乏足夠有深度的思考,想不到更快的馬可以被福特汽車所取代,但坐過福特汽車後吐槽減震太爛了、太TM費油之類的能力還是有的。在改進型版本里,主要是做好這幾類事情:

    最佳化粗糙的介面設計的體驗

    增加跟核心功能相輔相成的功能

    增加讓核心功能更好用的瑣碎小功能

    其實很多中國的產品經理冠著“站在上帝身邊的人”之名,也就是每天在做些個持續改進的事情,修修補補,做完發文字再做發照片、發影片、髮網址、發投票、發文件。

    控制產品節奏感所需要的支援

    專案管理

    依照傳統的瀑布流方式來做APP的話,先花一週來規劃功能,再花一週來設計介面,然後花上一週來實現功能,最後一週QA測試+改BUG,最理想的情況下也是至少4週一個版本。但實際情況更可能是開發做了一半時產品要改個需求,QA測出一堆問題給開發改結果越改越多,最後一公里大家跑的磕磕絆絆然後受迫於所謂節奏感的deadline把帶著一堆BUG的包發掉,或者就乾脆延期。這樣勢必是不行的。

    如果依照敏捷方式來推動專案,情況會完全不同。首先可以將每1周或每2周定做一個Sprint,將需求切分成合適顆粒度的story,然後在每個Sprint內設定好合適的工作量,團隊裡各個角色高效協作、並行驅動,就可以確保在Sprint結束時得到可釋出的新版本。這樣的話,3~6周的對外版本釋出是可以保障的。即便是MIUI這樣的每1周做一次釋出,也完全沒問題。

    技術支援

    想要穩定地控制產品中的BUG風險,其實是需要相當多的技術力量做保障的,否則很可能程式碼裡總是會有無窮無盡的BUG,程式碼隨著產品成長還會越來越複雜,想拿出一個穩定可釋出的版本都難。在XP的敏捷實踐裡其實是有很多方法來保障程式碼穩定的。

    TDD 測試驅動開發

    TDD會要求開發在寫程式碼之前先仔細分析好需求,想好要實現的這部分功能對應的測試場景有哪些,然後基於此來先寫好單元測試,再來寫實現。這樣做的好處是有了這些單元測試的保護,程式碼始終是健壯的。即便以後程式碼變得複雜,或者要重構修改程式碼,只要單元測試跑不過時不要check-in程式碼,就不會引入BUG。

    CI 持續整合

    在每個開發的單元測試都能跑過的基礎上,我們可以用CI來監控整體的程式碼。只要有Dev搞掛了CI,技術lead就可以打他屁股了。由於CI是完全自動化地在實時run測試,所以只要任何人check-in的新程式碼有問題,就可以及時查出來,這樣就可以避免Bug引入並積壓,讓我們隨時都有可用的版本。那每個Sprint結束時給一個穩定可用的版本還不是小意思。

  • 中秋節和大豐收的關聯?
  • 諸葛亮足智多謀,為何會選擇輔佐劉備?