這幾天在看一些專案管理的書籍，想起了以前的一個專案。就是那個專案讓我認識到專案中出現的問題大部分嚴格來說都是管理上有問題，最終也可以通過加強管理的方式和方法更正那些問題。也讓我充分意思到“專案經理必須對專案負責”這句話的意思。

　　在那個專案裡，所有的測試人員由於沒有理解測試用例中一個期望結果的英文描述導致一個bug到最後才被一個新加入專案的同事發現並提出來。後來發現那個英文描述確實簡單，但是客戶卻在某個bug的回覆中明確的解釋了那個意思。複測這個bug的同事沒有足夠的重視而忽略了。

　　說到這裡，不知大家明白了意思沒。估計有些朋友已經發現了問題所在。當時我的步驟如下：

　　.負責測試的同事。通過檢視版本的測試結果找相應的測試人員。但後來發現由於中間有交叉測試，所 以所有的同事都測過。

　　.是否是需求變更。查詢相關資料，結果無。

　　.是否有相似bug。查詢bug庫，果真發現一個相似的bug，並且客戶在回覆中明確的提到了那個期望結果的解釋。

　　.找負責重測或跟蹤bug的同事。回覆因為是客戶關閉的bug沒有仔細檢視及理解。

　　這時我自認問題找到了，將問題告訴了客戶經理。雖然是自己的專案出問題，但是我覺得是測試人員的問題，沒有自己的問題。由於那個bug比較嚴重，而且估計使用者會在以後的使用中發現，所以就告知了客戶經理一起商量決定這個bug是否要補報。

　　客戶經理還是比較老道，而且從她的角度看了看這個問題。當時就讓我倍感冰冷。

　　1.首先期望結果的描述過於簡單。不過它來源於功能說明書，直接從那裡面搬過來的。那麼當時負責寫測試用例的人應該檢討，為什麼對於這種模糊的定義沒有提出及詢問客戶?

　　2.然後就是對bug沒有做好跟蹤，一些實際上可以看為是需求解釋、變更或設計變更的客戶回覆沒有收集且釋出給所有的參與者。

　　3.最後對需求解釋、變更或設計變更沒有進一步測試。

　　好了，由於我和她是平級，別人也不好意思明著指責你的不是，但是通過她所指出的問題，我在心裡實際上已經發現自己的很多問題了。

　　1.首先沒有詢問測試設計人員是否有模糊或不清楚的地方，收集且詢問客戶。沒有充分評審測試用例，導致需求模糊，用例也模糊的局面。

　　2.沒有對bug的統一管理，沒有回顧bug，整理客戶在回覆時的解釋和變更並告知所有的同事。

　　3.沒有組織且展開進一步的測試。

　　後來針對上面的問題，我也採取了相應的糾正措施改正了。但是那次讓我深深的感到了對於專案而言，沒有問題是和管理無關的。而且作為專案經理，千萬別在出現問題時還分是你的錯還是其他人的問題。對於專案經理來說，一切錯誤都和你有關，在查清問題之後說明問題的起因固然重要，但自身的檢討和如何改正才是最可貴，而且讓其他人不會覺得你再推卸責任的嫌疑。那樣只會讓你的合作者鄙視和讓你的組員更加的難受。

　　最後借一句話自勉“真正的管理者必須有擇善固執，據理力爭，勇於認錯，接納指正，不推卸責任的精神。”