開課日期：2026-03-24上課地點：台北市大安區復興南路二段237號4樓上課費用：線上洽詢 課程介紹： 整 …

開課日期：2026-03-24
上課地點：台北市大安區復興南路二段237號4樓
上課費用：線上洽詢

課程介紹：

整合 SSDLC、UIUX 與資料驅動差異、AI 輔助開發、AI 程式碼審查、AI 測試與除錯 等主題。透過案例、實務演練與實作示範，學員將能在課後立即導入 AI 工具到現有專案流程，實際提升生產力與產品品質。

~本課程歡迎企業包班~

報名此課程

課程內容：

* 課程執行單位保留調整課程內容、日程與講師之權利

報名此課程

備註：
詳細內容及報名需知，請點選報名後見協會網站內容

[elementor-template id="128291"]

這篇文章 【3/24台北場】AI輔助軟體開發實務 – 工研院產業學院(台北學習據點) 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

創聚元科技有限公司是一家專注於軟體開發和運營的公司，致力於為客戶提供創新的解決方案，該公司目前正在積極招聘Go語言後端開發工程師，以擴大其技術團隊，應對不斷成長的市場需求，創聚元科技計劃利用Go語言開發各種類型...

記者 鄧天心／採訪報導

創聚元科技有限公司是一家專注於軟體開發和運營的公司，致力於為客戶提供創新的解決方案，該公司目前正在積極招聘後端語言後端開發工程師，以擴大其技術團隊，應對不斷成長的市場需求，創聚元科技計劃利用Go語言開發各種類型的應用程式，包括交友軟體和即時通訊應用程式，此外，創聚元科技希望開發類似於中國LINE的即時通訊應用程式，在雲端應用的部署方面，創聚元科技希望支持在亞馬遜雲端（AWS）上運行，開發應用程式的部署和維護工具。

更多新聞：該不該回辦公室 科技業為何還吵不停

創聚元科技看重Go語言的簡單性、高效性和並發性，認為它非常適合開發現代化的應用程式，因此正在積極尋找具有Go語言經驗的工程師加入團隊，以推動公司的技術創新。

Go語言的編譯速度非常快，執行效率也相當高，這使得它在需要高性能的應用中表現出色，同時它還支持跨平台編譯，能夠生成在Windows、Linux和macOS等系統上運行的可執行文件。

招聘後端語言工程師的要求

在招聘後端開發工程師時，創聚元科技主要關注面試者的技能和經驗。首先，該公司希望面試者具備約3年的相關工作經驗，在技術能力方面，創聚元科技希望候選人熟悉AWS的具體功能，並具備使用Docker進行部署的經驗。

此外，應聘者需要熟練操作Linux系統，並能夠使用各種自動化部署工具。最重要的是，能夠編寫服務器維護工具，例如日誌自動備份和上傳，並且熟悉相應的編程語言。

在面試過程中，創聚元科技將聚焦在四個關鍵問題，以評估其技術能力，包含曾經使用過的AWS功能及其應用場景，接著，使用過Docker進行部署的經驗，並請其分享具體的項目經驗，最後，為了了解候選人是否能編寫服務器維護工具，面試環節中會請面試者分享所使用的語言和工具。

創聚元科技正在積極尋找具有AWS開發經驗的工程師加入團隊，為了營造輕鬆愉快的工作氛圍，創聚元提供了一個充滿激情和創新的工作環境，鼓勵團隊成員在工作時聽音樂，並提供咖啡和點心，歡迎有志之士一起開創更美好的未來。

這篇文章 創聚元科技積極招聘後端語言工程師 推動技術創新 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在軟體開發中，前端和後端工程師需要密切合作。前端工程師主要負責用戶界面和用戶體驗，而後端工程師則負責搭建數據庫、維護資料安全性.

記者 鄧天心／綜合報導

在軟體開發中，前端和後端工程師需要密切合作。前端工程師主要負責用戶界面和用戶體驗，而後端工程師則負責搭建數據庫、維護資料安全性並設計API。對於希望轉職成為工程師的人來說，前端工程師通常是較易入門的選擇。在這次採訪中，我們與壹立方數碼創辦人暨執行長林育進聊聊他24年來在軟體開發產業的經驗，他分享了從前端工程師開始的職業之路，以及前端工程師需要具備的基礎能力和日常工作內容。

更多新聞：軟體應用工程師 陽光伏特家：要懂技術也要懂業務

從前端入門資歷更完整

林育進認為，前端工程師相對於後端工程師來說，是較容易入門的職位，甚至也是產品拿到使用者前的最後一道防線，「更是最後的完成者」，他以自身資訊工程系畢業的背景和豐富的管理經驗為例，指出前端開發需要熟練掌握HTML、CSS、JavaScript等技術，並熟悉流行的Vue.js和Node.js等框架。但他認為，一旦有了這些基礎能力後，學習第二種編程語言就會變得更容易，就像學習繁體字後再學簡體字一樣。因此，在公司招募缺乏相關經驗的工程師時，林育進通常會建議他們從前端工程師的角色開始，然後再轉向後端的領域。

期望工程師特質：有自主思考能力

