前言
隨著中國加入WTO后，外界對中國的軟件業(yè)帶來了機遇和挑戰(zhàn)；為新新的軟件行業(yè)注入新的活力。但細細一想，其實所帶來的更多的是挑戰(zhàn)。我所說的挑戰(zhàn)不單只是個人開發(fā)中的水平問題，更多的是我國軟件項目管理的問題。下面我就幾個方面來談?wù)劇?br>
開發(fā)人員問題：
1、你開發(fā)中按軟件工程做了嗎？
軟件工程，這對軟件開發(fā)員來說是多么熟悉的字眼，但其中的內(nèi)含你又知道多少，再進一步說，在開發(fā)中按軟件工程來做的又有多少。大家常在網(wǎng)上聽到一些程序員在抱怨說：“我加班加點的寫了10萬行的代碼，所以老板把我給開除了?！边@話扎聽有點好笑，但細細一想這是他的悲哀。他寫的代碼雖多，可是關(guān)鍵的又有多少。如果里面的代碼只要有80%的是關(guān)鍵的，我想老板是決對不會開除他的。問題出在10萬行代碼中有多少是關(guān)鍵的。先不說寫這10萬行代碼所開的時間了，就說以后的維護問題，要是你到一個公司，老板首先要求你看完這10萬行代碼。我想你第一想到就是走人，第二想到的還是走人。因為對于一個沒有按軟件工程來進行開發(fā)的程序，不要說是這么多的代碼；那怕是幾十行、幾百行，讀起來也是很難受的事。記得我剛到深圳找工作，老板讓我接手另一個程序員所開發(fā)的一個小系統(tǒng)。這樣理所當然的就是看設(shè)計文檔，可是沒有，這樣只有看源程序；當我打開源程序時，我呆了?？戳艘惶齑a，我決定走人。當我向BOOS提出時，老板給我做思想工作。當然加薪也是少不了的，這也打破加薪的記錄了。所以我就留下了。之后我開始看代碼。在我看代碼的同時真不知道把寫這程序的程序員罵了不知道多少次。這讓我更加增強了對軟件工程的認識。為了不讓以后維我的程序員不罵或少罵我。所以得好好按規(guī)定《軟件工程》辦事。說這些只是想讓大家靜下來想想，你在開發(fā)中按軟件工程做了嗎！

2、你是先寫文檔再寫程序的嗎？
一個好的程序是先寫好設(shè)計文檔再進行編程的，在設(shè)計文檔的指導(dǎo)下，才能寫出安全的代碼。在文檔的指導(dǎo)下，這樣寫出來的程序至少不會出現(xiàn)寫了10萬的代碼還被老板開除的情況。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設(shè)計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，你想想等你寫下一個時，回過頭來看原來寫的，你早就不知所云了，那時你就覺得好像在云里霧里亂走，修改的代碼也就更不安全了。我所說寫文檔不是說很正規(guī)的，那怕你只用一張搞紙劃上幾畫也要畫點出來（這是對小功能來說的）。對于大的程序來說，你就必須正規(guī)的寫了。因為這樣才能詳細的記下你的設(shè)計思想，如果開發(fā)一段時間后，感覺須要對一些功能進行修改或變態(tài)時，記住別刪除原來的，而是在下面進行變更說明。這樣再次看文檔時你就會更清楚為什么要這么做的原因。一看就明白不是多好?？偙饶闳ピ傧胍郧暗脑O(shè)計花的時間要少，如果刪除原來的設(shè)計思想，當你再次看修改或變動的功能時，你可能會對其不理解。這是多么可怕的事呀！我想作為程序員應(yīng)該知道文檔的重要性?？墒窃谝恍┬」?，先寫文檔后寫程序的開發(fā)員又有多少。要成為一個好的程序員大家想想自己該怎么做的吧！

