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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PM所需負責的工作：

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

PM執掌清單：

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

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

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

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

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

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

總結