http://www.infoq.com/cn/articles/tencent-team
InfoQ：永亮您好，謝謝您接受訪問，可以請先和大家做一個簡短的自我介紹。
Aland：艾永亮(Aland Ai)，騰訊公司敏捷教練&高級項目經理，曾參與QQ農牧場，Qzone商城，SOSO，無線應用、網絡遊戲等業務的項目管理與教練工作。曾任著名敏捷諮詢公司ThoughtWorks資深敏捷顧問。可通過騰訊微博、新浪微博與他交流。
InfoQ：很高興在上海 Scrum Gathering 中看到你的分享，當中有些還是騰訊公司的創新實踐，可以先介紹一下 “自運轉團隊” 是如何的概念？跟一般自我管理團隊 (Self-managing team) 有什麼分別？
Aland：實際上“自運轉團隊”也可以稱作“準自組織團隊”，他是通向“自組織團隊”的中間階段。 “自運轉”是通過一系列預定義的流程來將團隊成員串聯起來，但它在我們通常定義的工作流程上加上了三項重要內容：1. 當前環節負責人要對其工作的進度和質量負責；2. 當前環節負責人要跟進上一環節負責人的交付時間和質量； 3. 當前環節負責人要推動下一環節負責人的工作儘快開展。這樣在單純的事務流程上加入了“人”的內容，任何一個環節都有 “當前”、“上游”、“下游” 三名團隊成員關注和推進（始末端均爲項目經理），這就在讓團隊成員通過流程連接在一起，使得大家不只關心自己手頭的工作，還需要關心上下游的工作，團隊推動遠勝於項目經理一人推動。
然而，“自運轉團隊”卻缺乏“自組織團隊”的自我管理，持續改進的內容，因爲它的任務計劃和分工還是有PM統一規劃的。不過雖然它與“自組織團隊”還有一定距離，但是由於團隊成員彼此緊密聯繫，相互關注，這將促使團隊向自管理的方向發展。因此我們認爲這是通往“自組織”的一箇中間階段，同時由於它更容易實現，因此它實際提供了一個向“自組織”轉型的切實可行的方法。
InfoQ：可以介紹一下 ”自運轉團隊” 是公司在什麼背景下想出來的？
Aland：它出現原因其實很自然，指令型團隊讓所有人都很痛苦，自組織又難於實現，所以纔有了“自運轉團隊”。大家都知道騰訊爲了適應互聯網的快速變化和滿足用戶的需求，產品發佈速度都非常快，這使得大家壓力都很大，在這種情況下多數項目經理都會想方設法提升效率，一個很自然的想法是讓每個角色都能更加專心在自己的工作上，全力提升自己的效率，而由項目經理承擔起來大量溝通和推進的工作。這種情況下，每個人確實更專注了，團隊都在項目經理的指令下工作，但是大家卻忽視了團隊其他成員的工作，再加上缺乏充分的直接溝通，在配合中就產生了大量問題，比如實現偏差、接口不一致等。經過一段時間，問題頻發，大家感覺更累了，這時作爲敏捷教練的我們自然會建議轉換團隊管理方式，但是要打破大家的工作習慣，特別是已有很久的思維模式，是件非常困難的事，因此我們就嘗試先借助一些工具讓大家的工作透明出來，適度增加成員之間工作聯繫，經過一段時候的摸索和嘗試，找了利用流程和責任來驅動工作進展的方法，也就是“自運轉團隊”。
InfoQ：在敏捷宣言背後的原則當中提到 “最好的架構、需求和設計出自自組織團隊。”，在你們實踐中，”自運轉團隊” 又如何做出最好的架構、需求和設計呢？
Aland：是的，這一點“自運轉團隊”做的也還不錯。由於大家的工作聯繫，在“自運轉”過程中不斷加強，彼此之間越來越緊密，客觀上使得大家會越來越關注相關成員的工作質量，因此開發人員會主動幫助產品經理完善需求細節，測試人員也會從用戶使用的角度提出優化建議，架構設計也會在開發經理的帶領下組織大家經常性的討論、評審、優化，同時每個迭代我們都會固定的安排一些技術需求，以避免技術債務的累積。不僅如此每個人對團隊問題也會越來越警覺（這一點有點貼近自組織了，呵呵），有一次，素材多次出現問題，產品經理就主動拉開發同學討論解決方案，最後決定由開發同學寫一個檢查工具，其間項目經理都沒有參加。
InfoQ：在 ”自運轉團隊” 中，迭代的工作估計、任務分拆、申領任務是如何進行呢？
Aland：迭代的工作估計是由團隊在IPM上集體評估的，但是由於受制於各個成員所熟悉的領域不同，所以只能做到由部分成員估計，但至少不是一個人估計。任務拆分也由相關產品、開發、測試一起討論決定的。任務認領不會那麼自組織，主要是由項目經理安排，不過這裏也會充分考慮每個成員的興趣和意願。
InfoQ：在 ”自運轉團隊” 中，迭代結束的回顧會議會不會有什麼不同呢？會按照職能分別作回顧還是按團隊或是按項目作回顧呢？
Aland：回顧會議並沒有什麼不同，因爲自運轉團隊也必須要是一個完整的特性團隊，至少要包括產品、開發、測試等成員，這樣才能自己“運轉”的起來，因此回顧會議上也會要求所有成員都參與，共同爲團隊改進出謀劃策。
InfoQ：在 Tencent，回顧會議的頻度和形式是如何的呢？
Aland：騰訊的Retro一般會安排在重要版本發佈之後，有時也會選擇一些關鍵迭代結束的時候。形式上主要採用的是WELL/LESS WELL的經典方式進行。
InfoQ：在 ”自運轉團隊” 中，Scrum Master 角式會有不一樣嘛？
Aland：自運轉團隊中，Scrum Master實際由項目經理擔任，由於團隊成員尚未達到自組織，因此項目經理除了承擔原有Scrum Master的工作之外，還需要承擔更多的工作，比如迭代計劃、發佈計劃、組織發佈等。
InfoQ：項目經理職能和責任在敏捷轉形中有什麼變化？
Aland：關於項目經理的角色的職責，我們一直在不斷探索，過去項目經理更多是負責計劃、跟進、溝通等以過程爲主的工作，現在公司對項目經理提出了更多的要求，特別是在產品方面，要求項目經理不只能管好過程，更要爲產品交付負責，要能組織團隊保質保量的完成特性開發，而且還要在過程中平衡業務需求與技術需求的優先級，不能盲目的趕進度趕需求，做最有價值的事和控制節奏都很重要。
InfoQ：如果讓你從新作團隊組織安排的話，你認爲會不會有什麼不同的地方呢？還有，有沒有打算讓團隊朝向更自我組織的想法和計劃呢？會是如何做法呢？
Aland：一定會往自組織的方向繼續發展的，而且我相信這是團隊自身發展的必然結果，因爲團隊一旦步入正軌，只要方向保持不變（這個需要項目經理堅持把控），團隊的自組織性會自然產生，但是這有一個前提，團隊和業務要相對穩定。
除此之外，還要不斷加強團隊的產品意識建設，讓團隊所有成員都能持續關注做最有價值的特性，從用戶的角度不斷優化產品功能和體驗。不但要建設優秀的團隊，更要產出優秀的產品。
InfoQ：對於成立組織團隊方面，有沒有什麼心得能分享給讀者呢？
Aland：我之前總結過一個《建設融洽主動的項目團隊》的心得，在公司內部做過幾次分享，主要是談從“融洽”和“主動”兩個方面來建設團隊，內容比較多，其中有一點是大家感到比較有啓發的。團隊內部角色之間有些許矛盾是難免的，比如產品同學對需求如果考慮不周，開發同學就有可能產生抱怨，這時很多團隊採用的方法是加強評審環節。但是這樣並不能完全解決問題，原因有兩個，一是評審費時費力，二是評審也不能查出所有問題，開發過程中還會遇到問題。我認爲這不是根本的解決之道，因爲人非聖賢，總有考慮不到的時候，評審就像壁壘一樣只能屏蔽一部分問題，然而如果一個優秀的團隊是可以讓這些問題變得不是問題。我向大家推薦的辦法其實很簡單，就是“相互幫助”，我會去和開發同學解釋產品同學的難處與侷限性，請他作爲夥伴幫助他，如果有考慮不到的地方和產品同學一起來解決，這樣開發同學對產品同學的看法就發生180°的逆轉，對不周不再認爲是問題，而是想辦法幫助他，這樣產品同學就在開發同學的幫助下不斷進步，他們兩個的關係也會越來越好。這是也是一個化解團隊矛盾的技巧。
InfoQ：非常感謝Aland能接受我們的採訪，謝謝您。
另外，筆者亦希望在此感謝 Odd-e 公司的呂毅和滕振宇在問題設計上提供協助