Ps：說明一下，這里的產品設計主要指的是APP開發。在APP開發中，版本迭代的“節奏感”很重要，每個大的版本迭代時結合產品計劃、用戶規模、市場環境要改進什么功能，這些該如何把握?有沒有什么優秀的產品案例可以探究參考?

　　@朱晨

　　從 鵝廠到ThoughtWorks兩年了，從原來的只是畫畫線框圖到現在可以帶領團隊一起交付產品，對產品節奏感的體會與日俱增。在“騷窩”里浸潤著學到的 敏捷開發也讓我明白如何從技術執行層面支撐產品的有序發布。做產品就是在用戶需求的戰場上攻城略地，而節奏感就是每一次沖鋒時的默契。

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

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

　　對于用戶來說，以穩定的節奏感來更新產品可以：

　　把團隊新實現的產品價值周期性地交付給用戶使用;

　　讓用戶感知到產品的不斷成長，容忍暫時的不足，對新版本形成期待;

　　重新激活部分已經流失掉的僵尸用戶。

　　對于團隊來說，穩定的節奏感帶來的好處也很多：

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

　　產品經理可以不斷推出一些新功能給用戶做實驗，驗證猜想;

　　團隊可以持續地收到用戶的反饋，好的反饋可以鼓舞士氣，差的反饋可以激發調整的動力;

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

　　節奏感應該怎么控制

　　既然剛才已經將“產品的節奏”定義為“產品更新的時間間隔以及每次更新的內容”，那么控制節奏其實也就是這兩點了。確定產品更新的時間間隔相對容易。對于移 動端的產品，由于每次更新都需要iOS版審核，用戶每次更新都需要重新下載，所以定在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結束時給一個穩定可用的版本還不是小意思。

　　想要有節奏地規劃產品，揮斥方遒，其實挺不容易的呢，嗯哼~

　　@鄒建波Kant

　　產品迭代的節奏感是非常重要的。

　　這里可能存在一些誤解，節奏感我認為不是說要非常清楚未來每個版本該做什么，以及未來每一步的意圖，正如蘇杰老師所說，這是不現實的，即使有人說有，也更多是事后諸葛亮。

　　但是產品迭代的節奏感是的確存在的，并且很重要。

　　舉個例子。

　　最典型的MIUI的一周一迭代。一個每周更新的緊湊節奏感，帶給開發團隊，內測用戶和外界非常棒的感覺，各個方面如進化速度，用戶預期，內測者成就感和開發 效率都因而大大提升。這就是典型的節奏感掌握得好。多提一句，MIUI當時的團隊我覺得是不可能預測到幾個月以后會做什么功能的(除非戰略規劃)，但這個 節奏感并不矛盾。

　　如何實現產品迭代的節奏感?

　　我個人對迭代節奏感有這樣的思考：

　　通過穩定的大致固定的迭代周期(且比較快)，強化整個團隊的意識，如非特殊情況，提需求做設計做需求相對錯開。

　　保證每個迭代周期不是為了做個版本而做，每個周期要有切實有用有價值的功能。的確，許多時候我們不知道如何去考慮未來的功能，但是下一個迭代的需求是可以考 慮的(因為往往此前已有許多需求在等待排期了)。這需要考慮開發時間和需求優先級和需求的意義，具體方法更多需要實例來說。

　　確保每一個迭代 周期對用戶預期的滿足。許多產品的迭代周期控制得不錯，但是經常很多版本的更新對用戶毫無意義，不是修復體驗若干，就是帶來什么商家主頁優化，這些用戶不 在乎。每個版本都要給用戶帶來一些新奇，有趣，有價值的功能，確保用戶感知得到你的迭代，和你的節奏感，這樣，用戶會和你們一起來控制和把握，甚至推動這 個節奏感。這一點MIUI和微信都做得特別好，可以多參考下。

分享名稱：產品設計的“節奏感”該如何把握?
文章出自：http://m.newbst.com/news4/159504.html

成都網站建設公司_創新互聯，為您提供微信小程序、域名注冊、軟件開發、定制網站、外貿網站建設、手機網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