亞旭電腦公司是華碩電腦的子公司，不論是在公司的規模、組織、員工福利還有公司政策以及員工的發展上，都有長遠的策略跟規劃，這是吸引我去應徵工作的主要原因。

作者／子賢

亞旭電腦公司是華碩電腦的子公司，不論是在公司的規模、組織、員工福利還有公司政策以及員工的發展上，都有長遠的策略跟規劃，這是吸引我去應徵工作的主要原因。

面試過程一開始會填寫基本資料並介紹工作環境及公司福利制度，接著會跟用人部門主管面談，詢問的內容大致有(問答內容因有雙方隱私，因此部分以xxxx來表示)：

人資：請問為何想換工作?

答：與目前公司產業相較，貴公司產業發展更適合我，因此想換工作。

人資：您之前主要的經驗跟工作內容，跟目前我們的職缺需求蠻符合的，但是在職位跟薪資上可能沒法達到你預期的薪資目標，不知道你可以接受嗎?

答：如果可以，個人當然是希望可以爭取到期望的待遇xxxxx元，但在衡量公司福利與產業發展面後，若公司可提供的薪資差異沒有太大，我還是可以接受的。

人資：請問您自認最好的一項優點及缺點？

答：優點是工作上有想法，並且達成目標；缺點則是有時會急於達成任務，而忽略某些部分。

人資：恩，那相信你來面試前應該有上網看敝公司的介紹，那我大概跟你介紹一下公司的上下班及福利制度。

接著由部門主管來面試：

主管：請用3~5分鐘做一下個人的簡介

答：主管您好，我叫xxx，住xxx，研究所念的是xxx，之前曾在xxxx服務，並負責過xxxx專案，在工作上的專長有xxxxx，個人興趣有xxxxx等。最近看到貴公司的職缺，覺得蠻有興趣因此想到貴公司面試，希望未來有機會到貴公司服務。

主管：是否可分享在過去的經驗中，與同事合作最愉快及最不愉快的經驗？

答：最愉快經驗：初步介紹公司現有產品給新客戶後，持續的安排、討論，了解客戶需求並解決問題，經由產品導入流程，終取得客戶訂單，為公司帶來業績。

最不愉快經驗：相關部門因某些因素未能及早通知，而拖延預定時程，導致客戶的抱怨。

主管：請問您以前在工作上之重大貢獻或改進事項：

答：1.成功開發新客戶，為公司保留住舊客戶。2.處理原有的庫存，後續新訂單並要求客戶支付款項。3.將新服務從無到有建立。

主管：您跟之前主管相處如何?平常怎麼做溝通呢?

答：我和之前主管相處融洽，假日偶爾也會一起相聚；在工作上除了基本的郵件溝通，重要事情都會直接口頭報告。

主管：那您對敝公司了解多少?知道我們是做什麼產品嗎?

答：恩，我之前有稍微研究一下貴公司。

面試心得：整體來說，面試主管的態度都很親切，對談的內容主要是針對之前的相關工作經驗，還會詢問對公司的了解程度以及到公司的通勤時間，因此面試過程只要以平常心，並保持專注去說明自己的專業以及之前完成的成果即可。

在薪資部分，在面試過程中可詢問主管可提供的薪資範圍，若薪資比自己預期的要低，那可以提供自己之前的薪資，或期待的範圍供主管參考，但是最後的薪資核發是以人資審核為主。

建議若是去應徵有需要工作經驗的職務，那無論是男生或女生，都要穿著正式服裝去面試，這樣比較會凸顯自己的專業形象！

另外就是面試過程中，主管會詢問對公司的了解程度，包含了公司目前的主要產品類別，還有公司在哪裏有工廠等，藉此了解應徵人員是否積極，因此面試前一定都要先做功課了解公司喔！

但建議若是去應徵有需要工作經驗的職務，無論是男生或女生，都要穿著正式服裝去面試，這樣比較會凸顯自己的專業形象喔！

本文由 面試經驗暨工作甘苦談 授權轉載，原文〈亞旭電腦股份有限公司-專案管理主任專員-面試經驗分享〉

___________

你也有經驗想分享嗎？快來投稿賺稿費吧！

這篇文章 【學長姊帶路】亞旭電腦 專案管理主任專員 求職分享 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

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

文／堡壘文化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想要獲得一份好的新工作你需要有不同專業的技能，就像是拼圖一樣將軟技能硬技能相互完美契合，方可實現你的目標。在這科技時代，周遭的任何事物快速變化，你會發現自己必須不斷精進而獲得重要的技能。就拿科技業來說，科技人員必須掌握最新科技趨勢，還有新工具的使用是不可少的。

編譯∕龔鈺翔

