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