回想2016年初，至今還誠惶誠恐。在那時，Android應用開發(fā)團隊還一團亂麻，時常有緊急問題發(fā)生，在那時，敏捷開發(fā)還在蹣跚學步。好在，一年過去了，我們也走出來了，沒有原地踏步。

1.如何學做管理

其實，我很不想用“管理”二字，但是用一個新的詞語，又未免增加了理解的成本。為什么不想用“管理”二字呢？因為，提到這個詞語，我總是會很膚淺的聯(lián)想到“流程”、“控制”、“績效”、“計劃”、”組織開會“這些工作。然而，我每天跟在團隊后面，不斷的督促他們完成任務就是管理了嗎？這件事情有意義嗎，我做這件事能產(chǎn)生多少價值？做這些事情有利于我個人的職業(yè)發(fā)展嗎？這些問題，在開始之初時常在我腦海中蕩漾，久久不能平靜。

回到原點，公司把我安排在這個位置上，最現(xiàn)實的，也是最基本的，是保障這個領域能高質高效的配合產(chǎn)品項目的研發(fā)工作。那么，還管他管理的定義是什么，帶領一幫人，達成這個目標，就是管理。是的，我就是這樣一個現(xiàn)實主義者。于是乎，所有的管理工作，都將圍繞著這個目標去探索，去開展。

在這項工作的開展過程中，有兩個人的話影響著我，其中包括：“你自己寫程序都能干得那么好，為什么人到你手下后，就不行了呢？“，”現(xiàn)在你們的管理知識，就和小學的數(shù)學水平一樣?！?，”管理是一門實踐的藝術。“，在此，不得不感謝這兩位導師，促進了我在這一領域的發(fā)展。個人的拙見，學做管理要重點關注以下三件事情：

1.培養(yǎng)你的團隊成員，目標就是讓他們和你一樣強，甚至比你還強。

有時，我們會擔心團隊成員變得比我都還強，那我的位置不是會被他取代？公司還要我干嘛？個人的拙見，這是一個偽命題，這里僅僅是目標讓他們變得更強，但是既然是你去培養(yǎng)他們，他們不可能全面超越你，你們各有所長。另外，作為一名管理者，應該有這樣的自信和胸懷，我們自身也在不斷學習，我們會走得更遠。只有他們都變強了，團隊才會變得更強，才能把事情做得更好，我們帶領團隊的價值才能有所體現(xiàn)。

2.加強管理知識的專業(yè)化學習，而不是閉門造車，自己摸索，多看書，看好書，多聽有經(jīng)驗人士的講座。

3.針對公司的特點，團隊的特點，不斷的嘗試、總結、調整你所學到的方式方法，在實踐中驗證和改進它，變成你自身的經(jīng)驗，深入骨髓。

這種機會難得，很多人沒有這樣的機會去學習管理。

2.如何做Android應用團隊管理

Android應用技術團隊，專業(yè)知識強，技術細分領域多，人員技術能力參差不齊。面對市場上紛繁眾多的機型，移動端讓人惱火的網(wǎng)絡復雜性，以及讓人惡心到爆的運營商，簡直是苦不堪言?？鄽w苦，事情還得做，而且還得做好，于是今年一年經(jīng)歷了以下三個階段：

• 第一階段：全面重構以前那讓人難以啟齒的代碼。
• 第二階段：配合永不停歇的敏捷開發(fā)，人員迅速激增。
• 第三階段：領域化劃分，基本走上正軌。

我對Android應用團隊的管理的觀念，也隨著這三個階段，不斷的演變和進化。在接手團隊之初，團隊人員僅有5人，那是程序代碼格外凌亂，耦合嚴重，連最基本的代碼合并都會經(jīng)常出問題，線上問題也是時常發(fā)生，而且是越演越烈的趨勢。由于我個人經(jīng)驗有限，當時也就只看到了這些問題，針對問題解決問題。并且當時有這樣的觀念，只要我把代碼整體重構了，保障代碼框架清晰易懂，解耦，Android應用團隊就會在框架的引導下越來越好?？上В义e了，我真的錯了！雖然，這樣做了后，在很大程度上改善了原有的問題，但是并不徹底。整個團隊開始暴露新的問題：

