產品經理如何利用敏捷思維進行版本迭代?
編輯導語:產品經理在日常工作中總會遇到很多需求,一些需要改動或者更新迭代的需求要特別注意,不然很容易出現bug,導致后期問題頻繁;本文作者分享了關于產品經理如何利用敏捷思維進行版本迭代,我們一起來學習一下。
做產品時,你是否遇到以下這些情況?
- 需求反復變動,改某一處邏輯,開發的工期就得加倍,項目無限延期。
- 開發做出的項目,bug不但多,而且經常改不好,常常是改了一個bug,又出現另外一個bug,好不容易把一個bug改好了,過了沒多久又重現;原本好好的功能,反而因為改bug導致出現更多問題。
- 開發完全不按PRD做,前端邏輯沒搞清楚,就按著視覺稿寫代碼。最終做出來的東西不是產品經理想要的,兩邊理解的完全不一樣。而項目已經開發完了。
- 項目延期不是最壞的結果,更壞的結果是還不知道項目到底要延期多久,沒辦法準確的衡量工作量,團隊成員加班加點,態度端正,精神可嘉,搞但就是搞不懂問題到底在哪里。
- 團隊戰斗力每況愈下,經常對著干,在項目群打字說話陰陽怪氣,不愛語音溝通,各自單干,出現問題后第一時間甩鍋,不是我的問題,后端說是前段的問題,前段說是后端的問題。
如果你遇到以上一個或多個問題,那么多半是開發模式存在問題。
最近筆者接觸一個項目也遇到了以上問題,于是花了一些時間研究, 發現敏捷開發,是解決這些問題最好的方式;這篇文章,分享下敏捷相關的理論。
01 敏捷
敏捷,字面意思是迅速、靈敏的意思,如:行動敏捷、思維敏捷;敏捷通常用于描述快速而靈活的完成某件事情。
敏捷開發,就是快速而靈活的完成開發。在幾十年前,互聯網項目剛剛起步的時候,做一個系統需要幾個月或者幾年;這類項目,與傳統的建筑或工業項目類似,需要嚴格按照計劃、分析、設計、實施、維護的流程,不能隨意變動。
但隨著互聯網的發展,市場變化越來越快,互聯網項目必須快速響應市場變化,傳統的這種開發方法已經變得笨拙,敏捷才能快速響應變化。
敏捷有2個特點:『增量』『迭代』;增量是指價值的增量,即每個版本的迭代,都可以帶來價值的增量。
價值分為用戶價值和產品價值,用戶價值是從用戶的角度,新增的功能/內容,對用戶能夠帶來某些價值,這些價值可以用經濟學中的效用來體現,常見的效用如:貨幣、時間、情緒等,增量的用戶價值可以是增加收入或降低成本。
產品價值是從平臺/產品的角度來說的,是所有用戶價值的總和,產品價值=(新體驗-久體驗)-遷移成本;從另外一個角度來說,產品價值還代表著對公司的貢獻,比如帶來收入、實現社會價值等。
總之,每個版本的迭代,一定能帶來增量的價值,如果不能,這個版本是沒有意義的。
敏捷的另一個特點是迭代,迭代的核心思路是小步快跑,有句話說的好,好的系統是迭代出來的,而不是架構出來的。
快速打造MVP,然后投放市場,快速試錯,當產品方案和問題匹配時,再擴大市場規模,當產品方案和市場匹配時,再進行更大規模的擴張;小步快跑的迭代,是實現精益創業最好的方法。
02 實施敏捷
關于敏捷開發,有個著名的敏捷宣言:
- 個體和互動高于流程和工具:相對于繁瑣的流程和固定的工具,個人的主觀能動性和團隊之間的良好互動,更有利于敏捷。
- 工作的軟件高于詳盡的文檔:PRD寫得再完美無缺,如果做出的產品漏洞百出,邏輯不同,也無濟于事,敏捷更強調最終的產出,而沒那么關注過程;筆者之前就遇到過這樣的情況,PRD寫得非常細,但研發測試粗心大意,沒按需求實施,導致最終做出來的產品,bug非常多,不盡人意。
- 客戶合作高于合同談判。
- 響應變化高于遵循計劃:互聯網項目,具備短平快的特點,變更需求經常發生,實施敏捷的團隊,能響應變化,而不是一成不變的遵循計劃。
敏捷,強調的是一種思想,類似于面向對象,具體要實施敏捷,有多種實施的框架,最常用的是Scrum,我把Scrum簡單的梳理成了幾個部分:兩個工件、三個角色、四個會議,簡稱二三四。
1)兩個工件:需求列表Product Backbog、迭代(沖刺)計劃Sprint Backbog;產品經理將收集到的用戶需求,匯總到需求列表,然后從其中選出優先級高、有價值的需求,組成迭代的版本計劃。可以關注刀哥公眾號(刀哥說),獲取需求列表模板。
2)三個角色:產品負責人(Product Owner)、敏捷教練(Scrum Master)、技術團隊(Team);產品負責人通常就是產品經理,敏捷教練是團隊的服務型領導,負責團隊協作、組織會議、處理相關問題等,技術團隊包含前后端、UI、測試、運維等所有實施角色。
PO的重要性,不亞于一個技術團隊,PO主要對產品價值和驗收負責,如果提出的需求沒有價值,相當于整個版本的迭代就是在白做;所以,作為產品經理,一定要把更多的精力放在『如何實現用戶價值/產品價值』上面,畫原型、做項目管理都是過程而已,PO要拿結果說話,對價值負責、對技術團隊負責。
產品經理如果一直把精力放在功能設計、產品設計上面,很難有提升,要提升還得多關注用戶和產品價值,產品大佬唐韌把產品分成四個階段,你可以對比下當前處于哪個階段。
3)四個會議:迭代啟動會、站立會、評審會、回顧會。
迭代啟動會是PO給技術團隊過需求,需求有問題PO進行調整,直到完全澄清,然后技術團隊開始評估工期。
站立會是在迭代周期內,相關成員每天早上開站立會議,一般不超過5分鐘,成員依次描述昨天已完成工作、今天計劃、當前問題。
評審會是有技術團隊給PO演示開發成果,由PO進行驗收。
回顧會議則是迭代版本上線后,收集本次迭代的問題,提出建議,以便下一次更好的合作;如果當前版本有遺留問題,則將問題加入下一個版本的需求列表。
03 敏捷和瀑布
敏捷和瀑布是兩種開發模型,瀑布模型更像是傳統建筑工程的模型,這種模型強調步驟和過程,每個階段都需要輸入詳盡的文檔到下個階段,下個階段才能開啟;比如拿蓋樓來說,沒有設計圖紙,就不能開工,并且設計圖紙一旦確定,是不能輕易變動的。
在傳統的軟件時代,也更多的采用這種模型,但這種模型有個最大的問題是,不能擁抱變化,一有變化,將付出巨大的成本。
而敏捷開發,則更多強調擁抱變化,PO、SM、Team做為一個團隊,彼此相互合作,為最終的結果負責,沒有絕對的中心,每個人都是中心,技術團隊會思考業務,PO也會思考技術;總之,大家都為最終的價值和結果負責。
去年看過一本書,叫《賦能》,里面說到一個很重要的理念,叫『扁平化、去中心化、賦能』,敏捷開發,就符合這個理念。
當然,不是說瀑布開發就完全沒有價值、不能采用,在做外包或者規模巨大不易變化的項目時,瀑布開發也有其應用場景。
04 寫在最后
做產品,很講究一個節奏感,有節奏感的產品,才能穩定的產出價值,而這個節奏感,很大程度來源于對版本的把控。
產品經理一定要做好兩件事:需求分期、價值優先級判斷;能做好這兩件事,產品能力才會穩步上升。
而敏捷的這種思想,對產品做好這兩件事情,是很有幫助的,一定要熟練掌握敏捷思想,善于利用SCRUM框架方法,遠離無限延期,擺脫甩不完的鍋。
相關文章:
作者:刀哥;公眾號:刀哥說。
本文由 @刀哥 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
- 目前還沒評論,等你發揮!