軟件項目管理問題：
1、現(xiàn)代的軟件開發(fā)，技術(shù)不是關(guān)鍵：
隨著日益增長的軟件需求和軟件系統(tǒng)功能的增強，過去一個人開發(fā)的歷史以不復(fù)存在。現(xiàn)在單槍匹馬寫程序也只是一種娛樂。我們一般開發(fā)的系統(tǒng)都是一個小組才能完成的。所以管理才是開發(fā)出好的軟件的前提條件，沒有管理一定出不來好的軟件，當然有管理也不一定出軟件的。一個成功的軟件不一定是最好的技術(shù)，但在它背后一定有一個好的管理。所以現(xiàn)在的軟件開發(fā)已不像從前把技術(shù)放在第一，而是該把管理放在第一位。我在網(wǎng)上看到一篇關(guān)于中國軟件和印度軟件的比較。我現(xiàn)在記的不是太多，但對我影響最深的是他們會去權(quán)衡技術(shù)和開發(fā)效率問題。如現(xiàn)在開發(fā)一個軟件，用戶要求去在三個月內(nèi)完成，你在做系統(tǒng)分析時也認為在三個月能完成。但你沒有考慮到一些細節(jié)，你寫完系統(tǒng)的總體設(shè)計，在進行詳細設(shè)計時碰到要建一張不是太大的路由表。這時大多數(shù)國內(nèi)的設(shè)計人員就會想用什么算法，去花很多時間去設(shè)計研究新的算法和技術(shù)，而人家首先考慮的是系統(tǒng)的運行環(huán)境，而這個軟件設(shè)計了是在（CPU：1.1G，內(nèi)存：512M）中運行，用戶也沒特意提出其運行效率要求。所以人家就在內(nèi)存中開一個大數(shù)組來對這個路由表進行操作。從這點看，人家注重的是軟件的整體，而不像國內(nèi)大多數(shù)據(jù)設(shè)計員那樣，把個體放在首位。其實這方面我覺得我們的開發(fā)員應(yīng)當多向共產(chǎn)黨學(xué)習(xí)（本人不是共產(chǎn)黨員，團員也因沒交團費被Cancel掉了）。把軟件設(shè)計的整體放在首位，而不去花太多的時間在不一定成功的技術(shù)上。如果花太多的時間在技術(shù)上去，這將對系統(tǒng)的按時完成帶來影響。我也不是說不該研究技術(shù)，我只是說開發(fā)中應(yīng)當以全局為重。如果要加入新的技術(shù)，必須在分析時就預(yù)算其所需要的時間，并設(shè)置技術(shù)風(fēng)險管理。如果風(fēng)險太大就應(yīng)當取消用這項技術(shù)，改用其它的已成功的技術(shù)代替。風(fēng)險管理這是近來才提出的軟件管理方法。它對我們的軟件項目有著很好的控制作用。對于一些中、大型系統(tǒng)，它是一把走進成功之門的鑰匙。這里就不談了，我將在下面進行說明。

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

2.1、錯誤管理：
小時候當我做錯事的時候，我父親總是把我叫到他身邊，對我說：“沒事，只要下次不做相同的錯事就行了?！边@話也許很多家長都對自己的小孩這么講過。小時還不覺得，慢慢長大后，會發(fā)覺其中深刻的道理。這就是說從錯誤中吸取經(jīng)驗教訓(xùn)。軟件項目開發(fā)中的錯誤也是一樣。軟件開發(fā)是一項復(fù)雜的活動。一個典型的軟件開發(fā)項目可能會給我們提供很多的機會去從錯誤中吸取經(jīng)驗教訓(xùn)。一般的軟件項目也會提供少量的錯誤給我們學(xué)習(xí)。學(xué)過開車的人都知道，教練老是會這么講：“我希望你們從我身上學(xué)習(xí)我和前人的的經(jīng)驗，這些經(jīng)驗?zāi)銈兙筒灰偃ピ嚵?。如果要試你也許會賠上錢甚至于生命。”雖然軟件項目開發(fā)不會賠上生命，但是失敗的軟件項目是一定會賠錢的。所是在軟件開發(fā)中少不了要對錯誤進行管理。在項目的錯誤管理中我一般是這么做的，現(xiàn)在和大家討論一下：

a、 列出典型錯誤：

典型錯誤中有人員方面的。如：對有問題的員工失控、挫傷積極性、人員素質(zhì)低、英雄主義、項目后期加入人員、開發(fā)人員與客戶之間發(fā)生摩擦、不現(xiàn)實的預(yù)期、缺乏有效的項目支持、缺乏各種角色的齊心協(xié)力、政治高于物質(zhì)、充滿想像等…

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

典型錯誤中有技術(shù)方面的。如：過高估計了新技術(shù)或方法帶來的節(jié)省量、項目中間切換工具、缺乏自動的源代碼控制手段等…

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

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

c、 列出項目中的最差實踐：

