AC數位職涯相談室 #4 開箱數位軟體團隊 - 模擬專案體驗帶你找出適合的職能 流水帳心得

2021年7月22日，非常感謝AC又舉辦了每月一次的數位職涯相談室啦! 本次邀請到的就是本BLOG 方格子 的前端及全端工程師：Jiang & Kuan 來分享現實職場當中前後端各別負責的工作內容。

第一題：你期待在數位相談室獲得什麼價值？

1. 了解數位軟體產業的慣例與現況
2. 與有經驗的學長姐、助教討論職崖相關問題
3. 釐清自己的職崖目標
4. 了解現在學習的技術在不同的產業與職能中會如何被應用

此題我的答案是 - 了解現在學習的技術在不同的產業與職能中會如何被應用。因為本身在上AC課程的時候大概就有感覺，自己對於網頁的切版排版這件事抗拒很大，相對於撰寫JS的演算法會覺得很麻煩且較無趣，所以其實大概很清楚自己想走的是網頁後端，所以比較想了解現在學習的技術在不同的產業與職能中會如何被應用。

第二題：你報名/想報名全端Web App 課程的動機是？

1. 初步認識寫程式、探索興趣
2. 成為科技職涯人才(更好的PM、設計師、管理者或創業家)
3. 轉職成為專業網路工程師
4. 到海外工作和發展

此題我的答案是 - 成為科技職涯人才(更好的PM、設計師、管理者或創業家)，雖然前面有講到希望可以轉職成為後端網路工程師，但其實最最最終目標是希望有一天，我能夠靠著這項技能，成為一位創業家。因為本身其實很懶惰，常常遇到很多問題，希望能找到這些麻煩問題的快速解決路徑，或是不用一直重複的操作同樣的事情。所以未來或許當自己有一定工程師能力後，期望自己能在市場上尋找一個熱門問題，由自己先行開發相關程式透過提供解決這個問題的方式來創造價值。

第三題：下列何者最接近你理想中的職能?

1. 前端工程師
2. 後端工程師
3. 專案經理
4. 網頁設計師

此題我的答案是 - 後端工程師。雖然題目只能選一個，但當前目標是後端工程師，未來希望自己能夠成為全端工程師，能夠自己獨力開發一個完整的產品，這也是未來作為獨立創業家的第一步。

第四題：承上題，你覺得你目前對這個職能有多了解?

1. 完全不清楚
2. 大概知道需要具備那些技能，但也不是非常清楚
3. 很清楚這個職能需要那些技能，目前正在精進中
4. 知道這個職能需要的技能，在團隊中扮演的角色

此題我的答案是 - 大概知道需要具備那些技能，但也不是非常清楚。其實自己沒有太大的把握能夠清楚說出每一個職位實質上所需具備的技能，及工作內容，因為完全沒有經驗，尚在學習當中，所以覺得透過這次的相談室，一定也能夠有所收穫。

此次相談室以「模擬專案」流程方式來進行，模擬專案的目的主要是希望透過一個實境場景來帶入實際感，不是單純由分享者分享自己的工作在幹嘛，而是可以知道在一個產品團隊裡面要怎麼去解決問題，在不同的角色分工中會遇到的問題跟衝突，所以會分三個步驟：

Step 1 : 了解&拆解任務 拆解任務、了解要解決的問題、還有產品特性、要解決的對象有哪些，一一分析出來後分工，整個團隊的配置該有哪些部分。

Step2 : 選擇你的任務&角色 任務分析後，依自己的專長來完成自己的任務

Step3 : 團隊任務衝突 執行任務的時候，一定會有摩擦，在團隊中該如何解決衝突，讓任務順利完成。

模擬專案任務背景說明： 本次主要負責產品為方格子官網，為何設定在方格子？因為今天請到的分享者就是方格子的前端及全端工程師啦! Jiang & Kuan

專案目標：

任務拆解分析：

1. 打造吸引人，且操作&體驗順暢的介面呈現。 團隊配置所需－前端工程師
2. 確保每次給使用者的資料，能夠正確且即時地呈現出來。 團隊配置所需－後端工程師
3. 釐清專案需求，並清楚掌握與定義不同功能要達成的目的，確保成品符合需求。 團隊配置所需－專案經理(PM)

前端工程師所需負責的工作：

1. 確認資料呈現的形式
2. 網頁切版
3. 樸估開發作業所需的時間與複雜度

