文科少女學程式

做一份工作，別只是埋頭苦幹把它做完，而是思考該如何把它做對，這樣才有能力成就出自己在市場上最吸睛的亮點和價值。

又到了令人期待的月會時間了，這次的月會內容原本覺得自己因為還太菜，可能無法有太大的收穫，卻意外得還是收穫滿滿！
而且這次的主題也讓我延伸聯想到最近公司內部主管跟大家開會時提到的兩個關於將公司產品成功推銷出去這部分令我印象深刻的內容：
- 想把自家產品順利賣出，最重要的就是要有「有別於市場競品的亮點」。
- 我們家的產品價格的確在市場上偏高，但是並不是我們的產品貴，而是你買不起，因為我們有努力讓產品有值這個價位的品質。
雖然上面這兩段話，主要是在講產品銷售，但仔細想想我們在市場上求職，不也是一種銷售嗎？只是是在推銷自己。
那要怎麼做才能讓自己有能力以高價將自己售出呢？這次月會主題關鍵字「掌握商業價值」，我想就是一個很重要，但是卻常常被忽略的部分！



本次月會主題
工程師能如何學習掌握商業價值，取得更好的職位與薪酬？

本次月會流程

這次月會的流程大致上如下：
輪流自我介紹＆分享船長事前丟出來讓大家思考的問題 > 船長分享 > 分組討論、結論分享>船長針對分享結果給結語

會前思考問題
1. 在工作中，你曾做了什麼專案或是貢獻，讓公司因此獲利？
2. 其中是哪件事情你認為是最有價值的？
3. 那你覺得這件事替公司帶來了多少錢的獲利？

關於這幾點問題，其實我回答不太出來，只能從自己過往在主要任務外，幫助內部增加效率的side project下去分享。後來仔細想想，我可能就是犯了這場月會主要想要讓大家避免的錯，也就是「只專注在把事情做完，而沒多去思考要怎麼把事情做對和做好」。從這大家分享這個會前思考問題的過程中，也發現到很多人其實都有很好的習慣，有多多去了解公司因為什麼賺錢，還有賺了多少錢，以及為什麼這樣會讓公司賺錢和賠錢，這真的是我必須多多學習的地方。

船長分享 - 重點摘要
洞悉市場及環境 - 掌握外在大環境及市場
船長在分享中提到，如果大家已經有一定程度工作經驗了，其實可以多多從以下三個面向去掌握大家所處的大環境：
- 商業模型Business Model：了解公司主要的服務對象是誰，主要創造公司利益的核心業務是什麼，才能更有效率地幫公司賺到錢，也就更能創造自己在公司眼中的價值。
- 市場策略Market Strategy：了解大環境的市場狀況，不單單是知道現在市場上在紅什麼?(例如：AI)，也包括了解市場上對於工程師的供需需求。隨時保持這樣的敏銳度，不只在公司中能創造更多價值，也能幫助自己的職涯發展。
- 財務報表Finacial Statement：懂得看財務報表不僅能用在選出一檔好公司的股票，更能讓自己了解自己公司的營運狀況，當然必要時，也能幫助自己成為抉擇去留的參考項目之一。

有不少人可能會覺得身為一位工程師只要顧好自己的技術能力就好，但是想要持續讓自己有所成長，不論是薪資成長，或是職務位階的成長，單靠專注在技術上，其實是不太足夠的。另外，我自己覺得隨著AI技術的發展，對於這部分的影響度又會更大，因為AI技術主要就是在幫助技術部分的快速發展，等到AI的技術力，也就是所謂的硬實力發展得比人類還快且好的時候，人類該拿什麼來和AI拼呢？我想大概就只有人類才能感知的人和情這種沒有正確答案，必須靠經驗和對環境、Domain Know-how的理解才能做出更正確判斷的軟實力吧！

關鍵業務指標 - 找出可量化的數據資訊，來針對公司業務或自我進行優化
這個部分我自己覺得有兩個面向，一個是透過關鍵業務指標(KPI)找出可以解決公司問題，或讓自己有方向幫助公司業務發展得更好，一個是透過數據來量化自己的成果，有助於優化自己的業務成效，或是向上展現自己的表現。而在定義成效，找出可以量化的指標的部分．如果沒人協助定義的話，就自己去定義。能找到量化金錢的指標當然最好，但是如果沒辦法，能找出量化其他成效的指標也很好，像是處理了多少CS案件，或在自己底下的新進人員在加入團隊多少時間後，就能有所產出，亦或是當下是因為什麼可量化的數據資訊，導致問題發生。

