本文旨在引導產(chǎn)品從業(yè)人員關(guān)注和重視開發(fā)模式問題，隱去了各模式的實施細節(jié)和管理復雜性。文章介紹了常見的5種開發(fā)模式，并對各模式進行了分析，與大家分享。

我一個產(chǎn)品經(jīng)理（本文泛指產(chǎn)品人員）為何要關(guān)注開發(fā)模式，開發(fā)的事不是技術(shù)的事嗎？那不是技術(shù)團隊該關(guān)心的事嗎？

一、為什么產(chǎn)品經(jīng)理需要關(guān)注開發(fā)模式？

1. 開發(fā)模式即工作模式

首先我們要達成一個共識：產(chǎn)品經(jīng)理除了收集分析需求、拋出草案、定方案、輸出原型、prd、流程圖、架構(gòu)圖等專業(yè)工作之外，還需要負責協(xié)調(diào)資源、上傳下達等保障整個研發(fā)順利進行的工作。產(chǎn)品經(jīng)理是貫穿始終從頭走到尾并對最終結(jié)果負責的人。

互聯(lián)網(wǎng)軟件研發(fā)周期中的各團隊參與情況和當前項目所處的階段，大略劃分的話可以有如下關(guān)系：

完成軟件開發(fā)所要進行的工作和各團隊之間大致有如下關(guān)系：

為什么有交叉？

• 設(shè)計工作不僅僅是產(chǎn)品經(jīng)理設(shè)計產(chǎn)品方案，拿到產(chǎn)品方案后研發(fā)團隊需要構(gòu)建同樣重要的技術(shù)方案。
• 測試方面，測試團隊肯定是主角，進行項目質(zhì)量的整體驗收。除了這些還有研發(fā)團隊研發(fā)過程中的單元測試，提測前的整體自測，還有產(chǎn)品同學的輔助測試和上線后回歸測試等。
• 至于部署方面，硬件方面的事情自然運維團隊去處理，但設(shè)備選型則是技術(shù)方案的一部分。另外有的公司是技術(shù)團隊負責發(fā)布代碼，有的是運維同學進行發(fā)布。

各團隊之間看起來相互獨立，各司其職，實則緊密相連，不可分割。無論開發(fā)模式是不是技術(shù)團隊該關(guān)心的事，它都不可避免地會影響整個研發(fā)過程。各團隊為了消除這種影響，需要調(diào)整工作方式去配合，這樣才能釋放出相應(yīng)模式的優(yōu)勢力量，達到整體最佳。

2. 熟練掌握開發(fā)模式的好處

第一：加入一個新團隊，能識別出當前團隊正在采用的開發(fā)模式，可以快速適應(yīng)節(jié)奏展開工作，更順利更少犯錯。試想如果人家在采用敏捷開發(fā)，而你帶著瀑布開發(fā)的思維投入工作并產(chǎn)出，團隊首秀上來就挖坑，想想都覺得可怕。

第二：清楚團隊當前工作模式的優(yōu)勢和局限，在局限性方面就可以提前做好準備，不至于當問題發(fā)生時措手不及，處于被動的局面被牽制住。問題的產(chǎn)生很有可能是團隊工作方式的弊端帶來的而非你個人能力的問題，這個鍋不能背。

第三：以第二點為基礎(chǔ)，清楚局限可以有意識盡所能去優(yōu)化，無論對個人發(fā)展還是公司效率，都是極好的。

二、各開發(fā)模式相互對比

一款產(chǎn)品不是孤立的，它是和自身、公司、競品、行業(yè)、用戶群等相互關(guān)聯(lián)的，共同作用下的一個結(jié)果，我們研發(fā)一款產(chǎn)品，是基于一定需求痛點，服務(wù)于特定人群的。在信息過載、要求快速響應(yīng)的互聯(lián)網(wǎng)世界里，開發(fā)過程的靈活性和用戶參與程度被越來越多的關(guān)注和利用。

