2007年8月13日，在剛剛開始我
工作的第七個年頭時，終于順利的進入了M公司，并得到了一個
測試管理方面的職位。雖然之前的六年工作中，我一直在偏技術(shù)和偏管理的角色中游移，自信自己在兩個方面都有一些積累，足以勝任技術(shù)管理工作。可是在M公司的這一個半月，的確又真的讓我重新開始思考自己的工作。
零零碎碎想到一些東西，先寫下來，以后繼續(xù)慢慢補充，也歡迎大家一起討論。另外，雖然我的視角是從 Test Team 的角度出發(fā)的，但是也應該可以適用于其他想進一步提升自己價值的Team。
在大多數(shù)情況下，Test Team并不是以軟件的直接生產(chǎn)者的身份出現(xiàn)的，而是作為一個附屬的功能團隊承擔開發(fā)過程中的一部分職責。這也決定了Test Team 的工作并不不能直接的體現(xiàn)出價值，而是只有當Test Team的工作成果被其他人或Team所使用，為其他人或Team帶來價值時，才能真正的體現(xiàn)出Test Team的價值。
換句話說，當我們的“產(chǎn)品”能夠服務于他人時，我們的工作才有了價值；而當接受或使用我們的“服務”的組織越多時，則我們的Test Team的價值也就越大。
舉個例子。當一個 Test Team 僅僅認為自己的工作只是“盡早的找到bug，并確認每個bug都得到合理的解決（這是對
軟件測試工作的經(jīng)典定義）”時，一個Test Team產(chǎn)生的價值僅僅作用于某個Develop Team甚至某個Developer。這時，Test Team的大多數(shù)工作都屬于Team內(nèi)部的工作，與其他Team的接口可能僅僅限于一個bug tracking system，所產(chǎn)生交互的工作也僅僅限于對bug的討論和狀態(tài)的跟蹤。這種情況下的 Test Team的工作甚至存在的理由都無法被項目之外或部門之外的人或組織所了解。
但是當我們留意到我們可以為整個項目中的多個Team，甚至整個部門的多個項目或者企業(yè)中的多個部門提供我們的“服務”時，一切都會變得完全不同了。例如
為項目團隊提供每個版本的bug趨勢分析數(shù)據(jù)，讓項目中的每個人都了解項目當前的狀態(tài)
通過分析bug數(shù)據(jù)來建立或完善各種Checklist，幫助項目團隊更好的完成需求評審、設(shè)計評審以及代碼評審，減少bug出現(xiàn)的機會。同時，可以定期將多個項目的Checklist進行合并，使單個項目的經(jīng)驗可以通過Test Team快速的流動起來，及時的作用于其他項目
主動為Architect Team提供每個項目的
性能測試數(shù)據(jù)，幫助他們獲取更多的實際項目信息，減少踏入“陷阱”的幾率
……
我們可以做得事情還可以有很多，而關(guān)鍵在于我們是否有積極主動的與其他部門內(nèi)或部門外的Team進行溝通，去努力了解他們的工作和需求，并開發(fā)我們已有的“產(chǎn)品”所能提供的價值。也只有當我們把自己成功的“推銷”出去，并與更多的Team在工作上有了越來越深的融合，我們?yōu)閯e人提供的價值也越來越大時，我們自己的價值也才會變得越來越大，并且逐漸成為組織中無可替代的部分！