104學習

拆圖

指的是將複雜的工作任務或專案細分成更小、更具體的步驟或單元,方便理解與執行。這項技能能幫助提升工作效率,減少錯誤,也方便團隊成員分工合作。透過清楚拆解,能更精準掌握進度與資源需求,進而達成目標。簡單來說,就是把大問題拆成小問題,一步步解決,讓工作流程更順暢。

463 個相關職缺

提升你的實力,朝專業更進一步

精選課程

充實自己,讓能力持續成長

設計師接案必修課:從作品集到報價,系統化讓專業變現| 104獨家
設計師接案必修課:從作品集到報價,系統化讓專業變現| 104獨家
SolidWorks零組件機構設計
SolidWorks零組件機構設計
拆解簡報的技術:從分析、構思到設計,一次學會職場萬用溝通力!
拆解簡報的技術:從分析、構思到設計,一次學會職場萬用溝通力!
打造高投入團隊:遊戲化工作設計與激勵機制實作班【9/17】
打造高投入團隊:遊戲化工作設計與激勵機制實作班【9/17】
BIM 實戰建築工程設計
BIM 實戰建築工程設計
見招拆招,問題分析與解決(上)
見招拆招,問題分析與解決(上)
不瞎忙!職場達人必修課(一):工作目標的制訂
不瞎忙!職場達人必修課(一):工作目標的制訂
圖像化 企劃案撰寫
圖像化 企劃案撰寫
(確定開班)專案管理實戰特訓班:從混亂到掌控 AI助力【09/10】
(確定開班)專案管理實戰特訓班:從混亂到掌控 AI助力【09/10】
商業平面設計|PS+AI整合進階課
商業平面設計|PS+AI整合進階課

精選證照

考取專業證照,讓能力被市場看見

建築設計專業人員 |
TQC+認證依各領域設計人才之專業謀生技能為出發點,根據國內各產業專業設計人才需求,依其工作職能及核心職能,規劃出各項認證測驗。 在建築設計領域中,本會經過調查分析最普遍的工作職稱,根據各專業人員之職務不同,彙整出相對應之工作職務(Task),以及執行這些工作職務所需具備之核心職能(Core Competency)與專業職能(Functional Competency),規劃出「建築設計專業人員」。
財團法人中華民國電腦技能基金會
SSE Interior Design Using AutoCAD |
要成為一名專業專職的高薪室內設計師,AutoCAD是必須要會使用的軟體,只有能夠熟練運用AutoCAD製圖技術,才有可能進入室內設計的業界一展身手。 而同樣是AutoCAD,在室內設計領域所慣用的一些表現方式,也有其特殊性,必須要能畫出符合專業規範的AutoCAD室內設計平面圖及施工圖,才能讓雇主、業主乃至同行,信服你的專業能力,以及更實際的,讓實際施工的團隊,能百分百的完成建案,避免施工錯誤。 本試題即為AutoCAD室內設計的專業檢定,通過本測驗,代表您具有AutoCAD室內設計相關的專業製圖能力,是可以進入室內設計公司任職,即戰力的能力認可。
Silicon Stone Education (SSE)
室內設計專業人員 |
TQC+認證依各領域設計人才之專業謀生技能為出發點,根據國內各產業專業設計人才需求,依其工作職能及核心職能,規劃出各項認證測驗。 在建築設計領域中,本會經過調查分析最普遍的工作職稱,根據各專業人員之職務不同,彙整出相對應之工作職務(Task),以及執行這些工作職務所需具備之核心職能(Core Competency)與專業職能(Functional Competency),規劃出「建築設計專業人員」。
財團法人中華民國電腦技能基金會
乙級建築塗裝技術士 |
需具備丙級建築塗裝技術士之專業能力外,並能依照施工說明及工作圖,具有獨立從事一般建築塗裝工程,並有策劃及指導作業的能力。
勞動部勞動力發展署技能檢定中心
甲級建築製圖應用技術士 |
此證照考核持證者是否具備建築製圖的進階知識與技能,包括手繪與電腦繪圖、建築結構分析及施工圖設計能力。 甲級建築製圖技術士考試分為學科測驗與術科測驗兩部分: 學科測驗:建築設計原理、結構力學、施工法規及建築材料。 術科測驗:熟練運用建築繪圖工具或軟體(如AutoCAD、Revit),完成平面圖、立面圖與剖面圖製作,並進行設計細節標註。
勞動部勞動力發展署技能檢定中心
丙級建築製圖應用-手繪圖技術士 |
工作範圍:繪製基本建築圖樣。
勞動部勞動力發展署技能檢定中心

精選貼文,掌握第一手知識

為什麼目標總是達成不了?關鍵在「拆解」:重視複盤,而非結果

管理目標為何容易出現問題?作者認為制訂目標時若只盯著結果,不僅可能影響效果,甚至惠導致下次訂目標畏首畏尾。因此,建議關注「達成目標的步驟分解」,因為目標的實現本質上就是「拆解+各個擊破」的過程。本文節錄自《不內耗的主場工作法》。 文/夏鵬 本文目錄(點擊可快速前往) 實現目標就是拆解任務成功若單憑運氣或機率,只會讓你更洩氣 管理目標出現問題,關鍵在於「拆」這件事上欠缺方法與耐心。 目標和結果是兩個大不同的概念:前者是我們對未來的設想和計劃,後者則是過往因素累積後的實際展現,兩者的重要區別是我們在制訂目標時必須關注的。若只盯著結果,不僅情緒會受影響,還可能影響效果,甚至導致我們在下次制訂目標時畏首畏尾。因此,我們應關注達成目標的步驟分解。 簡言之,別只盯著結果,要盯步驟。 首先,結果作為之前工作的總結,屬於過去式。過去之種種,不是我們能把握和改變的,任何超出我們可控範圍的事件,一旦過分糾結便只會徒增內耗。舉個例子,你參加馬拉松比賽,若目標是跑完4千公尺,但由於體力不支,只跑了2千公尺就退賽了,此時你根本沒必要沮喪,因為這2千公尺是你體力和訓練水準的真實反映,是之前體力和訓練積累的結果。如果你看到別人跑完全程並獲得獎牌就心生懊惱,那你就是錯把結果當目標了。 又例如,如果我們月初制訂的2百萬銷售計畫,到了月底只完成了1百萬元,這也不是目標高低或結果好壞的問題,而是意味著我們需要根據目標,調整日常行銷策略。 目標是前進的方向,結果只是達成目標過程中的一個階段性事實。我們不應陷入達標或未達標下所帶來的情緒,而是要用階段性的事實去對照目標,以此作為基礎,進行複盤,制訂出改進計畫。在複盤時,我們要回顧之前做了哪些準備、採取了哪些行動,並分析哪些行動是有效的,可以繼續堅持;哪些行動是無效的,甚至產生了負面影響,需要及時調整或停止;以及還有哪些必要的行動是缺失的,需要補充實施等等。總之,面對結果,我們應該做的是複盤和改進,而不是簡單地評判對錯好壞。 實現目標就是拆解任務 其次,若只關注結果,往往無法達成目標。前文中提到,要實現目標,必須將其分解為具體的、可執行的步驟,而不是將其當成一道簡單的算術題。那麼,到底如何有效地拆分目標呢?這裡提供一個關鍵的洞察:對任何目標的拆解,都要遵循一個原則,即這件事必須在你的可控範圍之內。 以減肥為例,很多人只關注減肥的結果,例如「我要在一個月內瘦5公斤」。「瘦5公斤」可能是一個好結果,但絕對不是一個好目標,因為它缺少具體的步驟,遑論減重這件事並非完全在你的可控範圍內。而「我每天要跑5千公尺,並且每餐少吃碳水化合物⋯⋯」這樣的描述就是步驟,而且是在你的可控範圍之內。 如果你覺得自己的意志力不足,沒法堅持每天跑5千公尺,那麼目標的拆解就需要進一步細化,首先是解決意志力的問題。例如你可以先制訂一個每天跑1千公尺的計畫,先堅持一周,然後逐漸增加距離,每天多跑5百公尺,直到每天能跑5千公尺為止。在時間安排上,你可以爭取每天早起1小時進行鍛煉,而為了做到早起,你可能還要調整作息,爭取晚上也早睡1小時。同樣地,為了能夠早睡,你可能就要提升工作效率,或是調整晚上就寢的時間。 千萬不要覺得麻煩,因為目標的實現本質上就是一個「拆解+各個擊破」的過程。盯著結果看似容易但做起來卻難如登天。很多人的目標管理出現問題,根源就在於對「拆」這件事缺乏方法和耐心。 成功若單憑運氣或機率,只會讓你更洩氣 再舉一個工作上的例子。例如之前提到的,要在1個月內完成3百萬業績目標。當時按步驟拆解,其中一步是優化我在直播間的留人話術,爭取將停留超過兩分鐘的人數增加30人。那麼,接下來就需要進一步拆解,直到實現這個目標在我的可控範圍內。例如我需要學習一些有效的留人話術,但我不知道去哪裡學,這就明顯超出了我的可控範圍。因此,目標需要進一步拆解為:找到學習留人話術的管道。如果這一步仍然不可控,那就需要採取更具體的行動,例如問問別人或上網搜索,抑或是去其他主播的直播間觀摩學習。 到這裡,我找到了可控的步驟,能夠採取具體的行動了,目標才算真正拆解完畢。人們常說,辦法總比問題多,但關鍵在於是否能夠將目標拆解得足夠徹底,並確保每一步都在我們的可控範圍內。最後,目標和結果是兩件事,前者是我們對未來的假設,後者是具體發生的現實,而且是過往種種因素累積而成的一個產物。 這個重大的區別是我們在進行目標設定時必須關注的。目標只是一個方向性的指引,並不意味著一定要達到。達不到目標很正常,關鍵在於我們能夠從中學到什麼。這與將目標拆解到可控範圍內的行動是直接相關的。如果目標在制訂時只是一個簡單的算術結果,而沒有進行具體的步驟拆解,那複盤時就會兩眼一抹黑。沒有具體的步驟,複盤就會變得毫無意義,做成了也不知道是怎麼成的,沒做成也不知道下一步應如何改進。於是,只能將失敗歸咎於目標定得太高、領導支援不夠、自己對問題的認識不深刻、執行的時候不堅決等。 下一次制訂目標時,我們可能會說,由於上次沒有完成,所以這次要更加務實一些,一步一步來,結果只是簡單地在數字上做了減法,仍然還是四則運算。這樣的循環往復只會導致目標越定越低,最終不了了之。 人們常說,不換目標就換方法,但如果你連具體的步驟都沒有,又何談方法呢?只有將目標拆解到你可以控制的範圍內,你才能採取行動,而不是空想。只有一系列具體的行動才能產生相應的結果。結果固然重要,但通過複盤調整達成目標的方法同樣重要。好的目標是可以鼓舞人心的,但前提是你要一次一次地找到達成目標的方法。如果成功只能憑運氣、靠機率,那只會讓你越來越洩氣。 節錄自:時報出版《不內耗的主場工作法》/夏鵬 著
【104職場力】

「接案作品集」怎麼準備?6大要素及不同客戶應對技巧