關於這個部分，還真的是我原本沒想過的地方，雖然以前曾經是一位營運PM，幾乎每天都要跟一堆數據打交道，卻從來不知道原來除了PM以外的職務，也需要掌握數據，還有掌握這些數據能對自己有這麼大的幫助。就算現在自己已經轉職成工程師，也還是得培養對於量化成效的數據保持敏銳。

工作紀錄 - 找出亮點，反思再升級
關於做工作記錄的部分，主要是去紀錄「自己做了什麼？」(這個做了什麼，也可以包含這一天工作天中，有沒有發生什麼樣的事情，比如幫助同事做了什麼，或是花時間協調溝通了些什麼)，並且從中去找到「有沒有自己沒有掌握好的部分？或還可以再做得更好的部分？」，再透過這些資訊「定期給予主管反饋」，達到有效率地向上溝通。做工作紀錄的部分，不管用什麼工具都可以，只要自己習慣的方式就好。



這部分其實是我最近有開始好好做的一件事，這樣做了一段時間後，覺得對自己也很有幫助。主要有幫助的點如下：
- 不論是早上站會、one on one，或是到了年中或年終考核的時候，都有資料可以快速回顧自己這段時間做了哪些事。
- 可以當作Todo List或backlog使用，讓當天工作更有目標和方向，也讓未完成的事情不會那麼容易被遺忘。
- 知道自己的工作的速度怎麼樣，幫助規劃自己每個sprint的工時，也能知道自己的工作效率好不好，可能有段時間效率比較差，有這些資料也可以大概知道自己為什麼某個時段效率較差。

雖然不論是手寫還是用電子檔案的方式進行．記錄工作事項這件事都需要花時間，但是對我來說，好處還是大於壞處，所以個人也真心推薦大家做工作紀錄。

選擇賽道 - 思考職涯發展方向
選擇賽道也是我們公司內部主管週會有提到過的詞，雖然通常我們在週會上提到的都跟我們要怎麼販售、發展我們的產品有關，但真的就跟一個人的職涯發展很像。這部分主要是在說除了自己有興趣或擅長的領域外，也要去看哪個賽道比較有潛力。在船長分享到這個段落之前，有分享一個關於矽谷公司的營收圖表，以公司營收除以員工數的話，就可以大概知道一位員工幫公司產生的營收大概是多少，也就能大概推算出這間公司的薪水天花板在哪裡。雖然並不是所有公司透過這樣的公式計算下來，都有很漂亮、很高的數字，但這並不代表一定不好，還是可以去思考繼續待在這間公司是否能有其他機會，自己是否能成為那個增加人均產值的推手。不論如何都還是需要自己進一步地去思考、去判斷，再來做出對自己合適的抉擇。

分組討論（主題：各情境下面對技術債的應對方式）
這次分組討論主要討論了一下這四個技術債的情境：
1. 當初的抽象化假設已過時，不斷疊加新功能，沒有根本解決商業設計邏輯
應對的方法：
- 如果新的使用情境和既有的元件很相近的話，可以嘗試去修改它的抽象化，也可以去找當初設計它的人討論要怎麼改比較不會把原本的元件改壞。但這個方法需要確認哪裡有用到這個元件，並且確認測試範圍有涵蓋這些地方，才能比較安全的完成修改。
- 如果是已經改不太動的情況，或是目前沒有時間去重新設計既有的元件，那就重新設計一個新的元件，甚至新設計的元件也可能連舊版本的元件的功能都包含，雖然是這樣也可以不急著把所有使用到的地方都進行替換，避免替換的成本太大。
- 如果不想要改動太多既有的東西，也不想要複製貼上，也可以去把既有元件中比較關鍵的邏輯給抽出來，接著再把這些邏輯複用在新的元件中。

因為我自己是選擇這個分組討論的主題，所以最有感的其實是這題，也另外記錄當天討論的一開始我們這組主要在討論什麼。在針對這個情境討論之前，航海士一開始先丟了一個問題給大家思考，那個問題是「什麼是抽象化？」。(其實被問的當下，默默覺得好像在面試XD) 關於這個問題，我還真的沒有思考過，所以很直覺地脫口而出：「共用」。但這當然不是那麼正確的答案，「共用」只是只是抽象化可以達到的成效。從航海士一步步地舉例和問答下，像是「抽象化就近本質是在做什麼？」才終於對這三個字稍微有那麼一點感覺。所謂的「抽象化」其實是去定義某個商業邏輯的範圍、或某個目的的意義範圍，例如假設有一個商品列表，裡面有很多商品項目，我現在想要把顯示商品的「card樣式」抽象畫出來，那個這個抽象化出來的元件，就只會有card的UI，沒有商品資料，這個元件的參數也會是與樣式相關的參數。