想要獲得一份好的新工作你需要有不同專業的技能，就像是拼圖一樣將軟技能硬技能相互完美契合，方可實現你的目標。在這科技時代，周遭的任何事物快速變化，你會發現自己必須不斷精進而獲得重要的技能。就拿科技業來說，科技人員必須掌握最新科技趨勢，還有新工具的使用是不可少的。

但如今你將轉換跑道，那是不是技能就要全部從頭開始學起？其實未必，因為你有一些原本就有的可轉移技能，一旦你熟悉並掌握，很快就能適應新的工作與獲得新工作。總之，一切取決於你如何運用你的可轉移技能。

更多新聞：【職場二三事】個性內向者該學習的4種社交小技巧

1、閒聊與溝通的能力

閒聊是一種讓人放鬆自在的溝通，是雙方輕鬆聊天並交換雙方思維感想的過程。而在談話的過程中是否能夠繼續延伸話題靠的就是閒聊的能力。你甚至可以在面試中使用閒聊的方式做開場，這樣不僅讓面試官覺得你很Chill，還可以用聊天的方式破冰。

在面試一開始，你的溝通技能就已經開始受到考驗，面試官也開始在對你評分。你可以透過線上眾多公開資源來幫助你學習基本能力，或是可以找尋導師協助。

2、有成長思維敢冒險

每個企業都特別喜愛那些勇於挑戰現況脫離舒適圈，或是跟著團隊共同成長的人才。也因為各企業都在尋找擁有這些可轉移技能的人才，所以找求職者都在找尋擁於學習有抱負的應聘者。

成長上進的思維具有感染力，它可幫助團隊成員實現遠大目標。你可以在面試中提到這一點，談論過去你做了些什麼事情，來激勵你的團隊更勇於嘗試突破現狀。

3、適應力

現在的職場快速變化且變化萬千，這就像是變色龍一樣，你的保護色要能夠適應周遭環境的顏色，才可活下來，就是自然界生存中的「適應」，也是物競天擇的一環。

適應力可以幫助你快速融入新行業並蓬勃發展的技能，這技能是招募主管非常關注的技能之一。主要是因為科技時代變化迅速，企業都需要有這樣的人才掌握世界趨勢並適應改變，企業方能應對調整內部政策與其它事宜。

你可以在面試中分享一些關於你如何應對變化，如何能屈能伸的故事，這是面試官會想從你身上知道的事。

4、創新創意思維

創新不僅用於市場營銷、品牌形象等領域。創新可以幫助團隊之間找尋新的出路，突破現狀。就好比蘋果公司為例，有史蒂夫‧賈伯斯這種創新思維擺脫以往過舊思維，讓自己的產品區別於當時市面上所有電子產品公司。

所以每個企業都希望他們的團隊中有像史蒂夫‧賈伯斯這樣的發明家與企業家呢！

5、EQ情商

最後一個可轉移的技能就是EQ的能力。我們的情商往往被忽視卻又是非常重要的技能。擁有高EQ的人，都會表現出擁有同理心、同情心，這是未來領導者很好的一個潛力。

另外，高EQ的人面臨困境時，可以較好的控制自己的情緒、不容易失去理智，並找尋更兩全的解答。種種優點都是招募主管會注意到的。

結語：

可轉移技能就像是「軟實力」，而工作上的專業技能稱之為「可轉移技能」。以上的技能相互結合，可以建立起強韌的可轉移技能，即使你的職涯變換跑道，仍然不用過於擔心，因為你的適應力能夠快速融入新環境。

資料來源：Forbes

這篇文章 【職場二三事】2023招募主管最關注的5個可轉移技能 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

編譯／龔鈺翔 各行各業都需要專屬於自己一套獨特的技能，但有些領域的技能是相互共通的。以下7種建議技能，教你如何 …

編譯／龔鈺翔

各行各業都需要專屬於自己一套獨特的技能，但有些領域的技能是相互共通的。以下7種建議技能，教你如何使用才更具有高生產力，還能滿足工作與生活的需求，達到工作與生活的平衡點。

1、時間管理

聽似簡單，但不是人人都做得好。出於每個人掌控時間概念的不同，所以剛學習掌握時間可能有些棘手。雖說沒有一套萬用的方案來如何管理自己的時間，但最基本的方法就是，建立日程安排與行事曆來制定時間表。

你為何會管理時間失敗？原因是你設定了一個不切實際的目標，還是沒有目標？你可以使用市面上眾多的日曆App，來幫助你規劃安排自己的時間。這可幫助你按部就班照著日程安排執行，按時睡覺起床，避免工作拖延，甚至減少社交媒體所浪費的時間。

2、理財管理