對自由接案工作者來說,「作品集」往往比履歷更能展現你的專業度與價值。一份好的接案作品集該怎麼準備?作者為軟體工作者,分享好作品集的6大必備要素,並用自身經驗解析技術型、設計導向、非技術型與綜合型客戶的關心重點,幫你打造更有說服力的作品集。本文節錄自《不想上班的勇氣:軟體工作者的第一本接案指南》。 文/陳泰銘(Taiming) 本文目錄(點擊可快速前往) 為什麼需要準備接案作品集?接案作品集準備方向:依照不同接案類型、客戶來調整好的作品集應該具備的6大要素沒有作品集怎麼辦?最好平時就累積Side Project 為什麼需要準備接案作品集? 作品集是接案者的「敲門磚」,能夠幫助潛在客戶快速了解你的能力、風格和經驗。有時候,你的作品集甚至比你的履歷還重要,因為它是最直觀的證明,展示你的專業度和價值。 客戶沒有時間細聊,先看作品決定是否聯繫你 比起履歷,作品集更能說明你的實力 客戶更信任有實際案例的接案者 降低溝通成本,幫助客戶確定風格與需求 讓你在競爭者中脫穎而出 當你在社群平台或論壇上看到有人發問:「有人可以幫我做插畫設計嗎?」如果你只是留言「我可以做」,很容易淹沒在眾多回覆中,客戶也不會特別關注你。但如果你直接附上作品集連結,讓對方點進去就能看到你的實力,成功機率就會大幅提升。這樣的方式不僅能讓你在競爭中脫穎而出,也能迅速抓住客戶的注意力。 接案作品集準備方向:依照不同接案類型、客戶來調整 一開始瞄準方向很重要,因為不同類型的客戶關心的重點不同,你的作品集應該根據你的目標市場來調整。例如: 技術型客戶:展示程式碼品質與技術細節 當你的目標客戶是開發公司或技術團隊時,他們更關心你的技術能力,而不只是表面的作品展示。例如,當一間軟體公司正在尋找後端開發者時,他們不會單純看UI設計,而是會評估你的程式碼品質、架構設計與API文檔。如果你的作品集包含GitHub專案連結、技術架構解析、程式碼片段或效能優化案例,將更能說服這類客戶,讓他們相信你具備專業的開發能力。 非技術型客戶:強調成果與商業價值 當你的客戶是中小企業或個人創業者時,他們通常不懂技術細節,而是關心你的工作能否為他們帶來實際價值。例如,一位餐飲業老闆希望建立線上訂餐系統,但他不懂技術,對「技術堆疊」也沒有興趣。他想知道的是這個系統能否提升業績、減少人工成本、讓顧客更方便。因此,針對這類客戶,你的作品集應該側重於案例說明,包含專案背景、解決的問題、最終成果與數據,例如「這個網站讓客戶下單率提升30%」,而不是單純列出技術細節。 設計導向的客戶:重視視覺呈現與品牌一致性 當你的客戶是品牌商、電商品牌或行銷團隊時,他們關心的是視覺美感與風格統一性,而不是技術實作的細節。例如,一位服飾品牌老闆希望找人設計一組社群貼文模板,他不會關心這些設計是用Photoshop還是Figma製作的,而是想知道你的設計是否符合品牌形象,能否吸引目標受眾。因此,你的作品集應該著重展示設計風格,提供高品質的圖片、完整的設計概念,並附Behance、Dribbble或Figma連結,讓客戶能夠直觀地評估你的視覺風格是否符合需求。 綜合型客戶:需要靈活調整作品集內容 有些客戶的需求涉及多個面向,例如,一家新創公司希望開發一款APP,他們既關心UI設計,也重視技術架構與開發能力。在這種情況下,若你的作品集過於單一,可能無法完整展現你的能力。最佳做法是針對不同領域準備不同版本的作品集,例如一份專注於UI/UX設計,另一份則強調技術架構與開發過程,這樣才能根據不同客戶的需求靈活調整,確保你的作品集能夠精準打動對方。 因此,一開始要明確你的目標客戶,這樣作品集才能精準打動對方,而不會顯得雜亂或無法吸引適合的機會。 好的作品集應該具備的6大要素 一份優秀的作品集,不只是展示你的能力,更應該幫助潛在客戶快速理解你的價值,並建立信任感。以下是作品集應該具備的關鍵要素: 1. 清楚的自我介紹與專業定位 你的作品集應該開門見山地說明你的專業領域,例如「專注於SaaS產品開發的全端工程師」或「專精品牌識別與UI設計的視覺設計師」,讓客戶一眼就能理解你的核心技能與市場定位。 2. 精選案例,而非堆砌大量作品 作品集不應該只是單純堆放所有作品,而是要精選最具代表性的案例,並確保這些案例與你的目標市場匹配。例如,如果你主要服務科技新創,那麼展示SaaS產品設計或開發案例會比一般電商網站更具說服力。 3. 案例背景與解決方案 單純的圖片或程式碼展示不足以吸引客戶,你應該為每個案例補充背景資訊,例如:「這是為某家新創公司開發的會員系統,目標是提升用戶留存率」,然後說明你的解決方案與貢獻,例如:「透過重新設計UI/UX,讓註冊轉換率提升20%。」這樣的敘述能讓客戶更容易理解你的價值。 4. 數據與成果驗證 如果可以的話,加入量化數據來證明你的工作成效,例如「重新設計後的網站,跳出率降低25%」、「API優化後,請求速度提升40%」,這樣的數據能讓你的作品更具說服力,提升客戶的信任度。 5. 直覺且專業的視覺呈現 作品集的排版應該簡潔清晰,避免雜亂無章的內容堆砌。如果你是設計師,這本身就是對你美感能力的考驗;如果你是工程師,也應該讓專案展示清晰易讀,像是使用卡片式設計來分類案例,或提供 GitHub 連結搭配摘要說明。 6. 聯絡方式與行動呼籲(CTA) 無論作品集是網站、PDF還是簡單的Notion頁面,都應該明確提供聯絡方式,例如Email、LinkedIn、或接案平台連結。此外,可以加上一些行動呼籲,例如「有興趣合作嗎?歡迎來信討論!」,讓客戶知道下一步該怎麼與你聯繫。 透過以上這些要素,你的作品集不僅能夠有效展示你的專業能力,也能提升轉換率,讓潛在客戶更容易做出決策,進而提高你的接案成功機會。 沒有作品集怎麼辦?最好平時就累積Side Project 其實,比起事到臨頭才急著找作品集,最有效的方法是平時就主動累積Side Project。不論是為了解決某個小問題、實現自己的點子,還是純粹為了學習新技術,只要能完成、有成果可展示,就能成為你的實戰證明。 Side Project不需要商業化,也不必太龐大,關鍵是能展現你的能力與風格。這些專案可以放在你的個人網站、GitHub、Behance、Notion或Medium等平台,讓潛在客戶在搜尋你的名字時就能看到。 以下是一些常見的發想與執行管道: 解決自己的痛點:把日常遇到的問題變成產品,例如排程工具、記帳App、小型自動化腳本等。 模仿與改造:挑一個你喜歡的網站或應用,試著重製、優化或加入新功能。 開源貢獻:參與GitHub上的開源專案,累積實戰經驗與人脈。 挑戰題目平台:參加如Frontend Mentor、Dribbble Weekly Warm-up、Kaggle等主題挑戰。 幫朋友或社群做東西:主動幫朋友設計海報、開發活動報名網站、製作社群 BOT 等。 紀錄學習歷程:把你學會的新技術或解法整理成部落格、教學影片或Notion範本。Side Project的價值,不只是讓你練功,更是你與客戶溝通時最有說服力的「非商業作品集」。尤其在你還沒太多實戰經驗時,它們能說明你的主動性、邏輯思維、執行力與品味。 節錄自:博碩《不想上班的勇氣:軟體工作者的第一本接案指南》/陳泰銘(Taiming) 著 獨家課程推薦:【設計師接案必修課】從作品集到報價,系統化讓專業變現 [joblist_plugin title='更多104【軟體工程類 接案】工作機會' url='https://www.104.com.tw/jobs/search/?jobcat=2007001000&mode=s&page=1&ro=2&keyword=%E6%8E%A5%E6%A1%88&order=15' amount='4'] 更多【自由接案】分享: 上班族也掀「斜槓兼職」熱潮!高薪兼職時薪破千,兼職工作機會懶人包 接案族該如何報稅?一文搞懂「接案外包」的報稅技巧,趕快收藏! 設計接案合約必備5大要素!保護權益必知,終結客戶鬼打牆 接案報價不是憑感覺!給新手的基礎報價公式參考 2025 最完整免費接案平台、接案社群總整理(附設計、行銷外包接案工作機會)
【104職場力】・UX

量天測地、解構力學——深入成大南工土木科,從材料試驗到現代營建實務的養成記 

土木工程往往不像建築設計那樣容易受到矚目,但每一棟建築、每一座橋梁的安全與品質,背後都少不了土木工程專業的支撐。國立成功大學附屬臺南工業高級中等學校土木科便以「專業、實作、創新」為核心,透過扎實的理論課程、多元實作訓練與工程現場接軌,培養兼具工程知識與實務能力的人才。 土木科教師方偉烈表示,建築與土木外界看來似乎差異不大,但兩者的定位並不相同,「建築比較著重空間設計與規劃,而土木更關注工程技術與結構安全」。建築師負責完成整體建築設計,土木工程專業人員則負責讓設計安全落實、順利施工,兩者始終是相輔相成、不可或缺的重要夥伴。  從基礎到專業,逐步建立工程能力  土木科的課程依照學生不同階段循序漸進安排。高一以基礎能力培養為主,除了國英數等一般科目外,專業科目則會修習如土木建築工程與技術概論、構造與施工法,搭配測量實習、製圖實習,建立學生的基礎專業。  到了高二課程逐漸加深加廣,逐步深入專業核心,學生將修習工程力學、營建技術實習、電腦輔助製圖實習、工程測量實習、地形測量實習、材料與試驗等課程。此階段學生將投入許多時間在實習課程中,先學習基礎理論,再透過大量的做中學,在理論與操作中深化自身專業。以材料與試驗課程為例,學生會接觸粒料分析、混凝土拌合、混凝土養護、混凝土抗壓等內容,實際了解建築材料背後的工程原理。同時,學生也會實際進行砌磚、木工、鋼筋施工、模型製作及室內配線等內容,並有機會親自操作,透過大量實作累積工程現場所需的經驗與判斷力。  圖:學生參訪鋼筋加工廠了解實際製程  高三時課程則以專題帶領學生整合三年所學,學生透過組隊合作完成專題作品,專題主題以興趣為導向,鼓勵學生發揮專業視角,利用創意解決實際問題。有學生設計改善生活問題的木工作品,也有人規劃建築模型,從選址、結構到功能規劃,都必須活用過去累積的知識完成完整專題,不局限於土木內容,反而讓學生更能發揮創意和觀察力。此外,成大南工土木科更致力於課程的創新,透過加入無人機測繪等內容,讓學生接觸數位測量技術,讓學生在已有的知識基礎上,持續拓展在工程應用的新視野。  理論與實作並重,真正理解工程的本質  許多學生入學前往往認為土木科就是不斷動手施工,但真正進入課程後,學生才發現實作背後需要扎實的理論支撐。  方老師表示,材料試驗就是最好的例子,學生必須先理解材料性質、混凝土比例及相關理論,再進入實驗室完成實驗,驗證結果是否符合工程標準。土木科並非只有操作技能,更需要具備數理分析與工程判斷能力。這樣的學習歷程,也讓不少學生重新認識土木工程。  圖:學生合作組裝工程結構模型  土木科二年級林同學分享,原本以為土木科就是每天在戶外施工、砌磚,實際就讀後才發現,還必須學習材料、測量、力學等專業理論。「它(土木科)不是只有曬太陽做工程,也要學很多理論架構。」另一位二年級郭同學也有相同感受。他原本認為土木科以實作為主,真正接觸課程後才發現有比想像中更多的理論知識。  成大南工扎實深厚的課程設計,帶領學生在每一項工程操作之前,先建立完整的知識基礎,才能在實作中更深刻理解背後的原理,也讓學生在實際操作中更深入理解工程原理 。  大量實作、接觸現場,從實務中累積出專業即戰力  除了課堂上的操作,土木科也積極透過競賽與專題,引導學生將知識真正應用於實際問題。  例如,學生曾組隊參加正修科技大學木橋載重競賽,從木材裁切、打磨到橋梁組裝,歷經兩個月反覆製作與調整,最終獲得外觀特別獎。土木科二年級王同學表示,雖然橋梁承載能力仍有進步空間,但看到團隊一步步完成作品,仍讓他感到十分有成就感。  圖:學生參加橋樑載重競賽展示成果  方老師也指出,土木科最大的特色,就是讓學生「做中學」。學生不只是完成作品,而是在反覆操作、修正與驗證中,逐漸培養工程判斷能力,學生也會在不同年級,分別考取測量丙級、建築製圖應用-電腦繪圖項丙級、工程測量乙級等三張證照,累積未來升學或就業的競爭力。若直接投入職場,畢業學生將具備基本施工與監造能力;若選擇升學,也能良好銜接土木工程、營建工程等相關科系。  除了校內課程,土木科每學期也安排企業參訪,帶領學生走進建設公司、工程顧問公司、鋼筋工廠及材料檢驗中心,了解不同工程環節的實際運作。部分學生更有機會參與寒暑假的校外實習,親身進入工地現場,提前體驗工程工作的內容。透過一次次與業界接觸,學生不只是認識未來職涯,更能理解課堂所學如何真正應用於工程實務。  專業、實作、創新,培養面向未來的工程人才  談到土木科最重要的特色,受訪教師以「專業、實作、創新」三個關鍵字作為總結。「專業」代表扎實的工程知識;「實作」代表大量操作與現場經驗;而「創新」則是持續導入無人機測繪等新技術,讓學生能與時俱進,接軌產業發展。  圖:學生學習操作無人機設備  方老師也觀察到,許多學生在三年的學習中,最大的改變並不是學會多少技術,而是逐漸不害怕動手,也願意主動尋找解決問題的方法。從學生觀點來看,王同學認為,只要喜歡動手做、願意學習,就能在土木科找到自己的舞台;郭同學則認為,具備邏輯思考能力、願意面對挑戰的學生,都很適合投入這個領域。  從基礎理論、工程實作到創新技術,成大南工土木科不只是教學生如何完成一項工程,更希望培養學生面對問題時的工程思維,讓每一位學生都能在未來的升學與職涯道路上,穩穩築起屬於自己的專業基礎。  開箱土木科學習日常!更多科系探索,歡迎追蹤104高職生IG 在 Instagram 查看這則貼文 104高職生(@104v.hs)分享的貼文
【104職場力】

