二零一四年春，我接受了一個也是很大的谘詢公司的聘用，叫它Cap吧。我所工作的項目的客戶在佛羅裏達靠近邁阿密的一個小城市。客戶是一家私營企業，它壟斷了美國東南部五個州的豐田車的批發業務。項目的經濟目標是在同樣的車行分部的情況下能多賣10%的車，每輛車的銷售業績增長12%。其主要業務流程優化的原理是根據車行的銷售業績分配車輛配額，這樣避免有的車行有車賣不掉，有的車行沒有車子賣。二是在車輛配額方麵給予車行更多的參與權，具體地可到年份係列、發動機、顏色等等其它的車輛屬性。其宗旨就是為車行提供更為適合於其市場需求的車輛同時減少供不應求的現象。三是用追加付件選項銷售從而增加每輛車的贏利。從商業角度上講這是一個很有趣的項目。

我的一個技術以外的挑戰就是缺乏對業務流的了解，在這一方麵女業務分析員丹給了我很大的幫助。我開始工作時沒有見到她，後來聽說有個叫丹的人要來，開始以為丹(Dan)是一個男的，見麵才知道是個女的而且也是中國同胞，丹是她的中文名字。經介紹後了解到丹是這個項目的元老級的業務分析員，是一位這個行業的資深人士。我剛剛參加項目那段時間她休產假在家生孩子。在極不情願的情況下又一次出差來佛羅裏達幫助項目趕進度。

雖然不情不願丹一旦到了當地工作非常認真，有效。在知道我對業務不太了解又是同胞的份上，她專門為我開一對一講座幫我增加業務知識。有趣的是同是中國同胞的X架構師並不熱心參與。關於X丹說了這樣的話“X開始並不在這個項目，他是以幫助前任架構師做文檔開始的，後來他們把前任架構師請走了，X就成了架構師。他的業務知識都是我教的。” 丹還告訴我很多項目中的人事關係和重要的人和事，在後來困難的日子裏提供了有力的支持和溫暖的同情。為此我心存感激至今。謝謝了，丹！有朋友再困難的日子都能過！

技術上這是一個典型的微軟平台的方案。ASP.Net 前台，SQL/Server 後台。都是我的專長。可是問題就像人們常說的在於“鍵盤和椅子之間”。與大多數谘詢公司一樣， Ｃap為了降低成本有一個在印度的離岸公司。這種離岸模式在紙麵上看起來很吸引人，可是真實的情況卻是另一回事。首先因為是在地球的不同區域，為了有效管理在，不同的區域的部門要有各自一套管理班子。多出來的管理班子就是多出來的費用。第二，既然有各自的管理班子那就一定有各自的財務指標。所以就算是同出一門也是各自維護自己部門的利益。與客戶和商家的關係一樣的，絕無合作無間的可能。

但是因為是同出一門就有了一般客商關係沒有的複雜人事關係。可能你今天與印度的同事說他做的需要修改而且對方很認真地說他會去改，明天做好。然後你回家睡覺了。第二天醒來一看你的上司轉發了印度同事上司的電郵。並加上一句：為了項目進度，為了他們的贏利就不改了。

再有一個是這種離岸的合作關係由於層層壓支出，真正有水平的印度工程師他們也雇不起，可能有一兩個有水平的，其他就濫芋充數了。毎次項目開始時從印度分公司來的人都個個了得，你充滿信心地準備工作了，可是當項目真地開始了與你一起工作的人很可能不是你見過的人了。底層的工程師為了生存什麽都做沒有底線。再有就是溝通質量非常之差。但你講了半個小時後問道“有問題嗎？”95%的機會你會得到“沒有問題”的答案。可是你不知道對方是滿臉茫然，根本沒聽懂，更無法發問還是真的懂了。你所了解的是一個聲音和一個名字。他是有十幾年資曆的老手還是剛剛畢業的新手，你也無法知道。

在我工作過的離岸夥伴中有中國，墨西哥，印度，菲律賓。大多數情況下離岸夥伴做的事情我們大多需要重新做過，至少需要部分重做。

除此之外還有一個典型的軟件開發項目的問題。那就是關於方法論（Ｍethodology ）的決定。

早在七十年代開始，軟件產業一直沿用建築業的方法論和工作流程。用一個詞來描述就是流水線（waterfall ). 各大公司都有自己的流程和名稱。如微軟有Microsoft solution framework. Avanade 有Avanade Method. 業界較為標準的有Rational Unified Process, (RUP)和軟件標準組織的CMMI process.

這些流程的共性在於忽視了軟件生產和硬件生產的不同，軟件的生產可以返工而且不會有原材料的浪費。舉一個例子，你若建一個房子，開始隻設計了一個門，建好後想把後麵窗戶改成後門。你要把窗戶拆下扔了，再買一個門裝上。這裏有原材料的浪費。你若有一個軟件係統，在一個屏幕上原本有一個按鍵，你若想再加一個，或者改變原有按鍵的處理邏輯。你所需要的是修改源程序並進行有效的測試。這個過程沒有原材料的費用。有的就是人工的費用。