• 框架約束力不夠強，部分開發(fā)人員在執(zhí)行過程中有其形，無其實。
• 部分開發(fā)人員基礎知識不過關，框架可管不了這個。
• svn管理，jenkins編譯，gradle，maven等開發(fā)工具鏈問題不能得到較快、較好的解決。
• 團隊對某些領域的技術研究深度不夠，導致問題不能得到有效的解決。
• 敏捷迭代不斷，團隊成員忙于迭代，缺乏技術積累，人員工作分配不均，開發(fā)效率和質量得不到太好的控制。
• 人員不斷增多，但是卻不能較好的發(fā)揮他們的價值。
• 等等

就這樣，帶著這些問題，我走過了前兩個階段，直到到達第三階段，才有了質的改變。

總結以上問題，核心還是在于團隊能力線問題，所以提高團隊能力線，才是以上問題的正解。到這里，正如“如何學做管理”中所說，這個問題要通過培養(yǎng)團隊成員來解決，那么問題來了，怎么樣培養(yǎng)團隊成員呢？我們的Android應用開發(fā)團隊是一個年輕的團隊，一些知識體系都還有待完善和建設，作為團隊負責人，我有責任和義務給團隊成員指明未來的方向。因此，作為培養(yǎng)的第一步，先明確我們團隊需要些什么，他們要做些什么，現(xiàn)在能做些什么？我們先來第一步，組織構建：

組織構建

控制組織大小，4到6人為一個小組織。

我們團隊有20人，一個20人的團隊，任何思想的傳達效率都會比較低，協(xié)作成本高，根據(jù)我個人的開發(fā)經(jīng)驗，4到6人的團隊溝通成本低（隨便找個空地就能開聊），利于互幫互助。

明確各個小組織的領域范疇和責任。

這個點需要一定的技術背景才能操作，我將Android應用領域拆分為8個領域，包括數(shù)據(jù)與系統(tǒng)對接、網(wǎng)絡與性能、界面與國際化、H5與工具鏈，每個小組織負責2兩個領域的持續(xù)跟進研究，以及沉淀。

人員責任包括領域研究和產(chǎn)品開發(fā)。

對于人員的要求，所有應用開發(fā)人員同樣需要負責模塊功能的開發(fā)，同時要兼顧領域研究，讓所有人員既有產(chǎn)品觀，全局觀（了解應用開發(fā)需要的所有技術），同時又有自己的核心領域，做到廣而精。

這樣才劃分帶來了很多的好處，各個領域的獨立，降低了團隊成員的心智負擔（操心的事情多），每個人都能一門心思的研究自己的領域，遇到非自己領域問題搞不定時，團隊里總能找到能提供幫助的人（有所依靠，哈哈）。一個小組織的成立，我們還可以做弱結對編程、代碼審查。因為他們的領域相同，知識體系一樣，很容易做到這件事，溝通交流更順心。

另外，附加的收益，由于領域的獨立，緊接著領域的沉淀也逐步加強，各種設計文檔也很自然的產(chǎn)生（開發(fā)人員不是天生都不喜歡寫文檔，而是不愿意寫沒有意義的文檔），未來新成員培訓也是很有希望做到的。這些好像和團隊成員培養(yǎng)沒關系？嗯，是的，沒有直接關系，但是他們是我進行團隊培養(yǎng)的基礎，是成員成長必不可少的環(huán)境，沒有這樣的設定，團隊培養(yǎng)很難落地執(zhí)行，接下來開始團隊培養(yǎng)：

團隊培養(yǎng)

識別團隊中的核心成員，給他們合適的權力和責任。