ARCI法則是什麼?用4角色解決跨部門分工混亂│專案管理必學技巧

ARCI法則(阿喜法則)是解決跨部門分工混亂的專案管理工具,透過當責者A、負責者R、諮詢者C、知會者I這4個角色,讓每項任務都有明確主導人,本文會說明ARCI是什麼、當責與負責的差異,以及如何建立責任矩陣,趕緊學起來,讓專案不再卡關。 文/《104職場力》 本文導覽 ARCI法則是什麼?阿喜法則的4個角色定義一張表快速記住ARCI法則4個角色ARCI法則怎麼用?建立責任矩陣關鍵4步驟步驟1│先把專案拆成具體可執行的任務步驟2│為每個任務指定角色步驟3│確認每個人的角色認知步驟4│卻ARCI落實進日常工作流程ARCI常見問題與錯誤:3個地雷要避開地雷1│搞不清「當責」跟「負責」,導致出現兩個A!地雷2│把所有人都塞進C地雷3│I只是名單,資訊沒有真正傳到位ARCI適用什麼情境?為什麼跨部門專案特別需要ARCI法則? 多人協作的專案,最常在哪裡卡住?通常不是技術問題,也不是時程太緊,而是一件更基本的事:沒有人說清楚「這件事到底誰負責」。 任務在會議上交代了,但最後沒人真正接手;兩個主管同時下指令,團隊不知道該聽誰的;法務、客服等關鍵部門到了專案快結束才被拉進來,導致延誤或重工等,這些問題,幾乎每個跨部門工作者都遇過,根源都在於分工不明確。 ARCI法則(又稱阿喜法則)就是為了解決這個問題而生的工具,它不複雜,核心只有4個角色,但能把原本說不清楚的責任關係結構化,讓整個團隊知道該專案「誰主導、誰執行、誰要先被問、誰需要被通知」。 ARCI法則是什麼? ARCI法則(ARCI Model,中文讀音就是唸「阿喜」)主要是用來推動跨部門專案與管理的工具,這4個字母各代表一種角色,並依重要性排列: 阿喜法則的4個角色定義 A — Accountable(當責者) 當責者A是指身為一項任務的「最終負責人」,這個角色擁有拍板決策的權力,但也必須為專案握的最終成果承擔全部責任,通常每個活動或專案中只會有一位當則者。 R — Responsible(負責者) 負責者R是指實際把任務做完的人(執行者),在當責者A的帶領下規劃、執行、追蹤,並定期向A回報進度,跟A不同的是,同一項任務中可以有多位R。 C — Consulted(諮詢者) 通常在專業度或複雜度較高的任務推進前,會需要諮詢專家意見,諮詢者C就是這類顧問型角色,但要注意的是,除了給意見、協助溝通之外,C沒有決策的權力(主導權必須在當責者A手上)。 I — Informed(知會者) 知會者I不參與決策,通常也不會執行任務,只需要在每個節點上「被告知專案進度或結果」,方便後續任務執行即可。 一張表快速記住ARCI法則4個角色 角色關鍵問句人數限制Accountable 當責者這件事最後誰說了算?只能1位Responsible 負責者這件事誰實際去做?1位或多位都可Consulted 諮詢者決策前需要問誰?視需求,精準為佳Informed 知會者結果需要讓誰知道?視需求 ARCI法則怎麼用?建立責任矩陣關鍵4步驟 ARCI的執行方式比想像中容易,重點不是有沒有做表,而是有沒有讓它變成團隊的共同語言,只要依循這4個步驟就能輕鬆上手: 步驟1│先把專案拆成具體可執行的任務 不要一開始就急著指定角色人選,因為任務越模糊,角色越難分配,這階段首先要把專案「分解成明確的工作項目」,舉例來說: 今天有個新產品上市專案,任務拆開來應包含:產品定位與目標設定、行銷素材製作、合約與法規審查、平台上線與技術測試、上線後成效追蹤等具體細節,不是單純用「讓產品順利上市」這麼籠統的方式概括。 步驟2│為每個任務指定角色 任務拆解完後,再針對每一項指定對應的ARCI角色,同樣以「新產品上市」專案為例,分工舉例如下: 任務項目A當責者R負責者C諮詢者I知會者產品定位與目標設定產品主管PM業務、行銷工程、設計行銷素材製作行銷主管文案、設計師PM、品牌業務、客服合約與法規審查PM法務財務、採購產品主管平台上線與技術測試技術主管工程師、QAPM、客服行銷、業務上線後成效追蹤PM行銷分析師業務、產品各部門主管 延伸問題:「當責者A」與「負責者R」可以是同一個人嗎? 可以,但不是什麼專案都適合。 在小型任務或人力真的極有限的情況下,A與R都由同一人擔任這沒什麼問題(甚至還很常見),但如果是大型專案或跨部門合作時,A與R會建議分屬不同人,這樣有個好處:A能夠用更宏觀的角度督導成果,而R能夠專注在執行細節,兩者形成監督與執行的分工。 步驟3│確認每個人的角色認知 實行ARCI常常發生的烏龍是「角色分配好了,但對於要做的事情及責任範圍的認知沒對齊」,於是最後在混亂中失敗了。 建議分配好角色後,可以在專案啟動會議(Kick-off)中,明確說明個角色的權力義務,並讓大家複誦自己的理解,確保彼此認知一致,而不是分好、填上握表格就當完成。 步驟4│卻ARCI落實進日常工作流程 另一個ARCI最容易失效的原因是「分配的時候用ARCI法則,但執行用另一套」。 其實要把它融入實際工作也有訣竅,比如: 做下一個重大決策前,先確認C是否已參與並給意見。 每次例會先看A有無到場,是否了解情況跟當前成果。 定期追蹤專案進度,確保R有精準執行,若有問題也可同步解決。 產品或資訊對外發布或上線前,確認I名單中的人都已收到資訊。 當ARCI成為專案溝通跟執行的基本框架,它才能真正發揮效果。 ARCI常見問題與錯誤:3個地雷要避開 地雷1│搞不清「當責」跟「負責」,導致出現兩個A! 「當責」跟「負責」傻傻分不清楚,這是團隊在分配ARCI角色時最常遇到也是最容易混淆的地方,如果沒有釐清,導致一項任務出現兩個或以上的A,那最終還是可能會落得專案無人負責或目標分散的下場。 所以「當責」跟「負責」差在哪? 我們以一個具體例子來說明: 主管要你把一份文件寄給合作夥伴,你把信寄出去、任務完成了,這是「負責(Responsible)」的表現,但如果你在寄出後打電話確認對方收到,且傳遞到正確的人手上,確保溝通目的達成,這就是「當責(Accountable)」。 簡單說,負責者R對任務執行完成與否負責(事情做完了嗎?)但當責者A還必須對執行後的結果負責(要的結果達到了嗎?)這個差異,決定了A與R在專案中截然不同的角色定位,也決定了兩者的價值。 了解之後,團隊必須謹記規則:每項任務只有一個A,如果真的難以取捨,代表這個任務需要再拆細,或者需要在組織層面更清楚釐清誰有決策權。 地雷2│把所有人都塞進C C的本意是「需要其意見才能做出好決策」,而不是「有點相關的人都放進來」,沒經過取捨萬一讓C清單過長,會導致每件事都因為要等一大圈人確認,反而延遲專案進度。 真正應該列入C的人選,是那些「專業或意見會直接影響任務成果」的人,例如:法律風險由法務判斷、技術可行性由工程師確認。 地雷3│I只是名單,資訊沒有真正傳到位 ARCI矩陣上的I欄看起來雖然在末端,但絕對不能輕忽!會列入I代表這批人是「有必要了解進度或成果」的角色,可能是專案後期的支援端,或是完成後續的推廣/結案單位等,如實知會這些單位才能避免公司資訊或營運出現斷層。 ARCI適用什麼情境? ARCI其實適用於所有需要多人協作的工作,但在下列幾種情境中,使用的效益最為顯著: 跨部門專案:例如品牌活動、數位轉型、系統導入、制度改版等,涉及的部門越多,ARCI所帶來的降噪效果越明顯。 流程長、節點多的任務:例如新產品上市、大型品牌活動、組織年度報告等,這類任務每個環節的A和R都可能不同,適時定義與分工,才能確保每個流程細節的品質。 新主管接手或新團隊建立:在新團隊磨合期間,可以用ARCI快速建立共識與默契,比瞎猜、亂摸索再補救有效得多。 分不清責任歸屬的團隊:有些團隊可能人多事多,或都是資歷較淺的工作者,若沒有主心骨、分工不明確,可能會出現一團亂的局面,這時候實行ARCI能幫助大家了解責任歸屬、提升效率。 為什麼跨部門專案特別需要ARCI法則? 跨部門協作有一個共同的隱性問題:每個人腦中對「自己該做到哪裡」的責任認知其實完全不一樣。 因為專業、組織文化的不同,對同一件事有不同理解跟看法這很正常,但如果沒有拿出來討論,讓灰色地帶無限延伸,很容易變成專案卡關主因之一,甚至出現搶功勞或到處卸責的尷尬局面,比如以下幾個最常見的協作痛點: 任務沒人接:任務在會議上說完了,但沒有人明確承接,最後就懸在半空中,這正是因為沒有指定A與R,導致大家都以為別人會做,最後落得一場空。 找不到決策窗口:事情推進了一半,遇到問題需要選擇、收斂或決策的時刻,卻沒有人能給明確的指示,導致錯失黃金期或期程延宕。 太多意見喬不攏:跟上面那點相反,萬一是一堆人都搶著當A,光是對焦目標就夠累了,還可能會出現多頭馬車的情況,不僅影響執行效率,到最後也可能導致分裂對立。 關鍵部門太晚加入:很多組織習慣專案先行,邊做邊加人,其他部門有什麼問題再補救,但萬一是法務、技術這種硬傷,到最後階段才被通知的結果,不是雞飛狗跳就是砍掉重練,ARCI在一開始就把C與I明確列出,能有效避免這個問題。 很多人以為專案管理的重點只有包含時程控管、進度追蹤,但在真實職場中,當角色分配、責任歸屬等更前端的事沒有先處理好,後續會更加窒礙難行。 ARCI法則優勢在於,它把一件本來說不清楚的事,用4個角色結構化了,當每個人都知道自己在這個任務裡是誰,不需要每走一步就確認一次,那溝通成本就會明顯下降。 下次啟動一個新專案之前,不妨先花點時間把分工說清楚,會發現推行起來事半功倍唷! 延伸閱讀: 做了13個番茄鐘專案才推進10%?你可能用錯「番茄鐘工作法」! 甘特圖是什麼?免費軟體+甘特圖Excel範例教學懶人包
【104職場力】・專案管理