聊到關於「期望的工程師特質」林育進強調了「自主思考」的重要性。他希望工程師們不是只聽從指示，而是能夠主動思考和解決問題。例如，在設計會員註冊流程時，如何確保手機驗證過程的順暢，以及欄位設定防呆機制，才能有效控制成本，這都是他認為一位合格的工程師需要考慮的問題。

他進一步談到，一個有經驗的工程師應該能夠提前預見並解決潛在的問題，而不是僅僅依賴QA工程師和測試人員，當前端工程師沒有先提出問題時，會加諸不必要的麻煩給團隊，因此林育進在面試一位資深工程師時，首重他的責任感和自主思考能力。

談到喜歡聘用初階工程師，還是資深工程師，林育進笑笑的說「以前喜歡用沒經驗的白紙，現在喜歡有經驗的工程師。」他進一步解釋，沒有經驗的人少了一點歷練跟不同思維的碰撞，溝通上需要耐心，但相較有經驗並能真實回饋的工程師，不用太多交辦，就能更好地把複雜的問題簡單化，也是他在多年管理上的體悟。

在選擇新員工時，林育進希望找到展現出願意與公司共同前進的心態的人。「人員流動對我們來說是一大困擾，公司願意投入資源培養員工，但如果員工沒有積極反饋和成長意願，這種投入就會變得沒有意義。」因此，林育進特別重視應聘者的態度和心態，是否能夠正面看待事情，主動解決問題，而不是僅僅聽從指示。

壹立方數碼開發多元產品及創新商業模式

壹立方數碼在臺南成立超過20年，現已發展至二十幾人的團隊，產品領域橫跨美髮業、醫療產業及物聯網等，壹立方數碼專注於提供不同產業的資訊整合，並在開發專案上積累了豐富的經驗，以目前的產品為例，有美髮POS系統和頭皮檢測系統，美髮POS系統已經推出到第三代版本，並計劃今年推出手機安裝版本，特別的是這款產品過往收取年費，但考量到用戶使用一個系統，需要至少三個月到半年時間，才能真正體驗到其功能是否符合需求，因此他們改採用了點數制，同時也能讓他們在設計和開發過程中，更快迭代打磨細節。

林育進跟許多單獨創業的科技老闆一樣，從產品規劃到執行，都親自參與每個過程，在進行啟動會議時，就會確保每個人都清楚自己在專案中的定位，而壹立方數碼能接觸多元領域並快速開發產品，仰賴於執行長對市場需求的理解，以及在乎使用者體驗，在人員編制有限的團隊理，沒有龐大的業務團隊，但穩定的產品品質，仍有源源不絕的舊客拉新客，並為公司帶來穩定營收。

想了解更多的科技業職缺嗎？由科技島與1111人力銀行攜手合作、透視上百種科技工作內容與薪資行情的「職缺百科」正等著您前往探索！

[elementor-template id="118858"]

這篇文章 【前端工程師】壹立方執行長林育進：期望特質有自主思考能力 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

高雄師範大學軟體工程與管理學系系主任李文廷認為，生成式AI確實能提高工程師的工作效率，讓他們能更專注於創造性的任務和複雜的問題解決。不過，工程師的角色不僅僅是編寫程式碼，還涉及到理解業務需求、設計系統架構、解決複雜的問題，背後仍然依賴於具備專業軟體開發知識的人才。

記者／林育如

資訊科技的快速發展大幅提升了對軟體工程師的需求。從雲計算、大數據到人工智慧和物聯網，這些前端技術都需要專業的軟體工程師來開發和維護相關系統和應用。尤其在金融、醫療、製造等領域，對於具有專業技能的軟體工程師需求更為迫切。高雄師範大學軟體工程與管理學系致力於培養專業資訊軟體人才，提供紮實的軟體工程理論基礎及團隊溝通與合作能力的訓練，並將軟體工程技術應用於不同領域。畢業生不僅能夠順利進入職場，還可選擇投身教職或深造等多元發展路徑。

高雄師範大學軟體工程與管理學系李文廷主任表示，高師大軟體工程與管理學系著重在軟體開發及管理這塊，課程規劃強調軟體工程技術及應用課程。軟體設計課程除加強基本程式設計與系統分析能力外，並開設軟體開發方法、資訊系統架構、設計模式、人機介面設計、專案管理、軟體流程改善等進階課程。因此，軟體工程系以培養高級軟體開發與管理人才為發展特色，以軟體技術研發為主軸，希望能結合跨領域共同開發軟體應用。

扎實基礎、實習接軌實務

高師大軟體工程與管理學系課程設計採模組課程，共有二個模組：資訊技術模組與資訊應用模組，學生畢業前最少須修畢一個模組課程。學生們可以依照自已的興趣，選擇適合的模組。

李文廷主任指出，系上與多家業界企業簽訂了產學實習合約，包括資策會、叡揚科技、威聯通科技、哈瑪星科技等，並鼓勵大三和大四的學生積極參與實習。尤其在大四下學期，系上提供了靈活的實習選擇，學生可以選擇到產業界實習，並有機會修習9學分的兩門選修課。這樣的安排不僅讓學生獲得課程學分，還能加深對產業應用和人才需求的理解。統計顯示，大約一半的學生選擇了產業實習，另一半則選擇留在學校上課。