Jiang分享筆記重點：

• 實作設計師設計出來的分類業面(切版、動態評估)： 切版實作頁面上是滿主要的一個重點，透過實作把頁面做出設計時想要呈現的樣子。 實作頁面時有時候會忽略掉一個點，當要做一個頁面的時候，UI其實是交雜著需要被注入各種資料，可能名字很長數字很大，當中是有一些動態評估在裡面，這都是前端需要考量到的點。
• 評估前端實作上的可行性：確認特定需求在畫面上能不能做出來： 有時候要去意識到的不是當前的需求一定要完成，而是要考量時間的磨合，以及當前公司的系統架構以及資料架構上是不是能夠符合需求，這也就會需要跟後端去做溝通跟評估。 當PM將一個產品設計畫面出來時，要去評估是不是合理的，能不能做到，資料要哪來，再往後無限擴展。
• 評估開發規模的困難度以及時間： 可以思考哪些功能可以事先確認與動工（案例：那些頁面初步的頁面資訊可以先實作） 在實作這些功能時，去思考要用什麼樣最快的方式去製作出基本版本，之後再慢慢推進。 而一些需求功能在還沒有真正被確定前，能夠以經驗來評估有哪些東西是可以先接出來的，有哪些資料是要再做處理的。 且公司在營運這個平台中工程師一定會去建立一些組件（意指網頁常用元件，如導覽列、下拉選單、警告訊息、按鈕...等等），用組件去簡化實作邏輯，然後很快地把該有的元件套進頁面，元件套進頁面的同時會去思考哪些後端資料是需要被帶入使用的，去加快頁面的完整性，而這些已完成或是能夠完成的事情可能就比較不需要再討論，所以可以減少一些在溝通過程中產生的摩擦力。 只要在前期準備的越完整，討論的問題就可以越進階，溝通上的摩擦就能夠減少。
• 跟後端確認資料的串接格式，可行性 如果資料尚有疑慮，如何先出個相對可行的實作版本。 有時候這問題不是那麼重要，重要的問題是當拿到設計畫面時，能夠去思考到後端有沒有帶出這些資料功能，前端並不是只在乎說把頁面做出來就好，而是要去思考實作時，能夠去接觸的資料有哪些? 目前的資料結構長什麼樣子? 是不是適合帶入到現有的元件去載入? 如果不行的時候是不是有什麼建議可以提供給後端? 工程師非常重要的一個環節是會不會去溝通，以及能不能看到設計稿時去思考後面的所有相關問題，這些會去影響到能不能夠把這些任務做出來很重要的環節。

其他Ｑ＆Ａ

1. 前端工程師需要做動畫呈現嗎？ 動畫有很多種，有些是簡潔動畫，有些是互動上動畫，但這些其實都不是一定要擁有的技能，但有的話很好。動畫其實是by case 不是by project，這是當有需要才會去面臨到的問題，但我認為比較重要的是要怎麼把基本的畫面切出來，標後版，然後資料可以很乾淨的呈現在畫面上，這是最重要的。有些技能樹，像是要Opea GL、3D動畫那是其次，如果能掌握前面的技能，我相信這些進階的技能在學習上是滿快可以掌握的。動畫在工作上肯定會遇到，但以優先級來說沒有到那麼重點。 前端工程師常常會需要跟設計師溝通，如果會這些設計軟體對前端工程師有沒有加分? 應該算有加分，以業界來說有很多接案公司都會希望前端工程師他們也有相對應的技能，去把UI上的原件實現到切版上面去，這是有可能的。 不過我認為這只能算是一個延伸功能，你會了很好，你可能可以去跟設計師討論某些事。 不過其實在我們前端的角度上，通常設計師他設計出來的會是figma, sketch, ????(44分32秒不清楚), 然後會讓我們去看，這個畫面上的這個組件他的規格是什麼? 長寬高, upshadow, position 這些東西反而是我們怎麼跟設計師溝通的方式。PS算是一個次級的一個附加價值，你在你自己技能樹上你有這個功能，未來你可能可以協助設計師。 真正在前端來講，其實很專注在畫面上的資料呈現及動態掌握，你的畫面能不能完整乾淨然後順暢地呈現在使用者面前這是很重要的點。 Ken補充: 雖然在分享過程中有設定一個正確答案的概念，不過其實這個在更多時候，在不同家公司，不同的團隊會有不一樣的合作模式，這也是肯定的事情，不過比較常聽到的合作模式，前端工程師本身並不需要做太多複雜的視覺介面設計，更多時候是像Jiang強調的去了解資訊的呈現乾淨程度。