工作是為了賺錢與理想而去努力的目標，但有效管理資金可以減少對財務狀況的焦慮。理財管理的三個基本要素，是追蹤你的收入與支出、制定預算，還有重新找尋平衡支出的方法。

做好理財管理可讓自己更有紀律，避免衝動消費，還能計畫實現財務目標。如償還債務、應急基金、購車與退休計畫。提前安排可讓壓力減輕，無壓力時才能更理智分配財務。

3、專案管理

專案管理涉及三個管理核心：時間、金錢、人力資源。儘管不是每個人都是專業管理人，但每個人都需要知道在沒有外部監督與充足經費的情況下完成任務。

而對於專業人士來說，專案管理尤其重要，如果缺乏這項技能，很可能在工作中起伏不定。例如，你可在簡單的任務制定簡單的清單就足夠應付，但更複雜任務就需要強制使用嚴格的工作流程，因此專案管理工具是你一個很好的資源。

4、談判與說服力

談判技術一直都在我們周圍，例如參加工作面試、要求加薪、與客戶交易、應對憤怒的客戶等。如果你不懂得如何談判，就有被利用的風險。不過談判是可以靠後天學習的技能。談判是一種你了解對方的期望，也查覺自己的期望，兩者找到共利點，方可達成協議。

5、邏輯推理

邏輯推理可幫助你合理解釋自己的想法。例如，你向老闆提出加薪時，你就需要邏輯推理來支撐你的論述，提出合理的理由解釋你為何應該得到加薪。邏輯推理運用到我們工作生活的所有角落，它甚至還可以解決職場上的衝突。

在某種程度上，邏輯推理是溝通與談判的先決條件，如果無法先與他人進行推理，很可能無法勝任談判事宜，還可能被視為不真誠的跡象。

6、公開演講

多數人對公開演講的恐懼是非常普遍的。你可能認為自己表現得不好，或是對他人如何看你而產生焦慮。所以公開演講是培養自信心的重要技能。

公開演講時，你的目標就是完成演講本身的議程，而不是讓你表演。講白了就是，學會在演講時把自己擺在一邊，演講內容才是議程的重點。

7、自我反省

自我反省與審視自己，是情商核心要素。「向內看」來評估自己的價值觀思想、情感的能力，了解自己的優勢與劣勢，來調整自己。

自省可以幫助你找到與他人不同之處。例如，面試官問你一個出乎意料的問提，「告訴我一些在你簡歷上找不到的事情」，這能幫助你順利回答這些問題。

資料來源:Makeuseof

這篇文章 【職場二三事】透過7項技能，充實職場優勢並規劃人生目標 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

筆者目前擁有些許國際證照，例如 PMP 專案管理師國際證照、NPDP 新產品開發管理師、CSM CSPO 敏僅相關證照（Lean Agile Institute）、Google 專案管理認證（Coursera）。雖然說不上絕對的專業，對於證照的略知一二，與實戰上的實用性可以跟讀者們分享。

筆者目前擁有些許國際證照，例如 PMP 專案管理師國際證照、NPDP 新產品開發管理師、CSM CSPO 敏僅相關證照（Lean Agile Institute）、Google 專案管理認證（Coursera）。雖然說不上絕對的專業，對於證照的略知一二，與實戰上的實用性可以跟讀者們分享。

哪些人需要考證照

1. 資歷淺，需要靠證照證明自己的人：通常五年以內工作者，或是跨職能轉職的人通常會需要。或許未必有絕對的相關經驗，但透過證照表示自己有一定的知識水平與積極程度，是可以幫助自己在投遞履歷與面試的加分項目。
2. 資歷深，需要靠證照加深認知的人：證照考取不是主要目的，而是透過書本的學習與工具箱加強自我的認知，並且套用與修正在自己職場上遇到的問題。
3. 特定產業與企業的必備條件：在某些外商與特殊領域，證照是絕對項目。

考照前需要注意的事項

考證照本身也是專案管理，我們可以用專案管理金三角範疇、成本、時間來衡量自己短中長期的目標是否必要，我們最可以思考的方向是「機會成本」。

• 時間：像是 PMP、NPDP、Google PM 如果去補習至少要 6～8 週考取證照，拿這時間去閱讀、請教大師、參加 Workshop 或許也是個好方法。
• 金錢：上述證照每個都少說要花一萬元以上，在個人的財務上能否負擔與承擔投資，也必須思考。
• 目的：跟第一段相呼應，自己是因為學習，還是要證照加身才有用。必須明白的說，證照未必有用，多數看怎麼學習、怎麼實戰，有些公司甚至視為證照是扣分項，因為變成是僵化思維。

如何挑選合適自己的證照

這邊用最簡單的方式來幫大家挑選證照

