比较好的棋牌游戏

雜談產品灰度上線的研發模式

傳統的產品研發模式大致可以分爲:產品調研-架構評估-產品啓動-需求分析-產品設計-產品開發-產品發布七大階段。本人在公司經歷過大大小小的項目數以百計,發覺這些階段一直以來都是以一條直線的形式串行著:從產品調研到產品發布,總是一拖到底。這樣的做法對於範圍比較大,周期比較長的項目,尤其是用戶體驗類項目而言,存在較大的弊端:我們很可能在沒有足夠清楚用戶需求的情況下,定製了過多的輔助功能,這樣即拉長了項目周期,又無謂的投入了過多的人力,在資源如此寶貴的今天,浪費資源實在太過奢侈,我代表春哥鄙視之…

言歸正傳,切入今天要談的話題 —-「產品灰度上線的研發模式」。何謂「灰度上線」,簡單點理解就是按產品需求優先級,抽出核心需求,在滿足用戶基本要求的情況下快速上線,並通過限制流量、白名單等機制進行產品試用,以此收集用戶的意見,從而萃取出用戶潛在的需求,形成後續更有針對性的設計方案。

和傳統研發模式相比,這麼做唯一的區別就在於將原先一鍋粥式的需求和功能點進行了輕重緩急的排序,並以此將項目從原來的單長線作戰轉化爲多疊代短線循環,讓產品的生命周期不再曇花一現。

如此一來,需求分析階段顯得尤爲關鍵,我們必須清晰的將需求按優先級歸納分類爲幾個序列,如:p1,p2,p3…核心功能和必備的體驗在p1序列,輔助功能點和輔助型體驗列在p2序列,爭執不定的需求點可以放在p3序列。需求排序後,我們可以將項目發布點有序的分成(>2期),第一期只確保主要的核心功能和基礎體驗快速灰度上線,隨後通過用戶訪談、產品的tracker&session數據、業務數據等手段分析出用戶對產品的真實反應,並以此調整二期需求,該加的加,該砍的砍,做到有的放矢。

有畫面有真相,我們就以支付寶個人版三期中提醒代扣項目的研發始末爲反例,正視我們現有研發模式中存在的問題:整個項目從產品啓動到產品發布歷時近3個月之久,發布後卻尷尬的發現用戶的青睞程度並不高,甚至可以用「門可羅雀」來形容產品使用率之慘澹,當然產品的始作蛹者可以推託怪罪於運營力度不夠,也可以感慨產品的身不逢時,但是作爲產品的設計者,在用戶需求並不明朗,且欠東風的情況下除了核心功能,你完全沒必要夾雜過多的輔助功能、體驗…試想,在這個項目中,我們採用灰度上線的研發思路,那麼這款產品的核心功能上線周期將縮短一倍有餘,我們將贏得足夠的時間觀察用戶,並形成相應的運營策略以及產品體驗的優化策略。比之將產品一捅到底後奄奄一息,合理的規劃疊代研發將使你的產品呈現出更旺盛的生命力,這樣才可能撐過你感嘆的「身不逢時」。

當然從產品角度來看,我們必須肯定提醒代扣的戰略意義,他將成爲支付寶會員的理財管家,繳費、還款、充值、付款等等操作都可以在這個平台上進行定製,非常便捷,絕對堪稱支付寶一款「偉大」的產品。但是再偉大的產品,在一個不適合的時間通過不恰當的方式誕生,也無怪受人唏噓,唏噓的絕非產品本身,而是產品的設計規劃和研發模式,恩,設計師,你懂的!

作爲一個非專業流程管理人員誇誇其談了這麼多,實感不易,不論說的怎麼樣,最後還是要總結呈詞:產品灰度上線的研發思路,其好處就在於將原先一鍋粥的需求按輕重緩急做了一個排序,並將原來一捅到底的研發模式合理的做了一個疊代的循環,即縮短了產品核心功能的上線的周期,又大大降低了未明需求情況下的資源浪費,可謂雙贏。尤爲重要的是,通過有計劃的疊代開發,我們可以真正做到以用戶爲中心的設計理念。

純屬個人感觸,有磚的儘管砸…

來源:http://ued.alipay.com/2010/06/topics-for-product-r-d-intensity-on-line-mode/

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
圈子
  • 產品經理羣
  • 運營交流羣
  • 營銷增長羣
  • 文案交流羣
  • Axure學習羣
關注微信公衆號
大家都在問