編輯導語：產品的源頭是需求，一切偉大產品的實現都是從需求管理開始的。敏捷開發中的需求管理大致分為三個階段：需求調研，需求分析和需求確認，需求調研階段產品立項后，產品經理便開始了和需求打交道的漫長過程。作為產品經理，都需要自己的“敏捷開發”，你真的會敏捷開發嗎？

作為產品經理，我們除了了解競品分析、需求文檔以及活動策劃外，還應該了解掌握各種開發模式，例如：迭代開發、增量開發、瀑布式開發、螺旋式開發以及敏捷開發。

而其中的敏捷開發可以說是已經到了“家喻戶曉”的地步，并且許多公司或是團隊至今都在沿用敏捷開發的模式進行日常工作的開展。

就是在這樣“家喻戶曉”、“人人沿用”的情況下，敏捷開發在實際應用中一直兩極分化嚴重。敏捷開發他是壓力、無腦沖刺的代名詞，同時也是創業工作中的“救世良藥”，產品創新的方法。

為什么會存在這樣的兩極分化？

下面，咱們將通過三個方面進行討論，來深入了解敏捷開發之后便知道為什么會如此兩極分化啦。

1. 推崇敏捷開發的根源是什么？
2. 你使用的是流程敏捷還是思維敏捷？
3. 我們該如何選擇敏捷模式，它能給我們帶來什么？

一、推崇的根源是什么

我們都知道，敏捷開發突出在敏捷上。

根據用戶（顧客、甲方）的需求，進行短、平、快的研發沖刺，并且在沖刺過程中，還需要對需求、市場的變化進行靈活的調整，以適應變化。而恰恰因為這些特點，所以我們當前時代十分推崇敏捷開發。

首先，要想知道為什么推崇，就需要我們了解當前我們處于時代時代的背景。

我們現在處于互聯網高速發展的時候，而這個時代叫vuca時間，vuca時代中的vuca代表這個時代的四種屬性及volatility（易變性），uncertainty（不確定性），complexity（復雜性），ambiguity（模糊性）。

1. 易變性

當今社會的變化，速度越來越快越來越不可預測。

一個變量的變化，十分容易引起另外的變量進行變化，且這種變化十分頻繁。事物很難再保持較長的穩定。我們面對易變性要做好各方面的預備，保持良好的輸入輸出的習慣，積極迎合事物的變化，增強我們的反脆弱性。

2. 不確定

面對易變化的時代，我們以往的經驗無法或說難以在適用現在時代的場景。盡管，以往的經驗依然有很強的參考性，但面對現在這個因為易變化而充斥不確定的時代之前的經驗，我們不能盡信。

對此，我們要盡可能的擴張信息知識面，對已收集信息進行加工和分析，以求通過擴大分析網絡而降低這些不確定性，這也是我們常說的競品分析。

3. 復雜性

互聯網給我們的生活帶來飛速發展的同時，我們所面對的信息越加龐大；同時，增量的不光是信息還有問題，各種問題相互牽制，牽一發而動全身的情況越發明顯。

單一的解決方案已經無法滿足我們，因此我們需要定期進行復盤，重組。積累沉淀定向的專業知識，以垂直專業性應對復雜問題。

4. 模糊性

模糊性是最直接明了的，現在的時代我們對于事物的定義和邊際之間變得更加的模糊不清，之前，我們非黑即白的判定也越加不再適用。

現在，我們需要去尋求那些第三選擇。通過了解事物的因果，去主動地嘗試失敗，掌握失敗的結果，在這些結果中尋找新的解決之道，并從模糊性中找到確定性。

特別是在今年2020年，因為新冠疫情，公司裁員、項目延期被砍、資金斷裂似乎成了平常事?；ヂ摼W從業人員幾乎人人自危，這也就加速了我們對vuca時代認知。

面對vuca時代，敏捷開發的低成本、快速試錯、用戶需求為引導的開發模式似乎十分契合時代特性。

如果我們進一步思考，為什么敏捷開發如此契合？

這就要從敏捷開發的由來，國外咨詢公司說起。國外的咨詢公司說直白一點就是高端的外包公司。從提供個性化定制軟件到戰略決策，他們都提供相對應的解決方案。

