讀書筆記 - 朱贇的技術管理課

讀書給我力量，有些書籍給你第一眼的感受就是：愛了；第二眼的感受就是：買了；第三眼的感受就是：讀完了、舒服了。

本文爲 《朱贇的技術管理課》 讀書筆記。

jsliang 沒當過管理者，因此文中相關心得，皆爲我的粗鄙看法，不構成價值參考，也不構成購買建議。

一 目錄

不折騰的前端，和鹹魚有什麼區別

目錄
一 目錄
二 前言
三 精彩語錄摘抄
四 新人成長
4.1 新人成長：個人成長
4.2 新人成長：管理技巧
4.3 新人成長：個人思考
五 項目開發
5.1 項目開發：工做分配
5.2 項目開發：受權
5.3 項目開發：A/B 測試
5.4 項目開發：Code Review
5.5 項目開發：項目延期
5.6 項目開發：項目 Bug
六 團隊管理
6.1 團隊管理：團隊成員
6.2 團隊管理：晉升
6.3 團隊管理：建議和意見
6.4 團隊管理：一對一溝通
6.5 團隊管理：指望與被指望
6.6 團隊管理：職場規劃
七 其餘
7.1 其餘：說 「不」 的技巧
7.2 其餘：後續日子的思考
八 總結

二 前言

人總要成長，總要走出本身的溫馨區，變幻無窮的前端行業尤爲適合這句話，除非你肯定將來日子能當一枚千篇一概的複製粘貼工程師，不然你就要面臨各式各樣的挑戰。

摘抄下 jsliang 的工做筆記目錄：

• Node 經常使用工具庫（時間處理、Markdown 轉 Word、正則表達式）
• 自動化測試（Jest、Puppeteer）
• Git
• Charles
• ……

固然技術是折騰不完的。

世事總在變化，你總要挑戰本身極限，這篇文章就是講挑戰自個人其中一條道路：技術管理。

這僅僅是零散的觀點彙總，貼近 jsliang 「私有化」，不構成參考建議，但願對你有所幫助

三 精彩語錄摘抄

在觀看書籍的過程當中，jsliang 摘抄了一些以爲很是不錯的語錄：

• 《04 | 如何幫助團隊成員成長》一個技術管理者的成功並不在於本身代碼多好、能力多強，他的成功必定創建在團隊成功的基礎之上。只有團隊成員不斷成長，這個團隊才能夠作成更大的事情，而你才能夠在團隊的基礎上，站得更高、看得更遠。
• 《05 | 當咱們給別人提意見時，要注意些什麼？》因此在工做中適當放低姿態，每每更容易得到尊重。不要老是試圖居高臨下地提意見，尤爲是你在對方內心尚未創建任何信任和威信的時候，不要貿然給別人提負面意見。

四 新人成長

在讀書的時候，若是做業不會作，你能夠問同窗，直接 Copy 做業；你也能夠問老師，獲得答案或者啓發和引導。

工做了以後也同樣，你能夠 Copy 代碼，也能夠獲取引導和啓發，可是總歸仍是得到引導和啓發比較好的。

4.1 新人成長：個人成長

在入職金山後，做爲一枚萌新，身邊的小夥伴和組長的確給了我不少啓發：

• 帶着方案諮詢上級，不作無謂的探討

人急起來每每會將本身的但願寄託到某我的能快速幫忙解決問題上，jsliang 也同樣，在剛入職的時候就常常將一些問題拋出來諮詢組長或者身邊小夥伴。

雖然新人成長下直接諮詢問題無可厚非，可是有些內容仍是須要自身先行探討，再進一步諮詢的。

這點我一開始就作得不好。

因此後面碰到問題，我會先經過本身思考和資料查詢，選出 A、B、C 幾種方案，而後帶着問題和方案去諮詢領導和小夥伴，從而獲取到有用的引導和啓發，進而修改本身的方案。

這點我也嘗試在給身邊小夥伴們解答時使用，固然可能有些小夥伴會以爲我不夠直爽，沒有給最直白的答案

這點更讓我印象深入的是一句話：僱傭你過來是作事的，安排你作一個需求是想讓你接觸這類問題的處理（這不是一個緊急的問題），咱們畢竟是一個對外服務的小組，若是有問題你都問領導，那就是領導作事了，那招你過來有何用？

