項目管理：項目開發類型、模型、流程以及案例介紹

前言

職能部門越賣力，企業越像官僚？賠錢的項目也要，老闆是不是瘋了？日報，週報，月報…然並卵，項目照舊失控，都是惹不起的“爺”，先招呼誰？項目到底有完沒完？做項目累？那是你“姿勢”不對！

“做得更聰明”的一個方法就是建立透明的制度。德魯克說，管理是一套關於價值觀和信念的文化和制度。其實絕大多數管理問題都可以通過公開透明的制度來實現，這可以大量地減少人爲干預的資源浪費，還能發揮員工的自主精神。

現在的企業在轉型升級過程當中，都在追求更加高效的，面對項目的這種管理模式，就是以項目爲單元的精細化的管理模式，這種管理模式的特徵是什麼？就是公司裏的所有資源都面向項目，因爲項目是實現企業戰略的落地的載體，這種組織形式，它以矩陣形式爲特徵，也就是說我既有職能劃分的這樣的專業部門，也有從各個專業部門抽調的員工組成的項目團隊，所以它有兩個維度，豎着劃分是專業、職能部門，橫着我們再組建成一個一個的項目團隊，這種組織結構方式是有非常多優勢，這種矩陣形的組織，纔有可能讓組織的資源，也就是說我們企業的人力、物力、財力，得到最大化的利用，所以我們的工作努力都是面向企業的戰略。

項目開發的類型與模型

【迭代型的開發】：在動畫片《喜洋洋和灰太狼》裏灰太狼有一句經典的臺詞，“我一定會回來的”。其實灰太狼在每一集當中，都是想心心念念地抓一隻羊，送給它的老婆紅太狼做羊湯，但其實每一集，它都沒抓着。但灰太狼是屢戰屢敗、屢敗屢戰，從來都沒有放棄過，說，再來，我這次失敗了，我下一集再來，所以這就叫迭代。就是說我這個項目的開發是一版一版的不斷地更新、不斷地升級，這就叫迭代。

【增量型的開發】：就像搭積木一樣，我是一部分一部分的交付，我先幹完一塊，然後你先用，我再幹下一塊。增量開發的好處，是客戶能夠提前瞭解到你工作的成果，能夠把控這個項目的質量和客戶之間就多了一些交流的機會，增量開發是每一部分交付，都是一個完成狀態，只是我像搭積木一樣，是一塊一塊地交付給你。對比而言，迭代開發，它是一開始是個非常粗的輪廓非常簡單的，用最低的成本最快的速度，畫一個最簡的方案，那麼根據你的需求，根據你的反饋，我不斷地完善不斷地細化，這就叫做迭代開發。

【適應型地開發】 或稱爲 【敏捷開發】：在《終結者》系列電影中，施瓦辛格主演的科幻電影，他的這個機器人的型號叫T800很厲害，很抗揍，就是打得已經遍體鱗傷了，回去修補修補還能用。在第二部電影中，施瓦辛格的這個角色，他的對手敵人是一個更新的型號的機器人叫T1000，這T1000更厲害，就根本打不壞，它就是一坨液態金屬，這個子彈打穿身體，馬上就恢復了，它的適應能力就要比這個T800要強。在第三部新型號的敵方機器人TX，它不光是打不壞，而且根據環境的變化，可以隨時改變自己的狀態，它平常看起來就是一個美女，但一轉眼就變成一個冷血殺手，它的適應能力極強。所以什麼纔是最厲害，不是我結實我抗揍，而是我能夠根據需求，根據環境進行快速地適應。在敏捷開發當中常見的一個開發模型，叫做【Scrum模型】，它的意思就是說你有什麼需求隨時提，你提出來，我把你這個需求寫成一個【用戶故事】，然後放在我的這個需求庫裏。我現在有精力做，那我就及時給你實現，那如果做不到，那怎麼辦，下個版本去實現你現在的需求。所以能夠讓我們的團隊，能夠有節奏地進行持續地適應性地開發，這就叫敏捷開發。