視角轉換的藝術:為什麼優秀的架構師不只是「畫圖」,而是建構溝通的橋樑?

在推動企業數位轉型或構建複雜的雲端系統時,我們常陷入一種「溝通泥淖」:老闆在意的是投資報酬與市場佈局,開發人員執著於技術堆疊與資料庫效能,而終端使用者只關心操作是否直覺。當利害關係人各說各話,這種資訊不對稱往往會導致開發與業務目標脫節,甚至引發災難性的專案失敗。 身為資深架構顧問,我常提醒同仁:架構師的核心價值不僅是設計技術架構,更是擔任「翻譯官」。在 TOGAF 框架中,架構工件(Artifacts)正是打破資訊隔閡的關鍵工具。 前言:建立系統思維的「地基」 在深入探討工件之前,我們必須先釐清幾個 ISO/IEC/IEEE 42010 技術標準中的基本定義。沒有這些基礎,架構設計就會變成空中樓閣: * 系統 (System): 為了實現一個或多個既定目的而組織起來、相互作用的元素組合。 * 環境 (Environment): 決定對系統產生影響的所有因素設定。這不只是硬體環境,更包含技術、商業、營運、組織、政治、經濟、法律、監管甚至社會影響。 * 架構 (Architecture): 系統在其環境中的基本概念或屬性,體現在其元素、關係以及設計和演化的原理中。 * 架構描述 (Architecture Description): 用來呈現架構的作業產品,是「架構視圖」與「模型」的集合,共同記錄了架構的樣貌。 第一個衝擊:架構視圖 (View) 是「看到的結果」,視點 (Viewpoint) 是「觀看的位置」 許多架構師在繪圖時常混淆這兩個概念。簡單來說,視圖 (View) 是你為了滿足特定利害關係人所產出的「圖表」;而視點 (Viewpoint) 則是定義如何觀看系統的「視角」或「規範」。 根據標準定義,視點會引用一或多種模型類型 (Model Kinds),並建立建立、解釋與使用視圖的約定(Conventions)。 「架構描述包含一或多個架構視圖。架構視圖表達了與利害關係人相關的一個或多個關注點。架構視點建立了建立、解釋、分析和使用架構視圖的要求,以解決特定利害關係人的關注點。」 —— ISO/IEC/IEEE 42010:2011 顧問觀點: 區分兩者並非學術上的吹毛求疵,而是為了實現重複使用性。視點(Viewpoint)是通用的模板,可以存在儲存庫中;視圖(View)則是針對特定架構實作的結果。 第二個核心:別只顧著畫圖,利害關係人的「擔憂 (Concerns)」才是重點 架構師的職責不僅是開發系統,更是要證明架構設計「充分解決」了利害關係人的關注點。 * 擔憂 (Concerns) 的本質: 這是指利害關係人對系統的利益所在,包含效能、可靠性、安全性、分佈性或可進化性。 * 與需求的連結: 關注點通常與「需求」密切相關。例如,一個通用的關注點「可用性(Availability)」,可能會在不同視角下衍生出多個具體的技術需求。 透過識別關注點,架構師能精準選擇正確的工件類型,避免投入資源去開發那些對決策毫無幫助、沒人關心的複雜模型。 第三個精彩案例:飛行員與管制員的溝通藝術 為了更形象地理解視圖與視點,我們可以觀察「機場系統」中不同角色的互動: * 飛行員 (Pilot): 他的視點關注乘客、燃料、跑道位置。他的工具是「燃料指引」、「高度計」與「速度計」。他使用位置與向量模型來導航。 * 空中交通管制員 (Controller): 他的視點關注飛機間距、空域安全。他的主要工具是「雷達」。 兩者的視圖是完全不同的「系統子集化 (Subsetting)」。飛行員不需要看雷達上的所有飛機,管制員也不需要知道飛機還有幾份客餐。然而,兩者必須透過一套**「通用溝通語言」**(如無線電中的位置與向量語法)進行互動。 延伸到企業架構,開發人員關注「軟體分佈模型與硬體連結」,而使用者關注「資訊存取與回應時間」。架構師必須建立一套「溝通協定」,確保這兩種截然不同的視圖能透過通用的架構元素相互協調。 第四個實務關鍵:架構的「整合性」與「權衡 (Trade-offs)」 一個具備專業深度的架構必須展現以下兩特質: 1. 完整性 (Integrity): 確保架構「適合用途 (Fit for purpose)」,解決所有關鍵關注點。 2. 整合性 (Integration): 將所有不同視圖連接,調和利害關係人間的衝突。 架構師最難的任務就在於權衡 (Trade-offs)。當「安全性」與「效能」產生衝突,或者「開發時間」與「預算金錢」難以兼顧時,架構師必須展現出數據支撐的權衡分析。 這是一個從業務到技術、從高層概述到低層細節的迭代進展 (Iterative Progressions)。最重要的是,這必須針對**「現行架構 (Baseline)」與「目標架構 (Target)」兩個環境進行開發,以便透過差距分析 (Gap Analysis)** 找出哪些元素需要延續、新增、刪除或替換。 第五個高效秘訣:建立你的「視點函式庫 (Viewpoint Library)」 優秀的組織不該每次都從頭摸索。在架構儲存庫中建立視點函式庫有三大效益: 1. 減少工作量: 已定義的視點讓視圖產出更迅速。 2. 提升理解度: 利害關係人對熟悉的視角(視點)更有共鳴。 3. 增強有效性信心: 使用經過驗證的模式能確保架構的可靠度。 實務建議: 對於董事會或 CxO 階層,可以採用**「嵌套箱圖 (Nested boxes diagrams)」**技術,以外框代表「地理位置」,內框代表「業務功能」,清晰展現兩者間的高階關係。即便組織尚未全面採納 ISO 標準,你也可以先為特定系統建立「臨時視圖」,再逐步抽象化為可重複使用的視點模式。 結論:從「學術練習」轉向「務實交付」 架構描述的產出,其終極目的在於「溝通」與「驗證」。我始終堅持一個黃金法則:「架構應該只開發到適用的程度,而不是作為學術練習無限地重複。」 過度的架構設計只會拖慢數位轉型的腳步。架構師的使命是確保所有的視角都能互通、所有的工件都能對準商業價值,並在不同工具間實現數據的互通性。 最後,請自問: 在你的下一個架構設計中,你是否真的站在利害關係人的位置上看過問題了?還是僅僅在繪製一張只有你自己才懂的技術迷宮?
高梓銘・Jason Kao的IT知識分享

計畫趕不上變化不用砍掉重來!2招照樣保持高效

即使訂好了一天的工作計畫,突如其來的意外總是難以預料──像是上班途中遇到塞車,導致整個行程延誤,讓人不禁懷疑是否該整天「砍掉重練」。事實上,計畫不是用來完美執行的,而是提供方向與彈性調整的依據。本文節錄自《減法》,分享兩個簡單有效的做法,面對突發狀況也能穩住步調、維持高效! 文/王世民 本文目錄(點擊可快速前往) 1. 心態上的調整:破除完美主義,接受不完美2. 行動上的調整:及時調整當天的計畫 假如你本來的計畫是在9點到公司開始做第一件要事,但不巧的是,路上堵車,導致在9點15分才到達公司。在這種計畫剛開始執行就遇到了意外的情況下,你會怎麼辦呢? 圖/商周出版提供 大部分人可能會選擇放棄當天的整個計畫,但其實大可不必。 只要做好兩個調整,計畫依然能發揮作用,讓你的一天保持高效率。 1. 心態上的調整:破除完美主義,接受不完美 在一天的執行過程中,完全按照計畫執行的情況非常罕見。更常見的情況是計畫無法如預期般執行。 制訂計畫的本質,並不是要求執行情況必須與計畫完全一致,計畫的作用是提前做了一次預演,讓你在執行時心裡更有底,遇到問題後能快速調整。 既然這樣,為何大多數人在計畫未如期執行後,就會選擇放棄呢? 這就是完美主義在作祟:要嘛做到完美,要嘛就不做。 所以,只要心態上接受不完美,就不會輕易放棄一天的計畫了。 2. 行動上的調整:及時調整當天的計畫 當計畫執行情況出現偏差後,需要考慮哪些任務或時段可以進行調整,以適應變化後的情況。 以早上因為堵車而晚到公司15分鐘為例。 在這種情況下,可以接受稍晚開始做第一件要事,並利用上午預留的11點至11點半這個留白時段來做彌補,如圖5-42所示。 圖/商周出版提供 需要注意的是,調整當天計畫時,不要修改原計畫時段的內容,而是使用藍色字體在實際執行中填寫新的計畫安排。 節錄自:商周出版《減法:少即是多,慢即是快。關於時間、精力、效能與人生管理的核心科學。5%精英都在做的減法工作術》/王世民 著 推薦閱讀: 夢想太遠,讓你停滯不前?3步驟聚焦當下找回動力 別再貪多學不會!學習也要「減法」,3步驟避免淺層學習不白忙
【104職場力】

專案管理中的 WBS工具:專案計畫與控制的基礎!以樹狀圖或階層結構圖呈現,內文說明如何運用

WBS,全稱為工作分解結構(Work Breakdown Structure),是專案管理中的一種工具,用來將專案的整體工作分解為更小、易於管理的部分。其目的是通過逐步將專案工作劃分為更小的任務,幫助專案團隊更清晰地理解專案的範疇與目標,並有效分配資源與責任;WBS 也是專案計畫與控制的基礎,許多其他工具和方法(如甘特圖、資源分配表等)都依賴 WBS 來提供詳細的工作描述與結構。 📌WBS 通常是以樹狀圖或階層結構圖的形式呈現,從上而下依次分解,頂端是專案的最終交付物或目標,底層是具體的工作包(Work Package)。每一個工作包都是專案中的最小可交付單元,它能夠被分配、執行和監控。 🔆WBS 的優點包括: 1. 清晰定義範疇:避免範疇蔓延,確保所有工作都與專案目標相關。 2. 有效管理時間與資源:更好地估算工作量、時間和成本,並分配資源。 3. 明確責任:有助於分配工作,讓每個團隊成員明確自己的職責。 4. 風險管理:通過分解,可以及早發現潛在風險。 📌專案經理運用工作分解結構(WBS)時,主要是利用它來規劃、組織和控制專案的工作,確保專案的每個部分都能順利進行並達成最終目標。以下是一個專案經理如何運用 WBS 的具體步驟與案例說明: 運用步驟👇🏻 1. 確定專案範疇: 在專案啟動階段,專案經理和客戶、利益相關者討論專案的目標和範疇。專案經理需要確保 WBS 能夠涵蓋所有必要的交付物和工作,並排除不相關的部分,避免「範疇蔓延」。 2. 分解專案工作: 將專案的主要目標分解成較大的可管理模組,然後進一步將這些模組分解成小的、具體的工作包。這些工作包應該是可量化、可追踪的,並且可以分配給專案團隊成員。 3. 分配資源和責任: 專案經理可以根據 WBS 中的工作包,為每個任務分配具體的團隊成員,確定誰負責哪些工作。WBS 讓專案經理可以清楚地了解每個任務需要的資源、技能和時間。 4. 進行時間和成本預估: 每個工作包的細節可以幫助專案經理更準確地預估完成每一部分所需的時間和成本,這些預估值會被用來構建專案的甘特圖或進度計畫。 5. 進行進度和風險監控: 專案經理可以根據 WBS 來追踪專案的進展情況,隨時了解每個工作包的狀態,從而提前發現延誤或風險。WBS 也有助於識別風險點,因為可以從較小的工作包中看出可能的問題。 【案例:網站開發專案】 假設專案經理負責管理一個公司網站的開發專案,專案目標是建立一個功能齊全的企業網站。專案經理可以根據 WBS 將專案分解為以下幾個層級: 📌頂層目標:企業網站建置 2. 模組一:需求分析 - 需求收集 - 競爭對手分析 - 技術可行性分析 3. 模組二:網站設計 - 視覺設計 - UX/UI 設計 - 原型圖設計 4. 模組三:網站開發 - 前端開發 - 後端開發 - API 整合 5. 模組四:測試與優化 - 功能測試 - 使用者測試 - 性能優化 6. 模組五:部署與維護 - 上線部署 - 維護計畫 【專案經理的具體運用】 - 規劃工作:專案經理將每個模組進一步分解,確定每一個具體任務,比如前端開發可能包括編寫 HTML、CSS 和 JavaScript。每個任務都分配給不同的團隊成員。 - 資源分配:專案經理根據 WBS 為各個模組配置所需的資源,例如設計師負責 UX/UI 設計,開發人員負責程式撰寫。 - 進度追蹤:專案經理可以使用 WBS 來追蹤每個模組的進展情況,如果前端開發延遲,專案經理可以及時調整資源或優先順序,確保不會影響後續的測試和部署階段。 - 風險控制:WBS 幫助專案經理識別可能的風險點,比如在需求分析階段發現技術不成熟,可以在開發前期進行優化,避免後期出現更大的問題。 透過 WBS,專案經理能夠更好地掌握專案全貌,並確保每一個部分的工作都能夠按時、按質完成,達到專案的最終目標。
知識貓星球・PM雜學相談室-新手轉職PM交流區🙌