當下公司所采用的開發(fā)方式有N多種，每一種都是特定場景下的特定產(chǎn)物，沒有絕對的優(yōu)劣，適合最重要。我們先從操作靈活性、用戶參與度兩個維度對當下流行的開發(fā)模式做一下全局預(yù)覽。

三、5種常見開發(fā)模式介紹

我們選取了4種典型的開發(fā)模式進行說明，這4種模式有的是默認選擇的，可能你在用但是你自己沒意識到；有的是當下熱議的；有的是用于增加項目透明度可以隨時引入新的變更需求的；有的是應(yīng)對老板一聲令下要求即刻上線的。

1. 瀑布式開發(fā)

各個階段從上到下，一步一步地走，是不是很像瀑布，水從上流淌而下。

瀑布模型式是最典型的預(yù)見性的方法，是開發(fā)方法論的老大哥，嚴格遵循預(yù)先計劃的需求、分析、設(shè)計、編碼、測試的步驟順序進行。只能一個階段一個階段的執(zhí)行，不可回溯。每個階段都需要獨立評估，準確無誤的輸出，完整的文檔。上一個階段結(jié)束前，下一個階段不能開始。直到最后部署交付，期間都拿不到切實可應(yīng)用的項目。

這是大多數(shù)團隊默認采用的一種模式，甚至常用到自己在用它，但是都不知道它就是瀑布式開發(fā)。采用瀑布開發(fā)方式的用戶常見于新負責的項目經(jīng)理因為這種方式對項目的估計非常方便。項目開發(fā)中涉及到的幾乎一切都預(yù)先計劃，從而便于確定預(yù)期的開發(fā)成本和開發(fā)時間，非常方便地把整個項目置于自己的掌握之下。

缺點也很明顯，任何人都不能預(yù)知未來，做出來的方案也都不是完美無瑕，計劃趕不上變化，每個階段環(huán)環(huán)相扣，任何一個階段出問題，都可能導致延期甚至項目失敗。另外對于開發(fā)人員而言就可能顯得太嚴酷了。因為測試過程在開發(fā)階段之后實施，子系統(tǒng)測試所暴露的問題可能需要立即修改代碼，而開發(fā)人員一般在同一階段也會從事其他的開發(fā)任務(wù)，而所需要的軟件修改可能會降低開發(fā)人員的生產(chǎn)率和工作質(zhì)量，這樣就顯著增加了計劃架構(gòu)的成本。

2. 增量和迭代開發(fā)

增量和迭代其實是兩種開發(fā)方式。

增量開發(fā)是把項目切割成N個相對獨立的模塊。像堆積木一樣，每次迭代會增加新的軟件模塊，而在先前添加的模塊中幾乎沒有變化。開發(fā)過程可以順序進行，也可以并行進行，并行開發(fā)提高了交付速度。

這就要求產(chǎn)品經(jīng)理在分析設(shè)計階段，要充分考慮研發(fā)資源問題。如果研發(fā)資源有限，我們把項目切分成塊后勢必要按緊急、重要程度進行排序，業(yè)務(wù)人員會牽扯進來。如果研發(fā)資源充足，分析設(shè)計階段產(chǎn)品經(jīng)理會很忙，我們要在設(shè)計階段過后輸出的是供好幾個研發(fā)組并行開發(fā)的子模塊原型、PRD、流程圖等，當然如果你是個產(chǎn)品leader的話，就可以授權(quán)下面人去分頭行動了。

迭代開發(fā)和增量開發(fā)類似，也是把一個大任務(wù)切分成N個子任務(wù)。與增量模式各模塊間相對獨立不同，迭代開發(fā)的每次迭代任務(wù)都是以上一次迭代為基礎(chǔ)進行的。由于軟件是分部分交付的，因此從項目開始就不需要完整的規(guī)范，并且在開發(fā)過程中可能會對需求進行少量更改。但是，需求不能根本改變，必須在開始時就定義主要需求。

這就要求產(chǎn)品經(jīng)理每次迭代都要留下足夠清晰的文檔，供后來人能接著繼續(xù)迭代開發(fā)，后來人可能是公司其他產(chǎn)品經(jīng)理，也可能是新來的產(chǎn)品經(jīng)理。如果你是一個產(chǎn)品leader，如果你們公司項目采用的是迭代開發(fā)模式，如果你不想因為某個人的離職導致開發(fā)組陷入一團糟的話，就提前要有這方面的要求和準備。