---

後端工程師所需負責的工作：

1. 定義資料串接的格式
2. 確認資料庫是否能滿足本次需求
3. 設計能滿足需求的演算法

Kuan分享筆記重點：

這個list是今天從PM那接下一個任務後，可能會進行的一個工作流程，在團隊中做為一個後端工程師，在真正敲下鍵盤之前：

• 評估開發複雜度 。 API的改動幅度 一開始評估任務的複雜度有多高，是否需要修改API？用比喻的方式來講，我需要修改的匯款單上的欄位就好，還是需要設計一個新的匯款單來符合任務的需。這是越工作越有經驗之後越能做出正確的評估。
• 評估當前的資料(資料庫)是否能滿足新功能 。 資料可能不太夠，或資料庫可能要做變動(增加欄位) 比較實際面的就是，資料庫需要增加幾個欄位，這是後端工程師考量的事情。
• 評估效能變動的幅度 。 新功能上線後，活應時間會不會變太久？若會，如何做架構調整 因為PM對後端不是那麼了解，有一些功能後端工程師必須要去思考，這個功能會不會影響到API回應的時間，可能進到頁面之後前端呈現都是正確的，但後端回應太慢沒有辦法即時回應資料，所以讀取的圈圈就是一直跑，是否會導致這種情況發生?如果會的話就要去做溝通，讓這功能可能只有80%的效果，可是他不會對我們的效能造成影響，或是去溝通功能要做修正，還是架構要做修正。 。新功能是否需要做機器調整，長期流量會不會變大，促銷活動可能有瞬間流量 像是搶演唱會的門票時會有一個高峰流量，提前知道瞬間流量會出來，是不是需要做一些事前的調整，這也是後端工程師工作時的眉角。
• 設計能滿足需求的演算法 。 需求是最新的十筆資料，就要正確呈現 假設一個新功能，PM說他想要"近10天"，"最新的十筆資料"，"不能有重複的作者"，後端就要想辦法把這一句話變成一個正確的資料，不能錯、不能重複、也不能超過時間，而且效能要好，這就帶到後端工程師最有價值的三個地方：資料的正確性，系統的穩定性(不能壞不能慢)，以及程式的彈性，寫程式時要注意程式不能寫得太死、寫的太隨便，若今天程式有比較大的彈性，未來PM要新增什麼樣的新功能，就需要害怕，只要簡單的修改後就可以滿足新的需求。 正確、穩定、彈性的工程師就是一個優秀的工程師。
• 與前端共同定義資料的串接格式 。銀行的匯款單(誰?多少錢?那些欄位要大寫?) 此部分滿看公司文化，Kuan的經驗大多數是先由後端先做出一個初步的API，未來在實作過程再討論更進一步的修正。 未來網頁在實作的時候，不管前後工程師，都要盡量當個體貼的工程師，彼此討論修正出對雙方都更方便更彈性的資料，這是很重要的。
• 評估是否需要更動/串接第三方服務 。例如：要串哪一間金流，是否有每月定時扣款功能可以符合訂閱功能 調查某一種功能，要串接哪一家的服務，而此間公司提供的功能的系統是否符合，且服務是比較好，價格是能夠接受的。
• 撰寫測試 指自動化測試，每一次系統部屬上去的時候，他都會跑一次自動化測試，有什麼好處?他真正的價值不是在，確定你剛剛寫的程式是正確的，而是在未來每一次的更動，你都可以確定你前面的寫的程式都是正確的，最害怕的就是寫a壞b，改b壞c，異種瀑布式的修改，這樣一整天工作的心情就會非常糟糕。

以上是後端工程式要去評估及實作的一些流程。

而在上面提到的一些API資料庫，第三方服務，資料格式測試，這些在比較大的公司會有專業的分工，而較小的公司有可能會統一歸納交給後端工程師，所以可能會跟未來的職掌不太一樣，但也不需要太害怕為什麼需要學這麼多東西，真正重要的是學習這些東西的過程中順便排養出一種解決問題的能力，未來遇到一個新的stack下來，可能沒有處理過，但卻可以用過去的經驗來評估要如何學習這個新東西以及攻克它。