• 有些流程適合解謎，有些流程適合解答

有些問題並非直接給你代碼就好的，例如新人進來每每不會分配比較複雜的任務，都是讓你適應新流程的需求（除非是招你過來要立立刻手，解決重大問題的）。

可能這個問題在熟悉流程的老人身上，花幾分鐘時間就能搞定，而新人須要琢磨好久。

可是，若是這個問題新人不去了解全流程，不去熟悉它，那麼後面碰到這塊內容，他仍是會抵觸。

4.2 新人成長：管理技巧

• 不要將時間耗費在新人上

不能由於本身對系統各類設計和業務邏輯熟悉，因此直接給答案，或者幫忙找答案。

由於這樣子會致使：

1. 在你這裏容易獲得答案，因而問你問題的愈來愈多，雜事也多
2. 你給的答案，下次有問題還來找你
3. 忽然你不回答了，那麼新人會怎麼想

你須要作的應該是將這個技術點經過任務形式或者其餘方法發佈下去，讓新人自行調查，而後給予提示和啓發。

• 給答案 V.S. 給線索找答案

何時適合直接給答案？何時適合給線索，讓對方找答案？

1. 若是是對項目的流程熟悉，項目的搭建，那麼就適合給答案
2. 若是是對項目需求的處理，問題的分析，那麼就適合給線索

• 如何引導

1. 若是有方案，幫忙分析
2. 若是沒方案，誘導分析

不要太具象，也不要太抽象。

例如一個需求，應該代表本身想要的內容，UI 大概長啥樣，而不是讓對方任意發揮，而後審查後又以爲不足。亦或者讓對方先給出本身的方案，審對後再開發。

• 工做彈性

工做彈性是根據具體業務需求，讓本身可以有足夠的處理能力

1. 讓新人正確面對本身的壓力

   1. 已發生的，思考和覆盤
   2. 未發生的，琢磨將來計劃和規劃，思考不足之處
   3. 前 2 點不要一根筋

2. 當有壓力的時候，要學會走出思惟的誤區，打造本身的彈性能力

   1. 按期 Review，看下本身的改進是否有效果
   2. 不要由於不可控因素責怪本身，例如公司忽然加班，也不要讓這個因素讓本身放棄，鬆持有道
3. 與積極向上的人作朋友，保持良好的心態

4.3 新人成長：個人思考

• 【解答】搭建開發環境
• 【解謎】帶處理方案諮詢問題

五 項目開發

在項目開發的過程當中，咱們可能須要關注一些點：

• A/B 測試
• Code Review
• 項目延期
• 線上問題

5.1 項目開發：工做分配

團隊負責人的工做職責之一就是工做的分解和受權。

在沒有創建充分信任的狀況下，該如何分配工做？

1. 創建參考基線。在和一我的沒有任何接觸的狀況下，經過第三方評價、我的履歷以及員工作過的項目|產品來衡量能力
2. 問對問題比正確答案更重要。將任務交接到員工手中前，儘可能告訴他當前任務的詳細情景，看他有什麼問題和想法
3. 工期估算。須要多久完成，大概何時，須要怎麼樣的資源
4. 執行力。有些成員可能溝通、計劃能力都很強，可是執行力比較差，會滯後、遇難而退、有始無終，這些成員不適合託付大事
5. 後期維護。項目的完結並非項目的結束，還應包括項目後期的 Bug 維護，跟進用戶的反饋，完成產品的迭代升級等

須要注意的一些細節：

1. 職場新人。有些新人可能頗有潛力，可是經驗不足。因此初期不要輕易否認他們的工做，而是更耐心地指導讓他們快速進步
2. 針對不一樣類型的員工分配工做。不一樣類型的員工會給團隊帶來不同的內容，有些人可能邏輯性強，有些人可能技術性強，都會帶來不同的反饋

5.2 項目開發：受權

研發組長可能會參與全部的設計和討論，甚至不少核心的代碼都是本身寫；組裏其餘人的代碼也會親自過目；不管多麼忙都會參與全部的代碼評審，作到對每個改動都心中有數。