「建設性批評」和攻擊差在哪?專家傳授3階段面對、找解方

工作或生活中面對批評,該如何應對?作者為臨床心理學家,指出批評可以分為「建設性批評」與「攻擊性批評」,最大差異在於前者的出發點在於幫助對方。當我們面對建設性批評時,可以應用3階段一同找出解決方案。 文/安潔拉・森 本文目錄:如何面對建設性批評(點擊可快速前往) 第一階段:「等一下!」暫停與反問第二階段:主動道歉和承認第三階段:接受解決方案 批評可分為建設性批評與攻擊性批評。建設性批評的出發點在於幫助對方,具備提出和解決問題的正向功能,傳達訊息時的態度真誠且不具威脅。相反的,攻擊性批評則帶有指責的意味,同時無法滿足意圖、態度、功能等一項以上的條件。 根據批評的種類不同,應對方法也會有所差異。首先,就讓我們來看看如何面對建設性批評。 第一階段:「等一下!」暫停與反問 為了適當地進行應對,第一步要做的就是區分批評的種類。這時,我們可以活用「暫停與反問」的技巧,也就是在心中按下暫停鍵,讓對方「等一下」,接著反問「這是什麼意思」、「你指的是什麼呢」。 「暫停與反問」具有兩項功能:第一,能夠幫助自己穩定急躁的心緒。如果驚慌失措或情緒激動,視野就會變得狹隘,容易衝動地按照過往的習慣反應。在這種情況下,很難以健康的方式展開應對。在反問「這是什麼意思呢」,然後等待對方回覆的期間,雖然只有短短的幾秒,但是可以重新凝聚渙散的注意力,調整呼吸和心情。 「暫停與反問」並不是要等到情緒完全平靜為止,而是把激昂飛躍的情緒歸位,讓情感的濃度從100%降到70%左右,以輕鬆的心情準備與對方溝通。 第二,「暫停與反問」的技巧有助於判斷情況,以便區分對方的發言屬於哪一類的批評。面對危機情境,我們很容易被各種思緒席捲,搭上崩潰的「暴衝列車」。心靈發出的警報不斷提醒我們周圍有危險,必須趕快採取行動;或者對方不停催促,導致我們衝動地做出反應。其實,我們沒必要急著作答,只要停下來反問對方問題,就可以避免匆促的判斷,蒐集到更多情報。接著,我們可以再根據批評的種類,選擇適當的應對方法。 第二階段:主動道歉和承認 「主動道歉」和「承認」,是應對建設性批評的兩種方法。所謂「主動道歉」,就是在對方開始批評之前,先承認自己的錯誤並道歉。為了不讓道歉看起來缺乏誠意,應該明確地表達自己做錯了什麼,以及未來可以如何解決。例如約會時遲到,抵達約定地點時,就應該馬上向對方道歉:「對不起,我遲到了。」接著,再以同理心補充道:「等了那麼久,一定很冷吧?」或者積極提出解決方案:「這個時間路上太塞了,我下次會放棄公車去搭地鐵。」如此一來效果會更好。此外,也可以反問「我怎麼做比較好?」,尊重對方提出解決方案的權利。 第二種方法是「承認」,即坦率地接受對方的批評和指教。在受到建設性批評時,不妨同意對方指出的問題點,承認自己的錯誤。不過,千萬不要用「我果然做不到」、「都是我的問題」等自我攻擊的語句,表現出被動攻擊的態度,也不要順勢反駁對方的話,衝動地展開防禦,重點在於坦然承認自己的疏失。用「你說得對」,承認對方指出的問題,就可以降低雙方之間的緊張感,開始專注於解決問題,而不是一味地互相攻擊。 以下是主管批評下屬工作進度落後的例子: 主管:「工作進度落後了一週,再這樣下去,很難趕在期限內完成,你打算怎麼做?」下屬:「部長您說得對,我也覺得這次的進度有問題。雖然大家都很努力,但跨部門之間的合作,溝通效率好像太低了。我們在每個部門裡指定一位負責人,把各自的工作內容劃分清楚,之後再整合好嗎?比起透過電子郵件溝通,每天早上開個簡短的會議,應該能加快工作進度。請告訴我哪裡還有問題,我會再想想有什麼方法可以解決。」 父母和子女之間,也經常發生類似的情況,以下是孩子對著母親發洩不滿的案例: 孩子:「媽媽,你只要聽到弟弟哭了就會馬上跑過去,我不管再怎麼哭你都不理我─我也要當嬰兒!」媽媽:「啊,你說得沒錯⋯⋯媽媽沒有注意到愛蜜莉,讓你失望了吧?」(給予共鳴) 「承認」的力量來自於自信,以及只要我們願意,隨時可以改變現況的堅定信念。此外,「承認」也意味著希望,亦即我們沒有必要因為失誤或部分的缺點,就深深地感到挫敗或崩潰。 第三階段:接受解決方案 建設性批評的目的在於提出並解決問題,假如已在第二階段同意對方指出的問題點,那麼第三階段,就是接受「怎麼做」的解決方案。如果對方沒有提出解決問題的對策,可以詢問:「該怎麼做比較好?」或者直接提議:「這樣做好不好?」 和芝賢在諮商室裡討論到批評時,她突然想起自己高中時的經歷。當時在美術部的芝賢,因為沒有恭敬地向學長姐打招呼,和朋友們排成一列受到了訓斥。隨著時間愈拖愈久,其中一位朋友忍不住反擊:「責罵後輩是無法樹立權威的!」氣氛瞬間變得更糟。這時,某位安靜坐在一旁的前輩表示:「你說得對,想獲得後輩的尊敬,不應該用這樣的方式,我們應該以身作則才對,以後不會再發生這種情況了。」 在位階秩序嚴明的小團體中,改掉把委屈報復在他人身上的惡習,不是件容易的事。因此,虛心接受後輩的批評與建議,這樣的行為最終獲得了真正的尊敬。承認問題並接受對方的提案,不等於羞恥或挫敗,而是一場所有人的共同勝利。 節錄自:大好書屋《守護我的關係心理學:認識4種溝通類型×49個心理圈套,用英國IAPT 10週關愛課程照顧自己/安潔拉・森 著 》 更多【溝通好文】推薦給你: 如何拒絕別人?8種好好拒絕技巧,首先避免「習慣道歉」 一流人士都在用的談判法:讓對方主導7成發言,用提問探出更多情報 開會提出新想法別踩大地雷!意見想被採納、不招反感的加分說法
【104職場力】・溝通協調

你適合當PM嗎?解析產品經理必備3種特質與溝通心法

