電信軟體專案管理的誤區

　　參與過電信軟體專案的人員都會發現，電信軟體專案具有其獨特性，但更多的是體現當前國內軟體專案的通病。譬如說：需求說變就變；不切實際的進度要求；專案不正常的政治壓力；專案前階段的緊迫及專案後期的拖延驗收等，都突現出當前國內軟體專案的常見問題。

　　一直在電信行業也摸爬滾打，算起來也有好幾年了。幾年專案的經驗慢慢在告訴我們一些道理，這些道理都是在以往專案的慘痛經歷，有時回想起來，道理也就那麼幾條，但真正做到的人卻少之又少。“吃一塹，長一智”——犯錯不要緊，最怕的是犯同樣的錯誤。但回想起來，自己的總結還是來得太晚，相同的錯誤竟然不止一次地重犯。

　　誤區一：本本主義。

　　本本主義讓諸葛亮失去了街亭；毛主席也不只一次地批判過本本主義的危害性，但歷史的錯誤還是在今日輪迴般地出現。

　　觀念：一定要需求明確後再開始設計和開發？

　　專案管理、軟體工程的理論一套接一套，無數的書本告訴我們，對於軟體開發，需求需使用者完全明確後才能開始設計和開發。但是，在電信行業，如果按該準則去辦事，那隻能說明你的經驗還是太欠缺了。過多的專案歷程、複雜的政治環境使得使用者學會了自我保護。使用者對於自己提的需求總是帶有隨意性及不間斷性，但當你提出要需求確認時，使用者會提出要認真評估和論證，當然，論證一輪後還需要領導的層層審批，待整個過程完成後，使用者要求的專案時間可能已經過去了一大半了。退一步說，就算是使用者較為爽快地對需求進行了確認，但接下來在開發過程中、甚至是專案上線後，使用者新冒出來的一個想法就可以讓整個系統的需求完全變樣，而最終，使用者卻不需要負什麼責任，因為他們很認真地告訴你，你缺乏行業的業務基礎，對他們的需求沒有理解到位。

　　較好的做法：關於系統面貌，使用者永遠都無法有一個清晰的模型，除非你能根據使用者最初提出的想法去提供一個模型出來，使用者再基於它來完善自己的想法。所以對於電信軟體專案，原型法是一個不錯的方法。你可能通過成本較低的靜態頁面來構建系統原型，讓使用者基於它來修改和補充需求，只有這樣，你才有可能獲取到較完整的需求。

　　同時，你要認識到，如果你不想等專案延期後再和使用者理論責任所在的話，那麼，你就永遠不要等使用者需求完全明確下來後才開始設計和開發。當你感覺到需求已經逐漸清晰時，你應該立即開始設計，並對一些較沒有爭議的地方先行開發，在設計和開發中找問題和明確問題。

　　誤區二：完美主義。

　　對於電信行業的軟體，永遠不要有完美主義的想法，不然只會害人害己。許多專案經理出身於技術，身上流淌的是技術般偏執的血液。對於技術人員的通病是完美主義，認為自己設計出來的軟體要能夠滿足使用者的終極需求；認為自己設計出來的軟體靈活到能滿足所有使用者個性化的需求。

　　如果是這樣，那麼實踐會告訴你，你的想法會是多麼的不堪一擊。永遠不要有一步到位的想法，因為，使用者尚且沒有完整終極需求，那麼你一次性設計出來的軟體怎麼可能會滿足使用者的終極需求？使用者的個性要求甚至資料統計要求隨時會變，甚至隨著基本功能的滿足，使用者會提出升級需求，那麼你的軟體怎麼可能會滿足使用者所有個性化的需求？

　　較為理性的想法是：不要奢求一步登天，永遠要有分階段建設的思路。階段性目標的準確定義，階段的準確劃分，會給你的專案及時完成提供最大的保障。相反，追求完美只會令人花費大量的時間在百關鍵的枝節功能上，並最終導致你軟體的設計泛複雜化，甚至複雜和臃腫到技術和進度都無法支撐。

　　誤區三：我的能力強到能同時承擔設計和開發甚至測試的角色。

　　對於某些專案，可能由於資源及進度的因素，對於專案中的關鍵人員，往往出專案進度的考慮，同時出於對個人能力的充分自信，他們認為，在專案中，自己的能力強到可以同時承擔設計和開發甚至測試的角色。

　　我們不能否認有些人的能力較為出眾，對於小型專案，他們擔任多個角色可能是遊刃有餘。但對於複雜的大型專案，角色的頻繁切換會令他們筋疲力盡，最終生產力低下，能力最強的人，最終反而成為造成專案進度延期的關鍵任務承擔者。

　　較為理性的想法是：踏踏實實地承擔力所能及的一個角色。如果有設計的能力，那麼好好做好設計這份很有前途的職業，永不要同時承擔開發工作。如果資源不夠，要想辦法協調資源；如果實在沒有資源，那麼要好好評估階段目標，或者好好評估專案目標，資源不夠的情況下，要學會降低專案期望。

　　誤區四：專案進度延後時要往專案中不斷增加人員。

　　其實專案正常開展後，特別到了業務開發階段，盲目地新增人員，不但不能加快專案進度，甚至會起到負作用。因為目前國內專案的設計未能明細到任何一位開發人員可以在未充分了解業務的前題下開發，即是說，人員在投入工作前，需要花很多的時間來熟悉業務，熟悉業務的階段對專案進度沒有任何幫助，甚至為了幫助新人員熟悉業務，可能會影響現有人員的正常進度。另外，我們還要認識到，要融合成一個團隊整體向前推進專案，那麼人員的磨合時間是需要考慮的。

　　較為理性的想法是：當專案有延期的跡象時，第一時間考慮的是現有人員是不是沒有磨合好，是不是沒有發揮出應有的作戰能力。如果答案是肯定的，那麼考慮的對策並不是增加人員，而應該是重新思考和定位原定的專案目標是否過高了。如果真的是目標過高，較好的做法是壯士斷腕，減少一些一必要的功能，進而縮減延期時間。

　　誤區五：當大家都沒提問題時，專案應該就沒有什麼風險。

　　作為專案經理，應該有專案敏感度，也就是說，專案經理應該對於專案的風險有超乎常人的嗅覺。當大家都沒提問題時，並不意味著專案沒有什麼風險。大家可能感覺到了風險，但他們怕自己感覺是錯的而沒有提出；大家也可能感覺到了風險，但他們認為專案失敗後不關自己的事，所以沒有提出來；大家可能感覺到了風險，但由於你平時聽不進意見，所以大家都不想提出來等等，都可能是不提出的理由。

　　較為理性的想法是：當感覺到專案有風險時，要認真剖析造成風險的原因，評估每種原因的可能發生率，同時和專案人員交流，進一步驗證自己的判斷。如果風險屬實，那麼要對症下藥，想出最佳對策，儘量防患於未然，把風險降到最低。

　　誤區六：專案進度論證可行後，那麼專案就會沿著進度推進。

　　對於專案進度，要多考慮偶然事件對於專案進度的衝擊。臨時的售前支援、政治性會議、臨時出差、專案組員請假等原因，都會造成實際情況不能按原定計劃來執行。

　　較為理性的想法是：制定專案進度時，要充分考慮到突發事件，要對風險有所預留。

　　總而言之，一個電信專案的成功來之不易，要保障其成功，首要的是要避免自己陷入以上的不必要的專案誤區。

(leadge.com)

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