學生在實習中獲得的回饋普遍很好，因為課程內容注重實務面向，並與最新的技術和軟體工程趨勢緊密結合。例如，大數據分析、人工智慧和物聯網等前沿技術，都可以在系上學到。無論是課程還是實習，系上都致力於培養學生實際解決問題的能力，以及合作與溝通的技巧。這樣的安排有助於學生在實際工作中更好地應對挑戰和需求。

除了實習之外，學校還會安排了業界人士來校演講或進行周會分享，讓學生提前了解行業動態和工作實際。這些活動不僅提供了寶貴的業界見解，還幫助學生提早規劃未來的職業生涯。

畢業出路多元：就業、升學、教職

李文廷主任表示，不少學子因實習期間表現優異而畢業後直接獲企業聘用。高師大軟體工程與管理學系學子就業機會多元，每年畢業學子約有二分之一進入國內外研究所，其餘則投入職場，包括資訊科技、半導體、製造、金融、公職或教育等領域。

由於屬於師範體系，除了公費生能從事教職外，每年還會提供一些保障名額，讓有志於教職的學生可以申請。此外，學生也可以通過其他甄選方式來擔任教師。

人工智慧學程跨域學習

因應近年來人工智慧的爆發式成長，高師大開設了人工智慧學程，供全校學生選修，以培養他們在這一領域的專業能力。

對於不少人擔心生成式AI是否會取代人類，李文廷主任表示，生成式AI能夠快速生成文章和程式，這確實是一個巨大的機會，有助於提升軟體工程的生產力。不過，大型軟體開發仍然需要具備程式設計和應用等多種基礎能力。只有具備理解程式的能力，才能有效地進行大型軟體的開發。

專業進階的能力是生成式AI無法取代的，這也是系上培養學生必須具備的技能。例如，大型專案的管理、溝通協調與審查、系統分析與測試等，都需要高度的腦力密集和人為主的能力。這些都是生成式AI無法執行的。

選系、職涯發展以興趣為導向

軟體工程在各行各業都有廣泛應用，包括人工智慧、資安、物聯網、智慧醫療、大數據分析和自駕車等領域。李文廷主任建議，對資訊科技、軟體開發、程式設計以及專案管理有興趣或具潛力的同學，都歡迎加入這個充滿機會的領域。

這篇文章 高師大軟體工程與管理學系全方位培養專業軟體開發人才 打造多元職涯發展路徑 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

很多人迷失在開始和結束之間，開發東西非常困難，不管你的準則是什麼，或你在牆上掛的是什麼格言，大多數專案都會超出時間、超出預算、或是遭到取消。

文／堡壘文化

一九八三年九月，蘋果的麥金塔專案進度嚴重落後，團隊已經油盡燈枯，但還剩下很多工作要做。

蘋果的執行長暨該專案充滿遠見的領導者史帝夫．賈伯斯經過團隊辦公室的主要走道，並在附近的黑板上寫下後來他最知名的其中一句名言：「會發布作品才是眞正的藝術家。」

他寫下這句話，是因為他想強迫專案團隊更努力工作、更早結束專案，今日這句話成為許多領域創新人士的口號，但他們都忽略了當時賈伯斯強調的是發布， 而非藝術。

僅僅是發布某個東西，並不會讓你成為藝術家，然而，不管是藝術或是垃圾，世界要理解你創造出的東西唯一的方式，就是當你勇敢到能夠宣布已經做好了，並向全世界展出之時。

賈伯斯的名言讓人很容易忘記沒有人展開一項專案時，是計畫不要發布的。

沒有一整個聰明又努力的部門，心懷深沉又熱情的希望苦幹實幹了好幾個月，卻覺得等他們完成後，他們的成果會被裝進板條箱中，並運送到《法櫃奇兵》裡的倉庫，永遠不見天日。

所有熱情的開發者，都是受到能看見目標受眾使用他們開發成果的渴望所驅策；而且事實還恰好相反，多數擁有偉大創意的人，都會太快跳到發布這件事，並把他們第一個充滿靈感的晚上，花在幻想發布後世界會帶給他們多少榮耀， 即便他們根本就還沒有做任何事。

夢想是免費的，發布則需要自己爭取。發布任何東西都可能很困難，就算只是份大學的期末報告， 或是一頓感恩節晚餐。

現在就有數千名企業家和程式設計師正在空轉，要不是卡在似乎解決不了的問題上，就是執迷於很少用戶會注意到的細節。

在試圖發布的過程中，有很多狡猾的陷阱，這解釋了為什麼有這麼多人迷失在開始和結束之間，開發東西非常困難，不管你的準則是什麼，或你在牆上掛的是什麼格言，大多數專案都會超出時間、超出預算、或是遭到取消。

請你看看生活周遭所有的機器、書籍、工具、應用程式，這些東西能完成到產出根本就是奇蹟。

針對該怎麼克服發布出優質成果背後的挑戰，在這個思辨的核心中有個概念，源自艾瑞克．雷蒙的同名著作《大教堂與市集》。

