團隊管理之性能實施團隊日志8

帶這個團隊快有一個月了，我覺得內部磨合以及外部溝通基本上形成了固定的策略。

性能實施有兩個重要的worker階段。

寫腳本、做參數、定場景；

分析、調優。

我覺得第一個階段整體感覺上沒有問題了，除了還出現一些服務配置、數據之類的問題之外，壓力上除了有兩個系統還沒有壓起來過之外，其他的都基本上把性能問題在慢慢的暴露了。

那這最關鍵的分析調優的階段就必然要跟上節奏了。

分析調優要做到什么程度呢？如果能有下面這樣的響應時間對比圖，那就明顯不過了；

還是要說調優的思路，因為這幾天我在跟8個項目組溝通。而有些項目組中基本上是靠蒙的。突然之間就想到要改某個參數。如果能蒙一次對了、蒙兩次也對了，我絕對相信這是個巨牛逼的人了。但是一次兩次的失望，我覺得有點承受不了。

在我們這個臨時拼湊出來的小團隊中，我也是這樣要求的，跟別的團隊的溝通，要證據確鑿！沒證據，跟人說瓶頸在哪兒，那太不像是專業的性能分析團隊該干的事了。

今天我看一個項目組說，要把jdbc從40改到1000。可是據我所知，這個數據庫根本沒幾個忙的線程。我就不理解為什么要調jdbc？就問他們為什么要調，他們說：從日志里看到取不到線程池，所以試試。我說，那你們把證據發給我看看，我想知道你們分析的思路。結果也沒給我發出有力的證據。我只能懷疑這個又是蒙的。而這個項目組，我已經眼睜睜著他們的方向性錯誤，好幾天了。

而PM還要關注的是整體的狀態，昨天我看了一下問題。問題出現率還是挺高的。總問題已經記到141個了。其中也有功能問題，但是70%以上是性能問題。對8個系統來說，一個系統十幾個性能問題，從經驗上來說，似乎差不多了。但是真正的測試還沒有開始。

（之前有78個問題沒放到jira中，所以在jira中只能看到63個。）

預計這個項目中出現的問題，會走過兩百了，至少。對一個性能團隊來說，能發現這么多問題。也已經算是多的了。

從8個系統的各進度來看，整體上來說，有一個團隊的進度非常有風險，其他的還尚在可控范圍之內。

這兩天因為有一個培訓，所以又要離開項目組兩天。走之前我安排的本周工作目標是：每個系統都能把混合場景跑起來，要是跑不起來，那就加班。把相應的開發組拉著加班。

今天是6月15日了，從上次移了兩次項目計劃來看，我們的整體計劃還是非常有可能推遲到7月中旬，如果那樣的話，我覺得就非常危險了。從我帶性能項目的經驗上來看，項目推遲半個月，從PM的角度上來說已經是失敗的項目了。

可是性能項目就是這樣，它不僅依賴著開發團隊、基礎設施（或數據中心）等團隊，還依賴著領導層的重視力度，這個領導層的含義不僅僅是最上層的領導，還有中層的領導以及中低層的領導。

有些小leader的技術和思路還沒有那么完整，問題的理解和團隊的溝通都不夠深入。經常出現你說你的，我說我的情況。

中間總是有那么一小段雙方都不送過去。就像前幾天出現一個寫Cache之后取不到的問題。基礎架構那邊說，你業務方寫進去了成沒成功是有返回判斷的呀？業務方說，我寫成功了呀，但是你cache取不到，當然是你cache的問題了。這一段車轱轆話說了兩天，兩方都仍然不往前走。最后在我開會的時候又說了一遍。實在忍不了這種的溝通方式。

從我的經驗上來看，我覺得溝通比技術難題耗費的時間多得多。技術不行，還能上網查查，再不濟還能找人問問。

但是溝通產生的時間消耗是和每個人的處事方法、思維能力、說話能力、品質都有關系。同一件事情，不同的兩個人溝通，可能是1:10的差距。

然而悲催的是性能項目（其他項目也應該類似）需要的溝通尤其的多。

上次開PMO會的時候有三個項目組的人遲到大概10分鐘左右，房間里有20多個人等著。我想這種情況應該比較常見。但是如果太常見了那就不正常了。

鑒于前幾次開會總是有人遲到的情況，于是會上我說，后面我們會發正式的meeting request（之前是約定俗成的時間，開會前在微信群里喊一聲），每周的固定時間開會，同時我也把開會的時間從之前的一個小時縮減到30-40分鐘。會議分成三個階段：1. Brief；2. 過問題列表，但是一個問題如果討論超過兩分鐘的就停止，移到會后或另開會討論；3. 各項目組對性能實施的意見或建議；這一句我每次開會都問，但是沒看到有人提出異議。

并且如果以后還有人開會遲到導致有些事情沒有聽到就討論完了，那也只能按討論的結果來做。這就可以默默的給人安排活了呀。哈哈。

前面提了好幾次，我覺得有問題的點，我看到有人覺得我小題大做了。比如說，我提到沒有完整的系統架構圖和overall架構文檔。他們一直告訴我，有的呀。之前每個團隊都有畫呀。我說我要看到物理拓撲架構圖和邏輯架構圖。而之前各團隊畫的都是簡單的幾個機器的簡單的物理拓撲圖，也沒有系統間的connection、數據流轉說明之類的。而邏輯架構圖就更不用說了，我就沒看到過。

難道現在做項目連架構圖都可以不用畫了嗎？還是說我落伍了，這種overview picture是不需要的？

后來他們問我，你說的架構圖是啥樣的哩？我默默地搜索了一個linux的內核架構圖給他們看了一眼。看，就這樣的。

帶團隊還要注意的是團隊的能力結構，可以拆分的事情盡量拆分。但是要注意拆分之后的前后銜接，這個銜接的動作要PM來完成。 如果明顯覺得團隊能力不夠了，那就要想著迅速提升，或者讓他們知道一些常規的判斷問題的手段，能取出數據來也好。

如果實在帶不起來，也只能認命了。畢竟人生苦短。

帶團隊有辛苦，也有樂趣，關鍵是團隊要有成長。

壓力測試 項目管理 ProjectMan

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。