??? 偶然看了網友 BirdGu 的一篇文章（ http://blog.csdn.net/BirdGu/archive/2006/04/25/677369.aspx ），文中分析了一個失敗的外包項目里面的風險問題。非常感謝 BirdGu 能拿出這么寶貴的經驗和大家分享并提出了自己得見解，我自己在這方面也思考了很多，就該文中提出的問題，我自己也假設了一些情況，談談自己想法。

?

???? 第一個就是需求，作者也認為該項目的需求做的不好，如果再深究下去，不好的原因是什么呢？我自己的看法，該項目需求沒做好的原因可能有以下幾個原因中的一個或者幾個

1．??? 用戶自己都不知道需求是什么，傳達給日方公司的需求也就是不明確的。

2．??? 用戶雖然知道需求，但是日方的設計人員沒有理解，或者一知半解，也就寫不出合格的需求說明書。

3．??? 日方的設計人員對需求也很明白，但是寫出來的文檔中方開發者不能很好理解，而他自己卻覺得自己表達的很清楚了。

?? 如果是第一個或者第二個原因，那該項目的失敗就不僅僅是溝通上的問題了，起碼日方的公司要負大部分責任。原因很簡單，能把一個自己都不明確的需求發給別人來做，本身就存在問題，更別想得到符合需求的產品了。而現實中這種情況確實存在，怎么辦？首先，日方公司要對這個問題加強認識并改進，改進的辦法可以有很多，最根本的就是從管理制度上去解決，對需求是否完備要有相應的審核制度，并且納入質量管理體系，形成管理制度同時又要嚴格執行。或許這不夠敏捷，但是敏捷并不僅僅追求速度，而是在追求速度的同時保證質量的，也就是又快又好。后面我將闡述我對敏捷的認識。

??? 至于第三個原因，完全是一種理解上的差異造成的，作者也有所提到，要解決這個問題，需要不斷的反饋，我完全同意。但是反饋什么呢？僅僅是告訴對方哪個地方不明白么？我想這種情況下，中方公司可以理直氣壯的指出該需求說明中的不足，并提出希望增加相關的內容，這也給日方一個信息，就是告訴他們我們開發者希望看到的需求是什么樣的。同時，中方的開發人員也應該加強理解日本文化，商業習慣，業務這方面的意識，經常有這樣的情況，一個需求，即使非常明確，我們也常常按照自己的理解想當然的來做，結果作出來的東西，根本不符合對方的要求。如何做呢？我想最基本的要理解日本的會計規則，日語也叫簿記，企業系統無非就是人財物的流動，而這里面最核心的就是財，也就是錢的流動，理解了這個，對很多項目都有幫助。其次，日本人非常重視法律，很多新頒布的法令對業務系統和流程都有影響，這方面也是一個重要方面，例如馬上要實行的 SOX 法，就讓很多日本企業修改他們的業務系統以應對該法令。

??? 第二個，作者提到了 BSE 的職責問題。我也想談談自己的看法。 BSE 是做什么的？是一個重要的溝通窗口。那么這個窗口擺在日本還是中國就值得好好考慮了，我覺得把 BSE 安排在國內更好一些。理由很簡單，離現場最近，最符合敏捷原則，最有利于發現問題，并及時進行溝通。 BSE 沒有履行好自己的職責，這個原因也是需要深究的，使能力不足還是職責不明確。 BSE 的能力除了技術之外，更多的是對業務的理解，對開發過程的把握，發現問題，及時溝通及時解決。另外，日本人定義的 SE 和我們理解有所不同，他們要求的更多，更廣泛，有時間我會另外寫一篇文章介紹的。

??? 第三個，開發過程運用了迭代開發，并交付了一個阿爾法版，卻沒有發現其中對需求理解偏差的問題。這里面的問題就是中日雙方對什么是軟件原型的理解存在了誤差，畫面僅僅說明了針對用戶的接口，并不能證明對需求理解的正確性，畫面后面的各種各樣的處理才是關鍵，那個日本上司的抱怨，其實只能怨他們自己。同時，中方的開發人員也沒有作出一個合格的阿爾法版，也有一定的責任。阿爾法版里面應該用假數據體現出后臺處理的過程，然后日方來判斷該過程是不是正確。如何體現呢？我想應該有簡單扼要的說明文檔，所謂簡單扼要就是多用圖，少用文字。

??? 第四個，開發管理我認為也存在問題。這個問題是日方的。也就是日方對中方這邊的開發沒有進行良好的管理和監督，這個不是溝通和 BSE 能夠解決的，而是由該公司的管理制度決定的。不僅日本的外包存在這個問題，日本國內的開發也有這個問題，項目包給合作公司后就不管不問了，結果一交付，什么問題都來了。

?

??? 最后說一下我對敏捷的理解。看了 Object Primer 后，我最大的收獲就是對敏捷理解更加深入了。我現在的理解就是，敏捷就是用最簡單最有效的辦法，最快的解決問題，說白了就是不用拘泥于什么是敏捷不敏捷，也不用拘泥于什么形式，只要實用有效就好。談敏捷的書里面列出的一些最佳實踐，固然不錯，但是真正的操作起來，不能生搬硬套，需要根據我們的實際情況設計出符合自己的敏捷方法，有時候即使不十分敏捷只要有效也不失為一個好辦法。

?

???? 以上是我的理解，歡迎大家拍轉！