日本對海外軟體開發敲響警鐘
【日經bp社報道】日本企業在將開發工作外包給亞洲軟體公司時出現問題而失敗的例子層出不窮。「日方發包者不經意間將自己的做法強加於人，這種態度引發了很多問題」——從事軟體開發管理與質量管理研究的日本武藏工業大學工學院資訊系統工程專業的兼子毅講師對此敲響了警鐘。
兼子毅於9月份訪問了中國，就軟體開發問題分別聽取了日本發包方與中國承包方的意見分歧。在某一軟體開發案例中，當描述軟體標準的檔案交給中國工程師時，由於沒提出任何疑問，日本發包者覺得很放心，但最後卻發現中國工程師的理解大相徑庭。「中國工程師認為，主要原因是檔案不完整、條理不清。而在日本，即使表述不清晰，也常常可以通過相互關係補充完整。但此次仍帶著這種習慣交到中國，沒有進行提醒與確認」（兼子毅）。「此外，對於發包方大量更改標準，有的中國工程師也覺得非常吃驚。如果標準更改很多的話，就必須從一開始就講清楚」（兼子 毅）。
在發生這種問題時，「中國的工程師就會據理力爭，指出發包方的檔案不清楚，標準變更的界限不明確等」（ 兼子毅）。
此外，兼子毅還指出：「許多中國工程師都希望軟體開發過程能夠體系化」。並擔心「在日本並不希望軟體開發形成體系。這樣做的人似乎也非常少」。
向中國等亞洲各國進行軟體發包失敗時，「有相當多的日本人都認為是文化差異造成的，從而陷入了思維僵局 」（兼子 毅）。並呼籲「應當重新審視基本的開發程序」。
文章很顯明地提出了兩個原因：乙個是檔案不完整，條理不清晰．另外乙個就是文化差異．
再筆者近幾年從事的對日軟體專案來看，大多數專案失敗的原因就在於需求不明確，反應到文件上就是檔案不完整，條理不清晰，有時候可以這樣理解，有時候又可以那樣理解，給中國程式設計師造成的印象就是不知道怎麼理解．實際上在與國內的專案一樣，失敗的因數大多數是在專案啟動的時候就埋下的．
日本對外發包的軟體大多數是採用瀑布式模型開發流程，一般說來，在需求分析和詳細設計階段的工作是在日本完成，這中間有可能會要求中方的程式設計師一起參加完成．然後工作重心就轉到中國或者是其他勞動力**比較低廉的國家來做，有時候日方也會來到中國一起完成coding，ut和si的工作．做完si後的具體工作又轉回到日本，由日本的工程師做pt和rt的工作（主要是針對實際環境的測試和驗收測試,不同的公司做法也許略有不同）,這個時候在中國程式設計師的任務就是bug對應,修改測試階段發現的bug以及設計的變更.在做完一系列測試後就是具體的運用階段,這個時候就基本上算是專案結束了.
這樣做最大的好處就流程非常容易理解，管理起來方便，外包出去也界限明顯，在設計階段做完後以式樣的方式將文件交到中國，中國公司做完後把**及相關的測試文件交還給日方．在專案比較小的時候條理就非常清楚，成功的概率也很大．然而就系統分析的角度來說這未必是件好事，在絕大多數情況下，使用者是沒有辦法完全說明清楚他到底想要做些什麼事情，中間就必須要經過許多反覆和疊達．如果專案比較大的話，這些變更點的記錄以及針對記錄的管理工作就是一件非常可怕的事情.在筆者最近的專案中，設計方不是終端使用者，很多事情也沒有辦法做決定，於是許多聯絡票傳來傳去，短短半年的專案就有近千張聯絡票，甚至有時候根本就不知道聯絡票在誰手上，出現了所有的人都在等對方的回答的情況．特別是在專案後期，相關的確認就不計其數．
在和日本客戶交流的時候，中日文化之間的差距會很大一部分地影響溝通的效果。首先不得不提的就是民族感情問題，中日雙方都有一些人藐視對方，就是一些中國人瞧不起日本人，而一些日本人瞧不起中國人。在討論具體問題的時候，如果把這種情緒帶到桌面上來就很有可能是言辭過於激烈，雙方針尖對麥芒，互相不讓步，甚至於造成溝通的中斷，更影響了以後的溝通。
技術嚮導與質量嚮導。記得一次在東京的朋友聚會上，有位值得尊敬的前輩談到中國的工程師和日本的工程師時就指出：中國工程師是以技術為嚮導的，日本工程師是以質量為嚮導的。中國程式設計師特別注重專案中技術的應用，也關心在專案中能不能學到什麼新技術。在開發中，如果解決了乙個新的技術問題，很多程式設計師會有一種自然而然的成就感。這是好的一面，反過來，很多時候就會犯「技術鍍金」的問題，將一些可以簡單化的問題做得很複雜，使得控制難度加大，客戶又時候也很難接受這些，經常會發出「本來不要多少時間的東西怎麼要做這麼久」之類的疑問；還有乙個特點就是不重視容易解決的問題，在乙個專案中曾經出現了乙個這樣的事情：
乙個有login的畫面，「login」這個字串被錯誤地寫成了「登入」，然而在日語中「登入」是儲存資料到資料庫中的意思，於是客戶指出這是乙個bug，要求承包方修改。問題發到承包方後，負責修改的程式設計師s表示這個很容易修改，幾分鐘就改好了。然而等到客戶拿到新版本後仍然發現這個問題，問起原因來，s回答忘了。客戶很生氣，認為這是乙個很嚴重的質量問題，於是順著bug的控制流程，從文件的管理，**的修正，測試，及後來的review，從頭到尾查了個遍。s很不理解：「不就是改個字串，用得著這麼興師動眾嗎？」
相對來說，也許是終身事業制的關係吧，日本員工和企業的前途是綁在一起的，日本人很重視質量，出現了乙個問題首先想到是不是質量上的問題，會不會影響公司的形象等等。而對於中間採用了什麼技術反而不太關心，實現了就可以了。
日本人的推諉和中國人的浮躁。也許同樣是終身事業制的原因，日本大公司內部吃大鍋飯的現象很明顯，在工作中日本人之間相互扯皮和推諉，從上面到下面，沒有乙個人願意做決定，最後不得已開會討論，經過漫長的馬拉松會議後，得出的結論往往是先問問使用者，按照使用者的意見做。這樣經常浪費勒了不少時間，也會把不少應該是在設計階段解決的問題帶到coding階段，給後期工作帶來很多麻煩。與此相反的就是中國企業的某些浮躁現象，東西做了80%就認為差不多夠了。往往我們開發出來的軟體基本功能是實現了，但小問題一大堆，離真正的優秀產品差的遠。
目前，日本方面也開始對這些問題進行了反省，有些公司開始冷靜地考慮將軟體發包到中國是否能夠真地節省費用，帶來更好的利潤．有一種值得注意的傾向就是招聘中國的程式設計師直接到日本工作，而不是將專案發包出去，這樣費用或許會高一些，但就產品的質量來說容易控制多了．
先吃忌廉還是先吃蛋糕 推遲滿足感
不久前，一位30歲的財務分析師向我請求幫助，她想糾正自己最近幾個月裡總是拖延工作的惡習。我們 了她對老闆的看法，老闆對她的態度，她對權威的認識以及她父母的情況。我們也談到她對工作與成就的觀念 這些觀念對其婚姻觀 性別觀的影響 她同丈夫和同事競爭的願望，以及競爭帶給她的恐懼感。儘管一再努力，但這種常規...
客戶需求及骨頭與肉的分工方法
1.客戶需求 對客戶需求分析後可以進行產品功能設計。而產品功能設計又會衍生出新的功能性需求。2.骨頭與肉的分工方法 1.team leader 負責客戶需求分析和功能的概要設計，概要設計給出的是功能的骨架和應用的核心技術。2.team member 負責詳細的功能設計 程式設計和開發。即在骨頭的基礎...