***
我現在在一家日本公司工作。最近委託給國內一家公司開發的軟體提交了第乙個版本。情況非常不理想。用我日本上司的話來說，開發團隊根本沒有理解開發這個軟體的意圖和目的，目前提交的軟體與他最初頭腦中的想象差別非常大，甚至是方向上的差異。
對這樣的結果我並不感到驚訝和奇怪。我認為離岸外包專案中最大的兩個風險在這個專案中得到了充分的體現。
這個專案是由日本方面在日本完成式樣書的編寫，也就是完成需求分析工作。在國內的外包公司完成分析，設計，開發和測試。
這個專案的需求做得並不算好。很多功能只是停留在概念性的描述，缺少細節。需求文件本身並沒有能清楚說明開發該系統的目的，以及本系統試圖提供給使用者的價值，開發人員不能理解這些東西也就很正常了。當然，試圖一次性的寫出完美的需求說明書是件困難的事情，如果不是不可能的話。需求說明書的作者和開發人員之間有著不同的知識和經驗背景。有些東西，可能作者以為開發人員知道，或者以為自己已經講清楚了，而實際上並不是這麼一回事。解決這個問題的辦法就是反饋。通過開發人員和需求說明書的作者之間的討論和溝通，逐漸彌補雙方對需求認識上的差距，並不斷將需求說明書補充完整。但這個專案中恰恰在這一環節上非常薄弱。
需求的作者在日本，開發人員在中國，雙方完全沒有直接的溝通。更不用說面對面的溝通了。開發人員拿到並讀過需求以後，整理了乙份問題列表，然後交給在日本的「bridgese」，「bridgese」根據自己對需求的理解回答了一部分問題，然後將剩餘的問題以及自己的回答一起交給需求說明書的作者。該作者對所有的問題給出回答，或者對bridge se的回答予以確認，然後再通過bridgese將答案傳給在國內的開發團隊。這樣乙個過程化了超過兩個星期。
在我看來，這個過程未免過於漫長了。而且在開發以前，只有一輪問答過程是遠遠不足以使開發人員完全理解需求的。但是，這個專案本身的開發周期就不長（第一版的實際開發時間約兩個月），從時間上來說也不可能安排再更多的問答時間。而且即時再安排一輪，也未必有用。
本來，在離岸外包專案中，bridgese應該起到非常重要的橋梁作用。他應該和使用者以及開發團隊都保持密切的溝通。對需求，他應該達到和需求說明書的作者差不多的理解程度。但是不知道為什麼，在這個專案中bridge se沒有起到這方面的作用。
然後，不管怎麼樣，接下去就是分析，設計和開發階段了。大約半個多月以後，交付了乙個阿爾法版。但其實是乙個只有介面，而基本沒有功能的版本。因為需求中使用者介面部分還是講的比較詳細的，因此在介面開發方面當然也沒有太大的問題。但是因為介面後面的功能基本都沒有做，因此也無從知道開發人員是否真正理解了需求。
在這之後就是最近的版本交付了。在外包公司而言，是系統已經開發完了。至少功能都開發完了，後面可能只是需要更多的測試和debug。但是，對於定義需求的人來說，這時才發現開發出來的並不是他原來設想的東西。
在我看來，這個專案顯示了在離岸外包專案中最大的兩個風險：溝通不足，反饋太慢。
由於是離岸外包，使用者和開發人員分處不同的國家，距離遙遠，往往還存在語言，文化，習慣等方面的差異，這些都會給雙方的有效溝通帶來阻礙和困難。如果是那種在使用者側完成詳細設計，在外包方僅僅進行程式設計和測試這種方式的話，溝通方面的困難帶來的麻煩可能會少一些。但是，如果是象這個專案一樣，外包方根據需求完成分析，設計，程式設計和測試的所有工作，那麼所需要溝通的資訊是非常多的。在這種情況下，如果過分迷信文件在溝通中的作用，僅僅依賴文件，甚至依賴非常正式的文件進行交流，我認為它帶來的結果可能是災難性的。主要問題，打個比方來說，就是資訊溝通的「頻寬」不夠，「延遲」嚴重。
另一方面，要充分發揮bridge se的作用。前面說過，bridgese對需求的理解應該達到和寫需求說明書的人一樣的程度。如果做需求分析的人不能到開發現場向開發人員解釋需求（這應該是最理想的安排），那麼bridge se應該做到這一點。而且bridgese應該和開發人員共同工作相當長的時間，以在一定程度上起到乙個「現場使用者」的作用。
當然，現在在離岸外包領域，比如對日外包，即能克服語言障礙，又有紮實的技術功底的人是非常稀缺的。如果有這樣的人，一定會被同時用於幾個專案。雖然這可能是一種無奈，但卻不是正確的做法。
在離岸外報專案中，同樣由於距離因素，頻繁地向使用者演示開發中的軟體，反饋開發進度，也要比國內專案更困難一些。但是，仍然要盡力地按照「短迭代，經常發布」的原則去做。因為有前面所說的溝通方面的困難存在，更需要通過盡早地發布版本和向使用者演示來及時發現對需求理解上的偏差。如果等到最後交付日才發現對需求完全理解錯誤，那麻煩就大了。
通過internet，要做到這一點其實也並不那麼困難。比如，對於基於web的應用，完全可以在開發側架設演示系統，讓使用者遠端訪問。bridgese可以在使用者現場做演示，並聽取使用者的意見。
離岸軟體外包專案的初衷是降低開發成本，但它同時也帶來了新的風險。所幸，敏捷軟體開發方法的很多原則和實踐還是能幫助我們克服其中的困難和減少風險。
乙個專案的失敗
曾經看過cmm的一些資料，當時只是覺著這些東西有些空，而且很複雜，很沒辦法在中國的軟體公司實行。可是，這麼多年過來，經歷了很多的專案，也領導過很多專案，發現對cmm有了新的認識。cmm的關鍵問題域是很多失敗和很多成功的例子所總結出來的，也許它很複雜，要求也很高，但是如果我們真的理解了這些關鍵問題域，...
乙個失敗專案的總結
2013年 2014年，筆者參與了乙個大型專案，雲平台下做資源 資產 電子運維管理，由德勤負責需求整合 hp負責系統門戶和硬體整合，pccw負責實施整合。ibm 中興 亞聯 億陽等十幾家廠家做開發分包。專案合同額好幾億。當時我在pccw負責資源的實施管理，與中興 亞聯 億陽一起完成所有省份的實施，一...
乙個失敗專案的覆盤會
2018年5月份筆者參加了乙個失敗專案的覆盤會，領導開場介紹了這個專案的基本情況，2017年中標某集團十多個省的雲平台安檢專案，公司之前做了好幾年上百個類似的安檢專案，經驗較為豐富，所以在多家廠商競標過程中脫穎而出成功中標。但經過一年多的實施，最終2018年5月以客戶退單告一段落。然後讓專案團隊進行...