文∣阿安，PMP，NPDP，敏捷教練，歡迎關(guān)注，一起學(xué)習(xí)產(chǎn)品開發(fā)管理

埃隆·馬斯克太空探索技術(shù)公司( SpaceX)的創(chuàng)始人、首席執(zhí)行官和首席技術(shù)官,特斯拉( Tesla Motors)的首席執(zhí)行官和產(chǎn)品架構(gòu)師，他曾說:'來冒險吧!做點(diǎn)刺激的事兒!你不會為此后悔的。'

他把產(chǎn)品研發(fā)當(dāng)做一種冒險，他的勇氣令人欽佩。對與大多數(shù)企業(yè)來說，必須要考慮新產(chǎn)品失敗情況，選擇一條可以盡量規(guī)避風(fēng)險的發(fā)展之路。

“大廚式”研發(fā)VS“敏捷式”研發(fā)，孰優(yōu)孰劣

在中國企業(yè)依賴能人的研發(fā)狀態(tài)十分普遍，這樣研發(fā)高手就像大廚一樣，只有他們才能做得出“好菜”，這樣研發(fā)模式被稱之為“大廚式”研發(fā)。

這樣依靠能人的開發(fā)方式，時間短、效率高、成本低是中小企業(yè)尤其是初創(chuàng)企業(yè)的首選，但這種方式有個致命的弊端，就是公司的產(chǎn)品研發(fā)離開他們就不行了，只要高手一離開，公司就不能做出來好的產(chǎn)品 。

美國項目管理協(xié)會調(diào)研發(fā)現(xiàn)，大多數(shù)公司研發(fā)研究顯示新產(chǎn)品失敗率超過70%，

對大多數(shù)組織而言,一個關(guān)鍵問題是:'研發(fā)新品是否有可能降低失敗率?'如果有可能如何降低?

美國產(chǎn)品開發(fā)與管理協(xié)會的一項調(diào)查顯示：'有些企業(yè)新產(chǎn)品研發(fā)的成功率為61%，而這些成功率在很大程度上取決于企業(yè)采用的新產(chǎn)品開發(fā)實(shí)踐和流程的質(zhì)量。調(diào)查表明,開發(fā)實(shí)踐和流程是成功率提升的基礎(chǔ)。'

在過去50年里，產(chǎn)品開發(fā)流程的研究和應(yīng)用迅猛發(fā)展，因此出現(xiàn)了多種研發(fā)流程，很多流程是為了不同的行業(yè)、產(chǎn)品或市場而設(shè)計的。

今天，介紹用一張介紹產(chǎn)品開發(fā)模式的演變，軟件開發(fā)從20世紀(jì)50年代就隨著操作系統(tǒng)的發(fā)展演進(jìn)，隨著時代的演進(jìn)，新的開放模式不斷地被研發(fā)出來。

1.瀑布模式

瀑布模式由溫斯頓·羅伊斯于1970年提出,采用盛行于硬件工業(yè)界的生命周期模式,迅速發(fā)展成為當(dāng)時軟件開發(fā)的主流模式。

此模式將軟件開發(fā)分為幾個不同的階段,并清楚定義每個階段所要做的工作及所要交付的文檔,各階段順序執(zhí)行且如果需要修訂,僅往上一階段且僅循環(huán)一次。

瀑布模式可根據(jù)軟件系統(tǒng)的復(fù)雜程度,分為不同的階段。一般將軟件開發(fā)過程分為需求、設(shè)計、開發(fā)、測試、部署等階段,開發(fā)較復(fù)雜的軟件系統(tǒng)時,可細(xì)分成更多階段。

瀑布模式特色：

1)一個階段的結(jié)束就是項目管理的里程碑,根據(jù)階段成果,決定是否要進(jìn)入下一個階段;項目資源的配置是以軟件生命周期的各階段為基礎(chǔ)。

2)各階段的工作人員負(fù)有每階段產(chǎn)出的明確責(zé)任,各階段產(chǎn)出都須經(jīng)過確認(rèn)、驗證及測試,同時可借此發(fā)現(xiàn)質(zhì)量上的缺陷并加以改善。

3)各階段的工作人員須完成該階段正確、完整及易讀的文檔或程序,移交給下一階段的工作人員。且工作人員在接收前一階段的產(chǎn)出時,也要確認(rèn)其完整性與正確性。

瀑布模式缺點(diǎn)

1)在項目開始時,必須完整且清楚地描述所有需求,執(zhí)行上缺乏彈性且困難。

2)系統(tǒng)開發(fā)周期冗長,過程中客戶參與不足。

3)客戶要到項目末期時才能看到產(chǎn)品,無法及時反應(yīng)客戶需求

4)項目工期較后階段才開始進(jìn)行開發(fā),風(fēng)險與失敗成本都高。

