敏捷并非萬能，其應用需要結合具體場景和時機。本文從產(chǎn)品經(jīng)理的視角出發(fā)，探討了敏捷方法在產(chǎn)品設計、用戶研究、交互框架定義等階段的適用性與局限性。

敏捷的思想雖然起源于軟件開發(fā)領域，但是實際工作中被不斷泛化到其他工作領域，比如：用戶研究、產(chǎn)品設計、交互設計、視覺設計、業(yè)務協(xié)作等場景。

但切記一句：敏捷初心不假，切莫無節(jié)貪用！

敏捷被利益相關方中的商業(yè)利益相關者（你團隊的vp）所鐘情，無非是看中他的經(jīng)濟高效的預期。這里就是經(jīng)典的不可能三角，速度、質量、成本，不能同時兼得。所以，敏捷受到不可能三角的約束，換句話說，敏捷是不可能三角里面的最優(yōu)解。

特別在產(chǎn)研前期的用戶模型構建階段、需求（場景需求或者俞軍老師口中的交易模型）定義階段、交互框架定義階段，即便我們的開發(fā)團隊迫不及待的想進入敏捷的節(jié)奏里面，恨不得邊設計邊coding，但是這里還是不得不剎一腳，盡可能的給即便是我們口口聲聲所謂的“敏捷設計”方法預留時間。

敏捷就算應用到用戶體驗設計階段，也意味著無法一蹴而就的達到最貼合用戶目標的設計。但也正是敏捷方法具有自己獨特的優(yōu)勢，支持設計者可以在過程中進行定義的修正和優(yōu)先級的安排。

大設計->大開發(fā)，是不是嚴格的瀑布？

先設計、再研發(fā)，常規(guī)理解上很像是經(jīng)典的瀑布式模式，盡管在大開發(fā)內(nèi)部已經(jīng)普遍流行敏捷方法。但不得不說由技術限制蘊藏的阻礙與機遇，對于支撐用戶目標、市場目標、商業(yè)目標來說也同樣重要，這就導致了技術對于設計的反向制約。

你會發(fā)現(xiàn)，大設計、大開發(fā)其實并不太適合直接放在瀑布流中的。實戰(zhàn)的經(jīng)驗也發(fā)現(xiàn)了，如果你把它們當作瀑布，嚴格遵守設計之后再去做開發(fā)，它們就會給你猛潑一臉冷水！最后還不忘一口，呸！相反，有些市場機會就算商業(yè)和產(chǎn)品層面嗅探到了，但也可能由于需要技術發(fā)展的跟進才能進行場景的承接落地。比如移動支付、短視頻、NFC、RFID相關的商業(yè)場景，哪個不是要依賴技術和硬件設施的成熟后才得以場景的落地。

一個產(chǎn)品經(jīng)理把敏捷方法應用到工作中，特別是新產(chǎn)品、完全開發(fā)需要一定周期的，敏捷給你的最有價值好處就是用戶對于體驗的反饋。哪怕前期的用戶研究如何細致，當用戶真正面對和使用產(chǎn)品時，真實的體驗反饋/態(tài)度、如何使用、哪里易錯、哪里出奇不意，這些一定是更為寶貴的資源，切實的把你引領到藏寶閣。

敏捷，有所用，有所不用，最底層思想大致總結為三點：

1、別死磕計劃，先干再說

需求會變、問題會冒出來，別等“完美計劃”，先做最核心的功能，邊做邊調整，越快看到結果越好。

2、別自己憋大招，拉所有人一起搞

客戶、老板、程序員天天碰頭，有問題當場吵明白，別等到最后才發(fā)現(xiàn)做歪了。

3、做一點就立馬給客戶用，聽罵聲

早挨罵早改，別等做了一整年才發(fā)現(xiàn)全錯。客戶罵得越狠，你改得越快，最后東西才靠譜。

適合用敏捷的：需求不明確、老變卦的事（比如做個新App、搞市場活動）。

別硬用敏捷的：

• 需求100年不變的事（比如造橋，圖紙定了就不能天天改）；
• 領導非要按自己說的做，不聽團隊反饋的；
• 團隊躺平不溝通的，敏捷能急死你。

敏捷就是對付“變化多、要快”的武器，但如果你非要拿它砍柴，倒不如用菜刀。