成為一個小的管理者
成為一個小的管理者
對於入職場沒幾年的人來說，管理一個團隊的機會比較少，大多是會有一個老大來管理自己，但是管理的能力確實我們需要好好的學習。對於程式設計師來說，逐漸的一部分的精力會花費到管理上來，不管自己願不願，畢竟到了一定階段，我們都將會是一個獨擋一面的人，但一個專案不太可能只有自己一個人，如果管理，如何協調周圍的人，讓專案快速起來。下面是自己一些經歷和觀察到其他管理者的一點經歷。
一、分解任務，安排任務
專案會有許多功能，這些功能點之間的聯絡，如果進行關聯上，至少自己心裡有一個底。對一個團隊來說，需要每個人有不同的分工，不可能所有人一起上，需要一起協調配合，那麼最開始，如何分解任務就比較重要。舉一個後臺管理系統的專案。該專案一個OA系統，系統的功能是人員列表,考勤管理，工作事項等等。這些是一個功能點，然後接著根據需求文件和原型設計。
| 功能模組 | 小功能 | 時間安排 | 人員 |
|---|---|---|---|
| 人員列表 | 人員查詢列表 | 0.5天 | 小明 |
| 人員列表 | 人員錄入頁面 | 0.3天 | 小明 |
| 考勤管理 | 考勤顯示頁面 | 0.5天 | 小芳 |
| 考勤管理 | 考勤編輯 | 0.3天 | 小芳 |
上面僅僅做一個分解的過程，這種方式需要和小組成員一同交流，一起討論這個功能和功能完成的時間。這種形式將一個專案分解成很多小的任務，並且有任務的時間，這樣這個專案就有一個大概完成的時間點。具體如何安排，具體如何操作都可以一起討論。
一個專案通過分解後，就可以將具體的任務安排給其他人，這種方式也能具體到個人，每個人就可以朝同一個目標去前進。
二、協調工作和人員之間關係
協調工作和人員之間的關係，上訴分解任務之後，安排人員時，根據每個人的實際情況，安排具體的工作。開一個會討論討論，最後將其結果釋出出來。但是變化趕不上計劃，比如員工生病了，請了兩天假，本來可以完成的專案，可能就因此延期，這個時候，就安排一下，進度比較快的員工，協調一下接受一下生病員工的工作。
這次某個員工多做了工作，那麼在接下來的工作的時候，就可以少安排工作內容，或者安排一個學習新知識的任務等等，儘量做到相對公平。這個是需要自己對專案有一定的掌控能力，而不是讓專案失去了自己掌控。
協調人員的之間的關係，畢竟作為一個工作年限長一些的人，可以多組織一些活動，讓大家活動活動，吃個飯什麼的，這樣能夠促進員工之間的信任。儘量讓新人融入到新的環境中來，融入到這個小的環境中來。
可以安排大家一起攻堅一個新的技術，這樣可以一起去探討交流技術等等，或者是組織安排技術交流分享會，大家每週分享最近自己學習到新的知識。
協調自己與其他員工的關係，小的管理者暫還不屬於自己管理，畢竟自己也還從事月技術工作，但是會安排其他人員的任務，有一點點權力。有時候這種管理者和員工之間的關係就很特別，或者是不太會去交流。需要多做一些努力去了解他是一個什麼樣的人，比如是一個愛專研技術，那麼就可以聊聊技術，或者是將自己瞭解的新的技術分享給他。
三、程式碼檢查
一般大的公司在提交程式碼的時候，會進行程式碼審查，但是我所在的公司還沒有進行這樣操作。不進行這種操作，並不代表程式碼審查，檢查是不重要的，恰恰相反，如果作為一個對該專案的主導者，那麼需要理解現在的專案是怎樣的，需要大概的瞭解程式碼中的相關內容，有哪些合理的地方，哪些不合理的地方，並且將專案把控在一個合適的範圍內，不讓它失控。
程式碼檢查不是究細節，一般按照了一定開發規範開發後，那麼在不出大的偏差，就可以不需要修正。程式碼審查不僅需要去審查是否有錯誤，還需要去看這些程式碼是否符合規範，是否能夠有優化的地方。
四、解決問題
因為是管事的，下面的人可以任性一點，可以脫卸責任，可以說這個不會。但是作為一個小小的管理者，不能說這做不出來，還不能說原因。而是大部分事情，是需要找方法去解決問題。
作為專案的負責人，專案中所有的事情，都應該去解決。自己不能解決的，需要協調資源的，就需要申請，需要找資源。因為自己是專案的負責人。
當明白這一點之後，就需要思考和明白如何去解決問題。解決問題可以靠自己的經驗，但是很多時候是需要靠團隊的。
當一個複雜的問題出現時，需要一個團隊共同去攻堅。這個時候作為管事者，需要充當協調者，並且最後拍板。
如何解決問題，我觀察和自己一些體會：
- 擺正心態，大部分的問題總會有解決的方法，不能遇到問題，就將問題推卸掉。畢竟作為一個管事者，可能大部分的問題都會彙總到自己手上，自己不能找方法去解決，那麼這個問題就會堆積。
- 發動自己和同事的能動性，遇到問題，一起面對，共同解決。可以一起開會討論，將問題具體化，遇到的問題歸類，是屬於資源不夠導致，還是這個BUG團隊能力不夠導致等等。然後根據不同型別去找解決問題的方法。