1. 為了敏捷專案管理：推薦多參加工作坊為主，急需練習才有用，因此推薦 Scrum Master 優先。
2. 為了名氣而考取：首選 PMP，再者 Google PM 證照，先不說廣泛或是氾濫程度，如果自律性高的人倒是很推薦後者，因為有很多工作上真實遇到的難題提供思考。
3. 為了工具箱：產品相關可選 NPDP、專案相關可選 PMP，未來工作後有很多方法論可以讓自己去思考。

個人經驗

實務上以筆者是軟體產品經理為例，認為在 Lean Agile Institute 相關敏捷證照最為有用，未必說會直接在職場加分，但對於自己於專案管理、同儕合作的思維與實務上有很大的幫助，課程中因為是很好的講師，過程中不但有大量練習機會，也有更多借鏡海外企業對於敏捷思維的不同之處。

無論最後怎麼選擇，有個不變的道理：「師父領進門，修行在個人」。希望大家能透過證照學習，幫助自己的職涯加分。

如果你想知道更多證照細節，歡迎閱讀以下文章

• 淺談相關國際PM證照的異同之處 — PMP, NPDP, Agile/Scrum (動機篇)
• 淺談相關國際PM證照的異同之處 — PMP, NPDP, Agile/Scrum (知識篇)
• PM 學習進修路，該如何保持市場競爭力？常見疑問與參考方向 — Google PM 證照與 LAI 敏捷證照

這篇文章 PM 證照這麼多，如何挑選最合適自己又剛好需要的那一個？｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

做為專案管理職務相對有各種好準備的書籍，若是針對產品經理因為在技術、商業、設計上的涉略各有其廣深，準備起來更是不容易。

做為專案管理職務相對有各種好準備的書籍，若是針對產品經理，因為在技術、商業、設計上的涉略各有其廣深，準備起來更是不容易。而對於產業熟知的 Project Manager、Prodouct Manager、Product Owner 職能未必清楚該怎麼辦？以下筆者簡單推薦無論是年資深淺都可以閱讀的資源。

寫在推薦之前

各種書籍推陳出新，很難立刻閱讀完與吸收完，尤其還包含各種網紅與名人的書籍、該怎麼挑選。

最重要的是適合現階段的自己、且能夠消化，其次是看看作者是什麼背景？是否有真的實戰經驗（有的是怪力亂神且說不出細節）、第三是一堆 ME TOO 的概念書籍就顯得更無深度可言。

最後，千萬別忘了請益身邊 PM 在職者怎麼看待這些書籍，也能有效的篩選。

書籍

• Cracking the PM Interview: How to Land a Product Manager Job in Technology：裡面有豐富的履歷、自我介紹、專業面試、行為面試等各種範例題目與解析，非常適合跟三五好友共同討論該如何討論與加強自己的思考深度。

• Cracking the PM Career (PM職涯發展成功手冊｜卓越產品經理的技能、框架與實踐法)：對於想瞭解 PM 職涯路徑在初階、中高階、管理階層等等的職能差異，以及在跨團隊合作中該如何扮演合適自己的角色，是個非常棒的書籍。

• 產品負責人實戰守則：從洞悉顧客需求，到引領敏捷開發，韓國電商龍頭頂尖PO教你打造好產品的決勝關鍵：在敏捷圈子多了 Product Owner 角色，如果特別想知道這職能跟產品經理有什麼差別，可以看看不同國家的觀點。

• 俞軍產品方法論：前面有歐美與韓國書籍，當然少不了中國的指標性書籍，儘管地區文化有差別，但仍可以了解原來在不同地區的文化是怎麼看待 PM 這個角色。

資源

• SVPG Silicon Valley Product Group：在產品經理圈子最為指標性人物莫過於 Marty Cagan，他所創辦的專欄與思考維度，實在太推薦朋友們去挑選合適的文章閱讀並反芻。

• Cracking the B2B Product Manager：市面上很多分享 B2C 產業，如果你是想要知道 B2B PM，可以看看這篇文章的內容。

• 產品經理書單推薦 — 22本書 (角色、設計、工具篇)、Spotify、騰訊產品經理練功書單大公開，14本PM必看之書：如果以上的資源與書籍無法滿足你，這邊推薦其他讀者的書籍，大部分都是經典且值得一看再看的書籍。

小結

閱讀的陷阱莫過於盡信書與崇拜思維，必須搭配現實世界做些轉圜。這時候推薦大家找個朋友共同討論，或是嘗試用自己的話說出、自己的文字寫出，透過他人的觀點來看看有哪些不同的思考，這才是最難能可貴的地方。如果你問讀完是否就真的有把握面試上產品經理、專案經理，當然是「不一定」。但起碼自己能夠更接近自己所定義與嚮往的職能。