想想，一個班里面，除了老師還有班委。為什么呢？層級太多不是也不怎么好么？如果我能同時兼顧20人的所有細節(jié)工作，自然不想再構建新的層級。當我們的關注的事務細化到一個層面后，那么精力就不夠了，作為領域團隊層面，我們的關注點要細化到代碼設計甚至編碼級別，一個人能搞定嗎？至少我搞不定！那么這和培養(yǎng)有什么關系呢？我對培養(yǎng)的定義不僅僅是指導，還包括培養(yǎng)環(huán)境的構建。所以這里做的目的主要有兩個。第一，給他們更大的發(fā)揮空間，發(fā)揮更多的價值（構建帶領一個小領域開發(fā)的學習環(huán)境，現(xiàn)在的開發(fā)已經(jīng)很少能單兵作戰(zhàn)了），第二，讓他們帶我傳遞我的思想和理念，小團隊傳遞效率更高，深度更深。

各領域持續(xù)指導和跟進。

各領域成立后，我的精力主要放在和他們溝通上，讓他們明白程序應該怎么設計，這個領域需要做哪些事情，應該怎么做，成員如何組織等，反復不斷的溝通、總結、改善，持續(xù)的做下去，直到我覺得我們大家的思想是一致的，方式方法沒有問題（當然，如果我錯了，那么問題就大了，我得保證我沒有搞錯，或者錯了及時改正），這樣他們才能有效的指導他們領域的成員，帶領他們前進。

領域拉通，成員能力挖掘，查漏補缺。

各小領域成立后，并不代表我就可以做甩手掌柜，除了各領域的培養(yǎng)以外，我還需要拉通各個小領域，促使他們有效的協(xié)作，降低他們之間的耦合，減少跨領域的成本。同時，還需要持續(xù)不斷的關注團隊成員的學習進展，給與他們合適的建議，以及符合他當前能力的工作，針對有潛力的成員重點指導，針對有問題的成員及時告訴他的問題，促使他改善。

關注新技術，加強自身對技術的學習，帶著團隊向前走。

細節(jié)有很多，這里談到了主要方面，個人總結能力還是有限啊，主要只想說一點：核心是為了產(chǎn)品的研發(fā)，開展基于培養(yǎng)提升團隊成員能力，形成自組織，流程、規(guī)范、考核均是輔助措施，能無就無，謹慎對待。

3.如何做敏捷項目管理

敏捷團隊是一個全功能團隊，里面包含了各個領域的成員，由于公司原本組織架構的一些特點，我們并沒有像標準敏捷項目團隊那樣，有產(chǎn)品經(jīng)理、敏捷教練等職務，與之對應的是規(guī)劃與交互，項目負責人。雖然“形”對不上，但是如果能對上“神”，也是不錯的。

在敏捷之初，我們并沒有理解什么叫迭代，我們傻乎乎的定迭代周期為一周，而且還覺得自己在走敏捷的迭代?？上覀兡遣皇堑?，我們只是每周計劃一下需要開發(fā)的工作而已，僅此而已。因而帶來了很多問題，前端需求人員不知道功能的開發(fā)預期和進展，項目負責人也就是協(xié)調協(xié)調資源，面對紛繁復雜的功能項開發(fā)，也不太情況每個功能的開發(fā)進展，當前是否正常（除非非常不正常才能發(fā)現(xiàn)）。整個項目組感覺都忙忙碌碌，但是卻不知道大家都做了些什么？每天晨會大家說的事情都有點不知所云，感覺晨會都快沒有實際意義了。問題太多，以至于我們有點迷失方向。

敏捷，宣稱要擁抱變化，我們卻粗淺的理解為不需要計劃，是不是很白癡。我個人現(xiàn)在對擁抱變化的理解為：“及時交付可體驗的產(chǎn)品，隨時做好調整的準備，日常的工作任務安排，如果發(fā)現(xiàn)不合符預期，需要及時調整，重新評估新的任務，而不是掩耳盜鈴，覺得不列一個新任務就會快一點”。好了，臨近年底，對于敏捷總算有所頓悟，多虧了《敏捷估算和規(guī)劃》這本書，給予了我很多啟發(fā)。接下來，談談具體的一些實施細節(jié)。