【預測型的開發】：預測型的生命週期指的是我還沒做這個項目之前，我已經對這個項目的結果心中有數。比如說，我們的工程建設項目，在北京CBD，中國尊是非常高的一座高樓，我還沒做之前，這樓還沒有，我就知道這樓未來長這樣，而且我不單知道它未來外形長這樣，裏邊的結構、裏邊的電梯佈置等等，其實都在我的設計之中，還有我不光知道它建成之後長什麼樣，我其實知道未來每個時間點，就是比如說開工一個月以後它長什麼樣，兩個月以後這樓長什麼樣，其實我都心中有數，都在我的預測之中。在IT軟件行業當中，最經典的就是瀑布開發模型，一款軟件，如果用瀑布開發模型來做的話，那它是分這麼幾個階段，先是需求分析、然後方案設計、代碼開發、測試、最後上線運維。在需求分析階段，客戶提出一個需求，一個新需求，一個變更，客戶可以隨便提，提什麼都可以。但是如果說我在交付驗收階段，客戶提出說要改這個改那個，這時候它的代價實在是太大，可能比重新做一個新的項目還要費勁。瀑布開發模型，就是這樣一個從上往下，順序地這樣的一個過程。預測型指的是我一開始啥都想明白了，我都規劃好設計好了。對比敏捷開發，敏捷型開發是一開始根本沒法確定沒法想好，是根據現實的情況，你隨時提我隨時改，所以它的適應性更強。

【Stacey矩陣】：Stacey是研究企業的複雜性和它的適應性這樣的一個學者，他提出了一個Stacey矩陣。這個Stacey矩陣有兩個維度，豎的這個軸說的是需求是否明確，橫着這個軸說的是技術是否確立，所有的項目其實可以分成這麼幾個區間，第一個區間就是說需求很明確，技術方案怎麼實現也很明確，那這部分就叫簡單的項目。第二個區間說的是需求很清楚，但是怎麼實現卻並不能夠確定，到底怎麼解決，怎麼搞定它，現在其實心裏沒數。

那哪種類型的項目應該用哪種開發方式？Stacey就給出了一些建議：

簡單的項目，需求很清楚，怎麼實現也很清楚，那就應該用預測型。這樣成本最優，也是完全在我們掌控之內。
第二種就是需求清楚，不知道怎麼實現，這類項目可以用迭代的方式，就是說我不斷地嘗試，這版不理想，我下一個版本去優化。
第三類就是我們說的燒腦的項目，就是雖然我們實現的方法，並沒有什麼創新的技術，但是需求說不清楚，這怎麼辦？這類項目其實可以用增量的方式，就是說你能說清楚一部分，我給你實現一部分，你再想明白一部分，我再給你再實現一部分，這就是增量開發的方式。
那混亂的，既說不清需求，也不知道怎麼做，這類項目應該用什麼開發方式？這類項目不要碰，儘量地躲遠點！
最後一種就是模糊的項目，用的應該就是敏捷的方法，就是適應性很強的這種開發模式，才能夠做出這種需求和方案都不是很清楚，都處於模糊狀態的這樣的項目類型。

項目開發過程的劃分

本規定對一個完整的開發過程按“軟件過程改進方法和規範”把產品生命週期劃分爲6個階段:
- 產品概念階段(記爲 PH0)
- 產品定義階段(記爲 PH1)
- 產品開發階段(記爲 PH2)
- 產品測試階段(記爲 PH3)
- 用戶驗收階段(記爲 PH4)
- 產品維護階段(記爲 PH5)
軟件項目的過程有三大類: 項目管理過程、項目研發過程和機構支持過程。
而這三類過程可以細分爲19個主要過程域,分佈在PH0到PH5的各個階段。
項目管理過程包6個過程域,分爲:立項管理、結項管理、項目規劃、項目監控、風險管理、需求管理。
項目研發過程包8個過程域,分爲:需求開發、技術預研、系統設計、實現與測試、系統測試、 Beta測試、客戶驗收、技術評審。
機構支撐過程包5個過程域,分爲:配置管理、質量保證、培訓管理、外包與採購管理、服務與維護。
企業應根據自身情況(如發展戰略、研發實力等)適當地修改使用。

項目開發流程

項目開發過程域遵循的標準文檔

項目需求分析

需求調研的主要收集方式有以下方面:
- 與用戶交談,向用戶提問題。
- 參觀用戶的工作流程,觀察用戶的操作。
- 向用戶羣體發調查問卷。
- 與同行、專家交談,聽取他們的意見。
- 分析已經存在的同類產品,提取需求。
- 從行業標準、規則中提取需求。
- 從 Internet 上搜查相關資料。
輸出：新產品概念書、調研報告、《需求說明書》、《項目建議書》、計劃書和計劃表。