5)各階段的任何改變或錯誤都必須回溯到前一階段,須遵守每階段通常是冗長的審查或簽核過程,過程過于嚴(yán)謹(jǐn)且缺乏彈性,易造成項目超支與超時。

2、漸增模式

將軟件系統(tǒng)分解為多個子系統(tǒng)(或功能)后,先開發(fā)系統(tǒng)的核心功能,再依序或平行開發(fā)其他附屬功能,每一個漸增階段的開發(fā)模式以瀑布式進(jìn)行,必須清楚定義要做哪些工作及交付哪些文檔,每個階段循序進(jìn)行且僅循環(huán)一次。

漸增模式一般運(yùn)用于龐大或復(fù)雜程度高的系統(tǒng),經(jīng)由切割系統(tǒng)需求功能或依客戶要求,先行開發(fā)部分功能,再依序或同步進(jìn)行其他功能的開發(fā)。

漸增模式特色

1)漸增模式根據(jù)系統(tǒng)的復(fù)雜程度或客戶的需求,分階段配置項目資源,因此彈性較高。

2)由于漸增模式采分階段配置方式,對于項目預(yù)算的編制、付款、系統(tǒng)測試及人員教育訓(xùn)練等活動,都可采用分階段方式進(jìn)行這樣可有效降低財務(wù)風(fēng)險與項目失敗風(fēng)險。

3)若組織希望員工能充分熟悉與接受新系統(tǒng)時,采用漸增模式開發(fā),能讓組織成員有充分時間學(xué)習(xí)與進(jìn)行技術(shù)轉(zhuǎn)移。

漸增模式缺點(diǎn)

1)多階段開發(fā)的模式需要對每個漸增階段做清楚與完整的定義,因此可能使系統(tǒng)開發(fā)工期變長

2)每個漸增階層都是僵化的,且不易互相關(guān)聯(lián)。

3)每個漸增階段的開發(fā)模式都如同瀑布式進(jìn)行,有獨(dú)自的需求、分析、設(shè)計、開發(fā)、測試等過程,因此總開發(fā)成本通常大于瀑布模式

3、雛型模式

它的主要目的,是希望在無法很清楚描述系統(tǒng)需求的情況下,能夠先依客戶所提需求,快速地建置一個雛型操作接口,以便及早澄清或驗證不明確的系統(tǒng)需求。

軟件開發(fā)過程中,強(qiáng)調(diào)以雛型操作接口,作為客戶與開發(fā)人員溝通與學(xué)習(xí)需求的工具。雙方通過雛型操作與反饋,反復(fù)進(jìn)行厘清與修改需求,直到雛型系統(tǒng)確實(shí)符合客戶需求,再以瀑布模式進(jìn)行正式軟件開發(fā)與測試至完成系統(tǒng)為止。

雛型模式特色

1)強(qiáng)調(diào)雛型的快速開發(fā)及用戶高度參與。

2)強(qiáng)調(diào)以雛型作為用戶及系統(tǒng)開發(fā)者之需求溝通與學(xué)習(xí)機(jī)制。

3)雛型模式屬于客戶導(dǎo)向的分析與設(shè)計,但往往大部分時間,客戶并不清楚他們真正的需求是什么。

雛型模式缺點(diǎn)

1)雛型模式在軟件開發(fā)項目初期,開發(fā)團(tuán)隊無法確切掌握要花多少時間,才能完成一個可被客戶接受的產(chǎn)品。

2)雛型模式強(qiáng)調(diào)以雛型演進(jìn)代替完整分析與設(shè)計,因此系統(tǒng)文檔較不完備,后續(xù)程序維護(hù)相對困難。短期而言,能迅速滿足用戶需求,但長期而言,系統(tǒng)易偏離目標(biāo)而失敗。

3)雛型模式需要頻繁的用戶參與,易造成部分客戶排斥。

4)開發(fā)團(tuán)隊會將維型系統(tǒng)視為最終產(chǎn)品,犧牲產(chǎn)品質(zhì)量。

5)缺乏整體規(guī)劃、分析與設(shè)計,故較不適用于大型及多人參與的系統(tǒng)開發(fā)項目。

4、螺旋模式

它兼顧了雛型模式的循環(huán)特征及瀑布模式的系統(tǒng)化與嚴(yán)格監(jiān)控,最大特點(diǎn)則在風(fēng)險的識別與應(yīng)對,使得軟件開發(fā)項目有機(jī)會在發(fā)現(xiàn)無法排除的重大風(fēng)險時,及早進(jìn)行風(fēng)險響應(yīng)或終止項目

避免發(fā)生嚴(yán)重的損失。

每個循環(huán)階段所構(gòu)建的雛型,是用以降低風(fēng)險的方法,因此螺旋模式更適合大型軟件系統(tǒng)的開發(fā)。