或許有人覺得很奇怪，怎麼都沒有本土的資源推薦，並不是說本土的資源不夠好，而是我們要跳脫框架，借鏡不同國家的專家建議，尤其決大部分本土的資訊與落地，都是晚於其他國家好幾個維度與年代。如果大家對於觀看英文文章有些吃力，當然可以先由中文書籍消化吸收，當自己越來越成長進步，非常推薦多看看原文書籍。

這篇文章 不論年資深淺都可以閱讀！科技業 PM 必讀書單與資源推薦有哪些？｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

採訪撰稿／黃楷元、陳士勳 11月份AI Talk講者與AIA幹部合影。（左起：AIA理事長林建憲、AIA活動長 …

採訪撰稿／黃楷元、陳士勳

在現今社會，「人工智慧」已是人類現代科技的核心之一。無論是個人應用、企業決策，都扮演不可或缺的角色。為了推廣人工智慧的產業應用及相關人才培育，台灣人工智慧協會定期舉辦「AI Talk專題演講」活動，邀請人工智慧業界人士共同切磋交流。11月3日的場次，邀請到三位「台灣人工智慧學校」的校友前來分享，分別是英諾瓦科技產品經理鄭沅巧、亞達科技AI工程師王柏鈞、以及Google機器學習工程師黃誠熙。

首先，由鄭沅巧介紹AI專案管理於智慧醫療的實踐，其所屬的英諾瓦資訊科技服務有限公司運用創新科技提供資訊服務給全球不同產業的客戶群。位於台北的軟體研發中心，是英諾瓦為全美最大醫療支付系統公司──「Change Healthcare」所成立的首座海外軟體研發中心。鄭沅巧指出，針對專案管理方法論演進，敏捷式或瀑布式各有優缺點，若軟體企業已成長到一定規模，「大規模敏捷開發」將是一種有效的專案管理模式，能夠讓不同軟體部門「快速迭代」，又能避免溝通落差。

「交付內容會一直變動，直到大家都能接受的結果出現。客戶的需求回饋才是致勝關鍵。」鄭沅巧說。專案生命週期從起始規劃到執行結束，最容易失敗的並非沒有成果，而是做出來的東西偏離主題，或客戶不滿意。對此AI軟體從業者必須機動因應、配合需求變更，更貼近企業所關注價值。

鄭沅巧觀察，台灣的醫療專業與研究實力備受國際肯定，醫材硬體亦享譽國際，具發展智慧醫療優勢，不過最大挑戰是資源門檻太高，「不像製造業較為明確，醫療成果的變現時間很長。」若要善用AI專案管理，可設定好方向和目標，接著不停在過程中摸索，得擁有即便失敗，也要創造價值的恆心。

第二段的主講人亞達科技AI工程師王柏鈞，則向現場與會者重點介紹「聯邦學習 (Federated learning)」。聯邦學習 屬於分散式學習 (Distributed learning) 的一種，最初是為了配合資安規範所衍生出來的解決方案。在一些資料量不足、或是礙於資安規範無法收集大量資料的情況下，可以透過聯邦學習來達成目標。

以Google的智慧輸入法為例，在每個使用者的手機中，都會有許多選字習慣的數據。如果把這些數據赤裸裸地全部送到伺服器，固然可以有很好的學習效果，來改善輸入法的選字，但這卻可能是資安以及隱私的大災難，以目前歐盟要求的資安規範 (GDPR) 來說是不會允許這種事情發生的。因此山不轉路轉，聯邦學習技術應運而生。透過聯邦學習來進行模型的訓練，不需要傳出完整的「資料（data）」、只需要共享「資訊（information）」即可，對於用戶隱私的保障也更加周全。

在聯邦學習領域中，可以研究的議題很多，諸如：

• 加密技術：例如同態加密、或量子聯邦等。
• 資安規範：需要公正周延的檢驗機制，來確認聯邦學習的合法性。
• 通訊成本：從用戶端傳輸資訊到伺服器，對用戶及伺服器端都會造成負擔。
• 公平性與獎勵機制：根據貢獻的資料量，來決定獲得的回饋程度，可鼓勵更多邊緣端（用戶）參與聯邦學習。
• 防弊措施：如何避免模型被留後門、或是在干擾下維持穩定。

未來在許多客製化的應用上，聯邦學習都可以在保護隱私的前提下，提供更貼近使用者的方案。不同的企業之間，也可以透過聯邦學習，在不洩露商業機密的情況下，有更多的合作空間。