產品經理(PM)扮演產品關鍵的橋樑角色,不僅要看懂全局、擬定策略,更需要與設計師、工程師高效溝通,協調各方需求並推動產品前進。哪些人適合PM工作?作者透過實務經驗分享,解析PM必備的3種核心特質,以及在與不同角色協作時應具備的溝通心法。 文/Michelle Chen(軟體業PM產品經理) 本文目錄:3個PM需要的核心特質(點擊可快速前往) 特質1:你是否習慣全局性思考,並以策略性規劃推動執行?特質2:你是否喜歡且習慣站在對方的角度,使用對方的語言溝通?PM與設計師溝通重點PM與前端工程師溝通重點PM與後端工程師溝通重點特質3:你是否接受甚至喜歡改變,且有隨時改變計劃的彈性? 我習慣定期把自己的職涯規劃拿出來review,問問自己對於「現在的狀態」是否還滿意。最近是我在現職公司任職滿一週年的日子,於是又把這個問題拿出來檢視一番。我發現對於做PM打造產品這件事(撇除外在條件,像是workload、手上的案子、公司策略、主管等),過了幾年我仍非常喜歡且享受其中。再往下探索,是什麼個性或是特質讓我喜歡且適合做產品經理呢?今天整理3個我認為最核心的特質,分享給有興趣往PM產品經理發展,或還在思考自己到底適不適合的朋友參考! 特質1:你是否習慣全局性思考,並以策略性規劃推動執行? 作為產品經理你每天要應對來自各方的利害關係人,需求從四面八方而來,每季的Product Roadmap規劃&執行,每月2~3次的Sprint(如果團隊跑Scrum),甚至每天的跨部門Support,PM的日常總是被滿滿的需求與會議轟炸,任務清單中的To-dos & Action Item似乎看不到盡頭。在這種「艱困」的處境下,能習慣「全局性思考」的PM就比較能從容應對,懂得從任務海中抽身,避免無謂地瞎忙。所謂全局性思考有點抽象,換個方式來說就是:從整體,更高維度視角看待事情,而不是深陷於眼前的問題。 舉個例子來說,假設你是一位部門主管,你發現某個專案快到截止日但離完成還有一大段距離,你可以選擇臨時外聘人力,或是給團隊成員加班獎勵鼓勵他們挪出更多的時間工作完成任務,這也許是最快能見效的暴力解法。但如果你採取全局性思考,你會先退一步思考,這個專案的規劃是否合理,是否有可以簡化的部分,或者是否團隊中有某個特定的人遇到瓶頸。如果能協助這位成員解決問題,整個團隊的運行會變得更加順暢,也許就能如期完成專案。 全局性思考的能力能幫助PM有效辨識什麼才是真正需要解決的「關鍵問題」,而不是像在大魯閣打棒球一樣,只是對每個問題隨著出現而進行反應。這種思考方式讓你從整體上把握問題的根源,不是只解決表面的問題。 找到問題後,接下來就要透過策略性規劃來實作,這時候一定要提到常見的80/20法則。 20%的因素,將導致80%的結果。找出那關鍵20%重要的事情並全心投入,往往能帶來大部分的成果。 首先找到那20%重要並值得花團隊全心投入的P0-重要且須馬上行動的事。並懂得拒絕或是取捨那些重要但不急,甚至根本不用解決的問題 。取捨決策是一個好PM必備能力。 另外,作為產品的代言人,PM一定要知道哪些任務可以被整合在一起(甚至延伸成一個epic);又有哪些tasks可能會因為其他迭代而順勢被解決,因此現階段可以忽略不做;又有哪些可能看似有問題,但其實是故意為之的機制。 有策略、有條理的安排團隊資源,聚焦在關鍵20%重要的問題上,可以讓團隊更有效率且優雅的工作。(非常重要,誰會想要每天灰頭土臉工作,你說是吧) 特質2:你是否喜歡且習慣站在對方的角度,使用對方的語言溝通? 有這個特質的PM絕對會是團隊的寶,而不會變成大家避之唯恐不及的任務交差使者。習慣從對方的角度出發,用對方熟悉的用語溝通,不僅能提升理解效率,還能拉近彼此距離,建立良好互動。這有助於建立信任,讓未來的合作更順利愉快,形成正向循環,培養無敵默契。(每次遇到只是一兩句話一個眼神,團隊內的工程師和設計師就能馬上理解我的意思,就會覺得「哇,你們真的是神隊友,我好幸福啊!」) 這邊簡單舉例與設計師以及前後端工程師討論需求時應該著重的方向: PM與設計師溝通重點 重視使用者體驗(UX/UI):需要清楚描述使用者的需求(如果需要可以附上完整的user story),並在需求說明中「用戶使用流程」、「易用性」、「介面設計」以及「資訊呈現方式」等。 【溝通舉例】「我們希望這個功能的流程是:1.先點擊這個按鈕,2.展開選單,3.選單中會有幾個預設選項且我們會幫用戶進行預選,整個操作希望可以在3步內完成。」 特別注意!尊重設計師專業:作為PM一定要尊重團隊內設計師以及工程師的專業。對設計師,請保留讓他們自由發揮的空間。提出的需求絕對不會是硬性規定設計師只是把你想像中的畫面/流程畫出來而已,保留設計彈性通常得到的結果都會比自己發想的還要完整流暢! 【溝通舉例】如果需要做一個活動頁面:「這個頁面會包含A~C 3個大分類的資訊,其中A/B分類會另外連結到C/D頁面。這個主頁面的設計,希望能傳達出現代感,並保留畫面的簡潔性,方便用戶快速找到他們要的資訊。可以參考這個網站的設計風格,但具體的顏色/圖標,分類呈現可以自由發揮。」 PM與前端工程師溝通重點 重視介面與互動:前端工程師負責將設計轉換成可用的介面。他們關注的重點包含介面呈現方式、元件的設計與實現、與後端如何進行資料溝通、並且也要確保網頁可以各種大小的裝置和瀏覽器上都能順利運行。 【溝通舉例】PM:「我們希望在報名頁面上,使用者可以看到所有場次,點擊後展開場次詳細資訊,並透過一個動畫顯示出『點選報名』的CTA 按鈕。這部分在手機的 web view 上也需要保持操作流暢。」前端工程師:「這個顯示CTA的動畫在一些舊瀏覽器上可能無法支援,可能會出現卡頓或不顯示的情況。」PM:「如果確實有這個問題,我們可以考慮用彈出popup的方式替代,重點是整體操作要流暢,並且能有效吸引用戶點擊報名。」 特別注意!技術可行性&永遠都要準備PlanB:有時PM以及設計師一起討論出的設計可能在技術實現上會有挑戰。作為一個好PM,一定要工程師們討論在技術上的可行,以及如果無法實現,可以被接受的PlanB是什麼,並從中找到最佳解決方案。 PM與後端工程師溝通重點 重視系統穩定性及資料處理:後端工程師主要關注系統的穩定性及資料處理。他們習慣使用「API」、「資料庫」、「伺服器」等術語。作為產品經理,你需要清楚描述系統需求,並確保資料流(information flow)和功能邏輯的合理性。 【溝通舉例】PM:「我們需要建立一個數據報表,數據需要即時更新,並支援查看過去30天和60天的時間範圍。這個報表主要用來追蹤使用者行為趨勢。報表中的欄位定義以是{明確定義數據背後的計算邏輯以及fallback機制}。」後端工程師:「要實現即時更新可能會對系統造成壓力,特別是在高峰期,伺服器負載會增加,影響穩定性。」PM:「那或許我們可以考慮設定一個更新的cutoff point,在該時間點做一次性更新,確保穩定性以及更好管理系統負載。」 特別注意!具體明確制定規則:跟後端工程師討論事情一定要具體明確(制定出規則),不能給模糊的「形容詞」。以要新增檢查用戶註冊時的密碼強度的功能為例: 模糊的需求:「我們需要在用戶註冊時,先檢查密碼是否夠強。如果不夠強就讓他重新設置,夠強就讓他繼續註冊。」 ➞這時候工程師一定會問你:密碼強度怎麼樣算夠強?這個檢查是在用戶點擊註冊時還是輸入過程中即時檢查? 明確的需求:「如果密碼長度小於8位或不含大小寫字母和數字,則在用戶按下註冊時阻擋下一步,並顯示錯誤提示並要求用戶重新設置密碼。如果密碼符合這些條件,則允許用戶完成註冊。」 PM的工作內容和模式會隨著產品領域、團隊規模及系統架構等因素而有很大不同。然而,良好的溝通能力,尤其能根據不同溝通對象靈活切換用詞和表達方式,針對不同情境調整思考重點,是做好PM必須具備的。如果你發現這種角色切換對你來說有些困難,或是習慣從單一角度進行思考,那可能就不會那麼享受於PM的日常了。 特質3:你是否接受甚至喜歡改變,且有隨時改變計劃的彈性? 最後一點,「接受改變,且對已經計劃好的事情是否總是能保持隨時調整,甚至需要打掉重練的彈性?」是一個PM是否能樂在其工作中,蠻關鍵的特質。 有PM經驗的都知道(不管是Product or Project)都會面臨到原本說好的方向會需要來個大轉彎,產品策略可能因為市場的變化要做立即的調整(例如AI的快速崛起)。對於比較不喜歡變化,或是對於要臨機應變這件事情比較排斥的人,做PM會比較辛苦(心裡苦的部分)。 No two days are the same for a product manager 如果看到上面這句話,你感到興奮,那恭喜你!你一定能從PM的工作日常中找到許多樂趣! 以上就是我簡單從自己身上總結出為什麼就算有時候遇到再鳥的事情,或是有時候真的工作壓力很大,但終究我還是很享受做PM的3大特質與性格,希望能給還在摸索的人或是猶豫不太清楚自己到底適不適合的人一點小小分享。 (原文標題:你適合當產品經理嗎?3個PM需要的核心特質&性格解析) [joblist_plugin title='更多104【產品經理】工作機會' url='https://www.104.com.tw/jobs/search/?order=15&page=1&sctp=M&scmin=40000&scstrict=1&jobsource=joblist_search&jobcat=2004003005&keyword=%E7%94%A2%E5%93%81%E7%B6%93%E7%90%86' amount='4'] [course_plugin title='產品經理學習營|學習推薦' keyword='產品經理學習營' amount=2]
【104職場力】

從木藝傳承到製造──鳳山商工家具設計科:融合美學與工藝,打造空間裝修的設計職人

當家具製造逐漸走向數位化、自動化,傳統木工技藝是否還有存在的價值?科技的導入,不是為了取代手作,而是讓工藝與科技相互結合。鳳山商工家具設計科從木藝傳承到數位製造?學生又如何在三年的學習中一步步累積設計與實作能力,走向空間裝修與家具設計的專業之路? 從工地走進教室,一位木工職人的養成故事 「設計可以很有創意,但如果不知道怎麼做出來,那終究只是想像。」這句話,不只是張耿輔老師常掛在嘴邊的一句提醒,也是鳳山商工家具設計科始終堅持的教學理念。 身為家具設計科校友,張老師畢業後沒有立刻升學,而是投入室內裝修產業,從店面裝潢、住宅裝修到家具製作,一做就是近十年。那個年代沒有電腦繪圖,只要業主說出需求,他便用手繪立體圖一筆一筆將構想化為實際作品。「以前沒有電腦繪圖,我們就是拿筆畫,再跟業主討論。」他笑著回憶。 因為親身走過工地、參與施工,他深知一件作品能否完成,靠的不只是設計,更要懂材料、懂結構,也懂如何落實於現場。這份實務經驗,也成為他投入教育後最重要的養分。至今投入教學已二十七年,從職訓中心到高中職校園,也曾擔任技能競賽裁判。張老師希望把自己一路累積的經驗傳承給學生,培養的不只是會畫圖的設計者,更是能把設計真正做出來的專業人才。 圖:張耿輔老師於木工教室授課 從一把鑿刀開始,把設計真正做出來 許多人以為家具設計只是畫圖,其實學生真正學到的,是從一塊木頭開始,把作品一步一步完成。高一時,學生先從設計基礎開始,包含素描、圖學、立體造型,以及最重要的木工基礎訓練。第一次拿起鑿刀、學會磨刀、理解不同榫接結構,每一個動作都是未來製作家具的重要基本功。 到了高二,課程逐漸進入家具製作。學生會在高一升高二的暑假準備家具木工丙級,高三寒假再銜接家具木工乙級。取得乙級後,未來還能銜接建築物室內裝修工程管理相關資格,成為室內裝修的重要專業人才。 除了傳統木工技術,家具設計科近年更大量導入數位製造課程。學生除了學習AutoCAD、Rhino等電腦繪圖軟體,也接觸CAM數位加工與CNC木工加工設備,把自己設計的圖面直接轉換成實體作品。科上近年持續導入CNC等數位加工設備,從單軸加工到自動換刀系統,讓學生提早接觸產業現場最常使用的設備。「我們希望學生不是只會操作機器,而是知道每一刀為什麼這樣做,懂材料、懂結構,也懂設計。」張老師認為,數位工具愈來愈重要,但真正的競爭力,仍來自扎實的工藝能力。 圖:學生進行木工實作,測量木板長度 不只是做家具,更學會團隊合作與市場思維 到了高三,家具設計科的學習方式開始改變。不同於低年級著重個人技術,高三學生會以四到五人為一組,共同完成一件大型專題作品。從發想到設計、材料規劃、加工、組裝,每個人各司其職,也模擬未來進入企業後的合作模式。作品完成後,除了參加教育部專題競賽、全國技能競賽、工科技藝競賽等,也有機會參與校外展覽。 曾有學生作品在木藝展展出後,被現場民眾直接購買;也有學生利用課堂作品,在網路平台販售,第一次感受到自己的創作真的有人願意買單。張老師認為,這種成就感,是任何分數都取代不了的。「學生知道自己的作品可以被市場接受,自信心就會完全不一樣。」 除了參與競賽,科上也安排家具博物館、家具產業及相關展覽參訪,讓學生理解從傳統木藝到現代設計的演變,也思考家具如何兼顧美感、耐用與生活需求。近年課程更開始加入人體工學、循環設計、生活美學等概念,希望學生不只是製作者,更能成為真正理解生活的設計者。 圖:張耿輔老師指導學生 參與全國工業類學生技藝競賽榮獲 家具木工職類 金手獎第二名 一門技術,打開設計、裝修與國際產業的大門 家具設計科的出路,比許多人想像得更廣。升學方面,每年都有不少學生錄取國立科技大學相關科系,其中近年包括國立臺北科技大學工業設計學系、國立屏東科技大學木材科學與設計系、國立高雄科技大學營建工程系,以及建築、創意商品設計等相關科系。近兩年更有多位學生錄取北科大家具木工產學專班與屏科大木材科學與設計系,持續深化專業能力;就業方面,畢業生除了投入室內設計公司、室內裝修公司、建築師事務所,也有不少人成為家具工廠管理幹部,甚至前往越南、馬來西亞等海外臺商家具企業發展。 張老師分享,不少臺商家具廠目前正面臨世代交替,反而非常需要懂技術、懂管理的臺灣人才。有學生畢業幾年後便升任管理幹部,甚至成為海外家具廠廠長。 談到家具產業的未來,他也認為,臺灣不該再走低價大量生產,而是應該回到高品質、高工藝與客製化設計。 「真正有價值的家具,不只是使用功能,而是能陪伴生活很多年。」家具設計科希望培養的,不只是會做家具的人,而是能融合木藝傳承、美學設計與數位製造能力的設計職人。從一把鑿刀開始,到一台CNC設備,再到未來的空間設計與家具品牌,每一位學生都在這裡找到屬於自己的可能,也為臺灣木藝工藝寫下新的篇章! 開箱家具設計科學習日常! 更多科系探索,歡迎追蹤104高職生IG 在 Instagram 查看這則貼文 104高職生(@104v.hs)分享的貼文
【104職場力】

