前段時間，微信的創始人張小龍在WXG（微信事業群）領導力大會上的講話又一次刷爆了互聯網人的朋友圈，圈內人士紛紛拜讀一篇名為《張小龍最新內部演講:警惕 KPI 和流程》的文章，其中就講到了敏捷開發。產品大神張小龍是這么描述“敏捷開發”的：

實際上，就這么小的一個團隊在后面幾年里面做的事情遠遠超過之前幾十人的努力，這個小團隊是怎么樣工作的？這個小團隊是當時用了一個方法，叫敏捷項目管理，這里可能在座的一些同事都已經不太了解這個詞了，但是當時在騰訊挺鼓勵用這樣一種方法，我建議在座的如果沒有去好好研究過的可以好好研究一下。我們真的做到一種非常敏捷的一種項目的推進方式。

我們今天可以想一些與眾不同的點子，然后我們可以很快就看到效果，因為我們可以很快把它上線了，然后可以去驗證，如果不對就下線，如果還有改進余地，下個星期再去改它。這是一個能夠持續實現你的想法的過程。

其實，敏捷開發這個詞對產品經理來說并不陌生。近年來，國內越來越多的互聯網公司也開始采用敏捷開發的方法來做項目管理，你可以在很多公司的辦公桌椅旁邊到處可見白板和貼滿各種顏色便簽的任務墻，然后，每天早上上班的時候，幾個人圍著白板開個站會，這其實就是敏捷開發的典型特征。在國外硅谷等地，敏捷式開發也早已經被Google、Facebook、LinkedIn等企業應用。

另一方面，理論上來說，如果一家公司有專職的項目經理，那么產品經理是不需要做項目管理的，而且，一個優秀的項目經理在產品迭代的過程中，有著不可小覷的作用。但國內大部分創業型公司，由于團隊規模的限制，產品經理又往往會承擔一定的項目管理職能，那么對于產品經理來說，了解一些關于項目管理的知識和技能就顯得很有必要。

什么是敏捷開發？

那究竟什么是敏捷開發，我們來進行一一拆解下。

敏捷 ?vs ?不敏捷

敏捷的反義當然是不敏捷，但是這個“不敏捷”在軟件工程里面卻有個專業的術語叫做“瀑布式開發”。

所謂的瀑布式開發，其實是經典的軟件工程方法為了定義出一套完備的過程規范，使得軟件開發的運作就像是機器設備一樣正常的運轉而總結出來的項目管理方法論。這套方法論分為5個階段：需求分析、設計、編碼、測試和維護。需求分析階段通常定義系統的需求，明確系統的目標；設計階段通常確定系統使用什么數據庫，系統模塊的劃分，各個模塊的功能；編碼階段用編程語言實現設計階段的任務；測試階段主要測試功能是否實現，以及是否正確沒用Bug；維護階段是根據用戶新的需求重新修改系統，使系統運行正常，更加穩定。

瀑布式開發的局限性也非常明顯，比如對市場變化和用戶需求的響應慢，更改成本高等，有可能出現的情況是產品一推出市場就宣告失敗。

而敏捷開發則是以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發的一種方法。所以，在瞬息萬變的互聯網、移動互聯網時代，大家已經漸漸體會到敏捷的優勢，我們也看到越來越多的互聯網產品出現了一周發布一次的快節奏，這么快的速度，就是為了迅速響應市場與用戶的需求。

敏捷開發的一些特點

1.小步快跑，盡早交付

在互聯網時代，尤其是移動互聯網時代，隨著時間的變化，市場環境、用戶需求、競爭對手等因素都在時時發生著改變，需求方（比如用戶、市場、運營、老板或者是產品自己）會不斷地賦予產品新的需求來應對這種變化。為了讓需求方盡早地看到結果，并給予反饋，我們就應該以小步快跑的姿勢來做產品，盡早地交付新的版本。對于敏捷來說，可用的軟件勝過完備的文檔。比如之前傳統的瀑布式開發要求的使用產品需求說明書來寫詳細的需求，這個時候我們采用敏捷開發的方法，或許有時候只畫一個原型加點備注來告知需求，又或者直接通過口頭溝通來告知需求，這就大大簡化了項目交付的時間，從而達到了盡早交付的目的。

小步快跑，意味著產品交付的時間間隔越短越好，也就是產品有較短的迭代周期，通常是2-4周。傳統的瀑布式開發最大的缺點之一，就是產品投放市場的速度太慢。當然，通過這種頻繁地迭代是為了與用戶形成良好的合作關系，及時反饋，不斷地完善和提高產品的用戶體驗，對于不能給用戶或者產品帶來價值的功能需求，則堅決不做。

2.有項目計劃，但也“擁抱變化”

敏捷不代表不做項目計劃，恰恰相反的是，敏捷更加注重計劃的制定。因為敏捷開發就是為了能夠及時地響應用戶和市場的需求，所以并不會死守著計劃不進行調整，一旦市場發生變化，即使到了開發后期，敏捷也歡迎改變需求，不斷地修正自己原先的計劃，利用變化來為產品創造競爭優勢。同時，參與敏捷項目的團隊成員也不害怕變化，因為這些改變意味著自己更了解了市場需求，讓團隊本身能夠與市場、用戶需求同步。

