|
【生魚片文化 + 麻婆豆腐文化】中國外包開發成功與失敗的“實態”ZT 中國外包開發成功與失敗的“實態” 2010-06-09 00:44:25 康熙的博客 中國外包開發成功與失敗的“實態” 引子 上一篇中提到一個觀點，要讓中國外包獲得成功，必須要明確“外包要做什么”這一目的。這次要給大家介紹一些中國外包的失敗事例，以及通過研究這些事例獲得的教訓。 n 為什么日本在中國總是失敗？ 為什么很多日本企業在中國的外包開發一直失敗呢？ 至今為止，日本企業在眾多的外包開發候選名單中選擇了中國。如今的IT行業，無論 你個人喜歡與否，與中國和印度為代表的海外IT企業間的相互依存已經是不可缺少的了。如今已經是這樣一個時代，即便日本企業的負責人不直接飛去中國，中方的企業代表也能來到日本，用日語做一次精彩的 Presentation。 讓我們從這些事例開始研究失敗的原因吧。 充滿不信任感的代碼評審（Source code review） 某個中國外包開發項目的驗收結果出來了。很遺憾，因為發現了幾個BUG，所以驗收沒有一次通過。仔細分析一下原因，發現了有若干處的代碼，并沒有按照 “編程規則”來編寫。中國企業那邊早就應該國做過好幾次代碼評審了…… 日方企業的開發負責人（統籌人）必須要追究BUG的成因，然后尋找避免重復發生問題的方法。于是，日方的負責人與中國企業的負責人之間，有了如下一段對話。 （譯者注：對話日語內容有不少實用的地方，所以采用中日文對照的方式寫下去） 日本 ： 「中國側のソースコードレビューはどうなっているのですか？先日報告されたソースコードレビューの報告書を読みましたが、何をどのようにレビューしたのか、よく理解できませんでした」 （中國方面的代碼評審到底怎么做的？之前我看了你們提交的代碼評審報告書，我看不懂你們是“針對什么問題”從而“如何做的評審”。） 中國 ： 「ソースコードレビューで重點を置くのは、コーディング規約の確認です。ソースコードレビューは、別部署のリーダーである李さんに応援してもらい、既に3回も実施しました。李さんは、當社でも特に技術力に優れている人物です」 （代碼評審的重點是確認是否遵照“編程規則”來寫代碼。評審的過程中，得到了另一個項目的PL小李的協助，總共實施了3次評審。小李是我們公司技術非常優秀的人物。） 可是，對于中國方面的回答，日方負責人的腦海里出現了幾個疑問。 1、 明明使用了專用工具對代碼進行測試，為什么還會發生違反編程規則的情況？ 2、 在代碼評審會議上發言的，為什么只有小李一個人？ 日方的負責人開始懷疑中方的代碼評審工作是否只是形式上的了。他感到，在盡心盡力逐行做代碼評審方面，中方的能力明顯不足。由于代碼不能一次通過驗收，所以日方負責人要求中方再度實施代碼評審。可這時，卻得到了中方出人意料的回答。 日本：「コーディング規約を準拠しているかを再度見直すとともに、機上でのデバッグをもう1度実施してください」 （請你們再仔細檢查一下是否按照編碼規則來書寫代碼，請在桌子上重新做一次檢查。） *譯者注：在桌子上做檢查的意思為“將代碼打印出來逐行” 中國 ：「ご要望は分か りました。しかし、機上でのデバッグですが、その作業工數は非常に多いと思います。通常、當社では実施しません。紙の上でソースコードを追いながら要求仕 様を確認する方法などは、コーディングやり直しと実質的に変わりません。要求仕様の確認は、PC畫面上からのテストで検証するものです。本當に必要でしょ うか？」 （您的希望我們十分理解。但是，打印出的東西作Debug本身就十分耗費工數，通常我們公司不會這樣做。如果一邊在紙面上逐行確認代碼，一邊確認代碼是否符合式樣要求，這樣的做法與重寫代碼沒有實質上的區別。關于式樣要求的確認，應該通過畫面上的測試來證實的。所以，您提案的方法真的有這個必要嗎？） 隨后，中方的解釋還在繼續。 中國：「検収で見つかっ たバグはもうすぐ修正されるので、プログラムは安定稼動します。したがって、わざわざ追加費用をかけてもう1度ソースコードレビューを実施しても、その効 果には疑問があります。もし、機上のレビューだけですべてのバグは防止できるとなると、バグ摘出目標を上げる品質指標値の意味がないですね」 （因為驗收過程中發現的問題我們會馬上修正，所以能保證程序的穩定運轉。因此，加入繼續投入經費重做一次代碼評審的話，我們十分懷疑是否能得到預期的效果。如果把代碼打印出來看一遍就能防止BUG的話，那些寫著BUG統計值之類的“品質指標值”不就沒有意義了嗎？） 雖然他們的解釋也情有可原，但日方的負責人始終無法接受這樣的觀點。日方正準備反駁之時，中方開發商的負責人又繼續“闡述”他的觀點。 中國：「當社の方針では、最も重要なのは納期を守ること、そして品質を確保することです。品質保証はプログラムの動作確認テストが効果的です。畫面上から動作確認するテストが最も優れていると思います。 テスト項目を増やし、何度も繰り返してテストするとバグ摘出率は高くなります。ソースコードの仕様チェックの概念はいいと思いますが、効率は良くないのではないでしょうか。例えば、あるプログラムを1時間かけてテストすると、効率よくバグが発見できるでしょう。 ところが、機上でのデバッグとなると、レビュー者と擔當プログラマが2人で一緒にソースコードレビューしなければなりません。2人で半日かけてレビューしても、バグの発見は難しいのではないでしょうか。 また今回のプログラムには、複雑な計算アルゴリズムなどはありませんから、その観點での機上でのデバッグは必要ないと思います。 従って、當社としては動作確認テストを優先し、もし時間に余裕があれば、後からソースコードの仕様チェックを行う。これでよろしいでしょうか？」 (我們公司的方針是，通過多次重復的測試來提高BUG統計值。通過審核代碼來檢查是否滿足式樣的觀點是好的，但效率不就差了嗎？比如，某個程序用1小時來做測試，能夠高效率地發現問題。 可是，如果打印出來做一次檢查的話，至少需要1名負責人與2名PG一起參與。而且，幾個人做了半天也恐怕很難找到什么BUG。 尤其是這次的程序，沒有什么特別復雜的算法，從這個觀點上我們認為完全沒有打印出來作評審的必要。 因此，我們公司將優先采用“動作確認測試”，有余力的情況下做代碼的評審。這樣是否可以？) 以上就是中國外包的一個實例。 n 中國外包開發的教訓 教訓：囫圇吞棗般地看報告的項目負責人 有一種說法，說在與中國打交道的日本人不能成功的原因之一就是“過度信賴對方”。在中國的外包開發中，囫圇吞棗般地接受對方的報告，聽到對方說「すべて確認しました。もう大丈夫です！（都確認過了，已經沒問題了）的時候，就屬于這種情況。 外包開發成功的企業中，項目統籌人必須存在能敏銳地洞察到對方國家的文化與交流方式的傾向。具有敏銳的洞察力的項目統籌人，需要從失敗的事例中找到教訓，是能將日本式的項目管理手法與外包開發委托方的企業文化巧妙相融的人物。 n 教訓：經驗不足加上文化背景相異，沒有勝算 中國的軟件公司里，項目負責人往往是20歲后半或30歲左右的青年SE。他們中的大部分 技術優秀，但在在溝通能力方面還略顯不足。有時在系統交付后出現重大BUG等緊急情況時，即便日方嚴重抗議，他們也不會主動將問題的嚴重性匯報給他們的上級。 中方軟件企業內的信息不通暢，主要是由信息管理制度的不健全造成的，另一個重要的理由就是“技術者的責任感”（譯者注：原文中為“技術者的氣質”）這一問題。但這絕不是說，“中方品質意識地下”或者“中方不夠聰明”，這完全是兩個層次的問題。單純地來看，日本式的開發手法中有極為綿密的“報告”“聯絡” “商量”的過程，而中國開發商這方面卻十分欠缺。 讓我們回過頭去看一下先前提到的那個“代碼評審”的事例，中方對于“評審” （Ｒｅｖｉｅｗ）的認識與日本軟工教科書中的認識之間，究竟存在怎樣的差異。 日本 中國 代碼評審的目的 與式樣要求的整合性等方方面面的問題，嚴密地檢查代碼的細節部分 指導與確認“編程規則”與編程技巧等 評審手法 由下至上（Bottom-Up方式）的改善過程 從下至下（Top-Down）的指示 評審實施者 相關所有人員 理解程度較高的某一人 評審結果的信息交換方法 所有成員都聚在一起討論問題，所以當場就能共享信息 技術較高者將他自己的審核結果轉達給相關的擔當者。相關信息沒有實現項目組內的共享。 鑒于以上這些教訓，我整理了一下這些失敗事例的相關對策。 1、 針對日本式的開發過程進行強化指導說明 2、 不忽視結果報告的細節，對開發中的各個過程實施狀況做徹底檢查 n 其他的一些事例 中國外包開發失敗例 1、考慮到中國開發商希望從上流設計開始承接項目的愿望，所以日方企業從基本設計開始向中國發包。但實際上從開始到最后始終需要日本人SE常駐中國，所以幾乎沒有實現成本削減的目標 （譯者注：由于日本公司制度的原因，日方員工赴中國出差的情況下，從食宿到津貼各方面的成本非常高） 2、締結合約的時候，日方企業向中方提供了開發標準手冊。但是，后來才發現這份手冊是10多年前制定的，當時的老系統環境的開發標準在開放源代碼的開發中完全沒有參考價值。 3、試驗性的小規模發包獲得了成功，所以緊接著就將一個大規模項目發包去中國。可是，之前的一個中方項目負責人突然辭職，一切又要從頭開始了…… 4、在與中方開發商簽約時，要求中方出示過去開發項目的文檔。結果他們將記載著客戶名稱的設計文檔直接復印給我們……似乎他們完全沒有保密意識。 （譯者注： 對日項目中常常會被要求簽訂“機密信息保持協議”，日本項目大多為企業訂制項目，加上日本企業對自身信譽的重視，所以這是一個他們是否看重保守機密這個問題） 5、大連的某個公司，傳說有大量精通日語的職員。但后來發現，事實上都是同一個人以不同人的名義給各個客戶公司回復MAIL。 6、從中方的企業招聘了幾個研修生來日本，工作的時候遇到項目里的幾個中國人留學生，在得知留學生們的工資后，他們到處訴說自己對收入差距的不滿。最后失去積極性的他們攪亂了整個項目的協調，在項目未完的時候便強制總他們回國。事后，還聽說他們回國后就跳槽了。 7、因為發生了式樣變更，所以使用專用的“聯絡票”進行詳細說明，對方回答“了解しました”（明白了）之后便放心了。可是，過了很久之后發現程序當時并沒有被修改。日方對發生這樣的BUG表示抗議（譯者注：作為日本企業的習慣，如果沒有及時對應式樣變更的內容就會被認為是BUG），可中方企業也針鋒相對地回答道“當時は連絡票で説明を受けたが、正式に仕様書が修正されていない。だから仕様変更の依頼は受け付けていない”（當時我們收到了聯絡票，但正式的式樣書并沒有被修正。所以我們沒有接受這個式樣變更的要求。） ８、日方企業里出于培養年輕社員的目的，名義上說給年輕社員磨練“國際化感覺”的機會，但實際別說是外語能力，甚至連基本的項目管理知識都不具備的年輕人擔任外包項目的聯絡工作。結果，中方企業不把這個年輕社員當回事，項目最終破裂失敗。 n 中國外包的成功事例 當然，還有相當多的中國外包成功經驗。比如說： 1、 從業務應用程序到嵌入式開發，在多個開發領域削減了成本，日方項目組改善了效益 2、 有意識地認識到對方是中國企業，從而提高了自身的設計書質量和設計水平 3、 通過外包項目對中方企業的指導，提高了自己企業對外包項目的領導能力 4、 以外包為契機磨煉出了“國際感覺”，從而進一步實現了海外市場的開拓與投資 n 生魚片文化和麻婆豆腐文化 （譯者注：與本BLOG最初的譯文以題目相同，但文章出處有所不同。在本文中原作者在對這個論點有了一些補充和內容也略有調整） 前幾天，我在東京都內的的某個中國人社長那里聽來一段話，是針對中日兩國文化的差異打了個比方，我來介紹給大家看一看。 日本式文化：生魚片文化 日本是生魚片文化。 所謂生魚片，不用多做說明大家就知道，就是將鮮魚切成生魚片。這種料理方法恐怕幾千年前就在日本存在了吧。到了21世紀的今天，從北海道到沖繩，無論你在日本的什么地方，生魚片基本的口味和形狀幾乎沒有任何區別。當然，即便在日本以外的地區，即便魚的種類不同，生魚片的口感依然讓你覺得“生魚片就是這個味道”。還有，一部分精致的生魚片，甚至上升到了藝術的高度。 中國文化：麻婆豆腐文化 另一方面，中國文化就是麻婆豆腐文化了。 同一道麻婆豆腐，如果你在四川，正宗的川菜之“辣”絕對會超乎你的想象；如果你在北京，味道卻會變得醇厚起來；如果你在東京，甚至還會聽到在日的中國人說它“不夠味”。也就是說，不同地域的麻婆豆腐，會因為當地人的口味而調整“辣”的程度。 更有趣的是，有一種著名的說法認為“麻婆豆腐是種偶然的產物”（關于麻婆豆腐的起源有很多種說法）。我去四川的時候還曾經聽人說過，“豆腐的制作方法也是一個偶然帶來的”。看來，麻婆豆腐真是一道比較“隨意”的菜肴（譯者注：原文中為“いいかげん”表示“適度”）。 這個比喻告訴我們了一個中國 外包開發的關鍵問題。日本人重視“規律”“過程”“美感”；中國人重視最后的結果，擅長隨機應變。在麻婆豆腐文化下的中國，雖然外包項目中呈現出種種品質 管理的問題，但他們卻擁有日本不具備的發達的火箭發射技術。如果理解了“目標”，并將切實的目標“可視化”之后，在軟件工程的領域里也能正確完成高精度的 工作。 或許我的部分讀者中有過本文 前半部分提到的失敗經驗。但即使你們強調你們有過切身的失敗經歷，我也能認同你們的部分觀點，比如“中國開發上品質觀念落后”“中國是個軟件工業的落后國 家”等等。因為，你們的觀點無非也就是我們共同的“生魚片文化”中強調的“一切均一”的表現。 我認為，最重要的還是要討論 日本和中國不同的“文化土壤”這個問題。要準備好誰都看得明白的，并具有“客觀性”的數據，在雙方都能接受之前要充分要換意見。軟件領域中，論項目管理的 經驗的話，日本還是略微領先的，所以就毫無顧慮地提出你們的要求吧。左右外包開發成功與否的關鍵，并不僅僅是看最終結果，最重要的是在開發過程中的時時考 察各個開發環節是否按照要求正確實施。 如果不松懈相互間的過程確認，我相信過去很多的失敗事例能防范于未然。 |