由於軟件工程的特性使得沿用建築工程的工作流程在大多數情況下造成項目失敗或超資金預算或延後工期或就算是按期完成了但是已經不適應用戶的市場需求了。

這裏有許多原因，我在這裏舉例列出一些。

由於這種需求，批準，設計，批準，開發的工作流程，一但批準了就不讓改或者改就要多付錢，影響進度。所以用戶會在需求，設計階段遲遲不批準，常常造成用了三分之二的時間和預算在這些文檔上，真正用於軟件開發的時間和資金為由隻剩下三分之一不到。

由於軟件開發的工具平台相對建築工業的工具平台非常的不穩定。幾乎兩年一換。每一個項目可能都有沒有用過的工具或產品，所以設計文檔說的很可能不能實現甚至完全不適用。所以花了三分之二的資源做的需求和設計在實際中的價值大大折扣了。在八十年代時的軟件項目失敗率高達百分之八十以上。

在八十年代業界開始探索不同的工作流程。總的來說就是趨向敏捷（Agile)

有代表性的有兩個不同流派，一個叫極端編程（extreme programming ) 另一個叫scrum , 我都找不到合適的中文翻譯。總體上它們有如下共性：

不同於傳統流程注重文檔，新的流程注重能夠工作的軟件產品。

不同於傳統流程注重控製變更，新的流程歡迎變更。

不同於傳統流程分塊開發最後整合，新的流程一直整合中進行。

不同於傳統流程強調設計一次到位，新流程強調漸近設計。

不同於傳統流程不注重測試效率，新流程強調測試自動化。

不同於傳統流程按模塊分部開發，新流程按功能分部開發。

不同於傳統流程需要在設計文檔向幫助下閱讀程序和修改程序，新流程注重程序可讀性，（要求在不用文檔不看注解的情況下讀懂並能正確地修改程序）。

不同於傳統流程由資深人士估計工作量，新流程由程序員自己估計工作量，極端編程讓編程人員自己估計工作量。

不同於傳統流程在開始時就決定最終的係統是如何的係統，新流程邊做邊決定係統將有什麽功能。

新的流程的好處是不花太多的精力在文檔上，及時調整開發內容，在任何時候項目可以停止而且已經開發的功能都將可以進入生產運行。

可是對於大多數不太真正懂行的人來說他們理解的敏捷流程就是不進行設計直接進入編程，自動測試是費時費工會增加開發費用。

漸近設計是返工行為，會增加開發費用不太現實。

敏捷流程對開發人員的技術要求很高，一般開發人員的水平不夠。

其實這些都是對敏捷流程的誤解。

正如Ken Beck, XP 的創始人描述極端編程時說的那樣：其實我們所推崇的流程是更加符合人的自然本性，沒有什麽極端的地方，她之所以被命名為極端編程是因為我們把編程中的重要環節做到極致同時省略掉不重要的環節：

大家都說設計重要我們就不停地設計；（漸近式設計）

大家都說源程序檢查重要我們就不停地做源程序檢查（配對編程）

大家都說測試重要，我們不停地測試（測試自動化）；

大家都說整合重要我們就不停地整合（不間斷整合）

可是由於項目管理人員對不同工作流程的一知半解往往會選擇性地理解和選擇性的應用，大多數情況下弄出個兩不像，其結果比兩種流程中的任何一種都差。具體地說來有如下幾點：

以固定時間，固定資金的項目為理由，就不實行敏捷流程中的不停調整開發內容也不允許編程人員自己估算時間。

以客戶要求從項目開始時定期演示功能為理由就省略了係統架構設計。

以節約時間和費用為理由不進行自動測試和漸近式設計改進。

其結果是匯集了兩種工作流程的所有缺點，就像駕著一輛打足了氣但是輪胎有漏洞的車，你可以駕出一會兒但是很快就走不動了。

這個項目也不例外，上述的所有問題它都有。還有一個問題就是它的本項目組成員。這個團隊以前是做整合的從未做過真正的開發工作。他們對微軟技術了解甚少。沒有辦法與客戶溝通，沒有辦法對離岸團隊進行有效的監控。在這種情況下他們找到了我。但是原來項目的架構師繼續做他的架構師。盡管對他來說數據庫設計就是弄一些表，每個表裏加一些欄目，然後放一些數據進去。對數據庫的數據正確性，和數據庫設計原則一無所知。在編程方麵他隻有Java的編程經驗，“這個如果在Java 我們會如此這般”是他的口頭禪。

在原程序版本控製方麵 是完全空白。可是他既然在這個位子上總要說這個位子上的人應該說的話。所以他就每天把大家召集起來說一些空話大話廢話，別人問他問題時故作姿態，然後做一些似是而非的答複。離岸部門為了自己的利益一直在胡弄他。這麽一個架構師在對客戶和對離岸的交往方麵都顯得不夠真效。這其實就是他們招我的原因。在麵試時不論是在岸或離岸的技術人員都無法評價我的技術水平。出乎我的預料的是這位架構師是一位男同胞。在我開始工作時期我邀他一塊吃晚飯。席間我與他說道：在美國工作十多年，這是我第一次與中國工程師一塊工作。希望我們親密合作，做出一個成功的項目。在需求方麵我對這行的商業運作不夠了解，在人事方麵也不知道誰是誰，還望你多多關照。在技術上我一定全力以赴。我倆加起來，一定能把事情搞定。在後來的日子裏，為了保護他的麵子我盡量不在客戶或離岸團隊當麵指出他的錯誤，但私底下與他溝通。