如此，他們也會和我們一樣需要面對多變的用戶（顧客、甲方），也會遇見我不知道我想要什么但是我就是有錢的金主，就在面對多變和不知道我想要什么的背景下敏捷開發自然而然孕育而生。

1. 小故事

有個很典型的說敏捷開發的外包小故事，一天用戶（甲方）找到資深咨詢公司說，我要一個埃及金字塔我出錢你們幫我搞一搞，面對這個直接要什么的情況資深咨詢公司肯定不會直接開動做一個胡夫金字塔給用戶，而是嘗試問用戶你要金字塔的做什么？

用戶說到：要金字塔當然是做墓地啦。

咨詢公司接著說到：你看你要墓地，我們先給你做個棺材，先看看效果，看合不合適還缺什么，我們到時候修改就行。甲方想了想也就同意了，隨后咨詢公司給用戶做了個棺材。

用戶看見棺材發覺目的達到了目標，但是還不夠威嚴和埃及金字塔差了十萬八千里，便說要和金字塔一樣威嚴。

這時咨詢公司說：你看金字塔有很多的人面獅身雕像，所以感覺有威嚴，你看這樣我給你棺材也整個人面獅身的雕像，同時還給你配上兵馬俑，讓你選擇看那個更符合你。

用戶聽后感覺有道理就同意了咨詢公司的說法，等木乃伊后兵馬俑都出來后，用戶對比了下，用戶發現更喜歡兵馬俑，更符合國人的身份。

但同時又覺得幾個兵馬俑感覺沒排面，想更有排面點，之后咨詢公司給他搞了個兵馬俑方陣（高達方陣…..）

好了，上面小故事形象的說出敏捷開發的核心，就是就可能拆解需求，將需求聚焦到小范圍中，不停的發布可觀察（可使用）的產品進行交付，收集用戶反饋，在進行下次的開發。

同時這里我們不要忽視了，因為需要和用戶（甲方）頻繁的確認交付物，所以用戶是可以感知進度的，而這些進度都是需要用戶給錢的，這樣會比直接交付給的錢更多（資本的力量）。

至此我們可以了解到，用戶需求的變化其實與當前時代的特性存在著高度的共性。

首先是不確定性：用戶不知道我想要什么，到底想要的是墓地還是高達兵團或者是其他的。其次是易變性：原本想要金字塔最后做了個秦式陵墓，最后可能還會是宇宙飛船。

隨后便是復雜性：單人兵馬俑無法滿足用戶的需求，用戶還是會追尋兵馬俑方陣，甚至是給每一位兵馬俑配備上現代化的步槍，坦克。最后是模糊性：需求的本質很簡單，但實際結果因為表現而變得模糊不清。

那么如此推崇的敏捷開發為何在一些大公司其實并不完全受用？

二、流程敏捷和思維敏捷

在引入敏捷開發后，敏捷開發便在國內迅速崛起，初步成為屈指一首的開發模式。

但大部分都是“偽敏捷”，所謂的“偽敏捷”就是直接抄作業，將國外咨詢公司那一套流程直接照搬到國內，并直接在團隊內部或公司內部進行推廣，不去考慮公司“基因”和敏捷開發的“基因”是否相契合。

直接造成公司團隊內部怨聲載道，產品、ui和測試每周為了沖刺任務（敏捷開發中每次定的小目標）進行加班輸出，周而復始，與流水線工人毫無意義（這里未鄙視流水線工人，我想表明我們本該利用專業技能“腦動力”創造價值，而非手上的勞動力），這就是流程敏捷。

說流程敏捷存在的問題并不是否定流程敏捷，而是我們需要注意他的基因是否與我們自己相匹配。

我們要知道敏捷開發本就從咨詢公司衍生而出，本身就帶著一定咨詢公司的“基因”，所以在擁有同“基因”的小公司、創業公司和內部孵化團隊中便十分合適。

對于稍大點的公司，直接執行“偽敏捷”禍害深遠。

比如，在流程敏捷過程中，作為產品經理的我們經常沒有目標，不知道我們到底要做的是什么，而是不斷的通過收集反饋，最后根據用戶的反饋來輸出下個版本，一旦遇見問題，就說這是敏捷開發要面對的問題，直接就把敏捷開發當成“盾牌”。

