診斷中小企業軟體專案管理

民間有一句俗語：多大的腳穿多大的鞋。對於一個企業的管理來講， 大公司有大公司的方式，小公司也有小公司的方式，如果把別人的經驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟體專案也一樣，大專案和小專案的 方式雖然不完全一樣。而從另一個角度來看，專案的大與小並沒有本質的區別，很多方法是共通的。管理一個軟體專案大專案和小專案的方式不完全一樣，但從另一 個角度來看，專案的大與小並沒有本質的區別，很多方法是共通的。

　　小型軟體專案中常犯的錯誤

　　相對於大型軟體專案，小型軟體專案具有靈活性高、專案功能相對較少、 開發人員較少、開發週期較短的特點。業內常常提到“軟體危機”一詞，常是指一些大型軟體專案延期，導致專案順利交接存在困難。這並不意味著“軟體危機”就 與小型軟體專案毫無干系。正如上述小型軟體專案的特點，小專案看起來比較簡單，比較容易成功實現，因而人們往往忽視了小專案的管理，其實這是一種誤解，從 本人的經驗看來，小專案開發中容易犯以下的一些錯誤:

　　企業層面：

　　1、草率確定專案人員

　　對於中小IT企業來講，人員流動性高，崗位頻繁調換是不爭的事實。如 果這種情況出現在專案中，將對專案造成致命的影響。試想一下如果一個專案，即使是個小型軟體專案，開發人員三天兩頭調來調去，開發設計怎麼可能實現呢?所 以企業要根據其專案的週期長短謹慎選擇開發人員，保證其在開發過程中可以不間斷。

　　2、不看重隱性影響

　　作為一位專案組成員，當專案自開始時，就把自己與專案的命運聯絡在一 起了。專案的成功與失敗都無疑會對專案組成員造成心理上、情緒上的影響。在我們許多中小企業中，企業往往關心的那些大型專案的成果，而忽視了小型專案。原 因往往也很簡單：大型專案意味著大收益。然而，專案對專案組成員的隱性影響卻不管專案的大小，且這些影響最終會體現在企業的人員積極性上，這不能不說是企 業有效運營的關鍵。

　　專案管理層面：

　　1、草率的計劃方案

　　企業往往由於專案較小，在軟體開發之前沒有認真地進行專案可行性和工作量的估計，便很草率地制定一個開發日程表，沒有認真地估計專案難度，結果實際完成時間與估計完成時間往往有較大差別，這種偏差必將是專案陷入困境。

　　筆者從一位做專案管理諮詢工作的朋友哪裡瞭解到，許多中小企業對於這種偏差的認識始終停留在是執行過程除了差錯，然而根源卻是專案的前端出了問題。

　　2、蹩腳設計過程

　　從小專案的特點來看，開發人員少，意味著不同人員的程式之間互動、接 口相對少一些;開發週期短意味著往往是同樣的幾個人從頭到尾負責一個專案。這兩者雖是小專案的優勢，卻都讓人容易犯些錯誤，比如實施中，往往是幾個人碰一 下意見，討論一下最基本的資料結構、函式介面便分頭去做自己的工作了，並沒有一份較正式的文件。其實很多中小企業都是這樣的。這種做法很危險。

　　危險之一是有的人可能會對討論出的介面、結構理解有偏差，應該承認並不是所有參加會議的人總是很明白，人是會犯錯誤的。而往往一個單純的誤解可能造成以後的返工。

　　另一個危險是由於討論時忽略了某些情況，等大家都按當時的分工完成屬於自己的工作後，才發現各個模組組合起來卻形不成一個完整的系統。其根源在於系統設計不充分，沒有一個負責協調的人員不斷監控整個開發過程。

　　第三個危險是一旦有人中途退出開發隊伍，其他人加入時，新來的人難以理解以前別人做好的程式碼，索性自己從頭來。另外，沒有文件的程式，日後維護和版本升級都比較困難。這些不僅是專案沒有成功，而且為專案的後續工作要付出很多努力。

3、直奔系統測試

　　指專案不經過單元測試而直接進入系統測試，造成這一現象的原因是每個 模組相對比較簡單，但是為了測試一個模組需要建立一些測試環境。比如為了測試一個函式是否正確，應該用一些測試資料去呼叫該函式，需要編寫一些測試資料。 筆者曾經做開發時，也嫌麻煩，覺得反正其他模組也很快出來了，直接用真正的資料來執行幾次就行了。 殊不知，一旦直接進入系統測試，發現執行結果不正確後需要一步一步查詢。同時，由於模組間的呼叫關係，可能查了很久才發現是某個模組的問題。