如果把增量開發(fā)看作是橫向開發(fā)的話，那迭代模式就是縱向開發(fā)。增量迭代模式的優(yōu)點是如果失敗，影響的只是一部分而非整個項目，降低了損失。軟件更容易成功，通過先前的上線版本收集用戶反饋，結(jié)合反饋作出下一次迭代方案，小步快跑更容易成事。缺點是因為增量開發(fā)是拆開成塊，如果開發(fā)過程中沒有溝通好，或者文檔不清晰，會導致后期合在一起的時候出問題。

3. 看板開發(fā)

大家經(jīng)常聽到敏捷開發(fā)，其實敏捷開發(fā)不是一個模式，而是一組模式的統(tǒng)稱。本節(jié)講的看板開發(fā)和下節(jié)的極限編程都屬于敏捷開發(fā)，除此之外還有Scrum。

如果說瀑布模式是一種自上而下的驅(qū)動方式，那么看板模式就是一種自下而上的驅(qū)動方式。后道工序在需要時，通過看板向前道工序發(fā)出信號，請給我需要數(shù)量的輸入。前道工序只有得到相應(yīng)看板后，才啟動任務(wù)。用戶需求為其中的原始驅(qū)動力。

看板模式?jīng)]有明顯的迭代過程，沒有單獨的計劃階段，可以隨時引入新的變更需求?？窗迳系膬?nèi)容堅持“即來即增加”和“即變即更新”的原則，團隊中的每個人都可以根據(jù)實際情況增加或者流動自己負責的任務(wù)。可以清晰地看到所有項目活動，任務(wù)數(shù)量，負責人和進度。這種增加的透明度有助于更準確地估計最緊要的任務(wù)，項目組也更加趨向于自動化。

站立會是看板開發(fā)方式的一個顯著特征，每天開發(fā)組主要成員，一人一兩分鐘，交代下自己當前已完成的任務(wù)，正在進行的任務(wù)，有沒有遇到問題。之所以采用站立的形式，是因為不要在會上討論復雜的問題，產(chǎn)品經(jīng)理需要把控好站立會的時間。

復雜問題如需討論，單約專項會議進行。開發(fā)是環(huán)環(huán)相扣的，站立會會把問題提前拋出來，避免之前流程環(huán)節(jié)上的浪費。能帶來一種類似“Stop and Fix”的氛圍，出現(xiàn)問題時，能立刻暫停，分析根本原因，并加以解決，防止問題的再次發(fā)生。

但是這種方式，容易讓大家的注意力集中到某個點上而忽略其他點，不利于思維的發(fā)散。

4. 極限編程（XP）

極限編程和傳統(tǒng)開發(fā)模式的本質(zhì)不同在于它更強調(diào)可適應(yīng)性以及面臨的困難，去掉了條條框框，更強調(diào)專注問題，快速解決。也可以理解為這是一種更“隨意”的開發(fā)方式，但是設(shè)計、編碼、測試環(huán)節(jié)依然存在，只是不拘泥于形式和流程。所以除了團隊成員之間需要相互熟悉、默契之外，在團隊文化方面也是有一定要求的，它的基礎(chǔ)和價值觀是交流、樸素、反饋、勇氣和尊重。適用于經(jīng)常發(fā)生變化的項目、緊急上線任務(wù)和封閉開發(fā)等。項目組人數(shù)也要進行控制，建議在2～10人之間。

在極限編程式開發(fā)中，經(jīng)常見到結(jié)對編程，即代碼由兩個人坐在一臺電腦前一起完成。一個程序員寫代碼關(guān)注編碼細節(jié)，另外一個人主要關(guān)注整體結(jié)構(gòu)性的東西，不斷地對第一個程序員寫的代碼進行評審。團隊成員能夠長期維持努力工作的狀態(tài)，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。