最後的段落，由Google機器學習工程師黃誠熙分享自己的職涯歷程，他曾經在灣區的Google總部任職，親身體驗在美國科技產業闖蕩的各種點滴。如今返回故鄉、在Google台灣辦公室任職，在演講中分享自身觀點見聞，提供對於人工智慧、機器學習相關職缺有興趣的科技人參考。

黃誠熙把會應用人工智慧的公司分成兩大類，分別是大型科技公司、以及新創公司（Startups）。這兩種公司需要的人才略有差異，大公司比較重視應徵者的「潛力」，因為資源比較豐富，可以對人才進行長期的投資，以及更充裕的訓練，想要應徵的求職者，就要充分展現自己的資質與未來可能性；反之，新創公司需要的多是即戰力，尤其是你的特定技能可以直接對應到公司當前的需求者，在求職上才會更有優勢。

大型科技公司的AI相關職缺，包括數據科學家（data scientist）、研究科學家（research scientist）、應用科學家（applied scientist）、及機器學習軟體工程師（machine learning software engineer）；新創公司除了數據科學家的需求相同之外，其他的職缺則偏向分析師（analyst）及數據工程師（data engineer）。

黃誠熙也對於各種職缺所應具備的能力、或是應徵時會被考驗的技能，提出了建議。若是數據科學家或分析師，那麼會需要的是統計能力、假設驗證或分組測試（AB Test的能力、以及對於結構化查詢語言（SQL）的熟稔。

應用科學家則是亞馬遜和微軟的特殊職缺，從研究階段一路做到生產階段，機器學習或分析的需求必須一手包辦，因此和機器學習工程師相似，兩者需要的技能都是機器學習端至端的討論、數學推導能力、及基本編碼能力。最後，工程師則是專精於程式編碼的達人，Coding 能力決勝負。

席間氣氛熱絡，現場校友及聽眾不只在新知上收穫滿滿，在會後交流更開拓多元的交流及合作空間、滿載而歸。台灣人工智慧協會下一場次的「AI Talk專題演講」將於12月1日（四）舉辦，若有興趣加入研討人工智慧的行列，可密切關注【科技島】及台灣人工智慧協會官網。

這篇文章 人工智慧最新趨勢分享　AI達人來開講｜專家論點【台灣人工智慧協會 AI Talk】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

由於沒有報補習班且一切都是靠網路資源考取證照，目前網路分享的考照心得資訊較舊，因此希望藉有本次分享回饋有需要的讀者。

文／Chun Li

2022.08.29 經歷準備 4 個月的自學，考到 PMP 證照囉！

由於沒有報補習班且一切都是靠網路資源考取證照，目前網路分享的考照心得資訊較舊，因此希望藉有本次分享回饋有需要的讀者。（包含我自己也從 Medium 獲益良多。）以下針對我的自學準備方式、小資考證準備方法稍做分享！

關於傳說中專案經理必備的一張基礎 cert PMP 證照已經有太多的介紹，因此這邊簡單帶過。

此項認證為依照美國專案管理協會 Project Management Institute ( PMI ) 所制定的專案管理領域指導文件內容 ( PMBOK ) 進行的認證考試。為因應市場/產業需求，於 2021 年 8 月新發佈的第 7 版調整了部分內容。其中目的為使專案經理使用傳統的預測式、混合式、敏捷式及其管理方式時更易使用且更為上手。

◆考試題型

考試題目 180 題，其中含單選題、多選題( 會告知答案須選幾個)、配對題。

1. 一般 4 選 1 單選題，總題數約 150 題
2. 多選題印象中為 5-6 個選項擇 2–3 個答案，題數約 10+ 題
3. 配對題依照題旨將左右選項互相配對，題數約 10+ 題(類似：遇到問題，配對解決方法、提供情境，配對情境概念)

◆考試型態

1.共 230 分鐘(建議事先算好答題時間分配，考試畫面右上角有時間倒數)

2.共分為 3 個答題階段，以完成 60 題為一單位，可以休息 10 分鐘，共有 3 個答題階段，2 個休息時間。

3.每完成一個答題階段，有檢查時間(含在 230 分鐘內)，確認提交後續無法再更改已完成階段的答案喔！

4.休息時間可以離開座位走動，螢幕上會有 10 分鐘的倒數計時，務必要於 10 分鐘到之前回到座位並開始下一階段考試，否則時間會自動開始倒數考試剩餘時間。

◆報考資格

1.學歷要求：大學以上學歷(高中以上第 2 點條件不同，在此暫不討論)

2.3 年(含)以上的專案管理經驗

3.涵蓋 10 大領域的 35PDUs ( PMI 認證的課程即可)

◆使用教材（總共花費約 $1,500 左右）

由 PMI 協會所出版的 PMBOK 為考試的主要內容，由於本書內容繁多且不易閱讀(讀起來很累啊！)因此我所使用的是以下