2. 2023年，公司竟然還在用______，套件無法升級，安全等問題，bug只能自己修
應對方法：
- 找出面臨相同問題的技術團隊，並把可能遇到的問題擴大，來強調問題的嚴重性，以此來說服上層同意做出這樣的改善。
- 如果有不習慣新技術的客戶，也可以主動向客戶提出自己有其他技術可以支援他們的使用，或是給予教學，讓他使用上不會有不便利的地方。
- 向上管理的話，可以利用槓桿，凸顯這個問題的嚴重性，例如可能會造成內部效率降低，無法使用更好用的技術，讓高層意識到這個問題對於公司的影響其實很大。

3. 服務穩定度過低，沒有辦法達到客戶需求，不定期就會出問題，需要手動介入修正

應對方法：
  - 了解客戶的實際問題，去排出問題的優先順序。
  - 找到問題的root cause，並增加一些自動化測試，來提升系統的穩定度。
  - 定期檢視這些進行的方向是否對於系統穩定有幫助。

另外在這個主題的討論分享中，還有一個很重要的點就是「技術債一定會存在」，重點是要怎麼讓技術債的數量維持在一定的量，不要讓技術債不斷地累積沒減少。

4. 堆積如山的backlog與待修的bug，同事已經放棄治療，只處理眼前的事情，任務管理形同虛設。
應對方法：
- 去顧好現在留著的人的情緒。
- 收集身邊的資訊，來去判斷任務的輕重緩急。
- 把自己感受傳達給主管或老闆，讓高層去處理這個狀況。
- 把工作的內容攤給大家看，讓大家知道自己的工作有多忙。
- 透過量化的方式，轉化成高層比較能理解的語言和內容，讓他們理解現在的問題有多嚴重。
 

延伸的反思 - 有效溝通的重要性
從前面這幾個情境中，所討論出的做法也讓我想到最近自己部門內部發生的一些事情，雖然跟技術債無關，但和把事情做對，增加工程師價值有關聯。
最近有兩個需求，都是PO自己認為應該要請RD這樣做，但是在RD的立場上，卻覺得這麼做很奇怪，可是PO又堅持要這樣，在經過幾輪的討論後，這兩個需求分別走向不同的結果。
需求A：經過一來一往的討論，從過程中一步步地確認到為什麼想要這麼做，最後終於了解PO提出這個需求的背後目的性。原本因為PO省略同步他最終的目的性，只提出他認為應該怎麼做，認為這樣就是可以解決他的問題的作法，所以讓負責的開發人員相當苦惱該怎麼進行，最後因為有好好進行溝通，而讓負責的開發人員能以更好的作法去處理，同時也能達到PO的最終想達到的目的。
需求B: 經過幾次的討論後，依然僵持不下，負責的開發人員最後選擇放棄溝通，覺得PO想這麼做就這麼做，我們就照單全收就是了，但最後開發完的成果，卻被主管質疑為什麼是這樣設計，為什麼功能是這樣呈現。
雖然上面兩個需求不太一樣，但是有沒有好好地「溝通」，甚至是「有效地溝通」，所出現的最後結果就是不一樣。這個情境也呼應到船長在分享中提點大家的「在職場裡面，不是只有做得多才有價值．而是要去想怎麼發揮自己影響力，讓大家都能有效率地做對得事情」。


我的Action
在這次的月會後，一樣給自己定下幾個可以努力去執行的Action。
- 持續維持記錄工作事項的習慣，並有意識地放入一些可以量化的資訊。
- 在做需求時，不要只是傻傻得做，還要搞懂需求的背後目的。
- 有意識地從工作中，找出可以量化的資訊。

感想總結
原本沒有預期這場月會主題也能讓自己有那麼多的共鳴和延伸的想法，因為雖然自己知道自己需要加強這部分，但商業相關的部分總覺離自己還太遠，也太廣。但是聽了船長的分享，以及每組討論的分享後，才知道其實想要了解大環境、公司產業價值等，其實是可以從小地方開始做起，而且所謂的「商業價值」除了大家一眼看到的商業兩個字，覺得主要是公司業務、營運有關外，其實也跟客戶價值，甚至是員工個人的價值有關聯。所以我自己聽完和重新整理一下心得後，也又意外地連結到最近工作上遇到的情境，而有更深一層的啟發。雖然有達到這樣的境界，並不是那麼的容易，可能還比培養技術能力還要困難，但是有意識地提醒自己該往這個方向多多學習，相信對自己一定還是有好處沒有壞處的！
也希望有一天能成為一位大家公認的「最聽得懂人話，最能夠溝通的工程師」！