思考:互聯網產品一站式研發協同如何快速開始

2017年1月13日舉辦的【雲棲計算之旅】線下沙龍第4期研發管理專場,阿里巴巴協同研發平台產品專家李智為大家帶來了題為互聯網產品一站式研發協同的快速開始的演講。本文主要從產品研發方法論開始說起,談到了項目協作的重要性和一站式帶來的好處,也講解了產品如何快速開始,最後對開發平台的團隊配置和願景做了總結。

以下為精彩內容整理:

反饋&數據驅動——產品研發方法論

該方法論不是用戶說的算,也有PD的參與,主要從共創用戶開始,去藉助用戶的實際使用,觀察和收集用戶反饋,跟隨用戶的業務發展同步的去引進產品,也就是說產品服務你的共創用戶,當你的共創用戶由小變大的時候,你的產品也在由小變大,一旦你的產品的差異化競爭力形成了,就可以開始定向的向更多用戶去推廣,這個時候是以高留存率為標準,去快速的收穫用戶,當用戶積累到一定量時,就開始面向市場發力,最後達到一鳴驚人的爆髮式效果,從而取得產品的成功,這也是很多互聯網產品所走的路徑,阿里的釘釘就是走這樣的產品研發方法論,這種成功是可以被複制的,非常適合當下互聯網行業的發展。

我們是在研發平台中內置這個功能,通過建立互聯網用戶和產品研發同學之間的連接對產品發展形成一個強有力的驅動,上圖是我們內部做數據驅動時經常用到的數據圖表。

實踐當中,當用戶和研發人員建立連接後,10個提問會有一個提問時涉及到缺陷和需求的,十分之一的提問可以轉化為研發工作項,十分之一的提問需要人工參與回復答疑,並且沉澱產品研發知識庫,十分之八的提問機器人自動回復,這也是當前比較熱門的AI。

在產品研發過程中,如果按照波士頓矩陣的劃分,這樣的產品方法論是比較適合幼童、明星這兩個象限的產品,也就是偏前期和中期,特別是產品研發投入最大的時候;如果是金牛和瘦狗象限的,可能作用會小一些,金牛更多的是回收你的成本。另外,產品本身的模塊和頁面的功能也可以用波士頓矩陣來劃分。

數據驅動也是我們產品研發的一大利器,用戶提問數是一個非常好的核心對象,創建需求缺陷就像淘金剩下的金子一樣,它是來自於用戶實際使用當中所沉澱下來的發展產品的,這樣做出來的功能會非常貼近用戶需要。

NPS

NPS(凈推薦率)是一種超級易用且非常有效的方式,這是一個-100到100之間的百分比值,一般來講,能拿到正分已經很不錯了,如果能拿到50分以上,說明你的產品有非常好的口碑和影響力。在產品研發過程中,去實施NPS有兩個要點:一是要基於用戶行為數據去調研,一是要形成產品研發的閉環。所以一定要拿到分數背後的轉換成需求和缺陷的工作項,藉助整個研發協同去迭代,而在新的迭代上有可以拿到新的NPS數據反饋,整個的閉環會讓你的產品以直線的方式最快的發展。

項目協作的重要性

有的互聯網創業團隊直到資金快用光了時才恍然大悟,原來我做的產品沒有用戶需要,如果能夠及早的跟用戶在一起,在用戶實際的使用當中去關聯需求,悲劇就可以避免掉。產品需求應該與天使用戶去對等的交流,在實際使用中提問,加上產品經理的智慧和老闆的投入支持,使項目協作和需求管理完美結合。

其次,我們要關注缺陷,做到嚴格區分,優先解決,主動服務。當缺陷變多,會影響研發團隊效率。迭代、風險、敏捷等項目結構中的進階也非常有用,比如阿里的雙十一,最重要的是風險管理。

一站式帶來的好處

大家都在走一站式的趨勢,比如gitlab最近的版本就逐漸的在向橫向擴展,一站式之所以普遍認同,很關鍵的一點,單個垂直領域做的不錯的如果要去跟目錄服務進行打通,就會很痛苦,要去改一遍人員&組織機構、賬號&許可權等,資源組服務就更頭疼了,它跟產品研發依賴的伺服器、資料庫、搜索引擎以及所有基礎服務的連接也非常麻煩。

簡單來講,我們走的是全、整體最優的路線。全是指產品研發需要的服務都會引入到研發中台來,並且做好同其他服務的連接,產品研發人員看不到中間的改變,都是天然的一體的,更多的是底層數據的打通,當做一個上線發布時,代碼發布後需求和缺陷是流動的,我們可以知道這一次上線影響了哪些需求和缺陷;整體最優是指圍繞產品研發迭代的小閉環,也是產品應用發展的大閉環,去做到整體最優。我們追求的是項目協作、代碼服務、持續交付、測試服務的全局最優,在研發效率、質量上去獲得最佳的平衡點。

研發協同平台的必要性

  • 對中小企業而言,零投入的去使用公有雲是必要的,原本資金人力投入就不富裕,如果還要投入到代碼託管、持續集成、持續交付、項目協作這些工具的集成上,就很不划算;
  • 對於大企業來說,可以考慮自建,如果研發協同不是自己的主業,可以考慮小投入,Gitlab、Jenkins、Jira等開源產品作為基礎,可以購買商業套件進行二次開發;如果是大投入發展自己主業的話,可以自研。

快速開始

產品研發要如何快速開始呢?

我們做到7天發布Beta版,14天發布1.0版。快速開始最初的5分鐘是很重要的,就是上線應用,如果一個開發人員做一個功能超過一天以上,要麼是個人能力不夠,要麼是技術不夠成熟。上線應用類似於圖中的微博頁面,什麼功能都不要,上線一個Coming soon應該還是沒什麼壓力的,這樣你的用戶和研發人員就可以建立連接,開始溝通了,這就是反饋和數據驅動的小根據,能夠初始提供及時溝通反饋和數據埋點的採集,接下來就是套一個小閉環就可以了。

數據驅動

當你看一個頁面功能時候,給到它一個UV很多,但人均PV又不高,那就只有兩條路可以走,一是把功能做的更好,不要浪費給你的流量,另外是去調整用戶訪問的路徑,把這樣的功能放到合適的路徑中去。

SLA是穩定性的衡量指標,如果總是出現404、5xx,肯定沒辦法和用戶好好相處了,那恢復時長、持續可用時長這些指標能夠幫助產品提升穩定性。

GMV與商業模式有關,提升起來產品研發是要借力打力的,一般來講會在業務的鏈路當中去分析核心對象的增長,找到瓶頸點去一通百通。

互聯網產品一站式研發協同平台

對於互聯網產品研發團隊而言,1產品+3研發+2數據+1運營的7人組合是再好不過的豪華陣容了;如果投入不了那麼多的人力,那麼1產品兼數據兼運營+2開發的3人精簡小隊也是可以接受的。

我們的願景是做軟體生產運營夢工廠,提升研發效能,讓協作更簡單,讓交付更高效,目前我們正在做阿里雲一方產品公測商業化。

相關文章推薦:

聽阿里專家講述企業研發管理的最佳實踐

雲效平台簡介

從雲效1.0到2.0的升級,看技術如何驅動企業提效


推薦閱讀:

<張成功項目管理記>筆記
[專題思考] 為什麼我們總愛討論技術與業務之間的那些是是非非?
有對策 | 如何將項目管理做到極致
測試不是對抗而是一劑預防針 - 我們一起學項目管理 (三十七)
線性&沙盒遊戲與項目管理

TAG:互聯網產品 | 項目管理 |