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

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

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

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

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

什么是敏捷開發(fā)？

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

敏捷 vs 不敏捷

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

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

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

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

敏捷開發(fā)的一些特點

1.小步快跑，盡早交付

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

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

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

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

3. 版本周期內(nèi)盡量不加任務

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

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

4. 團隊配置也要敏捷

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

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

5. 敏捷也需要反思

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

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

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

什么是MVP和精益分析

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

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

mvp的版本迭代思路

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

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

1、抓住產(chǎn)品核心主流程

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

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

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

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

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

3、可以嘗試任何產(chǎn)品形態(tài)

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

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

那什么是精益分析呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

就這樣，分答在短短6周內(nèi)通過敏捷開發(fā)的方法創(chuàng)造了知識分享領域的“數(shù)據(jù)增長神話”。

#專欄作家#

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

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