由于我們?yōu)榱吮Ｕ习姹镜陌磿r發(fā)布，我們采用了版本火車的形式，所以，我們每個發(fā)布版本并沒有很強的計劃（目前還在糾結改善的地方），而常規(guī)的敏捷一般包括三個維度的計劃工作，最高維度為版本計劃，其次而迭代計劃，再次為工作任務。所以，針對我們現(xiàn)有的特點，本文僅討論到迭代計劃及其以下維度層面。那么如何做迭代計劃呢？我個人覺得一定要遵循以下原則：

迭代的目標是交付可體驗的產(chǎn)品，不是完成任務。

所以，迭代計劃里面只能是用戶故事及需求，而不是某某人的任務，另外迭代并不是完成開發(fā)，還包括視覺、測試的工作。

迭代的周期要合理。

針對不同的產(chǎn)品特點，迭代周期一般為2到4周，如果周期過短，就需要把用戶故事的粒度拆分到足夠?。ú皇侨魏萎a(chǎn)品都能拆到如此小的粒度），因為我們要在一個迭代周期完成開發(fā)、視覺、測試的工作，針對我們的產(chǎn)品特性，我們最終改為3周一次迭代。此外，過短的迭代周期，會議也會增加不少呢，還有一些別的非研發(fā)工作損耗。

評估故事點。

從長遠考慮，評估故事點有利于團隊知道自己的速度，如果哪天上版本計劃，有了這項基本數(shù)據(jù)，能更好，更快，更準確的評估版本開發(fā)時間。

故事點是對規(guī)模的評估，不是時間的評估。

評估故事點需要一定的技巧，我選擇10個用戶故事，里面包含各種難度的需求，然后給0.1、1、2、3、5、8、13、20、40、100，然后讓他們根據(jù)這些用戶故事的工作量（包含開發(fā)、時間、測試的工作量），然后給這些故事分配對應的值，值得重點說明的是0.1和100，在《敏捷估算和規(guī)劃》一書中采用了0，代表那些基本可以忽略工作量的故事，避免因個別故事太小導致影響后面的相對值，里面重點說到10個0不等于0，因此我干脆改為0.1，更容易體現(xiàn)出10個0.1是有工作量的，至于100嘛，僅僅是為了標記當前故事無法評估，其實目前我們20和40也沒有用到，過大的用戶故事不利于跟進。

有了這些以后，還有一些問題會困擾我們，一個迭代安排多少用戶故事，每日晨會如何開展？迭代發(fā)布會，迭代計劃會，故事點評審會這些會議怎么組織，在什么時候組織？我們怎么能準確評估一個迭代的工作量，某個領域任務過多怎么辦？啊呀，問題實在是太多了，真是人越多問題越多，我們的敏捷團隊有20人，20真的和我有緣啊，同時管理兩種類型，兩個20人的團隊也是一種挑戰(zhàn)！目前潛意識認為20人的敏捷團隊過大，還沒有想到太好的拆分計劃，還需要不斷的總結分析想辦法。

上面的問題我就不都解答了，只是想說明敏捷并不是幾項簡單的流程，它是一個系統(tǒng)化的解決方案，里面有很多細節(jié)，就像我們寫軟件，設計交互一樣。現(xiàn)在回想以前自己做軟件時，對項目管理人的哪些膚淺的認識真是慚愧。接下來我要重點說明一下在迭代計劃下的任務拆分，當我們計劃好本次迭代需要完成的用戶故事時，下一步任務就是需要將用戶故事拆分成實際領域的工作任務，這種任務我們簡直是太熟悉了，例如：完成界面編碼。那么在做任務拆分時，有哪些需要遵循的原則呢？

