談談軟體專案管理的重要性(轉)

談談軟體專案管理的重要性
前言

隨著中國加入WTO後，外界對中國的軟體業帶來了機遇和挑戰；為新新的軟體行業注入新的活力。但細細一想，其實所帶來的更多的是挑戰。我所說的挑戰不單只是個人開發中的水平問題，更多的是我國軟體專案管理的問題。下面我就幾個方面來談談。

開發人員問題：
1、你開發中按軟體工程做了嗎？
軟體工程，這對軟體開發員來說是多麼熟悉的字眼，但其中的內含你又知道多少，再進一步說，在開發中按軟體工程來做的又有多少。大家常在網上聽到一些程式設計師在抱怨說：“我加班加點的寫了10萬行的程式碼，所以老闆把我給開除了。”這話扎聽有點好笑，但細細一想這是他的悲哀。他寫的程式碼雖多，可是關鍵的又有多少。如果裡面的程式碼只要有80%的是關鍵的，我想老闆是決對不會開除他的。問題出在10萬行程式碼中有多少是關鍵的。先不說寫這10萬行程式碼所開的時間了，就說以後的維護問題，要是你到一個公司，老闆首先要求你看完這10萬行程式碼。我想你第一想到就是走人，第二想到的還是走人。因為對於一個沒有按軟體工程來進行開發的程式，不要說是這麼多的程式碼；那怕是幾十行、幾百行，讀起來也是很難受的事。記得我剛到深圳找工作，老闆讓我接手另一個程式設計師所開發的一個小系統。這樣理所當然的就是看設計文件，可是沒有，這樣只有看源程式；當我開啟源程式時，我呆了。看了一天程式碼，我決定走人。當我向BOOS提出時，老闆給我做思想工作。當然加薪也是少不了的，這也打破加薪的記錄了。所以我就留下了。之後我開始看程式碼。在我看程式碼的同時真不知道把寫這程式的程式設計師罵了不知道多少次。這讓我更加增強了對軟體工程的認識。為了不讓以後維我的程式設計師不罵或少罵我。所以得好好按規定《軟體工程》辦事。說這些只是想讓大家靜下來想想，你在開發中按軟體工程做了嗎！

2、你是先寫文件再寫程式的嗎？
一個好的程式是先寫好設計文件再進行程式設計的，在設計文件的指導下，才能寫出安全的程式碼。在文件的指導下，這樣寫出來的程式至少不會出現寫了10萬的程式碼還被老闆開除的情況。如果你不寫文件，一開始就寫程式，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，你想想等你寫下一個時，回過頭來看原來寫的，你早就不知所云了，那時你就覺得好像在雲裡霧裡亂走，修改的程式碼也就更不安全了。我所說寫文件不是說很正規的，那怕你只用一張搞紙劃上幾畫也要畫點出來（這是對小功能來說的）。對於大的程式來說，你就必須正規的寫了。因為這樣才能詳細的記下你的設計思想，如果開發一段時間後，感覺須要對一些功能進行修改或變態時，記住別刪除原來的，而是在下面進行變更說明。這樣再次看文件時你就會更清楚為什麼要這麼做的原因。一看就明白不是多好。總比你去再想以前的設計花的時間要少，如果刪除原來的設計思想，當你再次看修改或變動的功能時，你可能會對其不理解。這是多麼可怕的事呀！我想作為程式設計師應該知道文件的重要性。可是在一些小公司，先寫文件後寫程式的開發員又有多少。要成為一個好的程式設計師大家想想自己該怎麼做的吧！

軟體專案管理問題：

1、現代的軟體開發，技術不是關鍵：
隨著日益增長的軟體需求和軟體系統功能的增強，過去一個人開發的歷史以不復存在。現在單槍匹馬寫程式也只是一種娛樂。我們一般開發的系統都是一個小組才能完成的。所以管理才是開發出好的軟體的前提條件，沒有管理一定出不來好的軟體，當然有管理也不一定出軟體的。一個成功的軟體不一定是最好的技術，但在它背後一定有一個好的管理。所以現在的軟體開發已不像從前把技術放在第一，而是該把管理放在第一位。我在網上看到一篇關於中國軟體和印度軟體的比較。我現在記的不是太多，但對我影響最深的是他們會去權衡技術和開發效率問題。如現在開發一個軟體，使用者要求去在三個月內完成，你在做系統分析時也認為在三個月能完成。但你沒有考慮到一些細節，你寫完系統的總體設計，在進行詳細設計時碰到要建一張不是太大的路由表。這時大多數國內的設計人員就會想用什麼演算法，去花很多時間去設計研究新的演算法和技術，而人家首先考慮的是系統的執行環境，而這個軟體設計了是在（CPU：1.1G，記憶體：512M）中執行，使用者也沒特意提出其執行效率要求。所以人家就在記憶體中開一個大陣列來對這個路由表進行操作。從這點看，人家注重的是軟體的整體，而不像國內大多資料設計員那樣，把個體放在首位。其實這方面我覺得我們的開發員應當多向共產黨學習（本人不是共產黨員，團員也因沒交團費被Cancel掉了）。把軟體設計的整體放在首位，而不去花太多的時間在不一定成功的技術上。如果花太多的時間在技術上去，這將對系統的按時完成帶來影響。我也不是說不該研究技術，我只是說開發中應當以全域性為重。如果要加入新的技術，必須在分析時就預算其所需要的時間，並設定技術風險管理。如果風險太大就應當取消用這項技術，改用其它的已成功的技術代替。風險管理這是近來才提出的軟體管理方法。它對我們的軟體專案有著很好的控制作用。對於一些中、大型系統，它是一把走進成功之門的鑰匙。這裡就不談了，我將在下面進行說明。

