版本控制、資料架構，沒有技術基礎就學起來啊
有天老闆教會我 git 版本控制後，一路從我的座位碎念回他的座位，說教會沒技術背景的人好有成就感，說妳一定要把這些記錄下來 — — 於是就有了這篇文。希望在進三步退兩步、天天夜夜兢兢業業、職涯的學習曲線陡峭之際，記錄那些幫助自己上攀的經歷。
初成為 PM 的最大挑戰
網路課程與文章大多提及，產品經理的職責在建立團隊節奏、規劃產品路線。因有著帶團隊開發出 App （現在想想，當時只是上到 Testflight，距離雙平台 App 上架還遠得很）的專案管理經驗，我想著產品經理的燈塔就是技能樹的再延伸，應該很好上手。
既然會有這篇文，那當然是馬上就翻車啦 ^__^ 職涯的第一年，我都深陷在這兩個泥淖：
少有能著力的產出
公司組織下，相對於公司內其他追求內容、商業變現的產品團隊，我身處在管理伺服器、開發及維運共用系統的內部支援型團隊。
因此訂定工作目標時，相對於產品團隊是為推出新一版的 app 產品、提高公司營收；我們的工作目標是減少整個公司的重複性工作、加速產品團隊開發。
例如，建立公司內多個 app 共用的帳號登入體驗、事先研究好同時符合 iOS、Android 雙平台的設計規範。跨團隊的交付形式很多元，可能是整入多個第三方登入服務的 SDK、可能是搭有 wireframe 的 UX guideline 文件、也可能是撈取後台資料的 csv 檔。
首先，專案管理所需的心力不如想像中吃重。產品團隊目標是追求產品變現設計師、工程師、PM 都在追新一版的產出；於我們團隊而言則偏向各做各的，dependency、開發節奏相對來說不那麼需要人力管理。（咦那我在網路上看的那些炫技 case study 不都沒用ㄌ？）
再者，團隊中跟工程無關的工作相當稀少。在我加入之前的團隊全員都是工程師，我除了整理文件、畫 wireframe，比較難對團隊有其他直接的貢獻。連跨部門的需求進入團隊時，需求的規格往往會需要諮詢工程師後才有結果，記得當時的自己常是在懊惱，「他們工程師之間溝通不就好了，每次都得跟我講解多煩啊。」
知識集中在工程夥伴身上
在 Asana Kanban 上瞎整理一陣子後，自己的專案管理經驗似乎已經幫不上團隊，既然連記錄同事們例會上分享的開發內容都有困難，我在主管的建議下，嘗試從用戶端下手，用客服案件來理解團隊的守備範圍。
客服案件往往牽涉帳號資料、交易紀錄，這些都與跟 server 的溝通有關，我勢必可以在協助處理的過程中更了解 server 端的資料架構、順便減輕工程師的負擔，吧。
首先概略說明，用戶會遇到的問題往往是產品邏輯、第三方平台、使用者操作等等因素下的綜合結果。舉例而言，使用者提到他都登入不進 app，原因可能包含：
- 產品邏輯：server 掛掉了、產品按鈕沒在 work
- 第三方平台：Facebook 登入 API 壞掉了
- 使用者操作：使用者根本沒開網路
過往的客服處理流程，多是客服團隊後送予團隊內的工程師，工程師查驗使用者所遇問題後，再回覆予客服團隊。請客服團隊改送給我時，因為缺乏這些基礎知識，我基本上就是個總機——被客服夥伴 tag 後，再在同一個 thread 下 tag 我們的工程師。每每遇到此情此景，腦中直接浮現韓總機在議會的畫面。
hmm，也不必多著墨在途中的掙扎，只記得對自身於團隊的定位焦慮良久後，在 2022 年 6 月確診休息、狂追獵人漫畫、狂看 DoDoMen 的一個禮拜長假間，什麼包袱、心態就都——好——了，重新出發！（謎之音：所以是不是該多放點假？）
手伸長一點 — — 有助 PM 更熟悉技術的點技能方向
現階段少有能做的最終產出？
如果做不來技術工作，那做跟「技術有一點」相關的工作，可以吧？如果以團隊角度思考，可以怎麼減少工程師的臨時性、重複性工作，讓他們專注在更有價值的開發呢？
記下客服案件的 root cause，降低工程師查驗客服案件的頻率
工程師會透過使用者手機截圖的枝微末節（如：app 畫面的錯誤提示、手機的 wifi 有沒有開等）、CRM 後台的使用者操作紀錄、甚至是親自拿手邊手機測試來了解使用者所遇到的問題，以上提到的方法都不需要用到 source code。
因此我請工程師花一整季、每星期一三五處理客服案件的 1 個小時，用分享畫面、think aloud 的形式向我分享他如何「解題」。把 root cause 的筆記累積起來後，也漸漸地能舉一反三。有趣的是，同事有時候在進入 Google Meet 後，也會一副高三補習班老師的模樣說「那準備來解題吧」XD
練習使用 GitHub，提高溝通的精準度
專案管理時往往需要確認開發進度。比起口頭詢問，可以透過團隊的版本控制工具（如 GitHub）來直接查看。我是在為團隊確認第三方 SDK 的版本更新紀錄時學會讀的，意外帶來工作上的不少好處。
比如，發現產品的 issue 遲遲未被修正，卻在 Github 看到工程師 A 已經完成 issue fix 並發好 PR，反倒是 reviewer B 還沒 approve，那你就能從紀錄知道這時不是要無腦催工程師 A「你什麼時候會做好？」、而是去請 reviewer B 做 code review。
又比如，突然想知道其他產品團隊在哪個時間點已經修好某個 bug，這類枝微末節的小事不一定得找工程師詢問，可以從 commit、PR、或 release note 看到端倪；甚至工程師被問後，大概也得到 Github 看到自己推了什麼才回憶得起來。
後來也在老闆密集的傳授下學會使用 git，也開始可以在知道改 code 的範圍後，做一些簡單的網頁內容修正、編輯 i18n、並直接發 PR。
接手基本的資料撈取，認識產品的資料架構
由於 server 存有使用者的操作資料，時不時會有其他部門為分析、行銷等目的請我們撈取數據。看著工作夥伴有時下了一行 SQL 指令就能完成，十分之帥氣，有一天我就湊過去，說教練我想撈資料（並沒有）。
雖然沒有特別學過 SQL，但有程式基礎（自身學過 Python、Javascript 各半年）不難理解語法架構，函式也是網路上查就有，一些簡單的題目如「找到已付費會員中最多人是什麼星座」還是辦得到的。
學 SQL 的好處不一定是打開資料分析的進修大門，而是更了解目前產品資料是怎麼被存的，在現階段的工作中，光是記下使用者的購買狀態 purchase state = 0、purchase state = 1 各別代表什麼意義，就代表我們更了解產品一些。
再問多一點 — — 有助 PM 有效率地探索技術知識的方法
在學習技術的過程中，身旁的同事是最好的請教對象，可是工作的時間是時間、發問的時間也是時間，怎麼才能避免問得太久、又問得不精呢？
以終為始，控制問答時間
工程相對其他領域需要更廣泛的背景知識，在請教工程師時，可以先告知透過講解希望達到的目標，來讓工程師拿捏講解的深度及廣度。
與其只問「使用者登入不了的原因是什麼？」，徒留工程師煩惱是只就這個案件回應、還是整個帳號系統都解釋一番才好？
你可以選擇告知工程師說「我遇到這位使用者反映登入不了，想知道他遇到什麼問題，我們可以怎麼幫助他登入？」如此一來，他更能知道如何推進你的工作。
活用用戶研究，學習工程師思考邏輯
同樣的使用者登入問題，比起直接轉頭問工程師「為什麼使用者登入不了？」你還可以用 UXR 的技巧追問「你一開始看到這個案件有想到哪些可能性？」、「你會藉由哪些資料來排除可能性？」、「你是如何解讀這些資料？」非技術人員的我們正是缺乏對服務流程中斷點的想像力，唯有透過問答才能長出細節。
拿生活、工作案例來校正想法
在工程師解釋完畢後，我會嘗試用自己的話語重述給他，以確保清楚理解。有時我也會用這個句型「我過去工作／生活中曾遇過 xxx 案例，也跟剛剛提到的內容有關嗎？」來聯想其他經驗。
舉例而言，當別人解釋到 app 有時為維持網路連線體驗的穩定性，會採用弱聯網的方式；我會聯想起帶著薑餅人王國遊戲在路上玩時，只要開始對戰跟結算時有連線就好，途中關著網路也沒關係的生活經驗。
有助 PM 學習的資源
文章將盡，還是很感謝入職以來那些不辭勞苦（？）為我講解技術邏輯的同事與老闆，希望你們哪天看到文章的話，能感受到一絲絲的成就感。在此分享一些技術麻瓜工作上常聽到的領域知識，及我覺得有被幫助到（a.k.a. 看得懂）的學習資源：
網頁前端基礎
- 彭彭的 YT 頻道：了解基本網頁語法 HTML、CSS、JS 的個別用途
- 零基礎的小明要如何成為前端工程師？：幫助了解前端眾多技術名詞及其為何重要
前後端互動基礎
- 遊戲的「連線與驗證」機制淺談：一篇淺顯易懂、且以遊戲設計角度解釋為何需要前後端
後端、資料庫基礎
- What is backend?：感謝同事推薦，簡單講解了後端運作的原理
- SQL 3小時初學者教學：簡明地以 SQL 講解關連式資料庫如何運作
開發相關
- Git上的三種工作流程：PR、branch 等版本控制觀念都有被解釋到
- MVC 架構是什麼？：一篇講解我們現有實作的 MVC 開發原則
以及有常常去看的技術入門的免費學習資源：
- Alpha Camp Blog：收錄不少給跨領域轉職用的文章，偏應用面，適合聽到工程師討論特定名詞時去看
- Lidemy 鋰學院：有文章又有免費教學影片，文筆好，極少數有架構地從基礎面講解的資源，適合有空時建立基礎知識，一生推
闢路、摸索至今，才深切理解產品經理的 R&R 差異很大，都端看公司組織當下的需求；回頭看來其實很多主管的引導是好的，只是往往是先做了、學了才能理解。
I’ll do whatever it takes to win games, whether it’s sitting on a bench waving a towel, handing a cup of water to a teammate, or hitting the game-winning shot.
- Kobe Bryant
現下所學跟當初設想的學習途徑完全不同，卻成長得很開心。新的一年，祝各位都有個無論要做什麼、學什麼，都願意為其付出的團隊。
