一個人的美好？
轉職的頭三個月，需要完成一項「試用期檢核」，獨立規劃並且開發專案，在過程中讓新人了解公司的開發環境、也讓公司了解新人的能力(笑)。
這段時間除了每週和 Mentor 們 1 on 1 外，剩下的時間都是自己開發，有時候會覺得沒有融入團隊，有點格格不入的感覺。
(現在回過頭看，發現能專心開發是件很幸福的事情)
我寫了一篇心得紀錄試用專案，有興趣的朋友歡迎來部落格坐坐 😃：
正式加入團隊！
完成試用期檢核後，意味著「新人訓練」正式結束，是一個合格的人力了，準備被分配到現有的專案團隊中（貢獻新鮮的肝)。
當初轉職時，在幾個 Offer 中選擇現在這份工作，有一個重要的原因是希望能了解 Machine Learning 服務完整的生命流程。
在前一份工作當DA (資料分析師)時，大部分的時間都是在梳理需求和 Feature Engineering、驗證模型的表現，當模型表現過關後，就遞交給其他部門封裝成產品，對於後續的流程其實很模糊。
和主管 1 on 1 討論後，綜合自己的興趣和部門的人力配置，我加入了 DevOps Team ，這個團隊主要與DA協作，將他們建立好的模型部署成線上服務。 從模型建置、CI/CD 到正式部署上線，能夠完整參與到所有流程，這讓我相當興奮。
非線性的學習路徑
(非線性的路徑 - 中山站)
然而正式加入團隊後，在學習相關知識時，卻意外地感受到濃濃的挫敗感…
新人訓練通常是「制式化」的線性路徑，遵循規劃好的學習路徑就能完成。
但專案團隊的學習路徑通常是非線性的，很容易遇到幾個狀況：
- 團隊的知識點沒有留存：這意味著許多知識點都是存放在「團隊成員的腦海中」，當團隊沒有透過文件或其他形式留存知識點時，新成員需要透過「問」的方式來取得知識。
- 新成員難以建立知識地圖：僅管團隊成員都相當友善，願意不厭其煩地回答問題，但一來一往間將消耗掉團隊成員大量的工時 （有些問題甚至需要回答超過一次）。 這對於新成員來說，很容易會有無力感 : 「該怎麼樣才能快點派上用場呢？ 」、「感覺任何問題好像都要先問過別人，才會得到答案呢…」
- 知識的不一致性：有時候會出現「一個問題問不同人，得到不同的答案」的情況。
我在前一份工作也有帶過新人，深知在專案時程緊迫時，會留下許多技術債、暫時的解法，這些內容可能還沒有時間文件化、或者是過於破碎，不值得文件化。
在這樣的情況下，新加入團隊的成員該如何跟上其他成員的腳步呢？ 以下是我的做法：
一、試著製作會議記錄
我在加入團隊的初期，參加每週例會時很容易 Fade out，原因是有太多的專業術語或是概念是我不明白的，很容易在其他成員討論的過程中腦袋閒置，然後就…暫時斷線。
我嘗試的做法是試著擔任會議記錄，在會議過程中，為了要記錄內容，專心程度會顯著上升，如果遇到專業術語或是概念是自己不懂的，也沒關係，先記錄下來，若有餘力可以加上醒目提示。
在每次會議結束後，這些醒目提示就是「成長的起點」， 會在會議中被提及的概念或是名詞，通常是「正在進行的項目」、或是「特別重要的概念」。
將這些不懂的地方搞懂，能更快的變成可用之兵
在製作會議記錄的初期，因為有太多內容不懂，紀錄的品質往往有待加強，所以這份會議紀錄只會給自己參考。
等到差不多理解 7 至 8 成後，可以自告奮勇擔任正式的會議記錄，對於團隊成員來說，有人要分擔會議記錄是件好事，對我來說，這也是個成長的好機會！
透過會議記錄，補強真正重要的概念
二、製作屬於自己的問答筆記
透過會議記錄梳理出「需要釐清的知識點」後：
只要有問問題，得到的答案一律記錄起來
加入團隊後，舉凡系統的操作、維運的流程，甚至是程式的語法，只要有問題，向其他成員詢問後，不管得到的答案是簡單或是複雜，一律都先記錄到筆記中。
這樣的筆記主要是讓「未來的自己」參考，在融入團隊的過程中，有許多事情是需要學習的，有時候可能會顧此失彼。在嘗試理解新知識的過程中，很有可能會忘記某些內容，如果重複詢問，一來會顯得專業度不足，二來則是對於團隊來說，對於效率會有負面的影響。
大腦負責理解、記憶就交給筆記
剛加入團隊時，對於任何事物都是一知半解，甚至連業務都不甚了解，所以一開始建立問答筆記時，知識點可能會相當破碎，初期可以用列點的方式紀錄問題：
+ Q1: XXXX?
A: XXXX
+ Q2: XXXXXXX?
A: XXXX
隨著筆記的增長，可以在空閒時修整內容 :
- 把真的太簡單的蠢問題移除 (這也意味著你成長了！)
- 把相關類型的問題整併在一起
- 如果同一個類型的篇幅累積到一定規模，可以考慮進行文件化
(適當的修剪有助於成長 - 板橋)
三、協助將知識進行文件化
隨著「問答筆記」持續的凝鍊，某些類型的問題可能會累積成足夠的篇幅，這時候很適合將這些內容從「自己看得懂的筆記」，轉換成「團隊成員能閱讀的文件」。
舉例來說，DevOps Team 有個例行性的維運任務，要替 DA 團隊開設程式碼的儲存庫，這項任務本身並不困難，但步驟異常的繁瑣，且團隊成員對於部份步驟的認知有出入 (例如命名是大寫開頭 / 小寫開頭？）
剛開始學習這項任務時，覺得一個頭兩個大：因應不同的情境，會有不同的步驟，我的「問答筆記」塗塗改改好多次，終於梳理出 14 個步驟。
搞清楚規則後，接下來就是將這些步驟文件化！ 把所有的情境、命名規則全部都記錄下來。這項產出得到團隊成員的大力讚賞，這些步驟雖然不難，但在執行時總是會忘記一兩項步驟，在執行時有了統一的標準，錯誤率也會下降。
身為新進成員有一個優勢 — 可以用較客觀的角度去理解專案，從零開始的旅程，意味著「更容易找到缺漏的知識點」，如果能在成長的過程中，同時補強這些知識點，對於專案團隊、以及未來加入團隊的新人來說，都是非常有價值的。
結論：在成長的過程中，試著對團隊有點貢獻
回到標題的問題 — 「剛加入團隊的新人，可以做點什麼？」
我自己的經驗是：
- 透過製作「會議記錄」來找到缺漏的知識點。對團隊來說：有人幫忙製作會議記錄是好事 😄
- 接著以「問答筆記」來整理知識點，透過釐清問題、歸類問題，漸漸將知識由點串聯成線，建立自己對整體專案的理解。 對團隊來說：減少重複問問題的次數，能提高團隊整體的效率。
- 當「問答筆記」的內容成熟，將這些知識文件化，讓其他成員能藉此共享知識。 對團隊來說：避免資訊不一致，未來新成員加入也能更快上手。
以上是我的做法，如果你有更棒的想法，歡迎留言！
祝福大家都能在自己的職涯持續成長～ 我們下次見～