公司一專案發生質量問題，被日本客戶要求進行根本原因分析，並提出對策。
我們乙方的心態是怎麼能盡快把這件事情結束，而且盡量對未來的工作不產生太大的影響。
當然能讓客戶看到好像是真正的原因，是最重要的。
交涉了幾次之後，終於客戶納得（接受）了。
歡欣鼓舞。天空頓時晴朗的感覺。
根本原因分析是質量管理方面的乙個非常重要的方法，在日本的專案中經常用到。
日本it專案的成功率還是挺高的，雖然感覺他們的效率好像不是特別高，
但是從綜合的角度來看，
日本人幹專案還是比較成功的。
我認為乙個主要原因是他們的商業社會的成熟度比較高，
在專案管理領域就是比較深入的真正應用pmp的理論，
進行時間管理，
質量管理，
成本管理，
溝通管理等等。
日本專案一般在初期會讓各個乙方公司做出有根據的提案，
並對提案進行評估最終找到合適的乙方。
確定乙方之後，
乙方會做乙個粗略的計畫表和乙個詳細的schedule（也叫wbs）。
這個是完全沿用pmp的時間管理方法，
通常以最終交付的成果物為單位（或者更大些的單位），
對總的task進行分解，
最後根據分解的內容來排出來乙個比較詳盡的schedule。
通常這個schedule詳細到每個機能塊，
甚至更細到每個交付成果。
在跟日本提出這個schedule，
並且雙方合意後，
以後的進度管理主要就是以這個schedule為基礎進行管理。
另外，直接用pmp的evm進行管理的公司也不少。
整體上這些指標還是能非常好的反應狀況的。
是前導了還是遲延了，
遲了多少，
如果這樣下去未來狀況會怎樣，
通過evm的管理能非常清楚。
質量管理不用說了，
日本視質量為生命，
對質量的要求很高。
一般來說首先要有乙個質量管理計畫，
質量相關的活動都會根據質量管理計畫來進行。
比如為了保證質量，
事前要做哪些事情。
一般來說對成員的培訓，
一些相關技術，業務的講解，
一些規約的制定，
以及有多少經驗者都是專案質量方面成功與否的重要因素。
這些大部分都需要在專案大規模開始之前盡量準備好，
才能讓專案比較順理的進行。
另外在專案過程中通常會進行質量分析，
一般是定性的和定量的分析，
定量中還會對不同機能，不同人的狀況進行統計。
對發生的問題（比如bug）等會進行直接原因間接原因根本原因等的分析，
並根據分析結果實施對策，
通常要對同樣的類似的問題進行展開（日語叫橫展開）。
這樣避免同樣的問題發生多次，
減少了後工程的負擔。
溝通管理是最重要的。
尤其是跨國的這種offshore開發。
日本也非常重視溝通。
正式有了溝通這個基礎，
專案才能最終保證進度和質量，成本，
最終獲得成功。
通常在專案初期要確定溝通的方式，方法，會議體等。
除了中日之間進行充分的溝通，
內部的溝通計畫通常也要明確開來。
溝通做的好，
能極大的減少一些問題，
或者讓問題死在搖籃裡，
或者讓問題的影響變得最小。
日本那邊做設計，
中國做開發的情況比較多，
所以在中國開發之前，
通常會有乙個設計說明會。
這是乙個很好的例子，
開發者對設計的理解的提高能極大的減少後面的返工。
最近幾年中國飛速發展，
特別是類似bat這些領先的it公司，
在日本好像沒有出現。
日本的it好像還是在走老路子，
雖然做的東西質量不錯，
但是利用的技術等好像比較落後。
以上這些都給我們一種感覺，
在軟體領域中國已經大大超過日本。
其實不然。
我感覺質量終究會被更加重視，
而一些科學的管理方法也會左右未來的競爭。
而這方面，
中國還跟日本有較大差距。
做軟體的一點思考
這兩天在家畫了兩天的uml圖，當做是對自己所掌握知識的乙個複習。大概是這麼乙個過程，首先是編寫用例文件，將使用者的需求描述清楚。此步驟要盡可能的簡潔，盡量採用客戶的語言，不要採用計算機語言。其次抽象出參與者和動作，完成初步用例圖。確定主要動作和行為 分層，確定大致的開發框架。確定目錄結構 然後根據用...
某君的一點軟體測試思考
測試的過程應該嚴格遵循一定的過程與計畫，這樣的過程體現於測試案例中，測試者可以只按照測試案例便可以找出該軟體的問題所在，而不需要對軟體的需求有深入的了解，恰恰這個測試案例的編寫人卻需要很深入了解軟體需求設計架構，可是能夠編寫好的測試案例的是乙個測試員的基本素質。總結幾年風雨兼程的測試歷程,有以下的一...
遞迴的一點思考
廢話不說，直接上 searchtree delete int x,searchtree t else if t left null 沒有兒子的情況也包含了，因為t right 為null else else if x t element t right delete x,t right else t...