做任何改變都是需要付出一些代價的。

從半年之前，為了快速相應市場的變化和為無數的ABtest做基礎準備，產品開始初步響應敏捷的速度，版本由每月一個發布改為做每周一個版本。

一個月之前，團隊迎來了敏捷教練，在敏捷教練的帶領下，我們逐步由“假敏捷”漸漸開始嘗試 “真敏捷”，作為產品經理的我，也開始了和敏捷相愛相殺的過程。

這里總結和分享下：

1. 什么是假敏捷和真敏捷？
2. 用戶故事的魔力
3. 敏捷中的團隊精神
4. 敏捷給產品經理帶來的成長。

一、真敏捷還是假敏捷？

事業部是在去年年底開始實時每周一個版本的迭代，那個時候,在全公司我所在的項目組是第一個開始做頻繁發布的。

在變幻莫測的互聯網環境下，快速的響應和發布是非常必要的，并且能得到ABtest的快速驗證。

但是在這種快速迭代的初步嘗試中，團隊慢慢出現了一些問題。

1.假敏捷-7個團隊各自為營

我們從一個需求從產生到落地的過程來看，首先需求的來源有一些問題。

3月份在敏捷診斷的時候，幾乎所有的產品都把最需要解決的問題投給了“產品定位”。

產品定位可以沒有明文規定，但是在快速奔跑的過程中，每個人都要有一致的目標。

當項目組的每個人對產品的理解不一致的時候，我們傳達給用戶的，也是一些非常矛盾的東西。

舉個例子，本著一個服務于全球女性的APP，在一次商務的合作當中，商務的同學拉來的合作是“恐怖電影”?？上攵脩艨吹搅诉@些啟動頁廣告、banner大圖的時候被驚嚇的狀態。

同時，需求的產生是在每一條業務線中產生的；按照不同的業務線，產品、開發、測試被分成了7個團隊，團隊之間更多的是一些同步的工作，缺乏溝通和討論。

沒有總體的共識，一個APP被分為7個團隊，需求的產生比較分離，沒有重點。

在需求迭代的過程中，每個組是只有一個開發和測試加入到需求討論中，最后把會議精神帶回團隊;更多開發和測試的同學是直接按照PRD進行開發和測試的——團隊缺乏溝通，對需求細節的把控沒有那么到位。

最后，在需求交付的時候，功能核對大概幾種是在上線前1-2天。

這會導致很多風險項都沒有辦法提前暴露，需求理解不一致的情況沒有辦法得到有效的處理。

2.真迭代-兩個團隊試點，每周一個敏捷沖刺

敏捷項目啟動初期，在面對一個需求從開始到落地的五個環節：“產品定位”-“用戶定位”-“需求挖掘”-“需求開發”-“需求跟蹤”時，幾乎項目組所有核心人員都把最緊急、最缺失的一票投給了“產品定位”。

我們發現，因為沒有清晰的產品定位，所以每個人的著力點是不同的；大家像一盤散沙，看似忙碌充實卻綿軟無力。最致命的是：因為沒有清晰的RoadMap，大家走一步算一步的狀態影響團隊士氣和凝聚力。

于是，產品團隊利用將近一個月時間的依據公司戰略、產品目標、用戶需求和市場環境確定了清晰的產品定位“打造用戶的專屬攝影師”，以及根據產品定位確定了接下來1-2年的長期目標和近三個月的短期目標。同時，每條線也根據共同目標制定了版本迭代的計劃。

“計劃的結果是無意義的，價值在與計劃的過程本身”，在互聯網瞬息萬變的環境下，RoadMap肯定是會變的，但RoadMap能夠讓全項目成員做到“心中有數”，往同一個方向一起沖刺，這就是它最大的價值所在。

在同一個產品目標下，我們把小組分為幾個線，在產品內部共同討論下形成了需求池。

在需求迭代對過程中，我們也發生了一些改變。

例如產品經理開始用用戶故事去表達和拆解需求（用戶故事會在接下來展開來說），基于用戶故事，開發測試的同學參與到了需求細節的討論中，逐步達成共識。

在需求交付時，大家能夠按照故事點做得點對點的每天交付，甚至為了迭代目標的達成，出現交叉開發、交叉測試的現象。

3.Srum Master是誰？

在需求迭代和落地的過程中，敏捷引進了一個非常重要的角色“Scrum Master”（以下簡稱SM）；項目組漸漸弱化項目經理的角色，開始培養每一個團隊的SM角色。

SM是一個對產品迭代推進幫助特別大的人。

目前跑下來在產品看來，SM可以幫忙解決這樣幾個問題：

• a.服務產品，確保每個團隊成員都盡可能的理解目標和需求細節;
• b.服務開發，移除開發工作中的障礙，幫助開發梳理交付流程；
• c.服務組織，帶領每一個迭代的進行并持續提升效率。

SM和傳統的項目經理最大的區別在于：驅動形式不同。

項目經理是以任務范圍驅動時間和資源成本，而SM則是要以時間去驅動任務范圍，保證產品以一個節奏持續得往前走。

在敏捷框架下，每周一個迭代是死的（這個死是相對的死，可以根據實際情況做調整）。

每個團隊都像趕火車一樣在固定的時間點上車，如果沒有趕上，把優先級高的需求先保證發布，這樣就能保證我們總是在做有價值的事情。

所以每一周，我們就是一個沖刺——時間點基本上是固定的，整個產品是有節奏的一步一步向前。

