今網智慧科技股份有限公司 前端工程師

薪資結構 月薪符合市場平均水準，但年薪僅保障 12.5 個月，其中 0.5 個月為春節獎金。 原有的季獎金制度在 2024 年取消，改為中長期專案獎金，員工須在本職專案之外額外完成指定任務，一項中長期短至三個月，長至半年以上，最終中長期獎金以過往案例來看約落在 $2,000-$5,000。 績效考核 年度績效採評分排名方式進行評級，並非已本職專案成果為主要評級依據，而是以員工在部門中的能見度表現為指標，例如主動召開會議、分享新技術等。 由於主管技術背景與工程師存在落差，因此即使在專案上有技術層面突破，對於績效評核幫助實際不大。整體評估方式對中性格較內斂的工程師而言，參與成本較高 根據過往同事的實際紀錄，排名中等（B），年度績效獎金落點約在 $7,000~$12,000 之間。 公司採取偏向常態分配的績效制度，部門整體評分會被控制在一定平均值內，以避免不同主管評分尺度差異過大。 這種制度的優點是能統一評分標準，避免過度集中單一部門，但缺點是即使整體團隊表現不差，也通常仍需要拉出相對後段的評等，低評等者可能影響獎金，甚至進入 PIP。 我個人感受上，這種制度容易形成末位淘汰文化，且讓團隊長期處於競爭而非共事。 其他福利 端午節：無獎金，以實務禮品替代。 中秋節：無獎金，2025 年為月餅 + 品牌吉祥物抱枕。 勞動節：無獎金，2026 年為公司產品紅利點數 1,000 點 + 某連鎖品牌按摩券。 生日：當月生日假一天 + $200 尾牙： 1. 現金抽獎，表上最大獎為 $66,000 一名，實際可能會有創辦人或總經理額外加碼，2025 年尾牙整體現金獎項約共 25 名 + 額外加碼約 10 名。 2. 特殊活動抽獎：員工先自費參與抽獎，獎項多為參加者報名費由中獎者均分、公司實體庫存 不定期活動：部門約 3-6 個月會有一次部門聚餐以及一次下午茶，公司在特殊節日可能會有聚餐，例如中秋烤肉

辦公區 RD 分為兩個區塊，以下簡稱新辦公室、舊辦公室。 舊辦公室為傳統辦公桌，新辦公室為 IKEA 手動升降桌。 前端電腦配 MacBook Pro，CPU Intel ~ M3 都有，不確定是如何分配的。 公共環境 整層樓約 60 - 70 名左右員工，女廁似乎是兩間，男廁則是一間蹲廁及兩個小便斗。 男廁蹲廁是配置免治馬痛。 整層樓共一台飲水幾。 若急需廁所或飲水機可至樓下辦公室使用，但樓下配置也跟本樓層一樣。 以前需要隔週打掃辦公室，近期改成有請廠商清掃辦公室，讚讚。

近一年公司為了拼上市櫃，整體方向明顯偏向快速推出新產品、新功能，希望能提高市場話題性與吸引投資人注意。 但另一方面，現有專案其實已經累積不少技術債，RD 內部也一直有重構與優化的需求。結果就變成上層希望持續推進新功能，工程端則希望先處理維護與架構問題，兩邊目標經常互相衝突。 工作分配方式也偏混亂。 RD 主管想到哪裡需要優化，就會直接指派任務；上層臨時有新需求，也會直接再塞新的工作進來。原本去年有導入 Scrum 流程，但實際上沒有完整落地，例如 review 會議幾乎沒真正執行過。 實際工作狀況常常是： 原本正在開發中的功能做到一半，突然又被插入新的優化需求，並且要求立即評估時程。 此外，部分專案每週都需要持續回報進度。 如果因為任務量過大，導致部分工作沒有明顯進展，得到的回應通常會是：「你每天抽一兩個小時做就好，其他工作還是照常進行。」 另一個比較大的問題是，多個角色都能直接派工作： - 過去經手專案的 PM / 專案負責人 - 直屬主管 - 直屬主管的主管 - 直屬主管的主管的主管 但這些人彼此之間通常不會同步你的工作內容，因此常常會出現多方同時派任務、優先級互相衝突的情況。對 RD 來說，長期下來負擔其實蠻重的。 而每隔週 1on1，直屬主管才會在此時跟你確認你身上有哪些任務，而非在任務來之前就先進行過濾及安排。

RD 部門的管理層級拆分為處主管、部主管、課主管。 整體運作模式大致上是： - 處主管負責訂方向與目標 - 部主管負責提出有哪些事情可以做 - 課主管再把這些目標與需求往下分派給工程師 而實際執行層面，通常是工程師自己去評估： - 哪些地方需要修改 - 哪些架構需要調整 - 哪些需求需要其他部門配合 很多時候，管理層比較偏向「提出方向與追進度」，但實際落地與跨部門協調，大多還是落在工程師身上。 另外一個明顯的問題是，管理層會議非常多，導致實際上常常很難找到能立即做決策的人。 不少主管也傾向把責任集中在自己身上，沒有有效往下授權，因此很多事情雖然表面上有人負責，但真正需要推進時卻找不到窗口。 尤其某些主管的溝通方式，經常是： - chat 長時間不回覆 - 即使人在座位上也不會回訊息 - 不直接走到旁邊詢問，事情就會一直卡住 跨團隊合作上也有明顯斷層。 以前端與後端主管為例，彼此對對方目前的工作狀況與資源分配幾乎沒有同步。 近期有個案例： 某專案原本想進行重構，前端主管詢問後端主管是否能提供後端人力協助，但得到的回覆是沒有資源可以投入。 於是前端這邊決定，既然後端無法配合，那就先以前端框架重寫的方式繼續進行。 結果過了一段時間後，後端那邊又啟動另一個服務的重構，反過來詢問前端是否能支援人力。 但當時前端團隊的人力，早已投入在前面那個「重寫中的專案」，自然也無法支援。 最後變成： - 前端持續重寫專案 - 後端重構停擺 - 雙方都投入大量時間，但整體協作效率並不好