1.Udemy Online Course

Udemy 上面的這個課程 (PMP Exam Prep Seminar — Complete Exam Coverage with 35 PDUs) 標題直接告訴你可以獲得充分的報考 PDUs，簡直就是最簡單的一種方式！同時由於考試中文翻譯有部分建議參考看英文題目說明，故此原文課程內容有助於加深重點專有名詞的印象。

2.深入淺出 PMP

本書內容依據 PMBOK 所編撰，內容比起 PMBOK 提供較為親民的舉立即更系統的整理，簡化專有名詞及 ITTO 的理解。

3.中國補習班網站的免費題庫(不建議用，為 2021 舊考試範圍教材)

4.朋友提供的台灣補習班教材(舊教材)僅閱讀重點整理，加強預測式基礎觀念。

5.iPASSPMP 線上模擬考題：網站提供免費題目一次 15 題進行練習，重新整理會是新題型，因此題庫的 base 應該蠻大的，時常遇到新題目。(與考試內容有部分相似，有助於增加勝率！)

6.Linkedin Learning 課程

Linkedin Learning 上的 Scrum 及 Agile 教材內容豐富，且選擇眾多，有助補充紮實觀念。(挑選 PMI 協會認可的教材也可累積 PDUs！)

P.S. PMBOK 本身內容我是完全沒有閱讀的。