這本書是有關開發軟體過程的各種觀察，其中提出了一個和所有工作相關的重要問題：要把時間投注在規劃一個精細的大型計畫上，還是直接開始，並在過程中找出辦法比較好？

你想像一下高聳摩天大樓的建築師，或是大成本電影的導演，你的印象很可能會是一名厲害的暴君，擁有詳盡的計畫，規範所有事情該怎麼完成。

這就是大教堂風格的思維，第六章提到的海濱鎭，就是根據一個精細的計畫建造，體現了這種方式。

至於另一種方法，則是請想像一下一個年輕的龐克搖滾樂團剛開始玩團，他們會從小地方開始，寫幾個簡單的和弦，然後很快修改，接著再次修改，每個團員都用自己想要的方式貢獻、借用、實驗、合作，這就是市集模式。

比起恢弘的中央規劃，工作社群會圍繞著某個構想形成並發展，許多知名的開源專案，例如 Linux 作業系統，都是採用市集思維開發，而這也啟發了雷蒙的著作。

然而，世界上有多數地方，包括大多數的軟體產業，相信的都是大教堂模式。

但在實務上，這其實是個錯誤的二分法，多數事物都是結合大教堂和市集模式完成，只不過兩者之間的平衡可能差很多。

不像興建摩天大樓，數位工作比較可以用市集般的態度漸進式改變。比起生產飛機、興建橋樑、甚至是做舒芙蕾，一個小錯誤就可能毀掉所有事，開發軟體的風險很少會這麼高，多數軟體其實是不受規範的。

相較之下，橋樑、醫療器材、汽車則是必須通過安全檢測，產品才能上市，這也導致了這類領域有嚴格標準。

擔心鑄下大錯或是進度落後，是世界上多數專案管理過程背後的動機，管理者經驗越豐富，看過的壞事就越多， 也有越多事必須試著避免， 我將其稱為「防禦性管理」，因為其目的是要防止一長串壞事發生。

防禦性管理很盲目，看不出執迷在防止壞事發生，同時也會遏止好事發生， 有時候甚至導致什麼事都不會發生。

WordPress.com 每天都會發布某個東西，常常是某個小東西，比如修復某個錯誤，或是細微的調整，但仍然是新東西沒錯。

我在二○一○年八月受聘進入公司時，WordPress.com 總共更新了兩萬五千次，而我二○一二年離開時，則是已經來到超過五萬次。

東尼．史奈德便用「持續部署」一詞來形容這個不斷進行小型調整的哲學， 所有點進使用 WordPress.com 主機網頁的訪客，看到的永遠都會是最新版本，很可能才剛發布幾秒鐘而已，程式設計師和系統設計師想多常發布，就多常發布。

這通常代表他們一完成就會發布，不用排隊測試、也不用互相檢查，不需要時程表或大計畫，因為根本不需要死線、日期、其他協調，也不需要什麼管理，因為根本沒有什麼要防禦的。

就算在最糟糕的情況下，搞不好某個版本不小心用該死的殭屍香蕉照取代了所有部落格，也可以回溯，讓軟體回到先前的版本，不過回溯程式碼頗為罕見，公司鼓勵程式設計師直接進行其他調整以修復問題，並規定所有發布了某個東西的人，都必須待在線上幾個小時，保證一切運作順暢。

缺少宏大的時程表，也移除了許多專案創造出來擔心進度會落後的恐懼，並以微小卻高頻率的成果取代。

我們讓狀況越來越好，工作感覺比較像是在吃一頓西班牙下酒菜，每隔幾分鐘就會有小盤小盤的美味食物送上桌，你不需要排隊，或是等到下一餐的時間，用戶也不需要等，不管他們在做什麼，使用的永遠都會是最新版本。

而且所有員工也都能在 IRC 上，看到程式設計師之間互相分享新的調整，我們通常稱之為修正檔，以便在發布前協助測試。

有時候光是一天就有可能發布二十五個修正，在忙碌的日子中，IRC 會充滿程式設計師彼此協調他們的發布，確保不會互相衝突，在旁觀察這些總是相當有趣。

相較之下，我一九九○年代在微軟開發 Windows 時，我們每隔幾年才會發布一個新版本，而同年代的瀏覽器戰爭期間我負責開發 IE 時，頂多也只是每個月發布一次。

由於我先前參與大型專案的經驗，讓我許多朋友都覺得在 WordPress.com 的混亂中工作， 對我來說會是件很困難的事。

結果調整起來還蠻簡單的，當時微軟的 IE 團隊有個相同的東西，叫作「每日開發」。

我們每天都會發布軟體的新版本，但只限於在公司內部流通，每一天都會彙整前一天所有的調整發布，也鼓勵每個人都安裝來用用看，以此為開發品質提供固定回饋。

加入新功能的過程中有珍貴的歡笑，也有悲慘的時刻，在日子好時開發品質非常好，我們就會將這些版本稱為「自行運作」，也就是「能夠安全在你的電腦上運作」；

品質普通的版本叫作「自行測試」，也就是建議你只安裝在測試用的電腦上就好，或是趁同事不注意的時候裝在他電腦上；