二、用戶故事的魔力

第二部分，想分享一下敏捷實施以來，產品這邊最大的一個感受：需求思考和表達的維度從原本的流程圖變為了用戶故事。

我們首先來看一下：用戶故事解決了一個什么樣的致命的問題。

我們必須承認的是：文檔并不等于共識。

在敏捷的框架中有一個價值觀——可交付的版本大于詳盡的文檔。文檔寫得再詳盡，如果團隊成員不夠理解，在快速的迭代開發中會大大的影響效率和交付的質量。

我們看這樣一張圖，當需求評審的時候，大家都說“我懂了”，但是在每個人心里，其實對需求的理解是不一致的；大家需要通過反復的溝通去保證，每個人心中對細節的把控大體一致。

不能夠出現產品經理、開發、測試在進入迭代的過程中，最后的交付和產品的預想不一致。

用戶故事就是一個梳理需求的框架，它最大的價值是能在迭代開始之前，用這個框架讓團隊成員迅速對需求達成共識。

用戶故事到底是什么樣的呢？就是：一個角色，需要完成什么樣的活動，最終達成什么樣的目的。

例如，作為<一個用戶>,我想要<快速拍到好看的照片>,以便我<能夠在 朋友圈里分享我的生活>。

用戶故事是一個幫助產品和團隊梳理需求的一個很好的框架，我們來看一個實例：

左邊是用“界面框圖+跳轉邏輯+邏輯細節”組成的需求，右邊是用用戶故事+界面框圖表達的需求，我們會發現，左邊的表達邏輯比較零碎，而右邊結構清晰，考慮到所有的場景不會產生遺漏。

用用戶故事表達需求的時候，我們會發現用戶故事的幾個大優點：

1. 測試和開發不一定有產品視角，但一定會有用戶視角，用用戶故事去梳理需求能夠讓大家對該需求的理解更加迅速、深入。
2. 按照場景拆分，需求在整理把控和細節處理上更容易暴露出問題。
3. 拆分之后，按照提供給用戶的價值劃分優先級，甚至幫助產品找到MVP。
4. 按照用戶故事做后期的迭代交付。

三、敏捷中的團隊精神

敏捷走了一個月的時候，我們開了一次總結會，回顧敏捷前、敏捷后、敏捷中你認為最大的變化。開發、測試的同學都在最大的變化的關鍵詞幾乎都寫上了同一個詞，那就是“參與感”————之前的需求評審的時候，產品和開發、測試有一種對立的感覺。

產品像是接受檢閱，開發和測試像是被通知。這是一種很神奇的社會心理，當人拿出一個經過自己謹慎思考的方案的時候，其實是難以接受修改和質疑的。

產品經理面對一個自以為很周全的需求的時候，實際上把需求框住了，把自己的思路和別人的思路一同框住。一旦別人提出一些質疑，會本能的抗拒，這是一種思維定勢練。

需求應該是在團隊的討論下涌現得到的，這個團隊不僅包括測試、開發，也包括團隊里的任何一個角色。

產品把控方向，團隊在討論中不斷得鞏固和涌現細節。而且在討論的過程中，我們經常會發現，開發和測試的同學也會有一些新奇的創意，其實他們渴望表達，渴望產品聽到他們的意見；并且產品的方案如何落地，細節的部分開發、測試同學會更了解并提出寶貴的想法。

非常感動的是：有一次一個需求delay了，其實我知道是因為產品在迭代的過程中對需求做了一些調整，但是那個開發的哥哥在回顧的時候，并沒有cue到產品，而是自己默默撐起了這口鍋。

當然我也做了自我的檢討，但是整個回顧會的過程就會讓人覺得：大家是一個集體，沒有人會默默甩鍋給別人。

四、敏捷給產品經理帶來的成長

在敏捷的大框架之下，對產品經理有了更高的要求。

不僅是對需求細節對把控能力，更是對整個產品方向和roadmap的把控能力都需要產品經理跟隨敏捷的節奏一起成長。

在這短短一個多月的時間里，非常有幸能夠參與到敏捷中，同時我也切切實實的感受到了一些成長上的變化：

1.在需求的不斷拆分中重新思考需求的價值。如何在有限的時間里做最有價值的事情，如果需求可以拆分，那么MVP是什么？我們在用戶視角去拆分需求的時候，會重新定義MVP。

2.用戶故事，強迫產品經理始終從用戶視角和用戶使用場景去思考需求的價值，這個思維轉變非常重要。

3.讓產品經理從全局和細節對需求有更多的思考。（1）全局的場景拆分（2）注重驗收標準的細節，如果丟失重要的細節部分，產品經理需要背鍋

4.團隊溝通，帶團隊的能力得到鍛煉。讓產品經理更參與到團隊協作的方式中和團隊文化建設的氛圍中，我覺得為未來做一個管理的角色有鋪墊作用。

做任何改變都是需要付出一些代價的。

例如產品的發版節奏被打亂，團隊的工作方式方法被打亂，甚至會出現剛開始做敏捷時團隊的產出效率變低，這都屬于正常的“學習曲線”。

經歷過一番痛苦的掙扎，我相信在正確的使用敏捷后，團隊中的每個人都能收獲一定的成長，產品也能在這樣的思路和框架下有更大的提升。

作者：小梅梅，美圖公司產品經理

本文由 @小梅梅 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議