案例
D公司對日軟件外包項目失敗的故事
這是一個針對日本的軟件外包項目�？蛻羰侨毡镜囊患抑拇笃髽I，全球500強之一。
客戶要求的內容很多，也很嚴格，不僅要求使用指定的技術和工具，而且還自主開發了一個平臺，要求在該平臺上進行開發、測試；還有各種文檔格式要求和技術要求；最重要的是要保證工期，一定要在2個半月內提供高質量的、完整的產品。
中國數家企業參與了該外包項目。D企業是其中之一，主要負責該項目40本程序（本是實現一個完整功能的程序單位。一本程序也就是一個程序。這與我們國產軟件的設定不一樣。）的詳細設計、編碼以及單體測試工作。
成立項目組
項目立項后，D公司成立了項目小組。項目經理是一名在對日軟件項目方面有多年開發經驗的開發人員，但是，他是第一次帶項目。項目經理下設三個小組：負責詳細設計的DS小組（6名成員），負責編程的PG小組（5名成員）以及負責測試的PT小組（5名成員）。每一小組設置一名小組長，配備若干組員。（見圖1）
同時，D公司在日方派駐了一名SE（高級分析設計人員），主要負責分析、設計以及中日兩方的協調工作。DS人員具有豐富編程經驗，提前1周進入了項目組工作。
之后，PG和PT小組成員開始進入項目。項目經理安排PG和PT小組1周內熟悉這個復雜的平臺。
項目正式開始了。經過分析，項目組決定將40本程序分為A、B、C三類，分別包括10本，12本，18本程序。其中，A類的難度看起來似乎不高，是一些數據庫表的維護工作，和業務沒有太大關系，工作量也很少。B類和C類難度預計差不多，但是，分別屬于不同的業務領域。
一個星期后，部分程序的詳細設計出來了。為了保證工期，項目小組決定三個小組同時進行，并行工作。詳細設計人員繼續做詳細設計，編碼人員投入編碼，而測試組成員同時編制測試設計書，并設計測試數據。
初試成功
項目經理決定PG小組首先從難度最小的A類程序入手，這樣不僅可以看到成功的曙光，而且可以鼓舞大家的士氣。于是，5名PG小組成員開始分別著手A類程序。一切都很順利。1本程序差不多在2天內完成了。
一周后，A類程序全部編碼完成，PT組開始測試，完成了一半的測試工作。隨后，測試修改完畢后的5本程序交給日方確認，順利通過，客戶評價也極高。
于是，項目經理信心百倍，項目組成員也信心十足。經過仔細分析，剩下的B類和C類程序，可以根據處理側重點的不同劃分為入力系、Batch系、賬票系三類，比例大致相當。項目經理也更新了進度計劃。新的進度計劃中，每名PG成員分別負責2本入力系、2本Batch系、2本賬票程序。DS小組的工作也進展順利。
遭遇難題
正當大家懷著勝利的喜悅繼續前進的時候，PG小組遇到了很大的難題。日方提供的開發平臺太復雜了。此時，項目小組才發現，已經開發完成的A類程序其實只是一種2層結構的程序，而B類、C類程序是復雜的3層結構，要搞清楚如何開發這些程序不只需要時間，更需要充足的經驗和高超的技能。PG小組成員紛紛卡殼，不知道該在哪兒賦值，不知道該在哪兒取值，與以前接觸的編程截然不同，似乎每本程序都有一個無窮的長鏈，只有龍頭，沒有龍尾，無法理清。
一周過去了，原定很順利就編寫完的程序的實際進度卻是5%，或者10%，這并不是說，已經開發了5%或者10%，而是為了表明這些程序的開發工作已經開始，而向客戶展現一種開發中的姿態（因為每日都要給客戶發送進度報告）。于是，項目經理開始要求大家加班。
兩周過去了，技術最好、經驗最豐富的一名PG人員—小G的進度率達到了40%，而其他成員仍然在原地踏步。大家紛紛去請教小G，小G不耐煩地回答：“去看日方發過來的資料吧”。
煩躁，焦慮，疲勞，一名PG成員病倒了，打了個電話要請假。過了幾天，又一名PG成員也來電話請假，說是感冒。三周后，也就是1個月后，除了10本C類程序全部開發完成，通過驗證外，只有一本程序的進度率達到了80%。5名PG成員中的2名病倒了。大家都忙著從數百頁的日文開發手冊中尋找答案。
于是，項目經理開始要求PT組有經驗的成員加入PG組以填補空白。
小G的程序完成了，可是運行后什么也沒有。又經過一周，小G的程序基本可以運行了，但是還有很多的技術問題，測試結果極不理想。
緊急救“火”
工期已經非常逼近，不能再等了，于是項目小組開始向公司反映情況。公司立即從其他項目組中抽調了2名經驗豐富的“技術高手”來協助。鑒于絕大部分程序的詳細設計已經完成，召回了在日本的窗口SE—“業務高手”，同時安排大家都加班。
為了很好地運用小組中的知識財富，D公司安排小G不再繼續開發工作，而是做技術總把關，做專職的問題解決能手。后來，集中大家的智慧，解決了入力系的入力難題，解決了Batch系的沒有界面而有極多數據復雜處理問題，以及賬票系的賬票出力問題。
快到截止日期時，原有的PG成員中有2名開始長期請病假。
經過大家的齊心協力，加班加點，在預定截止日期的當天，所有程序都開發完畢，測試完畢，只是還有很多問題和錯誤需要修正。
為了保證工期，項目經理決定暫時將問題和錯誤隱蔽，將所有的測試報告中的“再確認”一欄填寫上“OK”。項目經理提交所有預定提交的成果物。同時，PG和PT人員仍在繼續奮戰。
一周后，日方發過來大量問題，絕大部分是單本程序的問題。項目小組繼續修正。一個月后，項目終于結束了，項目小組才得以解散。
分析
D公司軟件外包項目敗在哪兒？
目前軟件外包業務已經得到了長足的發展，無論歐美，還是日本的一些大企業，為了降低成本或者其他原因，都在將一些軟件項目外包給其他國家成本較低的IT企業，印度的軟件產業就是依賴于軟件外包而成長、成熟。中國也已經舉辦了幾次軟件外包國際峰會，期望能夠仿照印度，將中國的軟件產業通過軟件外包打入國際市場。
在日本軟件外包市場，相對于其他國家，中國在文化上具有得天獨厚的優勢，語言方面更遠勝于其他國家的從業人員。因此，從日本的軟件外包市場入手，是我國打入國際市場的首選，對日軟件出口的比例高達70%。但是，很多對日軟件外包項目并不是很成功，這個項目就是其中一個。
該項目最終在規定的時間內完成了。在一個月后的日本客戶的《顧客滿意度》調查表里，各項評價都較高，如“工期保證（5分），質量較好（4分）……”�？磥�，該項目得到了日方的認可。因為日本企業最重視的是工期，只要在預計的工期能夠完整地提供產品，那么項目就是成功的。
但是，縱觀項目的全過程，項目小組先是歡喜異常，覺得所謂的難度也不過如此，后來卻感到驚慌失措，無法前進，原本驍勇善戰的精兵猛將也只好當逃兵，稱病請假。由此可知，雖然項目工期沒有延遲，客戶評價尚佳，但是，實際問題還有很多。
項目的四個隱患
仔細分析，可以總結如下：
1、項目技術復雜，出現技術瓶頸。在項目初期，項目組成員的技能對于B類、C類程序的技術要求來說，差距過大。以至于需要過多的時間來熟悉掌握。同時，由于時間原因以及這種技術瓶頸，導致本應熟悉業務流程的時間用在了解決技術難題上，從而導致本來不是很難的業務也成了一大難題。
2、開發人員信心不足。在項目后期，發生怯場稱病請假的情況，這在軟件行業里似乎并不多見。他們似乎已經顧不了自己應盡的職責和責任了。不是他們沒有責任感、沒有職業道德，而是他們實在受不了了。整天坐在計算機前，卻無法解決問題，1周、2周都沒有一點進展。正是由于責任感，使得他們異常焦慮，而焦慮使得他們實在承受不了這種壓力和氛圍，與其最后被逼得生病，還不如先請假回家。
3、項目管理不嚴。先是一名成員生病、請假。似乎請假太簡單了，一個電話就可以了，不需要醫院證明，還能拿到70%的工資，項目經理還和藹可親，溫和的說“好好在家休息”。對此，其他成員肯定會有猜疑，覺得自己挺虧，最后也要請假，而項目經理也不好意思不批準。
4、急功近利，遮掩問題。其實，項目開展三周后，項目的問題就已經很突出了�？墒�，由于剛剛當上項目經理，為了證明自己的能力，為了掩蓋已經發現的問題，項目經理沒有向上級匯報問題，而是將自己的責任推給項目組成員，讓大家加班加點，完成任務。直到離期限不到三周，實際完成的具備未知難度的B類和C類程序的開發工作量還不到1/30的時候，項目經理才知道不能遮掩了，這時才向高層匯報情況。經過公司高層的協調，才得已抽調人員，及時解決問題。
謹防項目計劃不切實際
以上四個原因，似乎都是很明顯的表面問題，那么，最主要的核心問題是什么呢？究其根源可知，問題其實出在項目經理上，最主要的問題是項目計劃過于樂觀，而且不切實際、不合理。
其實，在項目早期，項目小組成員對日方的數百頁的開發手冊有些敬畏，都感覺到這個項目有些難度，但是，不知道難度具體有多大。
項目經理為了穩住軍心，先將難度最小的A類程序排在進度計劃的最前沿，這本無可厚非。因為按照開發A類程序的進度,他看似客觀其實主觀而且極為樂觀地做了如下推算：1名PG 用2天完成1本程序，加上B類C類程序的難度，保守估計4天時間1本。那么完成40本程序的編程大概需要32天。一名測試人員用1天時間設計一本程序的測試設計書，2天測試完畢。一本程序在PT上大概需要3天時間，保守估計5天。完成40本程序的編程大概需要40天，編程可行。而且，測試不存在較大的難度，只是工作量的問題�？偣て谑�44天。實在時間緊張，還可以安排加班。測試能力足夠。測試沒有太大的風險。
但是，他忽略了一點，為了穩住軍心、增強信心的目的似乎有些單純，以至于在達到這一目標后，在項目組成員從對項目的敬畏和擔心中解脫出來后，隨后就忘記了難度和復雜性，而和項目組成員一樣歡呼雀躍，喪失了危機感，從而制定了較為糟糕的任務分配計劃和進度計劃，導致后期出現技術瓶頸，而又迫于期限，擊垮了項目組成員，嚇退了本應神勇的戰士。
任務分配要科學
由于忘卻了難度和復雜性的威脅，項目經理的任務分配計劃也出現了問題。
在他的樂觀估計下，項目肯定會異常成功。因此，他在A類程序成功完成的情況下，分配每名PG成員分別負責2本入力系、2本Batch系、2本賬票系程序。這樣一來，每一名PG成員都需要去學習掌握如何編程入力系程序、Batch系程序、帳票系程序，需要處理這些復雜的程序中潛在的技術難題。
但是，所有的入力系程序都是具有相同點的，只要寫好了一本，其他的程序就可以仿照，可以說，如果寫第一本需要15天時間，那么寫第2本可能只需要4天時間。同樣，Batch系程序和帳票系程序也具有類似的特點。
正是由于項目經理忽略了這種學習能力，導致他安排了大家去做同樣的攻關工作，造成智力和時間的浪費，也影響了大家的情緒。直到后來才安排出專門的技術專家，集中解決問題，其他成員在技術專家指導下工作，提高了開發效率。
計劃失策、預計不準確、缺乏危機感、任務分配不科學，是這個項目的主要問題，也是項目經理的最大問題。正是由于這些問題，導致了項目的差點失敗。
事實上，這個項目并不是如客戶評價的那樣極佳，雖然通過種種措施保證了項目的順利完成，但仍然留下了大量問題。因為，只要每本程序的質量得到保證，而設計書又是經過數次評審的，那么客戶方發現的問題應該很少，而且應該只是一些業務流程問題�？墒�，提交項目產品后，客戶發現的大部分問題是單本程序的問題，因此，該項目算不上成功。
據筆者所知，該項目在對日外包軟件項目中具有一定普遍性。由此可知，規范項目管理流程，使項目小組中每個人包括項目經理和技術能手，對項目的影響縮小化，是中國對日軟件外包企業需要關注和重點解決的問題，也是整個軟件行業需要解決的重要問題。
ISO9001質量體系認證或CMM認證或CMMI認證能夠起到一定的作用。同時，公司高層配備足夠的質量保證人員或者項目管理辦公室成員，應該能夠對項目進展情況隨時進行了解，也就能夠盡早發現項目中的種種問題，從而避免后期的各種不得已的補救措施，引領項目成功。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