品質最糟糕的版本則叫作「自行燒焦」，表示你要是敢安裝，那不管裝在哪台電腦上都會報廢。

只要我們連續三天發布的版本都是自行燒焦，就會暫停所有開發工作，直到我們讓開發品質恢復到正常水準，這是個防止專案品質爛到谷底的方法。

在 WordPress.com 這邊的發布也是依據同樣準則，只是過程加速，而且也向用戶開放而已，我不覺得缺少大型計畫或時程表是個問題，事實上，我大多時候都感到自由。

對任何曾經參與過大型專案的人來說， 這一切聽起來都超瘋狂的，沒有時程表要怎麼做事？怎麼能沒有安全措施？事情為什麼不會直接爆炸，或是從頭到尾都互相衝突？

這種方式之所以可以運作，主要原因便在於 Automattic 信奉一套反直覺的準則：安全措施不會讓你安全，而是會讓你懶惰。

大家在駕駛有防鎖死煞車系統的車子時，會開得更快，而不是更慢；美式足球員因為他們的防護，也會承擔更多風險，而非更少。

在 Automattic，打安全牌的陷阱會受到抵制，大家比較是受到自主感驅策，而不是什麼宏偉的工作原則，基本概念是如果大家都聰明又彼此尊重、不會把事情搞砸，那麼過多安全措施反而會擋路。

相較之下，員工在此受到信任，更擁有權力可以快速發布成果。

本文摘錄自《不穿褲子工作的一年》，堡壘文化出版。

這篇文章 專案的成功關鍵！賈伯斯：會發布作品才是真正的藝術家 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

編譯／鄭智懷 跨國資安公司趨勢科技（Trend Micro）發現，廣受各界好評和使用的線上編輯器GitHub …

編譯／鄭智懷

跨國資安公司趨勢科技（Trend Micro）發現，廣受各界好評和使用的線上編輯器GitHub Codespaces的公開共享通訊埠轉發（sharing forwarded ports publicly）功能可能被駭客濫用，合法運用GitHub設立惡意軟體伺服器。即使該伺服器提供惡意程式如腳本、惡意軟體或勒索軟體，也不會被標記為惡意或可疑內容，順利通過各組織的檢測，將相關事件通報為良性或誤報。

趨勢科技指出，GitHub 的Codespaces服務允許軟體開發者在前者的瀏覽器創建、編輯與運作程式碼。若惡意行為者將通訊埠設定為公開共享，即可在無需身分驗證的情況下託管惡意程式，且所花費的成本比Azure、亞馬遜雲端運算服務（AWS）、谷哥雲端平台（GCP）更低廉。

在趨勢科技的概念驗證（proof-of-concept）攻擊中，研究員以Python程式語言運行了一個使用超文件傳送協定（HTTP）的伺服器，轉發並公開該通訊埠。研究員表示，不僅其中存有URL 和用於身份驗證的 cookie 的缺失，軟體開發者還可以自由將任何通訊埠在超文件傳送協定及超文件傳送協定安全（HTTPS）之間切換。

研究員補充道，即使是使用VirusTotal等惡意軟體分析網站對該伺服器作進一步分析，分析結果也顯示為沒有惡意歷史記錄，從而減少阻止下載惡意程式的機會。

該研究報告總結，「雲端服務同時為合法用戶和攻擊者都提供了優勢」。「當惡意行為者利用相關資源時，向合法用戶提供的功能也可以為前者所利用」。

資料來源：The Hacker News

這篇文章 資安專家：GitHub Codespaces可輕鬆傳播惡意軟體 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

編譯／鄭智懷 隨著越來越多數位設備出現，以及有更多的設備連接到物聯網，其中的安全漏洞預估會大幅增加，進而影響資 …

編譯／鄭智懷

隨著越來越多數位設備出現，以及有更多的設備連接到物聯網，其中的安全漏洞預估會大幅增加，進而影響資安產業於2023年的發展。在此背景下，資安專家前瞻2023年資安產業，提出五大可能變化如下：

• 資安產業加速整合

近年來，由於資安領域炙手可熱，吸引大量投資者與人才投入經營。不過，並非所有人都大獲成功。同時，大型資安廠商也會透過併購壯大技術實力。在2023年，鑒於經濟持續不景氣，部分缺乏優秀產品，或是市場佔有率過低的小型廠商將面臨倒閉風險，或是遭到併購，加快資安產業的整合。

• 資安人才市場惡化

經濟不景氣同樣衝擊資安人才市場的發展。過去數年之中，許多人紛紛投身於考取各種盯上資安市場飛速成長，宣稱可以保障就業的證照─但事實上卻經不起考驗。而業界大砍人事成本，減少薪水支出以因應經濟衰退的舉動卻使更多的人期待透過取得證照而提高薪資，形成惡性循環。上述的情勢進一步加劇資安人才市場的負面發展。

• 攻擊面管理工具式微

攻擊面管理（Attack surface management）產品是近年來各大企業持續關注的網路安全技術，旨在協助使用者發現和管理數位資產的安全漏洞。不過，分析家質疑，市場上大部分的產品僅在標準資安商品上添加少許功能，是風險投資公司趕流行的投機產物。因此，攻擊面管理產品勢必備受考驗，多數徒具其形的無用產品將逐漸消失。

