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

如果你遇到以上乙個或多個問題，那麼多半是開發模式存在問題。

敏捷，字面意思是迅速、靈敏的意思，如：行動敏捷、思維敏捷；敏捷通常用於描述快速而靈活的完成某件事情。

敏捷開發，就是快速而靈活的完成開發。在幾十年前，網際網路專案剛剛起步的時候，做乙個系統需要幾個月或者幾年；這類專案，與傳統的建築或工業專案類似，需要嚴格按照計畫、分析、設計、實施、維護的流程，不能隨意變動。

但隨著網際網路的發展，市場變化越來越快，網際網路專案必須快速響應市場變化，傳統的這種開發方法已經變得笨拙，敏捷才能快速響應變化。

敏捷有2個特點：『增量』『迭代』；增量是指價值的增量，即每個版本的迭代，都可以帶來價值的增量。

價值分為使用者價值和產品價值，使用者價值是從使用者的角度，新增的功能/內容，對使用者能夠帶來某些價值，這些價值可以用經濟學中的效用來體現，常見的效用如：貨幣、時間、情緒等，增量的使用者價值可以是增加收入或降低成本。

產品價值是從平台/產品的角度來說的，是所有使用者價值的總和，產品價值=(新體驗-久體驗)-遷移成本；從另外乙個角度來說，產品價值還代表著對公司的貢獻，比如帶來收入、實現社會價值等。

總之，每個版本的迭代，一定能帶來增量的價值，如果不能，這個版本是沒有意義的。

敏捷的另乙個特點是迭代，迭代的核心思路是小步快跑，有句話說的好，好的系統是迭代出來的，而不是架構出來的。

快速打造mvp，然後投放市場，快速試錯，當產品方案和問題匹配時，再擴大市場規模，當產品方案和市場匹配時，再進行更大規模的擴張；小步快跑的迭代，是實現精益創業最好的方法。

關於敏捷開發，有個著名的敏捷宣言：

敏捷，強調的是一種思想，類似於物件導向，具體要實施敏捷，有多種實施的框架，最常用的是scrum，我把scrum簡單的梳理成了幾個部分：兩個工件、三個角色、四個會議，簡稱二三四。

2)三個角色：產品負責人(product owner)、敏捷教練(scrum master)、技術團隊(team)；產品負責人通常就是產品經理，敏捷教練是團隊的服務型領導，負責團隊協作、組織會議、處理相關問題等，技術團隊包含前後端、ui、測試、運維等所有實施角色。

po的重要性，不亞於乙個技術團隊，po主要對產品價值和驗收負責，如果提出的需求沒有價值，相當於整個版本的迭代就是在白做；所以，作為產品經理，一定要把更多的精力放在『如何實現使用者價值/產品價值』上面，畫原型、做專案管理都是過程而已，po要拿結果說話，對價值負責、對技術團隊負責。

產品經理如果一直把精力放在功能設計、產品設計上面，很難有提公升，要提公升還得多關注使用者和產品價值，產品大佬唐韌把產品分成四個階段，你可以對比下當前處於哪個階段。

迭代啟動會是po給技術團隊過需求，需求有問題po進行調整，直到完全澄清，然後技術團隊開始評估工期。

站立會是在迭代週期內，相關成員每天早上開站立會議，一般不超過5分鐘，成員依次描述昨天已完成工作、今天計畫、當前問題。

評審會是有技術團隊給po演示開發成果，由po進行驗收。

回顧會議則是迭代版本上線後，收集本次迭代的問題，提出建議，以便下一次更好的合作；如果當前版本有遺留問題，則將問題加入下乙個版本的需求列表。

在傳統的軟體時代，也更多的採用這種模型，但這種模型有個最大的問題是，不能擁抱變化，一有變化，將付出巨大的成本。

而敏捷開發，則更多強調擁抱變化，po、sm、team做為乙個團隊，彼此相互合作，為最終的結果負責，沒有絕對的中心，每個人都是中心，技術團隊會思考業務，po也會思考技術；總之，大家都為最終的價值和結果負責。

去年看過一本書，叫《賦能》，裡面說到乙個很重要的理念，叫『扁平化、去中心化、賦能』，敏捷開發，就符合這個理念。

當然，不是說瀑布開發就完全沒有價值、不能採用，在做外包或者規模巨大不易變化的專案時，瀑布開發也有其應用場景。

做產品，很講究乙個節奏感，有節奏感的產品，才能穩定的產出價值，而這個節奏感，很大程度**於對版本的把控。

產品經理一定要做好兩件事：需求分期、價值優先順序判斷；能做好這兩件事，產品能力才會穩步上公升。

而敏捷的這種思想，對產品做好這兩件事情，是很有幫助的，一定要熟練掌握敏捷思想，善於利用scrum框架方法，遠離無限延期，擺脫甩不完的鍋。

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