半年TeamLeader總結(轉) -半年工作總結

     成為一個小團隊的TeamLeader半年多了，有成功的喜悅，也有失敗的苦悶，無論如何，是該總結一下了。       *關于計劃       作為一個小團隊的Leader，項目的計劃分成兩個部分，項目計劃和進度控制，事實上在我經歷過的或者我觀察過的（我的或者他人的）多個項目當中，往往最常犯的毛病就是有計劃沒控制，甚至是沒計劃更沒控制。事實上兩部分相互相成，一個糟糕的項目計劃必然導致糟糕的進度控制，但有好的計劃而糟糕的進度控制則會導致一切努力化為泡影，領導不滿意，團隊成員多怨言，上下不討好里外不是人。自己曾經也多次地經歷過這種郁悶，甚至一度想放棄，最終還是堅持了過來。       1)項目特點總結：一般目前處理的都是一些短時間迭代的任務（周迭代），每個迭代相對比較簡單       2)時間評估：良好的開端是成功的一半， 在項目的開始時，首先仔細地進行時間評估，盡量地細化任務以獲得更好的時間控制。此階段非常地重要，評估的失誤往往導致進度過緊，而人在疲倦的時候更是往往錯誤不斷，最終導致整個計劃失去控制。我的經驗是，在一切任務開始之前，一定要跟相關人員將業務溝通地非常清晰，此階段的一個小錯誤，將導致后面的全面被動，在溝通完畢之后，由開發人員評估時間，之后根據經驗得到一個正常的評估結果。這個過程中最容易犯的錯誤就是,一是開發人員對時間評估往往非常地樂觀，因為他只看到了開發的這個過程，關于這個問題，我把評估時間段分為：溝通時間、設計和開發時間（包括自測）、聯調時間（跨團隊甚至是跨公司）、發布Beta測試時間，跟開發人員強調每個過程可能會發生的時間，在這些時間的基礎上，再乘一個緩沖基數，得到最終的評估時間，盡管如此，在不少情況下，還是出現了需要加班才能夠完成的情況，這個確實是需要繼續總結思考的地方；二是對一些任務，往往領導規定了時間，這種情況下都是非常地被動，只能根據時間來定計劃，往往這種情況下更需要保持清醒地頭腦，更細致地進行計劃，而一旦發現偏差太大，則必須強烈拒絕，否則最終的結果也不會是領導期望看到的，在這個問題上可以說是犯了非常多地錯誤，對困難估計不足，過于樂觀，屈服于領導的意愿，看來這方面還是得繼續加強。       3)與第三方合作：多次與第三方進行了合作，也總結出了下面的經驗；在開始階段雙方定義好業務流程圖，并指定每一步驟由哪方完成，并形成文檔; 在開始階段根據業務流程圖定義好所有的接口，包括接口參數和返回結果，并形成文檔; 在定義完業務流程圖之后，出原型（包括界面原型、郵件原型等）; 定義好雙方各個時間點，包括Stub測試程序發布時間、接口文檔提交時間、某業務點發布、出原型時間、 聯調時間等等; 控制變更。其實在與第三方合作最困難的一點就在于，對方看不到如上這些控制的好處，思維不在一塊，往往會導致在后期還在不斷地調整，一整個就搞地非常地郁悶。       4)過程控制：控制整個過程，我的經驗是從控制各個時間點，必須把各個重要的時間點和產物定義地非常地清晰。目前主要定義的時間點和產物包括：需求確認完成階段--最終確認無誤的需求文檔（包括原型和相關的模板之類的），提交測試用例--評審后的測試用例，設計時間點--設計溝通（比較簡單）或設計文檔（比較復雜），開發、自測時間點--代碼、自測的結果Excel列表（根據項目的特點而定）、版本和變更說明，Beta測試--測試報告，發布。此外，目前的做法是每天花二十分鐘了解一下項目的進展情況，并一再跟項目團隊成員強調，一旦發現進度偏離，必須馬上反映。       5)變更控制：無止境的需求變更往往就是項目進度控制的掘墓人，剛開始最容易范的毛病就是，往往不加以評估就隨意地答應業務人員的需求變更�，F在的做法就是，發生需求變更時，進行仔細評估，是否會影響項目的進度，往往對一些無傷大雅的需求變更則大方答應，樂地做好人，但一旦發現對進度會產生影響，一般的做法就是，向業務人員建議，要么下個迭代處理，要么砍去目前已有的功能。經過這些溝通，往往