3. 版本周期內盡量不加任務

盡管敏捷的目的是為了盡量讓產品能夠適應市場需求的變化，但也并不意味著可以毫無節制地添加和修改項目任務。事實上，從這個角度來看，我們可以把每個版本迭代看作一次小的瀑布式開發，敏捷并不是全盤否定了瀑布式開發，而是借鑒了它優秀的部分。比如說，瀑布式開發對于那種需求比較確定的項目來說還是不錯的，比如工廠里面的生產環節就可以采用瀑布式開發的項目管理方法。

每個版本都有自己的開始時間和結束時間，也在項目剛開始的時候就配置了相關的資源來實現產品的需求，如果臨時突然插入新的需求或是修改需求的話，多少會對項目的進度產生影響。所以，我們還是盡量在版本開始前就思考地清楚一些，除非碰到特殊情況，盡量做到版本內不加任務。

4. 團隊配置也要敏捷

為了實現項目的敏捷，在團隊組成上也是需要進行敏捷處理。一般來說，一個項目團隊要小于20個人以下，太多了的話可以進行團隊分割（事實上，很多大公司已經在這么做了）。有過異地溝通經驗的人都知道，異地溝通的成本有多高，如果可以，項目成員在一個辦公室進行辦公將會大大提高溝通效率，有什么問題可用直接面對面地解決。這樣的話，也可以充分利用辦公室里的白板和墻壁。

在互聯網公司里，應該都聽說過“站立晨會”這么一說，這種形式也是要基于敏捷的團隊的配置才能更好的完成。想象一下，如果一個場地，站滿了幾十上百號人，每個人說一下自己的日常工作，那么基本上一個上午的時間就過去了，這是效率非常低下的一種表現形式，如何談的上敏捷二字呢？

5. 敏捷也需要反思

項目團隊成員需要定期對前一個或者前一段時間的迭代進行反省總結，以便調整自己的行為，提高項目的開發效率。因為很多不確定的因素都會導致項目的原計劃失敗，比如項目需求的變更、人員的流動、市場的變化等等都會讓我們做出不同的反應。在每次失敗中進行反思，吸取經驗教訓，其實是對敏捷的進一步認識，團隊成員只有通過不斷地總結、反思和調整，才能更好地保持團隊的敏捷性。

了解了敏捷的基本概念和特點后，我們來看看敏捷的本質是什么——

事實上，敏捷的背后是兩個在當下非常流行的概念，一個叫做MVP，一個叫做精益分析。

什么是MVP和精益分析

MVP是最小化可行產品（Minimum Viable Product）的簡稱。這個概念是Eric Ries 在《精益創業》里提出來的，簡單地說，就是指產品開發團隊通過提供最小化可行產品獲取用戶反饋，并在這個最小化可行產品上持續快速迭代，直到產品到達一個相對穩定的階段。

MVP模型也是《精益創業》中最為崇尚的方法，在產品的生命周期中，產品處于探索期時，產品價值、市場切入點、用戶群、用戶體驗平衡點、商業目標等都模糊不清，這時候就需要低成本快捷的MVP去探索以上問題，讓產品找到更好的發展方向。

mvp的版本迭代思路

如上圖所示，傳統的產品設計思路是一步一步，從車輪、車轱轆、外殼、動力裝置、內部裝飾一個流程一個流程做起，最后得到一個完善的產品。正確的敏捷迭代應該是每一步的產品都是最小可行的，雖然第一版滑板車和最后的汽車相去甚遠，但也是能夠滾動的代步工具，在驗證了用戶對出行工具的認可程度后，我們就可以去生產更加高級、完善的摩托車、甚至小轎車。

MVP的幾個原則可以和大家分享下：

1、抓住產品核心主流程

MVP要求我們抓住最核心的產品流程，剔除多余的功能或者高級功能。比如電商產品，核心目標就是讓用戶在產品上下單買東西。那核心流程就應該是：瀏覽商品——挑選商品——下單付款——查詢物流信息。那就圍繞這個流程，剝離其他多余的功能需求（個性化推薦、活動推薦、秒殺大促、分享評論、積分等），做一款MVP產品。

當然，一款產品的核心主流程具體包含哪些，這個是需要團隊和產品經理一起去商量出來的結果，不同業務，不同場景下的核心流程會有所差異。

2、不同階段的MVP目標不同

在產品從0到1的階段，產品剛剛上線，這個時候MVP1.0的目標就是驗證需求，設想的需求是真實存在還是偽需求？設想的需求是高頻還是低頻？是剛需還是非剛需？

而在后續的迭代中，如果產品設想的需求的確和市場痛點相匹配，那么MVP2.0的目標則會開始優化產品核心主流程的用戶體驗，然后增加一些新的功能點。下一個版本的迭代則繼續去觀察新增加的功能點是否符合用戶需求，考慮如何改進或者是下線處理。簡單來說，在不斷的迭代的過程中，我們對MVP的關注目標發生了一些變化，但最核心要關注的還是產品的核心主流程。

