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

從半年之前，為了快速相應(yīng)市場的變化和為無數(shù)的ABtest做基礎(chǔ)準(zhǔn)備，產(chǎn)品開始初步響應(yīng)敏捷的速度，版本由每月一個發(fā)布改為做每周一個版本。

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

這里總結(jié)和分享下：

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

一、真敏捷還是假敏捷？

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

在變幻莫測的互聯(lián)網(wǎng)環(huán)境下，快速的響應(yīng)和發(fā)布是非常必要的，并且能得到ABtest的快速驗證。

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

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

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

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

產(chǎn)品定位可以沒有明文規(guī)定，但是在快速奔跑的過程中，每個人都要有一致的目標(biāo)。

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

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

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

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

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

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

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

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

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

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

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

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

在同一個產(chǎn)品目標(biāo)下，我們把小組分為幾個線，在產(chǎn)品內(nèi)部共同討論下形成了需求池。

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

例如產(chǎn)品經(jīng)理開始用用戶故事去表達(dá)和拆解需求（用戶故事會在接下來展開來說），基于用戶故事，開發(fā)測試的同學(xué)參與到了需求細(xì)節(jié)的討論中，逐步達(dá)成共識。

在需求交付時，大家能夠按照故事點做得點對點的每天交付，甚至為了迭代目標(biāo)的達(dá)成，出現(xiàn)交叉開發(fā)、交叉測試的現(xiàn)象。

3.Srum Master是誰？

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

SM是一個對產(chǎn)品迭代推進(jìn)幫助特別大的人。

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

• a.服務(wù)產(chǎn)品，確保每個團隊成員都盡可能的理解目標(biāo)和需求細(xì)節(jié);
• b.服務(wù)開發(fā)，移除開發(fā)工作中的障礙，幫助開發(fā)梳理交付流程；
• c.服務(wù)組織，帶領(lǐng)每一個迭代的進(jìn)行并持續(xù)提升效率。

SM和傳統(tǒng)的項目經(jīng)理最大的區(qū)別在于：驅(qū)動形式不同。

項目經(jīng)理是以任務(wù)范圍驅(qū)動時間和資源成本，而SM則是要以時間去驅(qū)動任務(wù)范圍，保證產(chǎn)品以一個節(jié)奏持續(xù)得往前走。

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

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

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

二、用戶故事的魔力

第二部分，想分享一下敏捷實施以來，產(chǎn)品這邊最大的一個感受：需求思考和表達(dá)的維度從原本的流程圖變?yōu)榱擞脩艄适隆?/p>

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

我們必須承認(rèn)的是：文檔并不等于共識。

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

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

不能夠出現(xiàn)產(chǎn)品經(jīng)理、開發(fā)、測試在進(jìn)入迭代的過程中，最后的交付和產(chǎn)品的預(yù)想不一致。

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

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

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

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

左邊是用“界面框圖+跳轉(zhuǎn)邏輯+邏輯細(xì)節(jié)”組成的需求，右邊是用用戶故事+界面框圖表達(dá)的需求，我們會發(fā)現(xiàn)，左邊的表達(dá)邏輯比較零碎，而右邊結(jié)構(gòu)清晰，考慮到所有的場景不會產(chǎn)生遺漏。

用用戶故事表達(dá)需求的時候，我們會發(fā)現(xiàn)用戶故事的幾個大優(yōu)點：

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

三、敏捷中的團隊精神

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

產(chǎn)品像是接受檢閱，開發(fā)和測試像是被通知。這是一種很神奇的社會心理，當(dāng)人拿出一個經(jīng)過自己謹(jǐn)慎思考的方案的時候，其實是難以接受修改和質(zhì)疑的。

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

需求應(yīng)該是在團隊的討論下涌現(xiàn)得到的，這個團隊不僅包括測試、開發(fā)，也包括團隊里的任何一個角色。

產(chǎn)品把控方向，團隊在討論中不斷得鞏固和涌現(xiàn)細(xì)節(jié)。而且在討論的過程中，我們經(jīng)常會發(fā)現(xiàn)，開發(fā)和測試的同學(xué)也會有一些新奇的創(chuàng)意，其實他們渴望表達(dá)，渴望產(chǎn)品聽到他們的意見；并且產(chǎn)品的方案如何落地，細(xì)節(jié)的部分開發(fā)、測試同學(xué)會更了解并提出寶貴的想法。

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

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

四、敏捷給產(chǎn)品經(jīng)理帶來的成長

在敏捷的大框架之下，對產(chǎn)品經(jīng)理有了更高的要求。

不僅是對需求細(xì)節(jié)對把控能力，更是對整個產(chǎn)品方向和roadmap的把控能力都需要產(chǎn)品經(jīng)理跟隨敏捷的節(jié)奏一起成長。

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

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

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

3.讓產(chǎn)品經(jīng)理從全局和細(xì)節(jié)對需求有更多的思考。（1）全局的場景拆分（2）注重驗收標(biāo)準(zhǔn)的細(xì)節(jié)，如果丟失重要的細(xì)節(jié)部分，產(chǎn)品經(jīng)理需要背鍋

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

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

例如產(chǎn)品的發(fā)版節(jié)奏被打亂，團隊的工作方式方法被打亂，甚至?xí)霈F(xiàn)剛開始做敏捷時團隊的產(chǎn)出效率變低，這都屬于正常的“學(xué)習(xí)曲線”。

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

作者：小梅梅，美圖公司產(chǎn)品經(jīng)理

本文由 @小梅梅 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議