或者是每天為了忙而忙，每次沖刺輸出盡是一些不健全的demo，隨后在后續迭代中丟失等等。那么面對這些問題，真的敏捷開發到底該是怎樣的了？

我認為真的敏捷開發應該就像馬克思主義進入中國變成中國特色社會主義一樣，應該根據中國互聯網特點形成中國特色敏捷開發（其實就是不要亂抄作業，抄作業也要改下名字，不然連名字都抄就過分了）。

在國內，我們的公司常分為產品部門、業務部門、研發部門、測試部門、數據部門等等，每個部門各司其職。

當需要進行敏捷開發時，我們是在每一個部門抽調人員暫時組成一個小團體組成敏捷團隊，這樣可以進行跨部門協同，這是一個現象。

我們常圍繞這個現象做大團體的敏捷，除了做大團體的敏捷我們還需要做思維上產品的敏捷。我們要將大團體再次依據職能分成小團體，例如：產品、設計、研發和測試。

在每次小團體交付給下個小團體之前，如產品小團體交付給設計小團體前，我們要先做好小團體內部的敏捷任務，等小團體內部敏捷完成后再交付給下個小團隊。

對于產品小團體交付給設計小團體前，我們要做需求、方案、原型三個方面的敏捷沖刺。

下面是主要思考的核心，為了避免干擾思考，盡可能不在放圖。

1. 需求敏捷

面對多變的用戶和需求，我們不能只是記錄用戶遇見了什么問題，有個什么功能就好了。而是通過小故事的形式將用戶所處的場景、問題、期望方案記錄下來。

別看只是兩種不同的記錄形式，這對于我們產品來說卻是存在天壤之別。

單記錄一個問題和有什么功能（用戶期望的解決方案），無法讓我們復現問題，固定了我們思維方式。這讓我們思考目標直接放在了用戶遇見的問題和用戶自身提出的解決方案上。

使用小故事的形式來進行記錄，我們可以不光可以傳達用戶遇見的問題，還可以傳達遇見問題時用戶所處的場景，甚至對于用戶自身的屬性和路徑都能表述出。

在隨后思考解決方案的時候，我們有更加廣闊的思維空間，更能捕捉問題后面的因果，而非現象的因果。

對于多變的用戶，小故事形式記錄更能讓我們從用戶多變的屬性中找到不變屬性，讓我們加深對于用戶的理解，在利用同理和共情我們玩完全可以在腦子里面復現場景（就像看小說）。

有了故事，我們可以快速的通過“假象”來進行場景再現，并利用線下實際操作來復現問題，結合產品本身的屬性篩選出“真”需求。

到這里需求的敏捷就完成了。但是我們還需要完善兩個信息，一個是用戶畫像，一個是用戶路徑。

用戶畫像需要我們盡可能的貼切真實，并且是依據我們小故事創建的。這樣會使用戶畫像更加有真實感，如果我們使用卡通圖片，卡通名字和虛假的內容進行填充用戶畫像，那么這個畫像完全起不了用戶畫像本身指導的作用。

用戶路徑也就是在小故事中用戶的經歷，如果把小故事比作游戲場景，那么用戶畫像是游戲角色，而用戶路徑就是游戲角色的行為。游戲角色他們可以在游戲中唱、跳、rap…..

咳。所以用戶路徑很重要。

在梳理用戶路徑時，我們需要更加注重用戶的行為，關注用戶事前、事中、事后做了什么。有點像把大象放入冰箱需要幾步，例如：先確認大象是真的還是假的（假的玩具大象），在打開冰箱門，拿起玩具大象，放入冰箱，關上冰箱門。

在這個例子中為什么沒說需要先走到冰箱前，在打開冰箱門了，因為追求這樣的細節反而無意義，畢竟除非特別的行走（跳著走）需要我們進行說明，其他我們只需要使用去上廁所，到了廚房等用詞就包含了走路這些細節。

到這里需求的沖刺就完成了，我們也擁有了用戶相關的三樣東西，故事、畫像、路徑。至此我們可以進行下個方案的環節。

（過程中也會設計到用戶調研，用戶訪談，關鍵是根據自身公司屬性進行調整，畢竟不是所有公司都用專門的問題反饋線：客戶->Customer Service->Support Engineer->PM->SDM->SDE）