• 員工重返辦公室

過去大肆流行的遠端工作模式在2023年將逐漸扭轉，員工重返辦公室勢在必行。受此趨勢影響，開發商也將重視並積極修復遠端軟體的安全漏洞。

• 政府與私人企業大鬥法

儘管政府開始出手限制企業的商業活動，不過，大型公司會透過各種手段影響政府立法與執法，以獲得更大利益。事實上，政府推動的資安政策也並非能促成所有私人公司的正面發展。以近年流行的軟體材料清單（全名為Software Bill of Materials）為例，小型軟體開發商可能就無法負擔相關的開銷成本而面臨倒閉的風險。

資料來源：Help Net Security

這篇文章 資安產業2023年五大轉變 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

Facebook 臉書產品經理（PM） Ben Erez，前幾天在 LinkedIn（領英）發表了一篇動態，感嘆他之前擔任 PM 時，花太多時間在需求管理的瑣事上，比如在 JIRA 創建任務清單、規劃衝刺期內容等。

圖文／Selena Chen (陳亭勻)

Facebook 臉書產品經理（PM） Ben Erez，前幾天在 LinkedIn（領英）發表了一篇動態，感嘆他之前擔任 PM 時，花太多時間在需求管理的瑣事上，比如在 JIRA 創建任務清單、規劃衝刺期內容等。

而在擔任臉書 PM 後，這些專案管理的文檔事務改由工程師自治負責，他則專注在策略、願景與夥伴關係，發揮自己的價值。

他建議同業思考：「團隊是否花太多時間在需求管理的瑣事上？」

業界的正反迴響

文檔與任務管理真的是產品經理（PM）可以拋棄的瑣事嗎？

這則貼文吸引七百多則回應，回應中有三個主要觀點：

• 贊同派認為，Ben Erez 點出敏捷開發的弊病，也就是過於專注在方法與標準流程，卻忽略敏捷的精神。
  同時，這樣的做法將 PM 從日常文檔瑣事解放，更有機會發揮產品經理的價值。
• 中立派覺得，貼文描述一個極為理想的開發環境，也是許多 PM 希望能達到的境界。但也許只適用於特定條件下：(A) 資源豐富的企業，如臉書；(B) 矽谷等高階工程人才齊聚的地方； (C) 或是具有高度自治能力的團隊。
  畢竟多數工程師，更傾向看到整理列好的任務清單，這樣他們能專注於程式開發與討論。
• 反對派則指出，當 PM 不再管理需求，也不再處理這些專案管理的事務時，究竟是對公司、團隊帶來更多益處，還是只對自己的時間管理有利？若 PM 抽離專案管理與工程參與，真的能確保專案開發的效率與成果嗎？

後續也有一位 Atlassian 的產品經理附和 Ben Erez ，不過他也坦承：即使在 Atlassian ，也不是每個 PM 都能擺脫文檔管理的工作。而確實，以他的職位，也不是負責做這件事的人，因此要下論斷並不適合。

不少人指出，之所以有人能擺脫文檔管理的工作，也許只是因為團隊中有別人去做了這件事。畢竟文檔與任務管理、進度追蹤等工作，終歸要有人去做。換言之，也不一定就是工程師該接手去做。

從正反立論可以看出，產品開發流程、團隊管理與職責分配，其實相當複雜，並沒有一體適用的最佳方法。多數人的自述清楚地呈現，不同公司體系、不同團隊規模，甚至不同產品，都有各自的開發流程問題。

不過，大概所有人都同意一個事實：「最終，團隊仍需要有人負責需求管理、建立任務清單，以及追蹤進度」，問題在於，「誰」來做比較好？

產品經理的文檔與管理困境

確實，產品經理的文書工作相當繁瑣。要在 JIRA 上創建任務，寫清楚每張任務的價值、目標、用戶故事（User Story）與實作細節等，並非三兩下就能完成的。

以我的團隊為例，工程師超過 6 位（4 位資深），每兩週完成一次衝刺（Sprint），能交付的任務總量很大，相對地事前要準備的工作也很多。

在這種情況下，除非你有 Delivery Manager 或其他 PM 協助，否則單靠一位 PM 很快就會燃燒殆盡。畢竟，PM 除了組織每個 sprint，也還有各種需求與討論會議要參加，也得抽時間規劃與定位產品、研究競品，甚至設計數據報表、參與用戶調研。

不過，產品經理會成為文檔的最佳撰寫者，有其原因。作為各團隊的橋樑，產品需求多半由產品經理收集而來，因此能說清楚任務價值、目標、開發原因的人，自然也非產品經理莫屬。

此外，藉由需求收集與討論、文檔撰寫、開發討論等，產品經理對公司的其他服務、自身的產品功能與價值，能更深入地理解（這點我體會甚深）。

只是，人力不足的情況已相當明顯。若要 PM 細緻寫完所有文檔再開始開發，PM 就很容易成為團隊的瓶頸（bottleneck），所有事情都卡在那邊。