代碼權(quán)限集體所有，每個人都可以更改代碼的任意部分，每個人都對所有的代碼負責。在XP中，沒有那種傳統(tǒng)開發(fā)模式中一次性的、針對所有需求的總體設(shè)計，設(shè)計過程幾乎一直貫穿著整個項目開發(fā)，而且實現(xiàn)方式簡單，能滿足需求、通過測試即可。

不推諉不扯皮，有話直說，對事不對人，勇于承擔任務(wù)，不逃避責任。這個“極限”就體現(xiàn)在把交流、反饋、勇氣、尊重這些最樸素的東西發(fā)揮到了極致。這種模式的弊端除了挑團隊之外，由于不拘泥形式，后期在文檔完整性上也會有所欠缺。

如果項目組成員有流動也會給開發(fā)帶來很大問題。因強調(diào)的是簡單設(shè)計簡單開發(fā)，更關(guān)注當下的需求滿足情況，所以后期重構(gòu)的幾率會更大。但是這種模式所帶來的效率提升，結(jié)果導向性，在某些場景下是其他模式所不能取代的。

四、不同場景下的開發(fā)模式選擇

每個公司，每個團隊，每個項目都有自身的獨特情況，以下關(guān)系基于各開發(fā)模式本質(zhì)特征進行推薦，實際情況需實際分析，也可以集合多種模式優(yōu)點組合使用。

無論使用何種開發(fā)模式，想要有效實施都依賴于對原理的理解、對原則的堅持和實踐時的隨機應(yīng)變。

1. 瀑布開發(fā)適合場景

1. 具有明確定義和不變需求的中小型項目，比如小型公司網(wǎng)站開發(fā)
2. 需要嚴格控制流程，預(yù)算和時間表可預(yù)測的項目，比如政府類項目
3. 必須遵守多個規(guī)章制度的項目，比如醫(yī)療軟件
4. 使用了業(yè)內(nèi)熟悉的成熟的技術(shù)方案的項目

2. 增量迭代模式適合場景

大型關(guān)鍵企業(yè)應(yīng)用程序，最好由松散耦合的部分組成，比如微服務(wù)或web服務(wù)類

3. V模式適合場景

故障和停機時間不可接受的項目，比如醫(yī)療軟件、航空管理軟件

4. 螺旋模式適合場景

1. 業(yè)務(wù)要求不明確或過于雄心勃勃地創(chuàng)新型項目
2. 大型且復雜的項目

5. RUP適合場景

大型和高風險項目，尤其是基于用例的開發(fā)和高質(zhì)量軟件的快速開發(fā)

6. 敏捷開發(fā)適合場景

1. 要求處理目標用戶前期反饋的新項目
2. 業(yè)務(wù)要求不能被清晰地轉(zhuǎn)換成產(chǎn)品需求的中型定制化項目

五、開發(fā)模式只是大公司大團隊該考慮的事嗎？

各種開發(fā)模式的產(chǎn)生是因為現(xiàn)實開發(fā)中遇到了各種各樣的問題，一個模式對應(yīng)一類問題的解決方案。無論團隊大小，結(jié)果導向，遇到問題都可以采用對應(yīng)方案。

開發(fā)模式本質(zhì)是關(guān)于工作效率、資源利用率的問題，小公司更需要關(guān)注花更少的錢辦更多的事。

內(nèi)耗導致的項目死亡。就像齒輪要克服相互之間的阻力才能對外做功，不合適的齒輪組合會帶來更大的阻力，大公司可以利用其強大的資金、人才去克服額外阻力，消除不良影響。小公司資金、人才方面比較弱，更應(yīng)規(guī)避內(nèi)耗問題。

寫在最后

采用什么樣的開發(fā)模式直接影響到各工種用什么樣的工作模式投入其中。小了說關(guān)乎效率問題，大了說關(guān)乎項目成敗。與公司大小沒有關(guān)系，結(jié)果導向、效率導向，希望大家避免無意中的自我毀滅。

最后，與大家分享一句《湮滅》中的經(jīng)典臺詞：“Almost none of us commit suicide, and almost all of us self-destruct”

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

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