組織機構(gòu)和其他項目組總結(jié)經(jīng)驗，學(xué)習(xí)他們的錯誤中得到的經(jīng)驗。和其他組同事交流項目開發(fā)中的磨難，學(xué)習(xí)他們的經(jīng)驗。列出潛在的錯誤，看到它我們就會盡量避免今后犯同樣的錯誤。

打個適當?shù)谋扔鳎湫湾e誤好比我們學(xué)車時教練講的經(jīng)驗，自己的最差實踐就像我們在實際開車當中出的問題，而項目中的最差實踐就是我們學(xué)車前的筆試的書。

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

2.2、風(fēng)險管理：
下面先看一下來自一段網(wǎng)上的文章吧！

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

但是，如果比起軟件開發(fā)所冒險，拉斯維加斯的賭博簡直就可以稱為“安全的冒險”了。軟件項目所面臨的不斷變換的用戶需求、糟糕的計劃與估算、不可信賴的承包人、欠缺的管理經(jīng)驗、人員問題、傷筋動骨的技術(shù)失敗、性能欠佳…..等等不勝枚舉的風(fēng)險，使大型項目按時完成的概率幾乎為0，大型項目被取消的概率和賭博一樣成敗參半（Jones 1991）?！?br>
所以項目開發(fā)中對風(fēng)險進行控制管理就大大提高了軟件開發(fā)的成功性。軟件風(fēng)險管理工作就是在風(fēng)險成為影響軟件項目成功的威脅之前，識別、著手處理并消除風(fēng)險的源頭。一般我們可以在幾個層次上定位、管理風(fēng)險。

1） 危機管理---救火模式，就是在風(fēng)險已經(jīng)造成麻煩后才著手處理它們。

2） 失敗處理---察覺到了風(fēng)險并迅速做出反應(yīng)，但只是在風(fēng)險發(fā)生之后。

3） 風(fēng)險緩解---事先制定好風(fēng)險發(fā)生后的補救措施，但不做任何防范措施。

4） 著力預(yù)防---將風(fēng)險識別與風(fēng)險防范作為軟件項目的一部分加以規(guī)劃和執(zhí)行。

5） 消滅根源---識別和消除可能產(chǎn)生風(fēng)險的根源。

1、2、3項都是被動進行的，亡羊補牢，為時以完。所以我們應(yīng)當著力于預(yù)防風(fēng)險，更好的是消除風(fēng)險根源。

風(fēng)險管理由風(fēng)險評估和風(fēng)險控制。而風(fēng)險評估由風(fēng)險識別、風(fēng)險分析和風(fēng)險優(yōu)先級組成：

l 風(fēng)險識別：就是提出一個潛在破壞項目進度的風(fēng)險列表，就像生成錯誤列表一樣。

l 風(fēng)險分析：評估每一個風(fēng)險出現(xiàn)的可能性及其影響，判定風(fēng)險的級別。

l 風(fēng)險優(yōu)先級：按風(fēng)險影響大小排出一個風(fēng)險優(yōu)先級，這個風(fēng)險列表將作為風(fēng)險控制的基礎(chǔ)。

風(fēng)險控制由風(fēng)險管理計劃，風(fēng)險化解和風(fēng)險監(jiān)控組成。

l 風(fēng)險管理計劃：制定一個應(yīng)對每個重要風(fēng)險的方案，同時就確保每一個單獨的風(fēng)險管理計劃之間以及與整體項目計劃之間相一致。

l 風(fēng)險化解：每個重要風(fēng)險所對應(yīng)計劃的執(zhí)行。

l 風(fēng)險監(jiān)控：就是對解決風(fēng)險的過程進行監(jiān)控，風(fēng)險監(jiān)控還可以包括識別新的風(fēng)險并將其反饋到正在進行的風(fēng)險管理進程中等方面的工作。

現(xiàn)在以我以前做的項目來說明一下我是怎樣進行風(fēng)險管理的。

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

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

除了以上幾個面的管理外還有其它方面的管理也決定軟件項目的成功與否。如：團隊合作、團隊結(jié)構(gòu)、生產(chǎn)率工具等等。這里就不多說。大家還是抽空多看看書。因為只要你選擇了從事計算機工作，你就選擇了永不能停止的學(xué)習(xí)、學(xué)習(xí)，再學(xué)習(xí)。否則你就將被淘汰。這是多么殘酷但又多么現(xiàn)實的事呀！

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

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

【?發(fā)表評論?0條?】