PM的隱性停滯:你是「救火型PM」還是「系統設計型PM」?

產品經理該如何避免陷入「雜務陷阱」與內耗?作者指出,能救火是能力,但一直救火是職涯陷阱!提供自我檢測、3種困境解析與PM行動指南,幫助PM從救火轉型為策略設計師。本文節錄自《泛 PM 職能的百萬年薪破關術》。 文/李星玟(Rafeni) 本文目錄(點擊可快速前往) 測驗: 你是「救火型PM」或「系統設計型PM」?PM隱性停滯3狀況:「一直救火」是職涯陷阱案例分析:其他PM如何擺脫救火模式?PM行動指南 :「救火隊長」到「產品戰略設計師」 我們在做產品經理,還是高級協調員?你在設計系統,還是在被組織設計? 許多PM一開始以為自己的工作是驅動產品成長,但做著做著,卻變成了解決團隊內部的大小問題,最終角色定位模糊。 PM變成了: 跨部門溝通的橋樑,但沒有決策權。 問題發生時,所有人都來找你,但沒有真正的權力推動變革。 自己明明很努力,但產品方向卻由別人主導。 這時候,PM會開始懷疑:我的價值到底是什麼?我真的在成長嗎?」 如果你發現自己陷入了「雜務陷阱」,那麼是時候重新審視你的職責與影響力了。這一節的目標,是幫助PM從被動「填補組織漏洞」,轉變為主動「設計更有效率的工作模式」,最後才有精力,重新找回職涯成長的動力。 測驗: 你是「救火型PM」或「系統設計型PM」? 這個測驗幫助你評估自己目前的工作模式,判斷你是「救火隊長」還是「系統設計者」。 測驗題目 請針對以下問題進行評分,0分(完全不符合)到5分(完全符合) 評分:0分(不符合)、1-2分(部分符合)、3-5分(完全符合) 問題我每天的工作內容大多是處理緊急問題,而不是規劃長期策略團隊遇到問題時,第一反應是來找我,而不是先嘗試自己解決我經常被臨時請求打斷,導致無法專心規劃產品方向公司的產品開發流程常常出現問題,但沒有人真正去優化它我的角色更像是「最後防線」,所有問題都需要我來處理 測驗結果解讀 總分0-6:你可能擁有「系統設計思維」,已經能夠讓團隊自主運作,減少救火工作的負擔。 總分7-15:你偶爾會陷入救火模式,但也有意識地在調整,應該進一步設計更好的機制。 總分16-25:你可能被救火型工作壓垮,建議立即改變你的工作模式,將重心轉向設計長期解決方案。 PM為何容易變成「救火型角色」?可能是因為你太有責任感,也可能是因為,你缺乏了系統設計思維。 PM隱性停滯3狀況:「一直救火」是職涯陷阱 小心!「能救火」是能力,但「一直救火」是職涯陷阱。 狀況1:PM在組織內的定位模糊,職責無限擴張 在一些公司,PM不只是產品負責人,還要處理開發管理、業務支援、客服應對,甚至是行政雜務。 工程團隊遇到問題,PM要來解決 產品需求變更,PM需要負責協調 上層要報告,PM要來整理數據 結果,PM變成了「補位型」角色,彌補組織內部的流程缺陷,但沒有真正推動產品價值。 狀況2:PM的影響力不足,只能負責「執行」而不是「定位方向」 如果PM沒有進入決策圈層,那麼他只能執行高層的決策,而不是參與決策本身。這導致PM變成了一個高級專案管理者,而不是產品策略制定者。 如果PM只是被動接受需求,那麼產品方向永遠是別人決定的。 如果PM總是在「應付變更」,而不是「制定策略」,那麼他只是流程管理者,而不是產品負責人。 狀況3:PM缺乏時間思考,只能不斷處理眼前的問題 當PM每天都在救火時,還有時間思考長期產品策略嗎? 產品方向的市場分析,沒時間做 用戶數據的深度洞察,沒時間看 更長遠的策略規劃,沒有空間推動 久而久之,PM變成了短期問題的處理機器,無法真正創造長期價值。 案例分析:其他PM如何擺脫救火模式? 【案例A】救火型PM的困境 「我每天的Slack都被大量@tag轟炸,工程師、設計師、業務團隊都來找我解決問題。我發現,我的時間全部被這些即時請求佔據,導致我沒辦法專心規劃長期產品策略⋯⋯」 問題根源: 團隊過度依賴PM,缺乏適當獨立決策的習慣與心態 缺乏標準流程,問題只能透過PM人工協調 解決方案: 設計FAQ或標準決策機制,減少PM介入的頻率 設立專注時間,讓PM不會被臨時請求打斷 【案例B】拆小決策顆粒,推動業務分組、建立標準與流程 「我曾經也是個救火型PM,每天應付無數的緊急需求、跨部門溝通,導致我沒有時間專注於產品策略。後來,我意識到這樣的模式不可持續,於是決定拆小決策顆粒,並推動業務分組,建立標準與流程,讓團隊可以更有系統地運作,而不是每件事都來找我。」 問題根源: 需求與決策過於集中在PM身上,導致PM過勞且影響力受限 團隊對標準與流程不熟悉,造成大量的即時請求與救火需求 缺乏分工機制,所有決策都需要PM來協調與仲裁 解決方案: 拆小決策顆粒,將大範圍的決策拆解為小型自治單位,讓不同角色能夠各自負責相應的決策 推動業務分組,讓團隊擁有相對固定的成員與責任,減少頻繁的跨組協作問題 建立標準與流程,讓每個組別都能有明確的作業規範,確保團隊知道該如何解決問題,而不是事事尋求PM介入 【案例C】與相關部門主管協商分工,由該部門主管制定相關規則與流程 「過去,我常常被各部門的問題淹沒,業務、工程、設計、客服等團隊都會直接來找我處理跨部門的衝突與問題,導致我的時間被大量消耗。後來,我意識到這些問題不應該只由PM來解決,於是我開始與相關部門主管協商分工,讓他們負責制定適合該部門的規則與流程,確保決策權回到正確的負責人手上。」 問題根源: 各部門習慣將問題拋給PM,而不是內部先解決或尋求主管協助 缺乏清楚的職責分工,PM成為所有跨部門問題的「最後防線」 PM需要處理非自己職責範圍內的管理問題,例如工程師的工作方式、設計師的交付流程、業務團隊的需求篩選等 解決方案: 與各部門主管協商分工,確保每個部門的問題由該部門自行處理,而不是直接拋給PM 由部門主管制定標準與流程,例如工程團隊的技術決策流程、設計團隊的交付標準、業務需求的優先排序機制等,確保有系統地解決問題,而不僅是依賴PM或特定角色人工協調 明確PM的職責範圍,讓PM專注於產品方向與策略,而非介入每個部門的內部問題 這些方法的核心思想是:PM不應該只是「解決問題」,而是「設計讓問題不會再發生的系統」。如果你的時間大部分都用來救火,那代表你的組織運作機制需要改善,從今天開始,試著讓團隊能夠「自動運轉」吧! PM行動指南 :「救火隊長」到「產品戰略設計師」 PM的價值,並不是「變得更會救火」,而是「設計出更少火災的環境」。如果你的日常工作大部分時間都在「解決問題」,而不是「設計更好的工作模式」,那麼你的影響力就會受到限制。 錯誤模式:「救火隊長」的日常 需求變更→PM協調修改 工程團隊卡住→PM來解決 跨部門問題→PM去協調 更好的模式:「產品戰略設計師」的日常 需求變更→PM提前設計決策機制,避免無效需求進來 工程團隊卡住→PM與技術主管建立更好的優先級決策框架 跨部門問題→PM設計更好的溝通與決策流程,減少摩擦 當PM意識到自己進入了「內耗模式」,就需要開始思考:「我要如何讓自己的時間,真正投入在高價值的事情上?」 請記得, PM 需要的不是「一直解決問題」,而是「創造不需要救火的環境」。 如果發現自己在做的事情沒有累積價值,就應該開始重新設計自己的工作方式。 PM 不應該只是確保「事情能完成」,而是確保「做的事情是對的」。 思考框架一:「救火vs.設計系統」思維 概念:優秀的PM不應該只是「處理問題」,而是應該「設計更少問題的環境」。如果PM總是要救火,說明整個流程可能有問題,需要被優化。 救火模式(Firefighter Mode)設計系統模式(System Designer Mode)思考方式這次怎麼解決這個問題?怎麼設計一個讓這個問題不會再發生的系統?行動方式回應需求、處理衝突、解決當下的問題建立機制、設計流程、讓團隊自動化解決問題長期影響PM變成團隊的「最後防線」,所有問題都要找PMPM把時間投入到長期策略,不再被低價值工作綁住 當PM總是處理問題,而不是設計更好的流程,就會陷入「救火模式」。這時候,可以運用以下思維工具,來幫助自己從短期應對轉變為長期優化。 思考框架二:「5 Why分析法」:釐清問題的根本原因 當問題發生時,PM不應該只解決表面問題,而是要深入挖掘「為什麼這個問題會發生?」,才能找到真正的解決方案。 【例子】某個功能發布後,數據沒有達到預期1. 為什麼數據沒有達到預期? →用戶使用率比預測低2. 為什麼用戶使用率低? →他們不知道這個功能存在3. 為什麼他們不知道? →產品內缺乏有效的引導與教育4. 為什麼缺乏引導? →我們沒有在設計階段規劃onboarding5. 為什麼沒有規劃? →需求討論時,缺乏對用戶行為的考量 解決方案:未來在規劃新功能時,必須把onboarding設計納入核心考量,確保用戶能順利使用新功能,而不是等問題發生再來補救。 思考框架三:「First Principles Thinking」(第一性原理): 拆解問題,找到本質 這個方法來自於Elon Musk,重點是將問題拆解到最基本的組成部分,重新思考解決方式。 【例子】為什麼PM總是被動接需求?傳統思維:這是PM的工作,只能接受現狀。 第一性原理拆解:• 需求來自於哪裡?→來自業務團隊• 為什麼業務團隊有這麼多需求?→他們沒有明確的產品規劃• 為什麼沒有規劃?→產品目標與業務需求沒有對齊 解決方案:與業務團隊共同制定「優先級決策框架」,確保需求與產品策略一致,而不是無限接需求。 上述所提及的,都不是單一PM的案例,我接觸到很多PM朋友都有遇到類似狀況。看到這邊一定有人會問,系統問題都是PM的問題嗎?系統開發團隊沒有技術方面的主管嗎? 我確實有看到有些案例很幸運,他們有很棒的技術主管帶領。 但對於沒有這樣資源的環境,我的觀點是,不如去思考,可以如何聯合有影響力的人,一起去看見問題,並願意去改善現況。這也是PM能展現影響力的地方,當你不只能辨識問題,還有方式可以帶來具體的改善(不躁進,又能在相對短期見效),這就彰顯了你的影響力。 當然,有時候總可能會有些阻礙,不論關鍵人士願意配合也好,或不願意配合也好,都分別有對應的方式可以改善問題。 節錄自:博碩《泛 PM 職能的百萬年薪破關術:職場 E 人,生活 I 人的逆襲,從被動執行到主動影響決策的理想人生》/李星玟(Rafeni) 著 [joblist_plugin title='更多104【PM 產品經理】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=%E7%94%A2%E5%93%81%E7%B6%93%E7%90%86+PM&order=15&page=1' amount='5']
【104職場力】・職涯規劃

產品經理 - 學習地圖(上):技能養成篇 

