背景介紹
- 當上開發經理不到半年時間。
- 團隊共5個人。
- 團隊主要負責混合雲相關的一款公有云產品的優化和維護。
身份的轉變
程序猿
- 如期完成開發經理安排的開發工作。
- 遇到一些解決不了的問題，可以說：完不成了，拋給開發經理。
- 對小組內的其它同事的工作可以不關心不過問。
開發經理
- 不再過多關心自己寫了多少漂亮代碼，完成了多麼優秀的一些事情；而是以整個團隊的整體輸出爲主要目標。
- 接到需求了，首要考慮的問題是：1.什麼時候完成。2.誰來完成比較合適（關於合適，考慮的維度會比較多）。而不是我要如何來做完這個事情。方向一定是：管理。
- 需要清楚團隊每個成員的性格以及工作能力，有針對性的安排任務。
- 需要保持比較合理的產品迭代進度，讓團隊成員覺得比較合適；也就是必須要有階段目標，而且是一直要有；誰沒事幹了，那就是你的責任。
- 時刻要有自己的想法，當前階段需要做什麼，未來應該做什麼；不要等領導或者產品經理提需求，然後纔去做，沒有需求的時候，團隊做什麼（這個可能得看團隊或者產品，暫時我沒有經歷過一直有需求的時候）。
- 上對部門領導，下對團隊成員，左對產品經理，右對測試人員，面對多種角色，溝通一定要到位。
- 團隊的每一件事情，都和你有關係，要對每一件事情負責。
開發過程管理
工作的安排
安排工作的一些基本內容：
- 以合適的迭代進度來安排任務，比如一週或者兩週；每個迭代都要有對應的里程碑，比如公有云產品的上線，小版本的升級，或者重大功能的完成，最好能有階段性總結。
- 每個任務都得有開始時間以及deadline，一定要具體到個人。
- 一件事情，我們的需求是什麼，現狀是什麼，目標是什麼，以及要達成這個目標的話，接下來可能需要關注哪些重點（這個視情況而定，有時間有必要的情況下，可以做一些說明），上面這些點，在安排任務的時候就得全部說清楚；或者其實是要求開發經理，要先想明白，否則根本無法落實。
- 不一定任何事情，開發經理都知道怎麼去做，沒有關係，只要說明白你想要什麼，並且這個目標是可實現的，然後讓同事去自由發揮就行了。
- 工作中肯定會處理一些需要相互協作（團隊內部的協作）的工作，所以一定要在安排的時候想清楚每個人負責的邊界，不能含糊不清。堅決不允許出現：本身被劃分得很細的一件事情同時由多人去做的情況。
安排工作中一些關於個人成長的內容：
- 知人善任，給什麼樣的人安排什麼樣的活，說起來挺簡單的，做起來不容易。
- 考慮這幾個因素：
- 個人能力屬於哪個層次------決定了安排什麼複雜程度的工作。
- 個人所喜歡做的事情以及不喜歡做的事情------安排做喜歡的事情當然很樂意，不喜歡做的事情難免有一些牴觸情緒（工作嘛，當然不是喜歡不喜歡，但得知道）。
- 個人較強的方面以及稍弱的方面------較強的方面，可以把一些緊急的任務安排下去，也能夠保證進度；稍弱的方面，就是你來負責提升的點，適當的時候應該給予機會去讓其鍛鍊和成長（前提是對方願意，這個從側面瞭解或者正面直接溝通就行了）。
- 個人對待工作的態度、做事情的方式------這個決定了工作中如何溝通吧，最難的一個吧。
- 安排工作的時候，一定要給同事留一定的發揮空間；把自己該做的做了，剩下的相信他們，讓他們去做。
- 有挑戰性的，或者無聊的搬運工作，相互兼顧着來吧。
- 適當的時候，安排一些超過個人能力本身的工作，其實就是把本來應該自己做的事情安排下去，比如一些設計或者調研工作；或者一些個人沒有做過的工作。
工作的跟進
工作安排出去了，那到底做得怎麼樣，什麼時候才能夠讓你看一下效果，什麼時候能夠開發完成，什麼時候測試就可以介入測試，能不能按照預期的做完，這些事情，你都必須要清楚。
簡單來講，你需要一個：任務看板。
任務看板的具體形式的話，根據情況而定吧，一般情況下，公司內部會有有關開發過程管理的工具，比如jira，或者更簡單的一些，就是excel表格了，最好能夠共享的那種。
不管是什麼樣的形式，一個任務看板中要能夠包含下述基本內容：
- 每一個迭代中所包含的所有任務。
- 每個人手中目前有多少個任務。
- 每個任務當前處於什麼樣的階段：未開始、開發中、開發完成自測中、測試介入等等。階段的話，主要是以你所關心的階段爲主。
- 最重要的一點：每個人要主動實時的更新任務的狀態；被迫更新的話，可能就只是單純的做一些面子工程了，也起不到開發過程的管理效果了。
但是實際上，小團隊的開發過程往往都是敏捷開發，而且加上小團隊本身的特點（人數少，迭代快，距離近交流方便），如果非得用任務看板來推進的話，可能會浪費一定時間而且效果也不少，距離這麼近，一句話就能說明白，還非得用看板？
可能對於一個事業部老大而已，幾十或者幾百人，那他們肯定只能看任務看板了，然後到了每個部門的話，有大概10-30人左右，對於部門經理，沒有辦法詳細跟進每個任務，那也只能看面板。但是到了每個開發小組的話，就那麼點人，再繼續用的話，可能就不是特別合適了。
所以一定要根據實際的情況，有針對性的使用一些過程管理工具來提高開發效率。
我這邊目前的一些做法就是：
- 使用jira來記錄跟蹤一些比較大的特徵。
- 使用協同文檔excel來細化每一個開發特徵，列出具體的開發任務、負責人、迭代結束的日期等。（目前我們這邊開發過程管理工具更多的是從產品層面來使用的，但是從開發角度來說的話，還差那麼點意思，比如可能要關注哪些方面，要重構哪些代碼等等，所以就用表格了，感覺更能滿足我的需求）
- 發現的bug，用Jira來記錄，這個可以上傳圖片、附件等，完成了打個關閉，然後自己去驗證，可以驗證通過或者不通過。
使用什麼樣的工具或者方式來進行開發過程的管理，不重要，重要的是我們保證開發任務的正常迭代，所以根據實際的情況找出合理的方式纔是最重要的，而且要不斷升級優化自己的管理迭代方式。
另一方面，跟同事說任務進度的時候，可能需要注意的點：
- 可以一次性安排很多任務，在不着急的情況下，可以讓他們自由安排，按照自己的想法去執行就行了。但是得說一個整體的截止日期，或者針對某個任務的截止日期。
- 一些任務變得緊急了，立即告訴同事，直接調整安排的進度。
- 一些任務眼看着要完不成了，要適當地說一些比較重要，必須完成之類的話，要想辦法促進任務的迭代速度，有一些適當的鼓勵措施，對個人，對團隊。
- 充分溝通之後，要是還是做不完的話，就得及時提前和相關人員溝通好延期問題。
工作的提交、測試
前面說到安排和跟進，完成了以後，那就要提交了。
- 需要一個清單，這個可能和開發任務或者特徵有所不同；這個清單是給產品和測試人員看的，所以更多的是功能清單，以及需要注意的點，影響的範圍，基本的測試方案。
- 用這個清單，和測試人員交流一次，然後去測試。
- 測試完全通過以後，讓測試把所有的測試用例整理出來，再過一波，看看有沒有遺漏的；然後用這份測試用例用於後面的迭代上線。
- 列一份上線流程，在預發、灰度等環境就直接使用此流程上線。
- 需要額外記錄一下在預發環境、灰度環境遇到的所有問題，徹底分析問題如何產生的，怎麼解決，以及如何在正式環境避免。
- 上線結束後，做一份上線總結，總結做的好的地方，進行鼓勵和表揚；但是對做的不好的地方，仍然需要指出來，責任自己先背了，但是怎麼處理以及後續避免的方式，讓相關的責任去完成。
其它方面
上面主要分享了身份轉變以及開發過程管理的一些感受吧，要說的話，還有其它的一些方面：
- 團隊工作氛圍的營造,工作方式的規範。
- 開發經理的持續成長。
- 如何成爲開發經理。
後面再分享吧，就先說這麼多。