日本對海外軟件開發敲響警鐘<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
【日經BP社報道】日本企業在將開發工作外包給亞洲軟件公司時出現問題而失敗的例子層出不窮。“日方發包者不經意間將自己的做法強加於人，這種態度引發了很多問題”——從事軟件開發管理與質量管理研究的日本武藏工業大學工學院信息系統工程專業的兼子毅講師對此敲響了警鐘。
兼子毅於9月份訪問了中國，就軟件開發問題分別聽取了日本發包方與中國承包方的意見分歧。在某一軟件開發案例中，當描述軟件標準的文件交給中國工程師時，由於沒提出任何疑問，日本發包者覺得很放心，但最後卻發現中國工程師的理解大相徑庭。“中國工程師認爲，主要原因是文件不完整、條理不清。而在日本，即使表述不清晰，也常常可以通過相互關係補充完整。但此次仍帶着這種習慣交到中國，沒有進行提醒與確認”（兼子毅）。“此外，對於發包方大量更改標準，有的中國工程師也覺得非常喫驚。如果標準更改很多的話，就必須從一開始就講清楚”（兼子 毅）。
在發生這種問題時，“中國的工程師就會據理力爭，指出發包方的文件不清楚，標準變更的界限不明確等”（ 兼子毅）。
此外，兼子毅還指出：“許多中國工程師都希望軟件開發過程能夠體系化”。並擔心“在日本並不希望軟件開發形成體系。這樣做的人似乎也非常少”。
向中國等亞洲各國進行軟件發包失敗時，“有相當多的日本人都認爲是文化差異造成的，從而陷入了思維僵局 ”（兼子 毅）。並呼籲“應當重新審視基本的開發進程”。
兼子毅擔任“第22屆軟件生產質量管理專題討論會”（12月4～5日舉行，由日本科學技術聯盟主辦）的委員長。在主題討論會上，將提出“在與亞洲一起進行產品製作時，希望能找到一個取長補短的途徑”（兼子毅）。（記者：安保 秀雄）
文章很顯明地提出了兩個原因：一個是文件不完整，條理不清晰．另外一個就是文化差異．
再筆者近幾年從事的對日軟件項目來看，大多數項目失敗的原因就在於需求不明確，反應到文檔上就是文件不完整，條理不清晰，有時候可以這樣理解，有時候又可以那樣理解，給中國程序員造成的印象就是不知道怎麼理解．實際上在與國內的項目一樣，失敗的因數大多數是在項目啓動的時候就埋下的．
日本對外發包的軟件大多數是採用瀑布式模型開發流程，一般說來，在需求分析和詳細設計階段的工作是在日本完成，這中間有可能會要求中方的程序員一起參加完成．然後工作重心就轉到中國或者是其他勞動力價格比較低廉的國家來做，有時候日方也會來到中國一起完成Coding，UT和SI的工作．做完SI後的具體工作又轉回到日本，由日本的工程師做PT和RT的工作（主要是針對實際環境的測試和驗收測試,不同的公司做法也許略有不同）,這個時候在中國程序員的任務就是BUG對應,修改測試階段發現的BUG以及設計的變更.在做完一系列測試後就是具體的運用階段,這個時候就基本上算是項目結束了.
這樣做最大的好處就流程非常容易理解，管理起來方便，外包出去也界限明顯，在設計階段做完後以式樣的方式將文檔交到中國，中國公司做完後把代碼及相關的測試文檔交還給日方．在項目比較小的時候條理就非常清楚，成功的概率也很大．然而就係統分析的角度來說這未必是件好事，在絕大多數情況下，用戶是沒有辦法完全說明清楚他到底想要做些什麼事情，中間就必須要經過許多反覆和疊達．如果項目比較大的話，這些變更點的記錄以及針對記錄的管理工作就是一件非常可怕的事情.在筆者最近的項目中，設計方不是最終用戶，很多事情也沒有辦法做決定，於是許多聯絡票傳來傳去，短短半年的項目就有近千張聯絡票，甚至有時候根本就不知道聯絡票在誰手上，出現了所有的人都在等對方的回答的情況．特別是在項目後期，相關的確認就不計其數．
在和日本客戶交流的時候，中日文化之間的差距會很大一部分地影響溝通的效果。首先不得不提的就是民族感情問題，中日雙方都有一些人藐視對方，就是一些中國人瞧不起日本人，而一些日本人瞧不起中國人。在討論具體問題的時候，如果把這種情緒帶到桌面上來就很有可能是言辭過於激烈，雙方針尖對麥芒，互相不讓步，甚至於造成溝通的中斷，更影響了以後的溝通。
技術嚮導與質量嚮導。記得一次在東京的朋友聚會上，有位值得尊敬的前輩談到中國的工程師和日本的工程師時就指出：中國工程師是以技術爲嚮導的，日本工程師是以質量爲嚮導的。中國程序員特別注重項目中技術的應用，也關心在項目中能不能學到什麼新技術。在開發中，如果解決了一個新的技術問題，很多程序員會有一種自然而然的成就感。這是好的一面，反過來，很多時候就會犯“技術鍍金”的問題，將一些可以簡單化的問題做得很複雜，使得控制難度加大，客戶又時候也很難接受這些，經常會發出“本來不要多少時間的東西怎麼要做這麼久”之類的疑問；還有一個特點就是不重視容易解決的問題，在一個項目中曾經出現了一個這樣的事情：
一個有Login的畫面，“Login”這個字符串被錯誤地寫成了“登錄”，然而在日語中“登錄”是保存數據到數據庫中的意思，於是客戶指出這是一個BUG，要求承包方修改。問題發到承包方後，負責修改的程序員S表示這個很容易修改，幾分鐘就改好了。然而等到客戶拿到新版本後仍然發現這個問題，問起原因來，S回答忘了。客戶很生氣，認爲這是一個很嚴重的質量問題，於是順着BUG的控制流程，從文檔的管理，代碼的修正，測試，及後來的review，從頭到尾查了個遍。S很不理解：“不就是改個字符串，用得着這麼興師動衆嗎？”
相對來說，也許是終身事業制的關係吧，日本員工和企業的前途是綁在一起的，日本人很重視質量，出現了一個問題首先想到是不是質量上的問題，會不會影響公司的形象等等。而對於中間採用了什麼技術反而不太關心，實現了就可以了。
日本人的推諉和中國人的浮躁。也許同樣是終身事業制的原因，日本大公司內部喫大鍋飯的現象很明顯，在工作中日本人之間相互扯皮和推諉，從上面到下面，沒有一個人願意做決定，最後不得已開會討論，經過漫長的馬拉松會議後，得出的結論往往是先問問用戶，按照用戶的意見做。這樣經常浪費勒了不少時間，也會把不少應該是在設計階段解決的問題帶到coding階段，給後期工作帶來很多麻煩。與此相反的就是中國企業的某些浮躁現象，東西做了80%就認爲差不多夠了。往往我們開發出來的軟件基本功能是實現了，但小問題一大堆，離真正的優秀產品差的遠。
目前，日本方面也開始對這些問題進行了反省，有些公司開始冷靜地考慮將軟件發包到中國是否能夠真地節省費用，帶來更好的利潤．有一種值得注意的傾向就是招聘中國的程序員直接到日本工作，而不是將項目發包出去，這樣費用或許會高一些，但就產品的質量來說容易控制多了．
記得幾年前和某個軟件公司的老總閒談的時候，他意氣風發地評論當時對日外包的市場，說正是喫蛋糕上的奶油的時候，不知道他有沒有想到：奶油喫多了會壞牙齒的．看來幾年後的今天應該是喫蛋糕的時候，隨着市場的成熟，啃骨頭的日子也很快就要到了．我們的軟件公司是否準備好了？我們的程序員是否準備好了呢？