產品經理是一個融合創新、邏輯與溝通的角色。隨著數位化加速,產品思維逐漸成為組織決策的核心。從技術團隊、設計部門到商業營運,產品經理肩負整合多方資源、定義方向並推動產品落地的關鍵任務。  本篇產品經理學習地圖(上):技能養成篇,將協助轉職者認識『從入門建構產品基礎思維』到中階『掌握用戶洞察與功能實作』,最終能『獨立推動策略規劃與跨部門協作』的相關職業技能,依循學習路徑,逐步成為具影響力的產品專案執行者! 文 /【104學習精靈】 本文目錄(點擊可快速前往) 產品經理是誰?為何成為熱門職業?  產品經理工作內容 產品經理與相近職類比較表 為什麼選擇產品經理? 誰適合轉職產品經理? 掌握產品經理的核心能力:必備工具技能 x 學習路徑 x 軟技能 產品經理技能 × 學習階段 對照表格 產品經理學習地圖與路徑(搭配AI工具) 成為產品經理應具備的軟技能  產品經理是誰?為何成為熱門職業?   產品經理工作內容  產品經理(Product Manager)負責定義產品要解決的問題,並與設計、工程、行銷等部門協作推動產品從構想到落地。其核心職責包含:  需求探索:透過用戶訪談、行為數據、回饋收集等方式,洞察真實需求。  功能規劃:撰寫 PRD、制定功能優先順序、評估 MVP 可行性。  專案推進:主持日常開發流程,跨部門協調資源,確保開發進度與品質。  成果驗證:追蹤產品指標(如留存率、轉換率),進行 A/B 測試與功能優化。  策略規劃:參與產品路線圖規劃,制定中長期產品方向與營收目標。  產品經理既是產品成功的推動者,也是用戶價值的守門人。其價值在於將「使用者需求 × 商業機會 × 技術可行性」三者整合為具體可執行的產品方案。  產品經理與相近職類比較表  職位 關注重點 負責內容 常見產業 產品經理(Product Manager)使用者 + 商業價值 規劃產品功能與開發節奏 科技、電商、金融、SaaS 等 專案經理 (Project Manager) 進度與成本控制 控管時程、資源、人員配置 各類型專案導向型公司 UI/UX 設計師 使用者體驗 介面設計、動線、視覺規劃 軟體、行銷、遊戲、EdTech 等 資料分析師 數據洞察 分析用戶行為、產品數據、A/B 測試 金融、零售、科技、行銷  為什麼選擇產品經理?  📈 發展潛力大|未來產業的中樞角色  不論是新創公司還是科技巨頭,產品導向已成為企業競爭的關鍵思維。  有產品就有需求,有需求就需要 PM——從 AI、SaaS、電商到 FinTech,每個行業都需要懂得「整合價值」的人。  企業不再只需要「能執行的專業者」,而是需要「能定義方向、驅動成長」的產品領導者。  🛠️能力多元|最全面的跨域訓練場  產品經理是一個訓練全腦能力的職業:👉 左腦要有邏輯與分析能力(數據、商業)👉 右腦要能發想與感知使用者(設計、體驗)👉 兩者還要能與技術部門深度協作(開發、工程)  在角色中將學會「如何說服利害關係人」「如何觀察用戶行為」「如何評估一個功能是否值得投資」,這些都是未來每一份高階職位都會需要的綜合實力。  🚀 成長彈性高|跨域轉換與職涯彈跳力強  PM 的角色可以橫跨不同產業與職能,時常需要與工程或設計專業職能有效通協作。是「所有關鍵決策職位的預備場」。  許多優秀的 PM 在職涯中轉職為:  創業者(Founder / Co-founder)  使用者體驗設計師(UX Designer)  數據分析師(Product Data Analyst)  成為產品主管、策略顧問,甚至進入 CPO、COO 等管理層  誰適合轉職產品經理?  🎓 1. 無產品背景但熱愛創新、解決問題者  你喜歡觀察生活問題、總是腦中浮現「這東西為什麼不能這樣改?」  從 side project 開始,就是最好的敲門磚。  無需程式背景,只要有邏輯、有使用者觀點,PM 是歡迎非典型背景者的職位。  💻 2. 工程師背景者  想脫離單純執行任務的角色,希望參與更多「要做什麼」的決策討論  PM 是讓工程師走向策略與產品領導的黃金道路。  技術理解力會讓你在 PM 角色上如虎添翼。  🎨 3. 設計師 / UX 專業者  有同理心、有用戶感知力的設計師,適合轉向更有產品話語權的角色。  讓你從 UI/UX 執行者,變成「產品體驗的主導者」。  許多產品團隊喜歡擁有設計底子的 PM,因為他們更懂體驗與細節。  📢 4. 商業 / 行銷 / 業務人員  熟悉市場與用戶痛點,對產品的商業價值有敏銳觀察  補足產品開發語言與邏輯,就能駕馭市場與產品之間的橋樑位置。  掌握產品經理的核心能力:必備工具技能 x 學習路徑 x 軟技能  產品經理技能 × 學習階段 對照表格   🧩 產品規劃與需求管理 📊 數據分析與驗證能力 🎨 戶體驗與設計思維 🤝跨部門協作與專案推進 基礎 - 撰寫 User Story、建立 Persona - 初步撰寫 PRD、功能清單 - 認識基本產品指標(DAU、MAU、CTR) - 初步理解 A/B 測試、使用 Google Analytics - 繪製使用者旅程圖、UX Flow - 使用 Figma 建立簡易原型 - 熟悉 Notion / Trello 等任務管理工具 - 學習基本會議記錄與任務追蹤方式 核心 - MVP 規劃、功能優先排序(RICE、Kano) - 撰寫完整 PRD、維護 Roadmap - 使用 Mixpanel / Amplitude 追蹤行為流 - 設計驗證機制(Cohort、Retention、轉換率分析) - 熟悉設計思考流程(Design Thinking) - 與設計師協作建立 Wireframe 與可用性測試 - 使用 Jira / Asana 進行敏捷開發任務管理 - 主持 Stand-up / Sprint Review / Retro 會議 進階 - 多模組產品整合與平台化思維 - 建立產品 KPI 指標並追蹤成效 - 設計數據導向決策邏輯 - 與資料分析師共構儀表板、做策略調整 - 優化使用者體驗,結合數據與測試結果反覆調整設計- 規劃用戶測試場景、引導焦點訪談 - 建立跨部門溝通 SOP 與產品知識共享 Wiki - 作為 PM Leader 引導 Junior PM、推進跨部門專案 認證 - CSPO(Scrum Product Owner)- Pragmatic PM 認證 - Google Analytics 證照- Mixpanel / Looker Studio 認證 - Google UX Design 認證- Nielsen Norman UX 課程 - PMP 專案管理師- CSM(Scrum Master 認證)  產品經理學習地圖與路徑(搭配AI工具)  🟢 第一階段:新手 PM 入門(0~6 個月)  ✅ 目標:建立基礎產品思維與跨部門語言,從具體產出中培養使用者理解與任務邏輯。  📌 學習內容:  【產品市場機會】:初步理解產品與市場的關係(例如:Who / Why)  【找出使用者需求】:撰寫 User Story、建立 Persona、使用者旅程圖  【設計思考】:練習 Wireframe / Wireflow 製作,視覺化想法  撰寫簡易 PRD:說明做什麼與為什麼  學會製作 UAT(功能性測試 / 反向測試等)  建立會議紀錄與議題追蹤清單,強化任務邏輯與流程觀  📌 AI 工具應用:  ChatGPT / Claude:生成 User Story、用戶情境模擬  Uizard / Figma AI:快速建立原型畫面與 Wireframe  Notion AI:整理任務、產出會議紀錄與需求清單  📌 備選學習:  學習基礎專案管理(甘特圖、排程、進度跟催)  練習回報 bug 與測試報告,建立與工程團隊語言  閱讀《Inspired》、《Lean UX》理解產品角色的多重任務  [course_plugin title='產品經理入門課程' keyword='PM產品經理|入門致勝攻略:打造最強怪物新人的實戰課|104獨家線上課' amount=1] 🟡 第二階段:中階 PM 成長(6~18 個月)  ✅ 目標:獨立負責一個產品模組,深化市場洞察與優先排序邏輯,開始建立產品成果思維。  📌 學習內容:  【產品市場機會】:進行競品研究、定位圖、SWOT 分析  【使用者需求】:進階訪談技巧、使用者回饋整理、Cohort 分析  【提出解決方案】:撰寫完整 PRD、定義功能 MVP、排定開發優先順序(RICE、Kano)  【產品企劃框架】:建立產品 Roadmap,依驗證結果動態調整  專案協調與跨部門簡報報告  主持 Scrum、Sprint Review 等會議,培養團隊推進力  📌 AI 工具應用:  Miro AI:協助需求 Mapping、建立 Feature Map  Amplitude / Mixpanel + AI plugins:用於用戶行為與留存分析  Jira AI / Linear AI:協助排程與任務追蹤自動化  ChatGPT:產出會議簡報、功能拆解與優先順序建議  📌 備選學習:  與工程師深度對話 API 邏輯與限制(建立技術思維)  學習使用 A/B 測試平台與分析資料結果  與設計師協作,規劃 Usability Test 測試流程  [course_plugin title='資料分析相關課程' keyword='用AI+Google Sheet建立自動化工具,打造你的業績成長引擎|104獨家' amount=1] 🔴 第三階段:資深 PM 精進(18~36 個月)  ✅ 目標:制定產品策略與願景、帶領多模組團隊與跨部門合作,具備從數據到決策的整體能力。  📌 學習內容:  【產品企劃框架】:建立成果導向型 Roadmap,結合營運目標與客戶反饋  【有效提案法】:提案簡報、策略 Buy-in、利益關係人對齊溝通(尤其是非 PM 部門)  【提出解決方案】:設計產品 KPI(DAU、留存、LTV、NSM)  【產品驗證與迭代】:產品指標監控 → 分析迭代邏輯 → 反饋進 Roadmap  建立跨部門合作 SOP、主持策略規劃會議  設計產品願景,指導 Junior PM 並進行 Mentor / Review  📌 AI 工具應用:  Power BI / Looker Studio + GPT Plugin:產出決策儀表板、進行策略預測模擬  Notion AI:整理策略紀錄、文件管理、產品 Wiki 協作  ChatGPT / Claude:撰寫產品願景草案、跨部門溝通稿  Suno / Gamma AI:製作產品簡報、提案影片輔助  📌 備選學習:  學習產品組合管理(Product Portfolio)  熟悉商業模型設計與利潤預測(可使用 Business Model Canvas)  進階使用 AI 作為產品功能的一環(如設計 AI Prompt 功能、智能推薦引擎)  [course_plugin title='產品經理實戰課程' keyword='第7屆產品經理學習營' amount=2] 成為產品經理應具備的軟技能  產品經理的成功關鍵往往不在工具,而在於這些關鍵軟實力的「日常實踐力」:  溝通協調能力  與設計、工程、商業部門建立共識  化繁為簡、拆解問題並說服他人  優先排序與決策力  在時間與資源有限下做出取捨  擁有面對模糊需求時的清晰邏輯  系統性思考能力  看見整體產品架構與模組邏輯  能理解「做這件事對誰有價值?」  同理心與觀察力  從用戶視角出發洞察潛在問題  不被表層需求誤導  學習力與適應力  快速吸收新工具、新領域知識(如 AI、資料分析)  面對變動保持彈性與專業判斷  繼續閱讀 【產品經理 - 學習地圖(下):職涯精進篇】  [joblist_plugin title='更多104【產品經理】工作機會' url='https://www.104.com.tw/jobs/search/?jobsource=index_s&keyword=產品經理&mode=s&page=1' amount='3'] 延伸閱讀: PM「產品經理」和「專案經理」差在哪?盤點工作內容及PM技能樹 PM工作內容做什麼?產品企劃/產品經理薪資待遇、履歷面試總整理|精選工作機會 PM意思有不只3種可能!為何PM工作職缺只會愈來愈多?哪種PM最熱門? 轉職PM不撞牆!從0學會提案,產品經理學習營揭3大挑戰|商業思維學院
【104職場力】・職涯規劃

有任何收穫或想分享的,都來和大家一起聊聊吧!