2、好的管理才能開發出好的軟體（小系統除外）：
大家都知道，軟體開發中有太多的不可預知性。但這種不可預知是對總體來說的，當軟體進行到一點程度時，不可預知的東西就會變成可預知的東西。以住的做法是不去管理它，這樣所帶來的就是專案的失敗。要是有好的管理方法就可以控制這些不可預知的東西，軟體專案就會一步步隨著你的設計思路起向成功。現在就和大家一起討論一些常用的軟體管理方法。

2.1、錯誤管理：
小時候當我做錯事的時候，我父親總是把我叫到他身邊，對我說：“沒事，只要下次不做相同的錯事就行了。”這話也許很多家長都對自己的小孩這麼講過。小時還不覺得，慢慢長大後，會發覺其中深刻的道理。這就是說從錯誤中吸取經驗教訓。軟體專案開發中的錯誤也是一樣。軟體開發是一項複雜的活動。一個典型的軟體開發專案可能會給我們提供很多的機會去從錯誤中吸取經驗教訓。一般的軟體專案也會提供少量的錯誤給我們學習。學過開車的人都知道，教練老是會這麼講：“我希望你們從我身上學習我和前人的的經驗，這些經驗你們就不要再去試了。如果要試你也許會賠上錢甚至於生命。”雖然軟體專案開發不會賠上生命，但是失敗的軟體專案是一定會賠錢的。所是在軟體開發中少不了要對錯誤進行管理。在專案的錯誤管理中我一般是這麼做的，現在和大家討論一下：

a、 列出典型錯誤：

典型錯誤中有人員方面的。如：對有問題的員工失控、挫傷積極性、人員素質低、英雄主義、專案後期加入人員、開發人員與客戶之間發生摩擦、不現實的預期、缺乏有效的專案支援、缺乏各種角色的齊心協力、政治高於物質、充滿想像等…

典型錯誤中有過程方面的。如：過於樂觀的計劃、缺乏足夠的風險管理、缺乏計劃、在壓力下放棄計劃、在模糊的專案前期浪費時間、前期活動不合要求、缺少管理控制、缺少質量保證措施、魯莽編碼等…

典型錯誤中有技術方面的。如：過高估計了新技術或方法帶來的節省量、專案中間切換工具、缺乏自動的原始碼控制手段等…

.

b、 列出自己的最差實踐：

注意典型錯誤，建立自己的最差實踐列表，可以避免在以後的專案中犯同樣的錯誤。

c、 列出專案中的最差實踐：

組織機構和其他專案組總結經驗，學習他們的錯誤中得到的經驗。和其他組同事交流專案開發中的磨難，學習他們的經驗。列出潛在的錯誤，看到它我們就會盡量避免今後犯同樣的錯誤。

打個適當的比喻，典型錯誤好比我們學車時教練講的經驗，自己的最差實踐就像我們在實際開車當中出的問題，而專案中的最差實踐就是我們學車前的筆試的書。

公司在發展的同時，也會積蓄一些各方面經驗。列出所有的經驗，按其分類。系統分析中的經驗提供給系統分析，設計人員中的經驗提供給管理人員，技術中的經驗提供給開發員。這樣我們就會有更多的時間花在新的錯誤的防範上面。開發出來的系統就會一個比一個好。

2.2、風險管理：
下面先看一下來自一段網上的文章吧！

“一般認為賭博是在冒險。拉斯維加斯老機的設計者將老虎機的最大賠付率定為97%，即你花一天時間，往老虎機裡塞進100元，最多隻能贏回970元。

但是，如果比起軟體開發所冒險，拉斯維加斯的賭博簡直就可以稱為“安全的冒險”了。軟體專案所面臨的不斷變換的使用者需求、糟糕的計劃與估算、不可信賴的承包人、欠缺的管理經驗、人員問題、傷筋動骨的技術失敗、效能欠佳…..等等不勝列舉的風險，使大型專案按時完成的概率幾乎為0，大型專案被取消的概率和賭博一樣成敗參半（Jones 1991）。”

所以專案開發中對風險進行控制管理就大大提高了軟體開發的成功性。軟體風險管理工作就是在風險成為影響軟體專案成功的威脅之前，識別、著手處理並消除風險的源頭。一般我們可以在幾個層次上定位、管理風險。

1） 危機管理---救火模式，就是在風險已經造成麻煩後才著手處理它們。

2） 失敗處理---察覺到了風險並迅速做出反應，但只是在風險發生之後。

