產品經理如何利用敏捷思維進行版本迭代？

做產品時，你是否遇到以下這些情況？

• 需求反覆變動，改某一處邏輯，開發的工期就得加倍，專案無限延期。
• 開發做出的專案，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框架方法，遠離無限延期，擺脫甩不完的鍋。

相關文章：

產品經理怎麼做可行性分析？

7年產品經理的工作流程，與你分享

產品新人沒有完整專案經驗？這篇文章幫你開啟思路

PRD到底該怎麼寫？更全面的文件範例來了

作者：刀哥；公眾號：刀哥說。

本文由 @刀哥 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。