3、可以嘗試任何產品形態

隨著移動互聯網紅利期的基本結束，一個創業公司通過開發一款APP而成為獨角獸級別公司的可能性已經越來越小了，這個時候APP的開發成本、推廣成本也是相當之高。所以很多的創業公司會去糾結到底是做一款APP還是做一個微信公眾號，這其實就涉及到MVP的產品形態問題。MVP可以是一個只有基本功能的APP，也可以是一個微信公眾號，一個微信群，甚至是一款紙面原型，一個視頻。只要是可以讓你的用戶直觀地感知到產品的價值，能激發出他們想要使用產品的體驗就可以。

現在更多的產品會通過微信公眾號的形式驗證，比如知乎的付費問答值乎，最開始的mvp產品形態主要是知乎服務號的自定義菜單或者朋友圈的分享，如果一開始就放在App端，如果用戶沒有來得及更新，就錯失了市場機會（同一時間，分答已經在市場上跑馬圈地了）。

那什么是精益分析呢？

所謂的精益分析，首先是你有一個想法或者靈感，然后通過MVP策略讓產品快速上線，產品上線后，通過數據來衡量用戶的表現，如果好的話就保持、繼續優化，不好的就下線反思。

在創業公司，大部分的idea都來自于創始人的靈光一閃，大部分情況下投放到市場上驗證時發現用戶沒有需求。創業團隊往往精力有限，要讓驗證的周期盡可能縮短，而MVP加上精益分析，通過數據表現就可以快速地幫助驗證市場對于產品的反饋。如果用戶反饋很好，就可以繼續加大投入，如果用戶反饋有問題，也可以及時調整避免更多的精力浪費。

MVP的實踐版——分答的版本迭代之旅

分答，是2016年度最引人注目的付費語音問答，用戶可以快速地找到可以給自己提供幫助的那個人，行家通過語音用一分鐘時間為用戶答疑解惑。這款產品由在行團隊孵化，也是延續了知識傳播與分享的分享方式。不僅是科學家，很多名人和各領域的專家也都加入「分答」付費問答的模式。上線僅四十二天，超過1000萬授權用戶，付費用戶超過100萬，33萬人開通了答主頁面，產生了50萬條語音問答，交易總金額超過1800萬，復購率達到43%。

在如此傲人的成績下，分答的產品總監朱曉華透露，分答的idea來自于在討論輕量化知識交換平臺中，姬十三想做個語音問答，從確定要做到產品正式上線，中間只用了一周的時間。

我們可以來看看一周的時間，分答團隊都做了哪些事情：

1. 一晚框架：1個產品經理
2. 一日原型：3個產品經理
3. 一個周末主體：1設計、1后端、1前端、1測試、1運營
4. 一周業余時間完善
5. 兩天內測
6. 一日引爆

通過一周緊張的設計和開發，分答的第一個版本終于上線了。第一版上線的分答，非常簡單、簡陋，只有最基本的提問和偷聽功能，而且還有不少的bug，但這并不影響產品上線驗證用戶需求。

在上線之后，分答團隊基本上保持了每天發布至少3次新版本的節奏在進行更新，這是怎么做到的呢？

除了精益迭代的團隊認知之外，還有一個產品形態的選擇也是產品能夠快速迭代的基礎。分答第一版的產品形態不是基于手機的客戶端，而是在微信環境內使用的一個H5頁面，并通過服務號完成通知、支付等服務。

比起直接開發手機客戶端，用基于微信服務號進行開發有幾個非常明顯的好處：

1. 用戶使用成本低：不需要下載客戶端，打開網頁就可以使用
2. 開發成本低： iOS、android客戶端兩大陣營開發起來就直接雙倍工作量，而且還有各種適配問題
3. 迭代成本低： 不需要去應用市場提交新版本，在讓用戶下載安裝包進行更新，直接服務器端進行更新就完成了迭代，用戶完全無感迭代

用H5版本進行開發，極大地降低了開發和迭代成本，在微信環境里，入口雖然深，但通知和交易閉環都是完整的。

上線并不意味著戰斗結束，如何精準、高效地記錄和分析產品數據，通過對產品數據和用戶數據的精益分析去迭代產品，則成為了下一個階段的工作重點。分答團隊通過使用第三方數據分析平臺，跟蹤不同模塊的使用頻次，監控搜索效率與付費收聽流程的轉化，通過觀察留存來分析各用戶群組的復聽率、復購率等，不斷地觀察產品的數據表現和了解用戶反饋去迭代產品。

就這樣，分答在短短6周內通過敏捷開發的方法創造了知識分享領域的“數據增長神話”。

#專欄作家#

壹百度，微信公眾號：倒退集，人人都是產品經理專欄作家。在線教育企業服務領域產品經理，創業公司Team Leader。曾主導多款重量級產品的產品策劃和設計工作。

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