◆參考資料(都是非常實用的資訊！！必讀！！）

一個月內考取PMP證照攻略，PMP實際上有用嗎？(針對新版更新)

PM｜PMP Prep。分享PMP超簡單自學考照心得 (part 1)

→有 part2 及後續 renew 的方式說明，都在同一個 blog 很好找！

【PMP 證照系列 1】2021 PMP 證照考試前要準備什麼 ? 報名、申請資料與注意事項

→【PMP 證照系列 1– 4】完整介紹相關報考方式及過程，實用好文推！

◆準備方法

Udemy 線上課程通常我以 1.5 倍速加速播放，以求迅速獲得 PDUs。深入淺出的部分閱讀後會自行整理重點筆記，後續閱讀筆記+ Linkedin 課程。考前以線上刷題+重點內容的講義為主。針對有錯的地方加強觀念。

以上就是我偏陽春版的最新 PMP 考試經驗分享啦～如同眾多資深前輩表示 5 大過程組、49 子過程及各個 ITTO 是藉由理解後得出的答案，因此不用死記硬背，同時掌握 PMP 以人為本、積極負責的願景，就有機會從選項中擇出最優解答！

這篇文章 2022 最新 PMP 自學考照分享 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

專案在執行時免不了要「溝通」，但每個人溝通表達的能力落差極大；為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

在上篇文章中，筆者介紹了正式開發前的初始任務有哪些。

今天就讓我們來聊聊「專案執行」時，如何讓合作的過程更加順利。

以筆者過去的經驗來說，團隊合作免不了要「溝通」，但每個人的溝通能力落差極大，有些人總覺得對方是自己肚子裡的蛔蟲，因此詢問問題、交付任務都沒說明細節，時常需要你來我往的多次確認。

為了減少彼此的衝突，我們可以針對常見的合作情境設計「格式」與「規範」。

▋工作記錄（Work Log）

如果團隊有使用專案管理系統，為了日後方便追溯與釐清狀況，建議填寫的內容如下：

• 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
• 如果使用到特別的演算法、技術、套件，請特別附註。
• 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關文件。
• 如果發現 Ticket 完成的時間與估計的不同，請與 PM 討論並調整。

▋工程師之間的合作

律定格式，讓溝通有一定的品質。

• 明定 Ticket 執行順序：一個 Sprint 中，每個工程師手上有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，為了減少等待的空窗期，工程師要在「 Sprint Planning 時溝通好」。
• 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
• 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「如何操作」會發生。
• 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

▋工程師與 PM 的合作

工程師與 PM 合作時，千萬不要惜字如金，大家都要把話講清楚；工程師要求 PM 做到的事，自己也要做到。

• 如果 PM 請工程師完成 Sprint 以外的需求：請說明「任務優先度」、「為什麼會有這個需求」、「可以將哪個 Ticket 排後面一點」。
• 如果工程師在開發過程中收到其他團隊的需求：請將對話窗口轉移到「PM」，由他來統一處理。
• 如果工程師請 PM 開 Ticket：需描述「哪個系統」、「為什麼會有這個需求」、「需求描述」、「估計時數」。
• 若 Loading 太重無法負荷：請說明「原因」，如：掛的 Ticket 數量太多、任務分配不均、某個 Ticket 實作遇到困難。
• 若多個專案同時發起高優先度的任務：有些工程師身上會掛多個專案，若不幸有兩個以上的專案同時發起高優先度的任務，就需要請「PM」協助排出優先順序。

▋為什麼都要由 PM 來開 Ticket？

有些工程師覺得自己開 Ticket 比較快，資訊多轉一手給 PM 根本是浪費時間，但這個制度是有原因的，如果不這樣做就可能導致：

• PM 對專案的掌握度下降：如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
• 專案進度偏離原定計畫：很多時候，工程師心中的任務優先順序跟 PM 是不一樣的，這導致最後在核對完成的任務時，會因為彼此的認知落差而產生爭執。
• 勞逸不均：有些工程師發現問題就想解，導致身上背了一堆 Ticket 天天加班，而其他工程師閒閒沒事做。
• 做了徒勞無功的任務：有些功能從專案的角度來看，可能不重要，甚至是不需要的。

為了避免上述的狀況發生，如果有任何想做的需求，請先與 PM 討論，讓 PM 從整體的角度來判斷（ex：如果你的 Loading 太重，PM 就可能將你提出的 Ticket 分配給其他人做）。

▋結語

筆者透過 3 個主題（專案啟動、初始任務、專案執行），與讀者分享制定工作流程的重要性。

制定工作流程是為了讓團隊運作更為順利，所以其中的規範、格式都要與成員充分討論；在彼此有共識的狀態下，工作流程才有存在的價值，否則會變成一種負擔。

最後再次提醒大家，文章的流程未必適用於每個團隊，但可以做為參考方向。

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 想讓「專案執行」更加順利？工程師與 PM 間的合作要注意這點！｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

如果「初始任務」沒有做好，專案就像是蓋大樓沒有施工圖紙，蓋歪、抗震係數不足、工程 Delay 都是正常發揮。

在上篇文章中，筆者介紹了專案啟動時要做的事。

今天讓我們來了解，在正式開發前有哪些「初始任務」要做，以及每個步驟由誰負責。

▋STEP 1：規劃每個階段的時程

由「PM」將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：

1. 要完成的功能（ex：前端、後端）。
2. 撰寫測試程式的時程（ex：單元測試、壓力測試）。
3. QA 團隊測試的時程。
4. 測試、正式環境部署的時程。

規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 10~15% 的時間來修 Bug。

▋STEP 2：撰寫 Ticket 需求規格

由「PM」在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：

1. Prototype 截圖：讓工程師了解功能具體的位置在哪。
2. 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
3. 相關計算規則：如果需求是「計算商品總價」，那就要列出「產品搭配、折價卷、信用卡優惠…」等多種排列組合的計算規則。
4. 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
5. 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。
6. 驗收標準：判斷這個 Ticket 是否可以 Close 的依據。

▋STEP 3：評估每個 Ticket 的時數

不同 Ticket 的難易度不同，這邊會由「Tech Lead」與「工程師團隊」一同評估，確認該 Ticket 由誰負責，並評估需要的時數。

筆者在這裡提醒大家，千萬不要勉強自己估出一個很難完成的時數，不然卡關時，會影響到後續一系列的時程規劃（但也不要估出不合理的時數）。

如果某個 Ticket 預估的時程超過 6 小時，建議要再做拆分，否則很難衡量每天實作的進度。

▋STEP 4：確認能否在截止日前完成

只要是專案就一定有截止日期，「PM、Tech Lead」需要在這個階段將 Ticket 的時數轉化為甘特圖來審視，若發現已經超過截止日期，那勢必要再做一些調整，比如：

1. 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
2. 規劃 MVP 讓客戶使用（ex：原本要經過一系列複雜流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時間）。

這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。

▋STEP 5：分配 Ticket

由「PM」規劃這個 Sprint 要完成哪些 Tickets，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Tickets 總時數不要超過 65 小時，因為：

1. 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
2. 在專案初始階段，我們無法保證是否有遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
3. 有時舊專案會有緊急狀況需要優先處理，這個也會吃掉不少時間。

▋小結

專案的「初始任務」非常重要，若忽略其中一個步驟，都等於埋下一顆未爆彈。

相信經過「專案啟動、初始任務」這兩個主題，大家都能體會專案前期規劃、評估的重要性；但如果開發時 PM 與 RD、RD 與 RD 間的溝通不良，專案在執行時也會困難重重。

因此在下一篇文章中，筆者會針對常見的合作情境，分享實用的「溝通格式」，讓專案執行時更為順利！

☛ 如果想更深入認識我，可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫，筆者最近出版的新書 也許能給你帶來不同的觀點。

這篇文章 為什麼軟體團隊需要制定工作流程？正式開發前的「初始任務」有 5 個步驟不能忽略！｜專家論點【林鼎淵】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。