　　這種方法如果僥倖成功，效率可能會很高，但這種概率不超過40%。所 以，總體看來，這種方法一來效率比較低，大量的時間用在了將一個錯誤定位在模組上了。另外由於這種測試不完全，真正執行系統，當呼叫某模組時，可能大部分 時候都是正常資料，極少出現邊界情況，可能某些邊界情況容易被忽視，很久之後才被發現，正所謂欲速則不達。然而，如果我們對每個模組進行單元測試時都進行 一下邊界測試，就會很容易消除這些隱患。

　　具體的解決方法

　　解決方法，一句話形容就是"麻雀雖小，五臟俱全"，即使是小型專案的開發，仍然應該遵循軟體開發的一般規律，必須的步驟是不能省略。但是小專案有它自身的一些特點，實行起來可以相對靈活些。

　　筆者就以下幾個方面進行描述：

　　1、需求獲取及分析

　　在這上面花費相當時間是很必要，也是很值得的。所有軟體專案進入正式開發之前，必須先從使用者處獲取準確的需求資訊，並對資訊加以分析。

　　我們知道軟體專案可以大致分為專用軟體和通用軟體兩大類。對於專用軟 件，需求相對較為明確，例如給某單位開發一套該單位專用的系統，一般使用者對於軟體要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大 致地規定了。但是，開發合同上往往規定的只是一個大概的框架，專案經理必須與使用者進行比較具體的交流和討論，瞭解清楚使用者心目中的產品究竟是什麼樣子。做 好這個步驟，那麼就可以避免開發後期因開發人員的理解和使用者的要求存在誤解，而造成的時間上的浪費。

　　對於通用軟體，一方面是從經濟效益考慮，另一方面是從技術的角度，例如，使用者現有硬體配置如何，軟體配置如何，使用什麼網路，使用什麼資料庫等等。為得到這些資訊，需要做一定的市場調查，並根據調查的統計結果決定即將開發的軟體的一些技術指標。

　　需求分析就是將需求用一種模型來表示。目前比較流行的分析方法是物件導向的方法，這部分涉及到具體的方法，在此不詳細討論，只想強調分析與設計過程的銜接。

　　分析過程的內容是用類的結構來表示目標系統，並不設計具體實現，如採 用什麼程式語言，在什麼作業系統平臺上執行等等。這些具體實現是在設計階段來完成的。物件導向方法的優點是分析、設計、編碼過程表示法統一，能比較好的銜 接。但是，是把分析和設計階段分開，採用瀑布式開發，還是採用其他方式，要看具體的情況。一般來講，對於需求潛在變化不大的專案，可以採用瀑布模型，有一 個很明顯的設計階段，這樣做的好處是有一份比較完整的分析文件。

　　2、設計過程

　　包括對分析模型必要的修改。可能需要對某些類結構進行一些修改，這些 修改的原因可能是程式設計環境的要求，或者為了重用以前的某些工作。比如定義介面部分、資料訪問(資料庫)部分。由於目前很多程式語言都可以視覺化地設計界 面，所以介面部分工作往往留到了編碼階段來完成。於是設計階段的工作量並不大。

　　3、編碼與測試

　　進入編碼工作之後，可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。測試階段正如前所述，即使是小專案，也應該嚴格地進行測試，在此不再贅述。

4、人員的安排

　　比較小的專案，往往是幾個人來完成，這幾個人基本上從頭到尾參加開發。在這幾個人中，有一位專案負責人，負責分析、設計和協調的工作。由於專案小，專案負責人也要參加程式設計,那麼這人必須把時間合理運用，據經驗來講，我們需要下面幾點原則：

　　A .協調工作比自己去做更重要.

　　專案管理主要工作就是協調，如果協調上出了漏洞，可能導致很大的問題，所以專案負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯後等等。只有在完成這些工作之後，專案負責人剩下的時間才能用於程式設計。

　　B .給每個開發人員明確的任務書.

　　不管是用物件導向或者其他方法開發，分析、設計模型只是從功能的角度來描述系統。但是，具體開發時每個開發人員必須非常明確自己的任務，這些任務應該採用明確的文件來表示。

　　C .讓大家都大致熟悉設計模型.

　　讓每個開發人員都清楚自己所做的工作在整個系統中處於什麼地位，有時侯可能會發現設計模型中的漏洞，避免了各人的程式碼編寫完畢之後又要修改的後果。