3） 風險緩解---事先制定好風險發生後的補救措施，但不做任何防範措施。

4） 著力預防---將風險識別與風險防範作為軟體專案的一部分加以規劃和執行。

5） 消滅根源---識別和消除可能產生風險的根源。

1、2、3項都是被動進行的，亡羊補牢，為時以完。所以我們應當著力於預防風險，更好的是消除風險根源。

風險管理由風險評估和風險控制。而風險評估由風險識別、風險分析和風險優先順序組成：

l 風險識別：就是提出一個潛在破壞專案進度的風險列表，就像生成錯誤列表一樣。

l 風險分析：評估每一個風險出現的可能性及其影響，判定風險的級別。

l 風險優先順序：按風險影響大小排出一個風險優先順序，這個風險列表將作為風險控制的基礎。

風險控制由風險管理計劃，風險化解和風險監控組成。

l 風險管理計劃：制定一個應對每個重要風險的方案，同時就確保每一個單獨的風險管理計劃之間以及與整體專案計劃之間相一致。

l 風險化解：每個重要風險所對應計劃的執行。

l 風險監控：就是對解決風險的過程進行監控，風險監控還可以包括識別新的風險並將其反饋到正在進行的風險管理程式中等方面的工作。

現在以我以前做的專案來說明一下我是怎樣進行風險管理的。

接到專案對專案進行調研工作，在調研中就要注意到刻服錯誤列表中的錯誤。調研完成後，寫需求說明書初稿（一般根據情況至少給出二個以上的方案），為客戶進行講解，結合客戶意見再次進行修。把修改後的說明書和同士進行討論，再次進行修改。在此期間寫出總體設計的初稿（大的框架）。最後再為客戶講解，再次修改少量的功能。客戶確定需求滿足後就可進行總體設計了。在生成需求分析的同時，注意列出需求中存在的風險。如：需求改變問題、需求定義欠佳等風險。在進行總體設計時，多和客戶交流。因為在總體設計中修改需求比在詳細設計中修改要容易比在編碼階段修改就更加容易了。之後生成總體設計說明書。同時在總體設計中也要對一些不定的因素進行風險監控。列出風險列表。根據總體設計說明書就可以開始詳細設計了。在詳細設計中除了要考慮系統設計外還要考慮一些技術風險問題。把很難預見的問題列到風險列表中。注意，從需求分析到詳細設計，隨著系統開發的進行度。以前不明的因素將會慢慢顯露。同時也會出現新的不明因素。這樣就讓我們必須在整個設計開發過程中進行風險監控、風險識別、風險分析和風險化解工作。同理，在編碼中也同樣處理。在開發過程中根據分析不同，把風險按階段分為需求分析階段風險、總體設計階段風險、詳細設計階段風險和編碼階段風險。並交由此階段的人員進行監控和化解。同時，如果在化解安全區（規定解決問題的時間段中）內無法完成解決，則提交專家組（包括到外請的專家顧問）解決( 我們一般是在週五下午的討論會上進行)。當然軟體開發中所碰到的風險是很多的。但不可能完全同時進行風險監控的。通常是把風險列表中認為最會發生的風險乘損失的大小後的最大數進行嚴格的監控起來。隨著開發進度，風險是在變化的，所以風險列表可能會增加也可能會減少。只要風險管理好了。系統就成功了一大半。

2.3、人員管理：
不同人員之間經驗的不同導致績效差別是有目共睹的，大家可能對不同開發人員之間生產效率差距達10：1的觀點較為熟悉，大家也知道一些明確激勵措施所帶來的正面影響。所以人員管理在軟體專案中也有較重的分量。很清楚，人力因素極大地影響著生產效率，同時任何關注提高生產效率的組織首先必須有一套良好的人員激勵、團隊合作、員工選擇及培訓的機制。這樣才能充分發揮人員的自身能動性。為公司創造更多的價值。

除了以上幾個面的管理外還有其它方面的管理也決定軟體專案的成功與否。如：團隊合作、團隊結構、生產率工具等等。這裡就不多說。大家還是抽空多看看書。因為只要你選擇了從事計算機工作，你就選擇了永不能停止的學習、學習，再學習。否則你就將被淘汰。這是多麼殘酷但又多麼現實的事呀！

在專案開發中軟體工程VS專案管理：
開發員對軟體工程是多麼熟悉的呀！為什麼會有這麼熟悉呢？因為現在的專案要求開發員“按章辦事”。否則充其量也只是一部程式設計機器。上面已講了軟體工程的重要性，這裡就不多說。現在打個比喻，如果把軟體工程比做音樂家，那專案管理就是音樂指揮家。一個好的音樂家一個人能揍出動聽的音樂，但一群好的音樂家在一起不一定能揍出好的交響樂。它還必須有一位好的指揮家。軟體開發也是一樣的，有好的程式設計師只是前提條件，要開發出好的軟體，還要有一個好的管理。

只代表個人關點，請大家多多討論。不如之處請多多指教為謝。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21082/，如需轉載，請註明出處，否則將追究法律責任。