一個程序員初試管理的一年多

時間 2019-11-05

原文原文鏈接

去年七月份離開了上一家公司，在那裏度過了對我職業生涯來講相當重要的4年。期間遇到了不少給我巨大幫助的朋友，我感受除了技術的提高，心智上也獲得了成長，也從最初的一枚菜鳥慢慢成爲可以獨當一面的團隊骨幹。在後期也開始接觸一點點管理，主要是帶新人。由於難度不大，並無什麼積累，更談不上什麼管理經驗。來到如今的公司以後，纔開始正式接觸管理，一年多的時間裏遇到了各類各樣的情況，也解決了形形色色的問題。主要想從我我的的角度出發，記錄一下本身在這一年多的時間裏的一些感悟。前端

1、轉換角色

由於確實沒有什麼管理經驗，入職後我給本身提了個要求：堅持不按期地和老大主動溝通。有一次和老大面談時，他問了個問題：爲何感受大家團隊只有你本身總加班，其餘人並無那麼忙？我才突然意識到本身這個問題。不得不認可本身當時仍然停留在團隊骨幹的階段，分析了一下緣由，主要有兩個：nginx

緣由一：對團隊不足夠了解，不足夠了解就很難充分信任。
當有一個需求時候，尤爲是較爲緊急和複雜的需求，心裏會糾結：交給他會不會有問題？他能不能按時搞定？我本身作是否是更有把握？這種糾結一旦出現，最終結果每每是：算了，仍是我本身來吧。在公司的起航培訓時，老師說這種現象在剛開始接觸管理的人羣中很是廣泛，它的後果也很明顯：本身累，同時也剝奪了他人成長的機會。我後來通過一段時間思考後，採起的解決辦法是對任務拆分，既然以爲整塊交出去有風險，那就經過拆分來分解風險。隨着對團隊的熟悉和團隊成員的自身成長，拆分的粒度慢慢放大，直至每一個人都能獨立負責一整塊需求。如今團隊的每一個妹子基本上也都達到了這個要求。面試

緣由二：很差意思給他人分派工做。
在團隊成員手裏有需求的時候個人這種表現尤其明顯，後來我分析了一下，徹底是一種不自信的表現。其實，只要把需求排期控制好，即使是有需求重疊，咱們經過均衡每一個人的任務隊列，正常分配便可。若是仍然有疑慮，能夠經過不按期溝通來確保任務的進度。數據庫

把自身定位思考清楚自己就是一件很難的事，想要及時的感知變化更加困難，但旁觀者清，身邊的同事絕對是咱們最好的幫手。及時收集反饋，很是有利於咱們自身的改善。後端

2、完成需求 `VS` 把事作成

這二者的區別仍是很是大的，尤爲是通過這一年多的時間，感受越發明顯。緩存

完成需求，是從一個開發者的視角來看，對本身最基本的考覈標準，也是整個的開發過程（需求討論、開發、測試、上線）中的其中一環。cookie

把事作成，則要求跳出開發者的角色限制，從整個需求層面有一個宏觀的把控，而不該該把視野侷限在本身僅僅是一個前端或者後端開發者的身份。數據結構

記得年初作主站前端重構，這徹底是一個技術自發的需求。我當時做爲需求發起人，保證前端重構開發的完成是我最基本的工做，同時還須要申請產品資源做爲業務支持，協調後端對模板變動，以及申請測試資源確保上線前的質量，甚至於包括後期灰度計劃的制定和推動。在這個過程當中，深入地體會到了owner的含義，當你把目標集中在如何把事情作成的時候，中間每一個環節都是你要負責的部分，這比單純的完成需求難度要大不少。另一方面，當想着把事情作成的時候，中間的過程是否要嚴格按照流程就顯得沒那麼重要了，好比申請產品資源受阻時會立馬調整策略：自行梳理問題後找產品確認，無需產品同事的全程參與。還有很是大的一點感悟：在大公司環境下，你們互爲資源，若是想把事情作成，協調能力是很是重要的一項技能。學習

上面的例子是技術發起的需求，其實對於平常的產品需求，也能夠試着打破對本身身份的限定。在整個過程當中，只要發現有任何不合理或者值得改進的地方，做爲參與其中的一份子，都應該及時發聲，提出本身建設性的意見，好比這個需求點是否符合用戶預期，接口這樣設計是否便於之後擴展，返回的數據結構是否能夠整合等等。你們都本着把事情作成的態度，對於這樣的參與熱情，相信不會有人忍心澆涼水。測試

3、必定要作時間管理