PM所需負責的工作：

1. 需求確認、盤點
2. 規劃開發時程
3. 確認資源(人力、時間、$$)

Yenting補充分享： 其實很多人會認為PM有技術能的時候可以加分，但這個加分不是在人力不足的時候，自己跳下去開發，而是加分在你知道整件事情的一些原理跟脈絡，所以可以做出一些比較好的人力資源分配或式時間管理。 其實這個道理在其他地方也是一樣的，例如前面提到的前端工程師是否要做畫面設計，也許許多前端工程師他是有這個能力，但當你的團隊裡面其實有一個人很明確的分工，他就是網頁設計師，這就是他的工作的時候，那你就不應該跟他去搶工作，那不然你這樣子就會造成重工其實也很難管理，所以同理得證，有時候及時你是個 full stack ，你今天這個任務分配到後端那你也會前端的時候你要不要跳下去做? 如果沒有被分到的話你就不應該做這件事情，所以這個道理其實是apply在很多不同的角色上面，所以希望大家可以知道，因為當你是一個團隊作戰的時候，你要專注在deliver你自己應該要做什麼事情的時候，這其實才是最應該要先完成的事情，而不是你今天會很多技能，所以你就要做很多事情，團隊運作不應該是這樣子。

PM執掌清單：

• 確認並清楚定義專案需求
• 預估中案所需的資源，包含人力、時間、預算
• 規劃開發時程
• 提供初步對專案成果的發想(User Story、Wireframe)
• 測試：檢查工程部開發出來的功能是否有滿足需求(使用者的角度測試，非後端工程測試)
• 擔任產品的內部代言人-用比較宏觀的角度去看產品，評估哪些功能最有價值優先開發 。知道產品現有的問題 。產品在使用者端的問題 。產品的內部邏輯

如何跟工程師配合做一個好的PM：

筆記Jiang分享 : PM要能夠掌握整個開發的節奏，要讓工程師明確的知道當前的任務要做什麼，目標在哪，什麼時候要完成，有問題的時候可以討論，PM的彈性跟能不能掌握這個專案的進度是很重要的 筆記Kuan分享: 讓工程師專心做該做的事，工程師會做一個時間的評估，好的PM不應該一直去壓時程，當然PM有他的壓力，但一個好的PM可以把所有的需求梳理成一個很順暢的時間線，分配各個工程師至擅長的位置，工程師最討厭覺得最煩躁的是，我做A做到一半被叫去做B，前面的東西做一半就卡到，或是這個需求沒有先確認完，然後做到一半就做修改。

團隊衝突情境1：設計師想要放Fixed title，前端工程師評估實作會太複雜。你會怎麼做?

1. 先這樣先這樣，總之需求開了，先做再說，先交付任務在討論。
2. 這什麼??覺得需求不合理，先跳過不做，完成其他需求。
3. Hmm 我想想，覺得需求不合理，先找設計師討論

Jiang分享重點筆記：

工程師在業界建立起自己能力所及到哪邊，要非常清楚的技術展示在哪個環節，要有辦法去掌握這個東西。

當需求進來時，要先思考這個需求會觸及到哪些專案當中程式碼的組件，切版，程式邏輯，可以用畫圓的方式表現，當畫出來後大概就知道這個需求觸及的範圍有多廣，若和原定的距離想差甚遠，就必須去思考怎麼跟設計師溝通，讓設計師了解到當前的問題(例如：實作畫面時有時是使用已經既有的組件，若要去加相關新功能，可能會有排斥現象、邏輯不符、或是有很多副作用跑出來)，與設計師溝通取一個中間值需求，但同時要記得設計師最終想要的目標是什麼，未來有餘裕的時候思考這功能有沒有辦法做到，那需要花多久時間去實踐。除了自己知道要做什麼之外，也要知道別人最終想要什麼，記錄下來未來有機會在慢慢發掘，最後在反饋給自己的團隊，這會是一個正向循環。

團隊衝突情境2：後端工程師發現「最新」及「近期熱門」分類，出現的文章會很像。

1. 最新&近期熱門都是很常見的分類，即使有重複，還是把需求做出來比較好，畢竟交付的時間也很緊急。
2. 評估後覺得做出來的觀看體驗可能不好，想先找PM討論替代方案。
3. 先做其他功能/想辦法找資源做出來

總結