2. 方案敏捷

方案的敏捷需要承接在需求之后，在這里我們了解了用戶的故事，知道了用戶的畫像，掌握了用戶的路徑之后進行，雖然我們不保證得到的信息是100%正確，但是對我們具有很高的參考價值。

我們要從場景出發，結合實際問題作分析給方案，分析的方式我們一般常用競品分析進行，這個可以參考我之前寫的《競品分析》文章。

思考分析的結果，將結果具現成實際的解決方案或功能，并將這些功能盡可能的通過可視化的紙和筆記錄下來，再去評估這些方案，選出方案中的最優解，推進到下個環節。

上面說到的最優解是指，根據實際情況，考慮方案的時間成本、研發成本、資金成本以及預期效果綜合得到的結果（可以說是最能自圓其說的方案）。

3. 原型敏捷

說到原型敏捷就不得不提一些現象，我們經常吐槽一些公司動不動就要做一個功能龐大卻完善的產品，從不去根據用戶反饋來做產品，這些常常做出來之后就直接涼了。

殊不知這和我們直接畫完所有的原型再去和其他人對接，隨后頻繁修改原型，最終幾乎完全重構一樣，沒有太大的區別，唯一的區別可能是前者成本更高而已。

面對這種情況，需要我們產品以最小成本，最大化復刻功能，也就是想盡辦法用最“假”的原型去驗證“真”的功能。

一般常使用紙、筆和白板畫來進行呈現，將所涉及的頁面、功能和邏輯等快速的通過可視化出要并于其他人進行溝通，最后基本確定之后再進行原型的繪制。

繪制完畢后并不是代表這個環節就結束，這是我們要進行原型敏捷最核心的一個應為，原型驗證。

原型驗證的思路其實很簡單，大家可以想象一個場景，在一個寫字樓大廳，放著這一臺自助販賣機，每當用戶選擇購買商品并投幣支付后，都會有找零錢并給商品，在現在看起來很平常的東西。

但實際因為自動販賣機的老板沒錢買真的自動販賣機，只能自己上場（躲在自動販賣機里面，人工給水）。

工作中我們要像這個自動販賣機一樣，我們不要迫切的將原型推進到下個環節去，而是我們可以利用已有手段結合原型進行一些簡單的“驗證”，去驗證當前的方案是否解決了開頭的需求。

如果未解決需求那么我們還需要對方案進行調整，如果已經解決那么我們可以推進到下個環節中。

如果原型實在達不到要求，我們還可以像github一樣打個分支，分離出一個平行且相同方案，只是這個方案只執行樣式上的變化，對樣式進行開發只需要少量的時間即可。

而他們的后臺邏輯我們通過人工處理，這個原理和自動販賣機的原理一樣。同時這也減少了方案的不確定性和模糊性。

到了這里我們產品的敏捷就結束了，下面將是設計的主場，他們將完成設計的敏捷沖刺，這里就不再過多說明。

三、最后

我們該如何選擇敏捷模式，它能給我們帶來什么？說句實話，上面不適合所有人，上面不適合所有人，上面不適合所有人。

大家畢竟所處的環境各不相同，有的產品部門十幾號人，一個項目團隊都有幾十號人支撐。有的甚至連產品部門都沒有，全部統稱為研發部，一個項目也才7-8人，甚至更少。

所以這個真不適合所有人，但是我想表述的事，敏捷這東西，在于讓我們拆解目標，專注沖刺。那為什么我們不把自己要做的工作也進行拆解沖刺？

選擇開發模式這個事情其實我們是無力去改變，只能去被動的接受，除非你真的到了一定的職位，你可以決定開發模式以及產品方向。

不然大部分我們的身份都是一個個互聯網“流水線”的打工人，在外部不能改變的情況下，我們只有對自身進行改變，將自身看待問題的維度頻率調節的與外界相通（都是敏捷）。

這樣才能在完成工作的同時又一定的收獲，而不是盲目在“流水線”上做相同的事情。

自身產品的敏捷，只是強迫我們去思考，去溯源場景，讓后續的決策都有依據，而不是憑直覺或是看見別人做了我也要這樣做，至于為什么這樣做，我也不知道。

所以他只是暫時的方案，而不是解決萬事的方法。

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

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

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