隨着負責的事情愈來愈多，天天戴上耳機安心敲代碼已成爲奢求，總會被各類排期、需求評審、技術方案討論打斷。曾經有一段時間，感受整我的都有一種撕扯感，被折磨的焦頭爛額，但一天下來又感受什麼都沒幹，尤爲是這一天沒怎麼寫代碼的時候，焦慮倍增。痛定思痛，感受本身的時間管理應該是重點思考的事情了。結合之前的工做方法，我作了一些整合，以周爲單位，把天天的事情經過表格的形式羅列出來，包括具體實施時遇到的問題等，具體如圖所示：

慢慢的我發現本身已經成爲了筆記的重度依賴者，固然，這沒什麼很差，好記性不如爛筆頭嘛。一個很是大的好處就是，這每一週的記錄都是階段性總結最好的素材。不過，利用筆記最大的收益仍是作到了對事情有規劃，這一點很是重要，不管生活仍是工做。

還想說的一點，當開始接觸管理以後，可能代碼的輸出再也不是衡量工做的惟一標準了，因此，有時候一天都在參加會議或者培訓，只要這些事情在規劃之列，那就無需糾結，按計劃執行便可。

4、技術仍然是安身立命的根本

每一個作技術的人應該都聽過這句話，說白了就是告訴咱們：必定要把本身吃飯的硬實力整上去。

看成爲團隊主力時，提高技術才能保證咱們高質量地完成需求，同時也能給身邊的人提供一些技術支持。做爲團隊負責人的時候，除了給本身的團隊成員提供技術支持以外，還要爲團隊提供技術方向的引導，以及對團隊的技術水平負責，另外，團隊的技術氛圍也很大程度上取決於團隊負責人的技術水平。

能夠說，雖然咱們處於不一樣階段時，技術對咱們的做用不一樣，但從咱們自身的價值來講，技術始終是第一位的。

基於個人觀察和經歷，我以爲：對於技術領域的管理，技術好不必定能作好管理，但技術差必定作很差管理。

技術領域的管理仍是很是須要硬實力支撐的，正所謂「一將無能，累死三軍」。因此，目前爲止，我仍是要求本身必定要堅守技術，極力避免出現吃老本的不堪境遇。

概括一下，這裏主要是想闡述：接觸管理以後並不意味着技術相比於管理經驗再也不重要，相反，管理崗位對技術的要求更高了，咱們應該始終堅守技術帶領團隊成長。

5、持續學習

上面說了硬實力的重要性，其實除了在本身的專業領域持續學習打造硬實力以外，還應該適當擴大本身的技術視野。

技術領域有那麼的多方向，我應該學哪些？學到什麼程度？這些問題曾一度困擾着我，不過，後來我思考了一段時間以後，給本身定了個準則：凡是本身工做中接觸到的但還不瞭解的，都應該在學習範圍以內，至於掌握程度，取決於和本身專業的密切程度。

前端開發平常接觸最多的就是後端了，其中涉及到接口的設計、數據庫的存儲邏輯、後端緩存的原理、nginx的原理和配置等等。若是掌握了這些，對於咱們制定和評判技術方案有很是大的優點。舉例來講，網站用戶登陸態是個很是常見的問題，但我發現有不少同窗對維護登陸態的原理不很清楚，對先後端的邊界有點模糊，以致於出現先後端都要維護cookie的現象。再好比，若是咱們掌握了nginx的基本配置，徹底能夠在本地模擬線上域名，對於一些和域名相關的自測在本地就能搞定。

曾經和一個面試官討論過爲何如今的前端崗位或多或少都要求一點後端的技能或經驗，他給出的觀點是，這樣的同窗面對整個系統時看到的層次更深，我對此深表贊同。

另外，測試領域的一些思想和方法也很是值得咱們學習。咱們的自測不少時候都是跑通就行，其實咱們提測前用測試的思惟思考下，可以規避掉不少問題，好比說場景法測試、邊界值測試等。

除了學習後端和測試領域的一些技能外，學習一些與人打交道的軟技能也很是必要，好比溝通、協做以及尋求資源。軟技能的學習要比技術的學習更復雜一些，沒有統一的標準，每一個人的風格又不同，因此更多的須要咱們本身去多總結。我以爲軟技能的惟一衡量標準：是否有效。因此，無需過多糾結於細節，有了想法就去驗證，而後再根據反饋的結果及時修正，這樣就能快速創建起本身的一套軟技能體系。

至今還記得之前的老大曾說過的一句話，大意是：在學習方面，如今的投入未必會立馬收效，但在未來的某一天終將受益。