任務需要拆分到1到16小時的工作量。

控制任務的粒度，有利于更快的得到任務的進展和反饋。

告訴團隊成員，盡量評估準確任務工作量，但是我們允許任務評估不準確，并且我們也認為任務不可能評估那么準確。

拆分任務的目的不是為了評估某個人的工作量和效率，主要目的是基于任務得到反饋，團隊事務透明，以及便于拉通各個領域協(xié)作。

當發(fā)現(xiàn)任務評估不準確時，及時調整任務時間，或者將原有的任務重新拆分為新的任務，或者新的幾個任務。

我們要客觀的承認任務的難度，這樣有利于團隊成員更積極的拆解任務，更真實的評估任務時間，讓整個團隊得到最真實的反饋。

根據(jù)任務計算各領域工時，發(fā)現(xiàn)迭代瓶頸。

當所有的故事都拆解成各個領域的任務時，我們可以很輕易的發(fā)現(xiàn)瓶頸出下哪個領域，并及時作出對應的調整。

根據(jù)剩余的總工時量，繪制迭代耗散圖。

每日晨會根據(jù)看板的任務流動情況，更新迭代耗散圖，讓團隊成員了解到迭代進展和速度。

不要量化團隊成員的個人速度，更多的基于團隊去考核和引導。

不要通過量化團隊成員的速度來對團隊成員進行考核，這樣很容易引起團隊成員各自為政，并且各種評估不合理，我們需要通過其他手段進行成員評估，引導大家基于團隊目標進行行動，共同承擔責任。

當我們任務拆解已經(jīng)完成后，接下來就是每日晨會了，開晨會一般是聊昨天做了什么，遇到什么問題，今天要干什么。在沒有做這些計劃之前，我覺得早上說這三件事很無趣，很無意義。但是，當我們的迭代這樣進行后，說這三件事就很自然了。

昨天做了什么？

用于驅動看板上在doing中的任務，是否要挪動到done中。

遇到什么問題？

根據(jù)對應任務遇到的具體問題，促使團隊成員了解具體的情況，進行交流。

今天要做什么？

用于驅動看板上在todo中的任務，是否要挪動到doing中。

有了這些細粒度的工作任務，晨會就這樣開就可以了，由于晨會流程的標準化，我們可以任意安排團隊成員主持晨會，好開心！我可以從這件事中解脫出來，在晨會中更專注的關注項目的進展。在任務安排中，同一個人盡量要控制doing中的任務不超過2項，否則不太好及時得到反饋和跟進。這樣的晨會，我能很及時的發(fā)現(xiàn)項目中的異常點，及時評估和協(xié)調，當我告訴測試你們資源不夠時，再也不是那么蒼白無力，測試也會很悻然的接受我的建議。

4.總結

本年度參加部門的例會，部長的三句話目前印象深刻。

三角形最穩(wěn)定。

剛開始聽到這句話基本上是左耳朵進，右耳朵出，沒有太多的感觸。直到我將Android應用開發(fā)團隊劃分為四個小領域團隊后，才有所領悟。是的，多方關聯(lián)的組織相對于一家獨大的情況確實更加的穩(wěn)定可靠，也許物極必反也是這個道理。

提升團隊能力線。

這句話給了我信心，讓我確信當前做的事方向是正確的，作為一個團隊管理者，這一點一定要做到。

我們談原則。

這句話給了我信心以及指導，漸漸我的也潛移默化的給團隊成員談原則，談思想，談未來。讓我們的思想在同一戰(zhàn)線上，路才不會走偏，才能放心的把一些事情徹底的交手出去。

很感謝部門對我的信任，對于我這樣一個管理的新人，授權我去嘗試這么多的事情，給我成長的環(huán)境。2017年且行且珍惜，盡量少挖坑，帶領團隊走得更遠。

本文由 @空穴來風 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。