螺旋模式開發(fā)步驟

1)每個循環(huán)階段有明確的目標(biāo)、備選方案及其限制。

2)對備選方案進(jìn)行評估,辨識并解決既有風(fēng)險。

3)進(jìn)行此循環(huán)階段的開發(fā)與測試。

4)與客戶一起對該階段進(jìn)行檢討與回顧。

5)重復(fù)步驟1)-4),當(dāng)風(fēng)險得到很好的分析與解決后,也就是確定詳細(xì)的需求后,再用瀑布模式進(jìn)行開發(fā)與測試。

螺旋模式優(yōu)點(diǎn)

1)通過建立軟件雛型與客戶溝通,軟件開發(fā)過程每個循環(huán)的目標(biāo)明確。

2)螺旋模式包容了現(xiàn)有軟件開發(fā)過程模式的大部分優(yōu)點(diǎn),借由風(fēng)險分析,大幅降低軟件失敗造成損失的可能性。

3)每個循環(huán)階段中的軟件測試,可確保每個循環(huán)的軟件質(zhì)量。4)通過與用戶的反饋與溝通,以符合客戶需求

螺旋模式缺點(diǎn)

1)過分依賴風(fēng)險分析經(jīng)驗與技術(shù),如果在風(fēng)險分析過程中出現(xiàn)偏差,將造成重大損失。

2)過于靈活的開發(fā)過程,不利于已簽署合約的客戶與開發(fā)者之間的協(xié)調(diào)。3)過高的風(fēng)險管理成本,可能會影響客戶的最終收益。

5、RUP（統(tǒng)一開發(fā)過程）模式

統(tǒng)一開發(fā)過程模式1996年提出，是軟件分析與設(shè)計的標(biāo)準(zhǔn)。

以水平軸與垂直軸加以區(qū)分,說明如下,交又格上的圖形面積代表其估計工作量或比率。

(1)水平軸

區(qū)分為初始、詳述、建構(gòu)與轉(zhuǎn)移等四個階段,每階段內(nèi)可依需求,分為幾個迭代進(jìn)行。

(2)垂直軸

依工作過程順序,將軟件開發(fā)與管理支持區(qū)分為:企業(yè)建模需求、設(shè)計、開發(fā)、測試、部署、配置管理與變更管理、項目管理環(huán)境等九個核心工作過程

RUP模式優(yōu)點(diǎn)：

1)以企業(yè)建模為系統(tǒng)開發(fā)首要工作,讓開發(fā)者了解其重要性,進(jìn)而能更精確了解用戶的需求。

2)迭代式的軟件開發(fā)方式,讓開發(fā)者能夠在每次迭代中及早發(fā)現(xiàn)問題,降低開發(fā)的風(fēng)險。

3)可視化的軟件模型,可提升軟件開發(fā)人員之間的溝通效率。

4)提供良好的工具支持,軟件開發(fā)各個階段中項目成員能明確了解其責(zé)任與義務(wù)。

RUP模式缺點(diǎn)

1)模式過于繁雜,相對使得企業(yè)在學(xué)習(xí)及導(dǎo)入時都很困難。

2)RUP模式支持工具上,受限于 IBM Rational軟件。

6、敏捷模式

敏捷是一種基于敏捷價值觀、原則及實(shí)踐的心態(tài)或做事情的思維哲理,敏捷就像一把大傘,符合敏捷價值觀與敏捷原則的就是敏捷方法論。方法論通常要搭配一些敏捷過程與實(shí)踐,才能更發(fā)揮敏捷的成效

大傘下的左方是常用敏捷方法論,大傘下的右方是常用敏捷實(shí)踐。

常用的敏捷方法論有 Scrum、極限編程( eXtreme Programming, XP)、精益(Lean)、看板( Kanban)、動態(tài)系統(tǒng)開發(fā)方法( Dynamic Systems Development Method, DSDM)、功能驅(qū)動開發(fā)模式( Feature-driven Development, FDD)水晶家族( Crystal Family)等。

以上所提及的每個開發(fā)流程的基本結(jié)構(gòu)和基本原則都有顯著優(yōu)勢。但在實(shí)際業(yè)務(wù)使用時，應(yīng)該評估其開發(fā)流程是否符合公司及項目的特征，按照以下問題對比流程：

· 它是否對整個產(chǎn)品開發(fā)流程進(jìn)行管理?

· 它是否專注于跨職能團(tuán)隊的使用?

· 它能加快上市速度嗎?

· 它最適用于什么類型的產(chǎn)品和行業(yè)?

· 它如何降低產(chǎn)品失敗的風(fēng)險?

· 它是線性的還是迭代的?

對于公司來說，沒有最好的流程，只有最適合的流程。