那麼，我們到底該怎麼應對呢？

我的團隊怎麼改善工作流程、提升效率？

在調整開發流程之前，原本的做法是由 PM 寫需求文檔，並在 JIRA 開完所有 Ticket ，連同 Subtask 一起列好。如果文檔還沒準備好、功能尚未問清楚做法，就會延後到下個衝刺期再開工。

然而，隨著產品規模增長、功能變多、內部跨團隊協作機會增加，倚賴 PM 一人變得越來越不可行。

我們團隊意識到人力與流程問題，因此很積極調整協作與開發流程。經過三個季度，藉由一對一面談、衝刺後檢討會、季末回饋等討論，我們總結而摸索出的方法，就是依據職能優點，在各階段分工，藉此改善原先集中於 PM 所導致的開發困難。

現在， PM 依然會收集需求，寫清楚核心功能的需求與規格，但更多發展中的需求，會交由工程師去作早期調查。文件部分，也適當的調整期望，只要溝通有效即可，不追求每次都寫得超細緻。

簡單來說，我們不再要求需求提交得「一次到位」，而是藉由拆分並進，跑得更快。

調整後的新流程

1. 需求收集
   • 產品經理收集需求後，經過一段時間的研究與討論，說清楚為什麼開發
   • 開發結果會帶來的價值與結果
   • 預期看到怎樣的改變
   • 專注回答 Why, Who, What and Where
2. 工程發想
   • 工程師與工程主管，針對 PM 所提（或自己發起）的需求，先提出大概的解法
   • 告知前置作業、風險、兼容性考量
   • 預估交付時程、是否需分階段交付
   • 專注 How and When
3. 需求排序
   • 當需求討論日漸成熟，足以成為一項任務時，PM 會將之排進開發清單
   • 依優先層級或前置開發所需，排出下次衝刺期的概要任務清單與目標
   • 定案最終設計稿與產品需求文檔
   • 向團隊與利益關係人說明最終的交付項目
4. 實際分工
   • 工程主管會再帶領工程師，針對概要清單，討論詳細作法
   • 開立更詳細的分工任務，也可能衍伸更多工作
   • 這個階段由工程主管或工程師自治，會比產品經理更適合；但產品經理還是會參與部分討論，確保工程師的實作討論，不會為了「快」或「好做」，而偏離實際需求，或是為了達成目的而過度設計
5. 成果交付
   • 工程師會在衝刺期開始時，承諾本期預定交付的項目
   • 產品經理則作為 End User 的代表，在開發過程中提供開發決策建議，或適時調整交付預期
   • 技術文檔則會在開發過程中完成

分工優點

藉由拆解文檔階段與轉移階段負責人，讓各職能可以在不同階段依據所長發揮。產品經理更專注在回答「為什麼要做這件事」，而工程師則涉入更多的開發設計與分工協調。

在實行一段時間後，我們發現，過往由產品經理主導開發工作時，很容易漏掉一支 API，或忽略營運端的 UI 流程設計，導致功能上線後仍需要工程師幫忙改東改西，或在衝刺期中追加許多工作。

但在交給工程師主導開發細節後，由於前後端充分討論，因此漏工程的情況大幅減少。此外，將文檔拆成初稿與終稿兩個階段，除了讓 PM 能爭取更多編寫與思考的時間，也讓工程師有更多思考與設計的空間（對，工程是需要設計的！）

最好的開發流程，應該依團隊而變化

回到 Ben Erez 這則貼文，從他後續的回應，可以知道 Ben Erez 其實仍花很多時間，運用 Gsheet 與臉書內部工具撰寫功能概要、追蹤開發狀態。

此外，他的 EM （Engineer Manager） 與 PPM （Principal PM）則承擔了跨專案追蹤進度的工作。

換言之，他雖然從 JIRA 解放，但並未擺脫文檔工作，而他所描述的美好成果（讓 PM 更專注於策略與願景），則是因為適度分工才能達到的成果。

假設你的團隊沒有 EM ，那有經驗的產品經理可能要更頻繁涉入開發討論。而若你的工程師都是業界頂尖人才，也許文檔不用細到破表，幾個手繪示意圖就能完成溝通。

而你省下的文檔製作時間，可以拿來做更具影響力的事情。比如調節開發節奏，或是中長期的產品定位與願景規劃，以及更多的產品與用戶調研。

總而言之，不同團隊有不同的行事方法與溝通流程，但最重要的是，與團隊一起優化屬於你們的服務設計，才能更有效率地產出。

而我更建議，產品經理主動帶著團隊所有成員，一起討論、改善開發流程。

也許有些成員需要多點時間思考，因此傾向早點知道需求概況；有些成員喜歡詳盡的文檔，然後邊做邊找問題；有些人則還在職涯早期，可能沒有特別偏好，但需要多一點產品或商業知識的建構。

究竟什麼方法／工具適合你們，很值得團隊花時間探討。而探索的過程，也是團隊建構的一個重要環節，能為團隊帶來很多正面影響。

最終，良好的工作流程與文檔成果，更取決於團隊各職能的成熟度與共識。產品經理若想要有更多時間，專注於產品願景、定位、計畫，最重要的不是把日常工作通通拋開，而是先搞定最適合團隊的開發流程。