隨着業務規模的擴大，人員的增多，事事親爲會變得愈來愈吃力，加班變成常態，這時候就須要帶人和受權，將事情分配出去讓別人作。

誤區：

1. 事情能不能作好和徹底按照你的方式作好，是兩碼事，別人有別人的工做方式，也能把事情作好。
2. 介入和非介入並非非黑即白，用什麼方式介入，在哪些地方介入，纔是關鍵

受權和分配任務須要注意：

1. 明確目標。讓對方知道最終想要達成的結果和對任務完成的指望值。
2. 制定計劃。保持跟進很重要
3. 給出反饋。給予對方正面的反饋很重要，給予確定。

5.3 項目開發：A/B 測試

若是產品須要修改 UI 上某個模塊的交互設計，引導用戶點擊 「下一步」 按鈕，而後不知道哪種效果更佳，這時候就須要 A/B 測試。

經過 A/B 測試，讓一部分用戶體驗新的 UI，另外一部分用戶繼續使用舊的 UI，再對採集回來的數據進行分析：

• 哪一種 UI 下，用戶更願意繼續往下走

A/B 測試須要注意的問題：

1. 不要過度相信你的直覺。將你的想法和別的工程師、設計師、產品經理深刻交流，經過溝通獲取更好的選擇
2. 實驗樣本的數量和分配很重要。實驗數量小、隨機分配不平均，都不能很好地作 A/B 測試
3. 分析維度要全面。A 與 B 對照組，發現 A > B，可是 A 下網絡延遲更差，或者出錯率更高，那就不是好的設計
4. 數據埋點很重要。經過前端埋點採集實時數據，後端埋點採集實時事件或者聚合數據。

5.4 項目開發：Code Review

開發應當對本身的代碼自測，而後提交上去進行審覈。

• commit：代碼改動

commit 應當註明本次改動的類型：

1. feat，需求功能
2. fix，功能修復
3. ……

每次 commit 的功能應該是單一的，例如本次 commit 修改了對應文檔上的內容，下次的 commit 添加了功能代碼，這些在 GitLab 等能根據具體的 commit 去查看改動，而不會亂七八糟丟在一塊兒。

• pull request：代碼提交請求

pull request 簡稱 PR，是指將你的代碼合併到 GitLab 測試|線上分支的時候，須要進行的操做。

1. 正常提交：至少一我的承認
2. 重要提交：負責人承認
3. 多項改動：不一樣組進行各自代碼審覈

在 jsliang 平常工做中，若是是多語言等無關功能的提交，只須要身邊小夥伴的審覈；若是是新增功能，則須要組長審覈；若是涉及到其餘部門，那麼須要各自提交到組長審覈。

5.5 項目開發：項目延期

影響到項目延期的因素：

• 產品加了特性，需求變動
• 人員減小，開發時間增多
• 項目組成員被調去緊急增援

項目開發過程注意事項；

• 先提問：何時感受到項目可能會延期，在此以後你作了什麼
• 創建必定的流程。計劃制定流程和計劃跟進流程，每週或者天天同步會議
• 明確優先級。分好輕重緩急，將重要的事情先開展起來
• 制定項目共享狀態表。讓團隊成員一眼就能夠看清項目進展，並保持圖表更新
• 不要漏掉任何一我的。不能由於某成員暫時沒有任務，就先擱置，而是事先通知他並讓他參與到任務事實跟進中
• 提供有效的反饋渠道。任何人有問題或者質疑，均可以提出並解決他的擔憂

5.6 項目開發：項目 Bug

當項目出現線上 Bug 的時候，如何處理？

1. 用戶第一，解決問題。對外的事情永遠放在首位，作修復和補救，下降損失。
2. 避免重犯，追究責任。錯了就是錯了，該承擔的責任仍是須要承擔的。
3. 環境監察，流程優化。人不必定都能具有到位的，因此須要自動化測試或者多種測試，創建預警機制，防止高危操做（災備演練）

同時，對於線上問題的公關：

• 補償：包括但不限於發優惠券、送套餐和營銷召回等

六 團隊管理

6.1 團隊管理：團隊成員

如何幫助團隊成員：