第一天參加技術人員會議時就發現項目的數據庫設計管理特差，同一個數據庫居然有十幾個版本，誰也不知道，它們之間有什麽不同，哪個是對的。整個一團糟。會上我沒有說話，連問題都沒有問幾個。會後我私下與他溝通問他對這個問題的態度。他說他不會SQLServer也不知道有什麽更好的辦法，問我有什麽辦法。我說我以前也有過類似問題後來我找到一個方法，用起來還不錯，如果不介意我可以試試。根據他的要求我寫了個PPT，給他看，他看了後讓我給離岸技術人員作一個講座然後實行。

講座時離岸的首席工程師因故未到（天知道他除了這個項目還在幾個別的項目上掛名了）其他人不知道有幾個真正地聽懂了，X懂了多少也是一個大問號。會後我開始與離岸數據庫工程師實施我的方案。可是一旦實施了，離岸首席工程師強烈反對，我努力與他溝通也找不到他，隻是電郵來來去去，這時的X反倒裝做好人，總是以高高在上的姿態提出一個一個的折中方案來。可是就像駕車一樣，交通規則一定要大家都遵守才有效率，如果有人這樣做有人那樣做，就會亂套了。沒有中間方案可行的。從管理角度上看這也是X唯一能采取的立場，可是他的位置是架構師，缺乏基本的技術知識盲目地走中間線路就沒有什實際意義了。

解決了數據庫的開發應用問題我繼續前進向係統的縱深進軍。沒費多少事就發現了一個更為嚴重的問題。根據安全需求係統應該設計成麵句服務的三層結構，前端網站與服務層交互，服務層與後台的數據庫交互。前端網站不與後台數據庫直接交互。這主要是因為一般麵向大眾的網站大多設置在安全區，不能直接訪問網絡核心的數據庫。可是我所看到的係統是直接由前端網站訪問後台數據庫。這是一個重大錯誤，如果沒有發現並改正將會造成項目失敗。我提出後，離岸架構師一再抵賴，最後在事實麵前不得不承認；X架構師的反應是這個設計是客戶架構師推薦並批準的，有問題應由客戶負責。客戶架構師說我們花大價錢用你們的專業人員，設計把關應由你們負責。最後的安排是由我給出改進的架構設計然後與一位印度來的離岸部門的工程師利用周末對係統重組。這個問題至少造成一到兩個星期的日程推遲。但總的來說救了項目避免了失敗。經過這兩件事，客戶的高層對我另眼相看，對X架構師就不那麽重視了。

客戶中的數據庫專家公開表示他不願意與別人浪費時間隻願意與我一道做有意義的工作。就這樣我拯救了項目，在客戶上到副總下到數據庫設計和係統架構師中建立了良好聲譽。可是我得罪了X架構師和離岸架構師。由於我堅持軟件質量也讓項目經理不快。特別是X架構師，慢慢地對我的態度從友好變成傲慢，沒有禮貌了。到了後來達到了語言暴力的程度。我忍無可忍向公司的人事部門投訴。有朋友告訴我項目經理與X架構師是二十年的朋友我告不贏的。果然我確實是告不贏他。調查結果是沒有發現我所投訴的語言暴力證據，要求我繼續配合工作。為了維護自己做為一個人的尊嚴我提出退出項目。與上層交涉的結果是我繼續做兩個星期並向接手的架構師E做好交接，條件是X不再對我無禮。客戶方麵知道我即將離開從上到下紛紛表示惋惜，開發副總和應用副總分別找我談話希望我能留下做完項目並表示他們願意越過 Cap 直接雇用我。

我對他表示了深切的謝意，不過我知道 Cap一定會動用法律手段阻止我在客戶那裏任職的，再說出差還行，我可沒打算長期在佛羅裏達工作呀。為了維護我的專業形象我認真地與接手的E架構師解釋了現行的架構設計和編程質量問題和工作流程問題。其實我所指出的問題都是用Visual Studio 生成的程序分析報告能看到的，任何一個合格的.Net 架構師都能看到的，客戶方麵有這樣的技術能力的。誰曾想就是因為我的盡職讓我後來失去了在Cap 的職務。容我下集再敘。

經過兩周的艱苦努力我完成了交接。我覺得我維護了自己的尊嚴也維護了自己的職業聲譽。雖然困難但我心存寬慰。在與E一道去機場的路上E使勁地向我保證會把項目做好不枉費我的心血。並極力推薦我參加新的項目。在機場的餐館裏我們一道用晚餐。在看到我的微軟認證證書後，E說了這樣的話“你的證書加上我的證書，多過Cap .Net 部門的所有其他人的證書的總和。你是名符其實的.Net 軟件開發專家！”

就這樣我結束了三個多月的飛人生活。重回地麵。請看下集許若之地

文字編輯：Ellen