楔子
工作一年有余，一直在做對日外包的項目。我不是個偏激的人，不會因為做外包學不到精深的技術而惴惴不安；不會因為做外包學不到高超的設計技巧而唉聲嘆氣。但是，對技術的追求，我不曾停止腳步；對軟件的設計，我也不曾避而不談。所謂“橫看成嶺側成峰，遠近高低各不同”，關鍵是你怎么看待自己，怎么對待自己。或許你在項目中擔任一個開發者的角色，終日為某個模塊的編碼勞心傷神，但是不要固定你的視野，去思考，去總結，用與人不一樣的視野去看待工作。本文盡管標題有日式二字，相信關於外包項目的運行，甚至於自主項目的運行，都有很多共通的點。由於個人能力有限，總結的內容如果有不足和錯誤的，煩請留言告知！
正文
從上升到理論高度的軟件工程角度上看，我們可以找到一款軟件從可行性分析到需求分析，到設計，到編碼，到測試各個階段的作業內容。軟件工程是一門置之四海而皆准的學問，是通學。而專學，則需要我們去摸索，去實踐，最后形成我們自己的思想體系。本文就筆者在工作中的實踐，總結出關於對日軟件外包項目的運行體系作介紹。
公司A委托公司B完成一個軟件項目，這個軟件項目的運行體系是怎樣的呢？筆者將其分為以下十個構成部分。
一、工程周期預估
二、開發團隊構建
三、匯報體系建立
四、QA&課題管理
五、工程計划制定
六、風險控制管理
七、品質控制管理
八、代碼版本管理
九、文檔控制管理
十、交付控制管理
下面就一一介紹每個構成部分的內容及作用。
一、工程周期預估
決定開發周期，雖然我沒有接觸到任何與之相關的，但是我覺得這個預估應該是由客戶來決策的，不過既然是生意，也肯定卻不了大領導們之間的談判。這一部分具體的細節我還真的是一點都不知道，只是覺得肯定會有這么個階段，只是工程周期的長短，應該是人數、生產性、時間的一個平衡點，畢竟軟件開發並不是人越多越好。
二、開發團隊構建
根據項目規模，開發時間估算團隊人數，選擇團隊成員，這由管理層決定。這里的預估和選人是核心，預估需要根據規模和時間找到匹配團隊人數的平衡點，而選人則是管理學的延伸了。選擇一個對的項目經理也很關鍵，對於大型項目，應該選擇一個有豐富經驗的項目經理。而對於小項目，可以適當培養非項目經理的開發人員。還有就是選擇開發人員，開發人員的能力與項目的風險息息相關，同時要注意項目組的新人率，高新人率即高風險。
三、匯報體系建立
我挺佩服日式項目在匯報這一點的做法，完善的匯報體系可以從上到下明了的掌握項目的進行情況。
在對日外包公司，按照報告對象不同可以分為三部分，分別是：向日方客戶報告、向項目領導報告、向項目經理報告。下面就簡單的介紹這三種報告。
■對日方客戶報告
在我所在的項目，每一周都會有一個與日方的視頻會議，同時每天也需要項目經理發日報，主要匯報三個內容：1.項目進度 2.QA（即目前存在的問題） 3.課題
1.項目進度：對日方的報告重要的是讓客戶感覺到項目的確在進行中，並且取得了一定的成果，這需要報告人了解客戶需要什么內容，報告某一個功能用了多少行代碼是愚蠢的報告。
2.QA：QA的報告是為了讓客戶知道我們的項目中進行中遇到了問題，如果沒有QA那會更糟糕。
3.課題：課題一般是亟需解決的問題，當然也並非如此，比如項目組的教育，這也算課題，但有時也並非那么緊急，只是讓客戶知道我們這個超前的意識。
關於QA和課題，QA是一些零雜的小問題，比如需求說明中無法理解的問題，代碼中無法理解的片段。 而課題則是更大的問題，需要花費更多的時間和精力去解決，比如項目已經開始，但是開發環境，開發平台不明等。
■向項目領導報告
在我所在的項目，沒一周也會有一個自己內部的工程會議，工程會議的目的是讓領導知道目前項目的進度以及問題，這里要注意的是，匯報的內容要能突出問題，比如因為某些問題 導致項目需要延期等等，這些對項目有風險的內容一定要放到匯報的最顯眼的位置。
■向項目經理報告
在我所在的項目，每一天，每個開發人員都需要寫日報發送到郵件列表，日報的內容主要是匯報開發個人一天內完成的工作內容，使得項目經理可以在下班前總結進度時候參考，也 有助於開發人員的個人管理。
■關於報相連
在日式公司有一種說法，叫“報相連”，即報告（ほうこく）—相談（そうだん）—連絡（れんらく）。某種意義上來說這是一種推卸責任的方法，但是卻是能夠控制項目風險的方法。做到報相連的核心是及時，遇到問題絕對不能拖，要立刻報告，聯絡，商討對策。否則就相當於抱着一個燙手的山芋，最后山芋掉地上摔的稀巴爛，自己的手被燙傷不說，責任也得自己全權承擔。如果及時將山芋燙手這個問題報告了，聯絡了客戶，商討不出對策后，山芋掉地上的話，那責任就由兩者承擔，在原則上我們就沒有犯錯了。同時這樣做，也有效的利用了客戶資源。
四、QA&課題管理
與客戶之間的問答，各種問題如果沒有QA&課題管理體系的話，將會顯得很雜亂，可能會前兩天一個人問的問題，過兩天又向客戶提問，這樣會給人很不好的印象，所以QA&課題也是項目 管理中不可或缺的。
五、工程計划制定
在項目經歷了准備階段之后，就是制定詳細的項目計划了，這是正式開發作業所依賴的根本。制定計划是比較復雜的，要考慮的面也要很全面，主要有三點。
1.生產性
2.有效人員
3.難易歸類
即使是經驗豐富的經理制定的計划，在未知的未來面前，也需要調整。所以，對於項目經理來說，他關注的應該是總體的進度，在遇到可能影響計划的事情時，用一句不好聽的話 “拆東牆補西牆”，其實這也是常用的一招，A模塊開發因為一個重大技術問題拖延了進度，那能不能通過縮短B模塊的周期來彌補呢？這是項目經理應該反復權益的。
而這一方面也是我現在所未知的，需要努力學習！
六、風險控制管理
其實並沒有一套嚴格的體系來實現這個體系，然而事實上他是融合在其他體系中的，比如報告體系，比如計划體系等等。關於風險控制是否應該單獨拿出來作為 一個體系，我個人並沒有什么偏好，拿出來也好，放到其他體系也好，只要做到能夠即使預測風險，合理解決風險，善於總結風險就行了。
七、品質控制管理
我不得不說，日式的品質控制體系真的是很完善，但是個人感覺自己還沒有完全吃透細節，況且我只是在中國的一家與日合資的公司，等到精通了他們的質量控制體系，一定要寫一本書來介紹日本的軟件精工。
下面簡單的介紹一下我所能看到的品質控制體系中的內容。
■評審
日式項目中，從需求說明書開始，到編碼，到測試，每一個環節都有評審，並且都有相應的評審記錄票來記錄評審中發現的問題，個人感覺這么嚴格的評審是質量控制上的絕妙的一招，不過也有一個缺點，就是低效率，對於緊急項目，這一套似乎不好用，所謂的敏捷似乎更是王道。
■測試
日式項目中，測試是我見過最為嚴密的測試，我所在的項目組，要經過嚴格的LT（白盒測試），UT（黑盒測試），CT，ST。對於發生大規模影響的開發，還需要進行RT（回歸測試）。而每一個環節的測試用例都需要經過評審，有時還不止一輪評審，這樣反復淬煉之后的測試用例才能用於測試。
■品質統括
統括，這是日式的說法，就是將各個工程階段中所有的品質數據收集起來，來判斷該產品的質量，這一點相信很多國內企業都沒有這個環節。但是日式項目很重視這一點，也或許是對承接方的監督吧。
八、代碼版本管理
代碼管理體系其實就是一些通用的代碼管理工具SVN、CVS之流，這一點上應該都差不多。但是值得我們學習的是：每次提交代碼都要寫上提交代碼的原因以及修改代碼的大概內容。
九、文檔控制管理
日式公司重視對文檔的管理，日方提供的資料文檔，工程階段產生的大量文檔，教育資料文檔，各種文檔都有相應的目錄存放，讓人看着一點都不凌亂。
日式項目非常重視文檔，及時開發人走了，找到另一批人，參照文檔，項目也能快速運轉起來。這也是日本軟件事業得以發展的基礎，試想，如果沒有這些平常的積累，怎么能成就日后的偉大。這也應該是我們所欠缺的，國內的開發偏於速度，文檔質量內容匱乏，導致積累少，人才斷層。
十、交付控制管理
項目7月就要交付，至於其中具體的細節我也在期待中。
后記
最后寫點自己在寫這篇博客中想到的東西，等到有所領悟，有時間以后的博客里會寫！
1.日式品質控制管理
2.日式文檔設計技巧
3.日式工程匯報技巧