1. 融合協做。經過指導、反饋、監督、交流、協調資源等方式幫助下屬提高能力
2. 佈置任務。分解和佈置任務，包括界定需求邊界、制定計劃、選拔人員和工做受權等
3. 創建合做。與上級、下屬和相關部門創建良好的合做

好的上級應該給予下屬機會、空間和支持。

下面不可取的有：

1. 固定的眼光看一我的，成員的提高看不到，也不去挖掘
2. 太重看天賦而非努力
3. 關注錯誤而非讓你在錯誤中成長
4. 認爲團隊比每一個人成長更重要

可取的是：

1. 一次失敗能夠容忍，可是屢次失敗應該警戒
2. 問題很棘手，可是容許你嘗試
3. 任務要求對系統比較瞭解，可是讓你作也能提高你的瞭解

值得幫助成員提高的地方：

1. 技術如何提高到更高層次
2. 潛力在哪，優勢在哪，如何培養和挖掘
3. 如何讓他改進和同事的關係
4. 錯誤哪些，缺點在哪，如何修正和改進
5. 創建不擅長領域的信心
6. 處理各類壓力和矛盾

自身反饋：

1. 和本身對話，反思上面可取和不可取的點
2. 將一些場景的心裏 OS 寫出來，方便回顧
3. 跟組員和上級溝通，交流和聽取建議
4. 哪些事情能夠交給組員的，可是本身卻承擔下來了

6.2 團隊管理：晉升

關於團隊成員的晉升，能夠考慮到如下幾點：

• 技術提高標準：這我的是否在過去的半年或者一年裏，按照下一個級別的標準在工做（我須要的提高點在哪，我本身的思考、組長的評論、好友的建議）
• Code Review：是否對本身的需求開發、任務完成有對應的記錄，並將這些內容統計分析出來

6.3 團隊管理：建議和意見

同事展現或者彙報工做成果，說完會表示 「有意見儘管提」，可是這是一個大坑！

若是你特別老實直接說了一堆負面建議/意見，很大可能會不歡而散。

因此，溝通是門藝術。

• 大多數人對於負面的反饋和意見，心理上或多或少都有些排斥感

提意見的方式：

1. 考慮由你提出這個意見是否合適。是否是換成領導比較好，或者技術問題由技術比較厲害的人提出比較好
2. 提出這個意見的時機是否把握好。別人忙得焦頭爛額，或者失戀了等場景，提這個建議/意見和加一把刀有什麼區別
3. 提出這個意見的地點是否把控好。是否在人員密集場所提出這個問題，是否在會議場所提出問題
4. 提出的建議或者已經對事不對人。避免讓別人感受你這是針對他，而是針對這個事情

多正面反饋，80% 的正面反饋 + 20% 的改進建議，會讓一我的有更好的動力。

聽取意見的方式：

1. 瞭解本身心裏，是否在認真聽取意見。看重提意見的人？意見我的化？心情因素？對方態度因素？
2. 克服自身障礙，避免情緒影響到聽取。不要試圖從惡的角度揣測對方，先假設是善意的，並標明本身的感謝
3. 瞭解建議細節，將關注點放到改進處。
4. 過濾建議信息，將改進處落實到具體。

6.4 團隊管理：一對一溝通

創建一對一的溝通機制，能讓團隊更加和諧：

1. 每一週或者每兩週和團隊成員進行一對一溝通
2. 談話的內容沒有定式，一般如下級爲核心，對項目進展、工做中的挑戰、技術、業務和人事關係等進行詳細探索和溝通
3. 經過信息分享，會提高團隊成員的工做品質，你也能夠學習瞭解到更多的知識
4. 不要爲了溝通而溝通，這樣會毫無心義
5. 能夠先爲溝通設定一下話題：產品提高、工做哪些方面能夠改進、技術方面如何提高

6.5 團隊管理：指望與被指望

管理者和被管理者之間，最須要避免的狀況之一，就是指望值。

• 團隊成員 A 平時很努力，但願能拿到優秀的績效，結果拿到合格
• 團隊成員 B 完成了一個很重要的項目，以爲能夠升職加薪，卻落到其餘成員頭上
• 管理者 C 以爲本身和團隊成員合做很愉快，結果成員但願換組甚至跳槽
• ……

這些狀況都會給以爲意外的一方帶來委屈。

