產品經理如何做敏捷管理
在移動互聯網時代,除了確保產品質量之外,產品的時效性也很重要,需要有一種相對更優的產品開發模型可以確保產品質量的同時,提升產品投產效率。于是敏捷開發模型(Scrum)應運而生,產品經理如何做好敏捷管理呢?本文作者對此作出了分析,一起來看一下吧。
“敏捷”常用Agile英文單詞來表示。Scrum英文原意為并列爭球,常出現于橄欖球運動中。近些年網絡對Scrum解釋為迭代式增量軟件開發過程。
Scrum和敏捷不是一回事,隨著近些年在越來越多的JD(Job Description,工作說明)使用Scrum這個詞匯來表示敏捷,Scrum也被賦予了敏捷的涵義。
在PC(Personal Computer,個人電腦)時代,產品開發過程模型常使用瀑布模型(Waterfall Model)、快速原型模型(Fast Prototype Model)、螺旋模型(Spiral model)或是噴泉模型(Fountain model)等。
在PC時代的產品需要通過應用軟件的方式安裝至PC上,因此為了確保產品質量,產品從構建到發布往往要經歷較長的時間,產品開發模型的嚴謹性相對于高效性來講更受重視。
在移動互聯網時代,除了確保產品質量以外,產品的時效性也至關重要。需要有一種相對更優的產品開發模型可以確保產品質量的同時,提升產品投產效率。
敏捷開發模型(Scrum)應運而生,敏捷開發模型是產品經理做敏捷管理的指導理論。產品經理實現產品的敏捷管理,需要結合理論、經驗、工具三個方面共同協作。
產品經理敏捷管理框架如圖1所示。
圖1 產品經理敏捷管理框架
本文先從產品經理敏捷管的價值為出發點,以銀行社區產品為例子,由理論、經驗和工具三個維度,講解產品經理如何做敏捷管理。
一、敏捷管理價值
斯坦迪什集團(Standish Group)主席吉姆·約翰遜(Jim Johnson)曾指出:“產品中64%的功能是很少使用或從未使用過”。
對于產品而言,產品的功能越來越多,功能越來越復雜,來自管理層的需求、來自業務部門的需求以及來自用戶的需求往往會夾雜在一起,使得產品經理對于產品的管理力不從心。
大多數情況下,產品研發團隊為了確保產品按時上線,不得不加班加點進行產品趕工。產品開發時長的增加,人力投入的增多,產品質量卻持續惡化,產品團隊士氣低迷。
市面上的大多數公司盡管投入了大量的人力和金錢,仍然未在產品的成功實現上有所突破,大部分產品以失敗告終,成功投產上線并生存下的產品寥寥無幾。
傳統產品開發管理模式建立在多個假設的前提,諸如產品需求在開發過程中嚴格執行,不能變更,員工能力一定足夠強并且足夠可靠(不會離職)以及產品的市場環境一定不會發生變化等。
很顯然這些前提條件在目前產品開發過程中大概率不會存在。
現實工作中,由于產品管理的缺失或缺陷,導致產品反復推倒重建,產品最終的失敗,以及產品團隊人才的流失等情況數不勝數。
由于互聯網時代的產品具有非一即零的特點,產品失敗后會導致前期所有的投入變為沉沒成本,公司以及產品團隊的努力付之東流,損失巨大。
馬爾文·康威在1967年提出的康威定律中指出:“設計系統的架構受制于產生這些設計的組織的溝通結構。”
隨著產品團隊人員的增加,團隊成員之間的溝通成本會呈指數增長:
溝通成本 = n(n-1)/2
大多數情況下產品團隊會面臨著需求的擴散與產品實現難度的不可控性。產品確定性越高,實現難度越簡單,人員結構簡單,產品達成目標較為容易。
產品復雜度矩陣,如圖2所示。
圖2 產品復雜度矩陣
由此可見,產品經理使用敏捷管理的價值在于面對產品開發的不確定性,最大可能地實現產品預期目標,降低產品失敗的概率,節省產品實施成本。
二、敏捷管理理念
產品敏捷管理的理念是實現產品目標的同時確保產品質量,最終提升用戶對產品的滿意度,增加產品在市場上的競爭力。更多的是傳遞一種價值觀。正如《敏捷宣言》描述得那樣:
- 個體和互動高于流程和工具
- 工作的軟件高于詳盡的文檔
- 客戶合作高于合同談判
- 響應變化高于遵循計劃
敏捷宣言如圖3所示:
圖3 敏捷宣言
產品經理在對產品團隊進行敏捷管理之前,首先需要在產品團隊成員宣導敏捷管理的理念,使得產品團隊成員認同敏捷管理模式和方法,齊心協力共同實現產品目標。真正符合敏捷精神的價值導向能讓產品相關者滿意,并得到公司的管理層的認可。
三、敏捷管理實戰
1. 建立敏捷管理團隊
產品敏捷管理的意義在于能在產品實施過程中的存在的各種不確定以及動蕩的環境下,迎接和適應各種變化,最終實現產品目標。
產品經理實施敏捷管理,在其理念上推崇以人為本,通過建立統一愿景來打造一個響應力強的高效能產品組織。
好的敏捷團隊中工作會使人感到興奮,成員之間協作高效充滿活力,具有較強的凝聚力。
在產品敏捷團隊中,我們設定以下角色:
- 管理者:可以由產品負責人擔任。對產品經理、研發或是測試錄入的產品問題進行評估,分配缺陷。管理者還可通過系統報告了解項目進展及團隊工作量和效率。
- 產品經理:細化產品功能說明,拆解所負責產品模塊功能,細化產品開發任務。
- 研發人員:查看由管理者或是測試人員分配給自己的問題,及時處理、填寫情況并提交工作量記錄。
- 測試人員:及時記錄問題并對開發人員處理之后的問題進行驗證和追蹤。
完成建立敏捷管理團隊后,通過每日的站會方式完成成員之前的信息的同步更新,回顧之前的協作事項,暴露產品研發過程中存在的風險與問題,便于成員彼此之間共同解決問題,更好地協作。
2. 使用敏捷管理工具
本文借助于目前市面上敏捷管理軟件Jira作為管理管理工具。
結合JIRA提供的產品功能,產品經理敏捷管理可以通過以下幾個步驟實施。
第一步:創建Epic(史詩)
Epic是產品的總體目標,建立Epic的目的是為了使產品團隊所有成員明確產品方向,彼此達成共識,共同努力。
第二步:制定Version Releases(版本發布)計劃
產品經理根據產品上線目標,制定產品發布計劃。一般成熟的產品團隊會有固定的版本發布周期,例如可以指定為每個月最后一個星期的星期四。這樣產品團隊成員便于記憶和理解,也容易在腦海中形成穩固的上線目標。
第三步:創建Sprint(沖刺)
在Backlog(積壓的工作)中可以創建Sprint,制定好Sprint后,可以將Backlog中的工作任務通過拖動的方式移入到相應的Sprint。非常方便。
第四步:創建Story(故事)或Task(任務)
在Jira中,Roadmap中的Epic下Task和Story是一個等級,可以在Epic下直接創建Story或是Task。Task下面可以建Sub-Task(子任務)。視具體產品情況,具體分析和操作。
產品經理可以進行任務分解,創建Sub-Task(子任務),創建子任務原則是一般能在一天內完成的任務,是對當前任務的進一步細化。
產品經理建立故事,需要遵循“INVEST”原則,即:
- Independent(獨立),產品功能邏輯自洽。
- Negotiable(可協商),產品故事范圍內的靈活。
- Valuable(有價值),完成產品故事是有意義的。
- Estimable(可估算),完成這個故事需要多長工時。
- Small(?。?,故事是經過細化的。
- Testable(可測試),根據輸入有明確的輸出可驗證。
在所建立的任務中,可以選擇將當前任務安排至哪個Sprint以及相當的版本計劃,估算工作量以及設置任務的其他字段參數。
第五步:看板與報告
看板是常見的產品敏捷管理框架,有助于產品經理和團隊成員透徹了解產品的工作進展和團隊能力。
Jira的數據報告類型有很多種,可以滿足大部分產品經理對敏捷管理過程中的數據進行分析。
比如常見的如Burndown Chart(燃盡圖),Burnup Chart(燃燒圖),Sprint Report(沖刺報告)以及Cumulative Flow Diagram(累積的流程圖)等。
產品經理可以根據實際的工具需求,通過配置和查看相應的數據可視化圖表進行敏捷管理效果評價。
四、小結
產品經理從實際的產品管理中發現,傳統的“瀑布”已經干涸了,在VUCA(Volatility-易變性、Uncertainty-不確定性、Complexity-復雜性、Ambiguity模糊性)的產品環境中,產品管理面臨的全新的挑戰。
敏捷宣言自2001年開始實行,到目前為止已經有二十多年的時間了,敏捷管理的有效性得到了充分的驗證。對于產品管理而言,最合適的就是最好的。在沒有更為卓越的產品管理模式出現之前,產品敏捷管理是相對最優的管理方案。
產品經理的價值不僅在于“做”某些事情,更重要的是“做成”某些事情。做事情容易,做成事情太困難。在漫長的產品實現過程中,產品經理難免會遇到各種困難,要做好長時間坐“冷板凳”的準備。
謀無術則成事難,術無謀則必敗。產品經理只要認定所做的產品的方向是對的,通過敏捷管理的理念與方法,快速驗證產品模型,根據實際產品環境迅速調整產品策略,堅持不懈,一定能迎來產品成功的曙光。
專欄作家#
王佳亮,微信公眾號:佳佳原創。中國計算機學會(CCF)會員。人人都是產品經理專欄作家,年度優秀作者。專注于互聯網產品、金融產品、人工智能產品的設計理念分享。
本文由@王佳亮 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!