業務人員之后對業務的變更會更謹慎。   6)持續迭代：對于有些任務，會使用短周期、多次迭代的方式進行，在這種項目中，我碰到的最常見的問題就是，往往到下一個迭代開始之后，才開始下個迭代的準備工作（需求了解、設計及相關工作），而往往每個迭代周期的時間又非常地短暫，導致開發和測試時間不足而引發其他的問題。最近總結的結果就是，對這種短周期多次迭代的項目，開發測試和下個迭代的準備工作同步進行，確保在每個迭代開始之后，相關的工作已經就緒，當然，這是比較理想的情況，在迭代準備工作需要涉及外部配合的情況下，會有一定的障礙，不過，盡快地推動開始，相當于拉長了每個迭代的開發和測試周期，能最終為計劃騰出更多的緩沖的時間，同時也能更好地保證開發質量。       *關于質量       項目最終產物的質量將決定了整個項目的成敗的結果，因此，如果在項目的過程當中去保證質量致關重要，我的經驗總結是，       1)流程中的質量控制：控制各個點的質量，以保證最終的質量：一是需求質量--我一般都會跟相關參與溝通的人員一再地強調，謀定而后動，必須想清楚想明白點滴確認好，不要匆匆忙忙地動手，現在一般都會非常仔細地去了解需求，對不明確地需求要求業務人員確認，通過此輪準備，重要的失誤不會在最后才被發現；二是測試用例--要求所有的相關人員參與測試用例的評審；三是設計--設計完成之后必須進行溝通，不允許在沒有經過相關人員地確認就匆忙開始；四是開發和自測--盡量地提交測試Excel報告、TeamLeader對代碼進行CodeReview；五是Beta測試--提交測試報告。       2)人為因素的質量控制：首先，質量控制是基于準確的時間評估，因此必須在開始階段保證了時間評估的準確性，過緊的開發進度容易導致人的疲勞，人的疲勞又常常導致過多的錯誤，導致質量失控；其次，在團隊成員上，不斷灌輸質量的理念，讓他們了解到質量的重要性，并積極參與質量保障措施（譬如測試Excel報告）；最后，灌輸分清主次的觀念，要求他們在時間緊迫地情況下，保障重要功能重要問題的質量。       事實上說的這個過程會過于理想，在實際操作中往往有非常多的意外情況發生，這也是需要不斷地去提高這方面的技巧。       *團隊建設       如上的說明更多地是在規范和流程上去控制好整個團隊的工作，事實上，人的因素非常地重要，個人的主觀積極性和能力，往往能夠能大大提交團隊地開發效率，目前在團隊的建設上，我主要采用如下的措施：       1)培訓：工欲善其事,必先利其器，只有整個項目團隊成員能力的提高，最終才能推動整個團隊的素質的提高，因此在培訓上的投入可以說是非常地重要，在后續中，也必須繼續加強這方面的安排。       2)構建團隊和諧地氣氛：這一點感覺做地還是非常地不錯，整個團隊的氣氛比較輕松和活躍，基本上每個成員之間都能夠彼此相互幫助，并感受到在這個團隊中的快樂，積極做事，快樂工作。當然，該放松時放松，但該嚴肅時必須嚴肅，特別是在項目進度上，是絕對不能討價還價，實在不行就得加班，當然，在兄弟們加班時，一般都會與大家一起奮戰到最后。       3)鼓勵：每周例會，現在一般強調地最多的就是兩點，一是總結，要求團隊成員總結本周工作情況、提出個人想法，其實一般這種并非是需要了解他們的工作，而是鍛煉總結能力和口頭表達能力；二是自由發言，鼓勵他們提出自己的想法。目前這個方面做地還是遠遠不夠的，看來還得繼續加強啊。       關于團隊建設方面，現在能做的還是太少，看來接下來得多花點時間多思考這方面事情。         半年的時間是非常短暫，總結出來的東西還是很淺薄，路還很長，希望之后能夠更多地學好這方面的知識，以期做地更好 來源:http://blog.myspace.cn/index.cfm?fuseaction=blog.view&friendID=1306090849&blogID=402533140

【半年TeamLeader總結(轉) -半年工作總結】相關文章：

半年婚姻生活總結 -半年工作總結07-26

半年 總結 -半年工作總結（通用6篇）05-20

民兵工作半年總結 -半年工作總結10-25

半年工作總結09-12

半年工作總結06-11

眼科半年工作總結08-31

質檢半年工作總結08-19

廚師半年工作總結08-24

客服半年工作總結10-21

半年工作總結（熱門）10-29