校準管理者和被管理者對彼此的指望值：

• 增長彼此的瞭解。內向外向、自信自負、跟本身較勁仍是和他人攀比
• 半年或者一年進行一次關於指望值的深度對話。興趣是什麼；加入團隊但願作什麼；將來兩三年職場計劃怎樣；作了哪些努力而且正在努力哪方面；目前作哪些工做，還想作哪些工做，還能作哪些工做；想承擔什麼樣的責任；你對他的指望置，並表示本身會盡大可能提供機會和支持；明確表示若是對方之前的承諾目標沒有達到，那就暫時不回給予更有挑戰的機會
• 持續跟進。設置一些檢查點，一週或者兩週進行一次檢查，根據雙方的判斷進行調整

6.6 團隊管理：職場規劃

對於團隊成員，須要注意成員的我的規劃：

1. 我的價值觀是什麼，最在乎什麼？在乎獨立解決能力，在乎挑戰別人作不到的事情，在乎同事間的溝通氛圍良好關係
2. 長期意願是什麼，五年甚至十年後，你但願成爲何樣的人？
3. 爲了達到目標，你還須要哪些技能或者經驗？技術廣度、深度，產品系統瞭解
4. 優點和長處是什麼？合做性、獨立思考、行動迅捷、良好的產品思惟

成員但願領導提供怎樣的支持：

1. 須要能證實本身的項目
2. 須要能帶本身的老員工
3. 但願有更多練手的機會
4. 須要專一培養本身的技能
5. 須要讓本身接觸更多的業務或者架構
6. 須要參加系統的培訓

固然，在提供這些支持以前，須要先證實本身。

例如但願參與能證實本身的項目，那麼在這以前你有沒有參與各個項目的開發，髒活累活有沒參與，從而才能得到須要的機會。

例如但願能帶本身的老員工，那麼你是否作同等反饋，例如幫忙作一些力所能及的雜活，讓老員工能更輕鬆地幫助你。

不該該脫離實際去請求支持。

完成職場規劃須要：

1. 知道本身想要什麼，知道現實的你和理想中的你差距在哪裏
2. 和領導者溝通，獲得一些反饋和幫助
3. 設定目標，指定你和你的領導者都贊成的計劃和期限，確保計劃會讓你和目標更接近
4. 讓計劃變得可執行和可追蹤，循序漸進完成和跟進，持續改進

七 其餘

7.1 其餘：說 「不」 的技巧

若是什麼事情你都說 yes，你多是萬能的，可是你總會有栽跟頭的一天。

1. 分清事情的輕重緩急，有些緊急的事情和優先級高的事情很難拒絕
2. 正確評估本身的能力和時間資源

7.2 其餘：後續日子的思考

1. 下一步路怎麼走？

   1. 本身陌生領域開闢新天地
   2. 擅長領域繼續精進
   3. 轉崗

2. 思想是一種沉澱，時過境遷之後你可能再也寫不出來了

   1. 忙到後續再補筆記不是藉口
   2. 不會作筆記也不是藉口

八 總結

也許有的小夥伴看完會以爲一臉懵逼，這寫的都是什麼和什麼。

可是在讀原文和此時回顧以前寫的讀書筆記（2021-04-13），我仍是以爲有些點是很是值得關注的，例如：團隊成員的晉升。

雖然咱們不少人都但願本身能晉升到下一個職級，可是有時候想一想本身是否知足下一個職級的技術棧，並按照這個技術棧嚴格要求本身了？

固然有時候會以爲本身是否是被洗腦了，可是若是晉升不是按照一套流程走的，那麼開了口子後團隊管理是否是亂了。

除此以外，裏面還有內容值得拉出來深思，這裏不一一例舉。

我是 jsliang，咱們下本書讀書筆記見。

---

不折騰的前端，和鹹魚有什麼區別！

jsliang 的文檔庫由 梁峻榮 採用 知識共享 署名-非商業性使用-相同方式共享 4.0 國際 許可協議 進行許可。<br/>基於 https://github.com/LiangJunrong/document-library 上的做品創做。<br/>本許可協議受權以外的使用權限能夠從 https://creativecommons.org/licenses/by-nc-sa/2.5/cn/ 處得到。