這篇文章 從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

區塊鏈在夯什麼？傳統金融因信用問題，使許多人無法提出有效證明的人，不得不被排除在外，也讓金融機構經常被詬病不方 …

區塊鏈在夯什麼？傳統金融因信用問題，使許多人無法提出有效證明的人，不得不被排除在外，也讓金融機構經常被詬病不方便、效率低落，而透過區塊鏈的智慧合約，正為信任、產權、集資和安全等問題提供高效強大的解決方案。

根據美國勞動部的調查，軟體系統工程師的工作，在 2016 年至 2026 年有 11% 的成長，可見區塊鏈工程師的職缺，也將在此這類別有顯著的成長，尤其在金融、健康、公部門日益需要此類人才。許多大型企業如 IBM、匯豐銀行、Walmart 已經開始採用區塊鏈技術，聘請區塊鏈工程師為自家發展資料結構、演算法和軟體應用等。區塊鏈工程師需要有能力從設計、開發、分析、部署，並基於區塊鏈技術管理特定的商業模式，他們需要有能力為公司分析該用開源技術或建立一個新技術。

圖/123RF

區塊鏈工程師都在做什麼？

區塊鏈工程師需要有能力從設計、開發、分析、部署，並基於區塊鏈技術回應特定的商業模式，在尋找相關職缺時，須留意公司需要哪種層級的專業能力，許多公司會想找擁有多樣技能的人才，不過從市面上來看，有些基礎技能確實是必備的。大部分對區塊鏈工程師的能力要求包括：

• 擁有軟體開發的專業背景
• 精通  C++、Java、JavaScript 語言（視專案而定）
• 有實作開源專案的經驗
• 具備演算法和資料架構的知識
• 對密碼學有基礎了解
• 熟悉點對點網路（peer to peer networks）
• 熟悉比特幣與以太坊的區塊鏈技術

有哪些學習的重點？

想成為區塊鏈工程師，掌握程式語言、資料科學是基本技能，接著你需要進一步熟悉區塊鏈的專業知識，入門建議你從以太坊（Ethereum）公鏈開始，最容易上手也最穩定，可以從中學習區塊鏈的基本運作原理，如挖礦、交易、智慧合約等。以下是區塊鏈工程師Patrick Collins推薦必搞懂的關鍵字與相關工具：

1. 絕大部分智慧合約都會用的語言：Solidity

2. Solidity 的非官方標準整理：Openzeppelin

3. 連結多種來源智慧合約的預言機：Chainlink

4. 重要的部署框架：Remix 、Hardhat 、Brownie 和 Dapp Tools（可以選一個開始學習）

5. 基礎知識：如區塊鏈錢包、密碼學、 Solidity

6. 進階知識：NFTs、DAO、DeFi、建立可更新的智慧合約（Upgradeability）

（作者／Vanessa）

這篇文章 一文讀懂如何成為區塊鏈工程師？ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

國外科技部落格《About Chromebooks》近日透露，Google正在測試中的Chrome OS新增了 …

國外科技部落格《About Chromebooks》近日透露，Google正在測試中的Chrome OS新增了「快速密集計時器節流」（Quick Intensive Timer Throttling）這項功能，可望降低Chrome OS對CPU的使用率，並延長電池壽命，且該功能同樣適用於Chrome瀏覽器。

圖/翻攝自Google chrome

據了解，根據Chrome團隊的測試，透過「快速密集計時器節流」新技術，Chrome的CPU使用率能比原本少上10%，藉此使用更少的能耗，而主要的設計邏輯是藉由每10秒鐘就會計算一次，以限制閒置背景頁面的網頁使用率，以釋出系統效能和因此而來的能耗，進一步改善電池壽命。

其實早在2020年Chrome團隊就開始測試「密集喚醒節流」（Intensive Wake Up Throttling）功能，當時因為Google發現許多網頁都會在背景執行Javascript，而且每秒就會喚醒分頁一次，雖然所使用的CPU資源不到1%，但頻繁的喚醒再加上眾多的分頁，就會大量耗損CPU資源並降低電池續航力。

因此Chrome團隊設計了「密集喚醒節流」機制，只要分頁進入背景5分鐘後，就會限制Javascript每分鐘只能喚醒分頁一次，根據當時的實驗顯示，可減少5倍的CPU使用率，並讓電池壽命延長1.25個小時。

而這次Chrome團隊開始測試更進階的「快速密集計時器節流」功能，同樣是基於「密集喚醒節流」的概念，也是限制Javascript每分鐘只能喚醒分頁一次，但這次把進入背景的5分鐘緩衝時間縮短為10秒，意即只要網頁進入背景10秒之後，執行頻率就會從每秒一次切換至1分鐘1次。

不過，目前「快速密集計時器節流」還只是一個實驗功能，到了Chrome 104才成為測試版功能，《About Chromebooks》表示，他們持續在Chrome 105中發現這項功能，意謂著很有機會成為正式功能。（記者／竹二）

這篇文章 新版Chrome有望調整CPU使用率　減少電池消耗延長壽命 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。