項目管理-4-運籌帷幄

引言
“運籌帷幄之中，決勝千里之外”“三歲知老”，前面的愿意說的是某人的智慧超群，現在的意思主要是說謀劃的重要。后面一句說的是人在最初階段對后面的重要影響。對于項目管理來說，項目最初的選擇，對整個項目的成敗，起著至關重要的作用。而這個最初的選擇，就是項目的生命周期模型。
前面兩節分別介紹了項目章程和項目規劃，從這兩個項目活動過程中，得到了項目的成功標準和發布條件，按照順序的話，下一步應該是日程安排了，但是在日程安排之前，需要作出一個決定，即，這個項目采用哪種生命周期模型。不然的話，日程安排就沒法往下做。所以這一節就說一下，如何為項目選擇合適的生命周期模型。

跟前幾節一樣，先說概念，然后是注意，再有一張簡圖，簡圖包含了這一節的主要內容。

4.1概念定義
項目的生命周期模型：就是項目經理和團隊組織產品開發的方式。說白點，就是你打算讓你的孩子將來干哪一行。呵呵，如果你有孩子的話。
如果你的回答是‘沒有什么具體打算，看他自己的興趣吧，喜歡什么就學什么’，那么您選擇的生命周期模型就是‘敏捷’。
如果您的回答是‘我打算讓他學音樂，從胎教開始就讓他聽音樂，然后讓他學習音樂培訓課程，然后考音樂學院，是從音樂界的名師，然后進唱片公司’那么您選擇的模型就是‘瀑布’。
如果您的回答是‘先看看在說吧，先送他進幼兒園，學習各種科學，文化知識，然后再根據孩子的愛好，專門培養孩子的這種愛好，使之成才’，那么您選擇的模型就是‘增量原型’。

上面說了敏捷，瀑布，增量三種項目的生命周期模型，需要注意的這些模型本身的區別不重要，重要的是您對哪種運用的比較熟練。運用的好的話，這些模型都可以是項目成功。就好像上面的那個例子，只要多和孩子溝通，根據孩子的具體情況，身體方面的，頭腦方面的，發揮孩子的潛力，都可以把孩子培養成才。還有就是，這些生命周期不是絕對的，一個成功的項目，往往是多個模型的組合，在項目的不同階段，采用不同的模型，甚至在項目的同一階段，使用多個模型的組合。再次引用偉人的一句話‘不管白貓，黑貓，

只要能抓住老鼠，那就是好貓’呵呵。記住，完美的生命周期，只是‘模型’而已。夢想要照進現實才行啊。

4.2選擇生命周期模型
一般，項目的生命周期模型有以下幾種：
如圖所示。

這些模型的對比，如圖所示。

?

前面已經說了，這些模型的定義不重要，重要的是靈活應用之。所以下面就說幾種具體的情況，如果項目中有這些情況出現，應該如何應對。

及時的得到反饋。
對于項目經理來說，最麻煩的事情，就是沒有反饋。可能不止對于項目經理，對于任何人做任何事，如果你才去了一個舉動，結果沒有任何反應，俗話說的好‘咬人的狗不叫’。沒有反饋，就意味著你不知道這個舉動的效果如何，所以比‘摸著石頭過河’的情況還遭。因此，盡早的獲得項目的反饋，就能盡早的摸到項目的脈搏，摸到脈搏了，才能掌控項目。而這個反饋，就來自于測試，所以，應該讓測試人員盡早的加入到項目里來，對每一個新完成的代碼段（功能模塊）進行測試，這樣開發人員也能得到反饋，也能驗證架構設計的合理性，可行性，和穩定性。

如果這個項目中包含硬件或機械。
如果這個項目包含軟件，硬件，還有機械等等領域，那么難度就很大，軟件控制硬件，硬件控制機械結構，最終完成整個功能的執行過程。開發的話，順序就反過來了，要現有機械，然后才能驗證硬件的性能，然后有硬件，才能驗證軟件的性能。重要的是，硬件和機械的bug修復周期很長，一旦出錯，就需要幾天，甚至幾十天的延遲，此外，也造成了成本的浪費，還有，有時候硬件的改動，會引起相應軟件，尤其是驅動程序的修改，代價很大。所以，在這種情況下，我認為，想讓機械和硬件先做，并讓軟件參與討論和進行整體架構，等經過硬件基本完成調試后，才讓軟件開始編碼工作。當然，如果你已經確定某些模塊式硬件必須的，那么也可以開始軟件的工作。不一定非要等到硬件全部做好。

管理設計風險，也就是架構風險。
如果你擔心架構的某些方面存在風險，那么就盡早的開發可以驗證這些風險的功能模塊，來對架構進行測試和檢驗。對于瀑布來說，要盡早的做試驗，檢驗一下架構是否可行。比如說，你現在做的事一套UI，里面含有對顯卡，和內存要求比較高的動畫效果，你擔心的是在播放這些效果時會不會卡屏，你明白，一旦卡屏的話，就需要更換硬件平臺，或者采用其他的播放技術。那么就先做一個簡單的動畫，然后在實際平臺上播放一下。來決定是否采用現有平臺。
另外一種措施就是，用時間盒來限制架構所用的時間，留下更多的時間用來調整或優化架構。

如果你開始接手這個項目時，用的是瀑布，那么如何才能擺脫出來呢。
用迭代和時間盒來規劃和限制所有活動。
盡早的將產品原型化，即盡早的作出一個demo版，然后展示給客戶，然后從客戶那里得到反饋。我曾經歷過一個項目，客戶要求一個產品，我們做了大約兩年的時間，客戶基本上已經接受了，但是還有一些商品化屬性，需要做。這時，來了一個新的開發人員，原來的開發人員被調到了其他項目組，這個開發人員來了之后，發現，已有的這個產品，做的太次，于是經過老板同意，用了大約3個月的時間，重新設計，出圖，制造。調試完成后，拿給客戶。結果是，客戶認為，這個產品跟原來的產品差異太大，并且重量過重。后果可想而知。‘閉門造車’，我想就是這個意思。
從項目一開始，就開始測試。這個前面已經說了。
功能要逐個實現，不要把所有功能都實現后，再集成。要完成一個，集成一個，測試一個，也就是敏捷里面的‘持續集成’。

4.3小結
要綜合使用生命周期模型。只有完美的模型，沒有完美的項目。盡量不要采用瀑布，要不然在后期集成的時候，亡羊補牢，來不及了。羊都已經被狼吃完了。

總結

以上是生活随笔為你收集整理的项目管理-4-运筹帷幄的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。