電子商務管理

核心概要

本課程主要講解專案管理中的「醞釀階段」(Initiation Phase)，重點在於如何建立商業案例 (Business Case, BC) 以爭取投資與高階主管支持。內容涵蓋目標設定、關鍵績效指標 (KPI) 制定、替代方案分析、可行性評估、財務模型分析（如損益平衡、淨現值 NPV）以及投資組合決策。講師透過多個案例說明如何量化效益、辨識風險，並強調利害關係人溝通的重要性。

關鍵知識點

1. 目標與 KPI 設定

• 原則：將大目標拆解為小目標（例如：前 6 個月增加新使用者，一年內達成特定訂閱數）。
• 指標：使用簡單可量化的 KPI，例如透過網站帶來的新會員數、訂閱數增長量。
• 時間範疇：需明確設定評估週期（例如：兩年內達成 1000 個訂閱數）。

2. 商業案例 (Business Case, BC) 四大要素

一份優秀的 BC 必須包含以下四個關鍵內容：

• 目標 (Objectives)：明確的專案願景與預期效益。
• 替代方案 (Alternatives)：不能只提單一方案，需比較多種可能性。
• 成本效益分析 (Cost-Benefit Analysis)：客觀的財務量化分析。
• 風險 (Risks)：公正客觀地列出潛在風險與配套資訊。

3. 替代方案類型 (6 種)

提案時應考慮以下替代方案進行比較：

1. 維持現狀 (Status Quo)。
2. 流程再造 (不透過系統，僅改善制度/人力)。
3. 匯入同業系統 (參考競爭對手或同行現有系統)。
4. 改造現有系統 (Upgrade 既有系統)。
5. 採購套裝軟體 (Off-the-shelf)。
6. 客製化開發 (Custom Development)。

4. 可行性分析 (Feasibility Study)

• 經濟可行性 (Economic)：財務上的投資回報。
• 技術可行性 (Technical)：基礎建設與平臺環境是否匹配。
• 組織可行性 (Organizational)：使用者接受度與組織文化。
• 法律與道德 (Legal & Ethical)：法務規範與道德爭議。

5. 財務評估模型

• 損益平衡分析 (Break-even Analysis)：計算需要多少銷量或時間才能回收成本（例如：開發成本 10 萬，單位利潤 5 元，需賣出 2 萬單位）。
• 淨現值 (NPV)：考慮通貨膨脹與時間價值，將未來收益折算為現值進行加總。
• 投資回報率 (ROI)：比較投資於系統與其他投資渠道（如存款、基金）的回報。
• 評分模型 (Scoring Model)：針對非財務指標（如客戶滿意度、戰略匹配度）進行加權評分。

案例分析

• 銀行健康網站案例：
  • 目標：增加訂閱數與影片觀看數。
  • 方法：透過網站引導成為新會員，追蹤來源廣告效益。
  • 結果：高階主管同意後，設定兩年內增加特定訂閱數之 KPI。
• 鐵路局/公司 APP 再造計劃 (十幾億元投資案例)：
  • 背景：既有系統無法滿足成長需求與多元化服務。
  • 願景：整合資源、優化標準、創造多元服務。
  • 評估：透過 5 個 KPI 分三年階段式檢視專案成敗。
• 學校籃球場地租借 APP (課堂模擬案例)：
  • 利害關係人：電算中心、體育處、總務處、學生會。
  • 重點：提案前需先與關鍵人員（如電算中心主任）溝通，爭取支持與背書。
• 網購系統開發 (財務計算案例)：
  • 成本：開發成本 10 萬。
  • 收益：單位銷售利潤 5 元。
  • 損益平衡點：2 萬單位。
• 企業 BI 系統通報分析：
  • 週期：5 年評估。
  • 計算：將每年收益與成本折算為現值，計算整體 NPV 與回收期（約 2.1 年）。

風險與注意事項

• 提案風險：
  • BC 編制不周全，未考慮所有替代方案。
  • 缺乏利害關係人支持 (Lack of stakeholder support)，未事先溝通導致會議上反對。
  • 財務分析過於理想化，未包含風險成本。
• 執行風險：
  • 使用者抗拒新系統（無形成本）。
  • 系統上線初期的混亂與不便。
  • 維護成本與資料擴充帶來的持續支出。
• 決策考量：
  • 投資組合管理：需考慮專案是否符合公司政策、急迫性與戰略匹配度。
  • 並非所有提案都會通過，未通過亦為醞釀階段的結束，需記錄過程供未來參考。

課程回顧與測驗

講師於課末進行重點驗收，確認學生掌握以下內容：

• 優秀 BC 的四大要素：目標、替代方案、成本效益分析、風險。
• 六種替代方案：維持現狀、流程改善、同業系統、改造現有、套裝軟體、客製開發。
• 醞釀階段職能：建立目標、辨識利害關係人、可行性分析、財務量化、提案推薦。

核心概要

本課程為專案管理教學，重點介紹專案生命週期與管理流程的區別、專案醞釀與規劃階段的核心任務，以及 MOV（Measurable Organizational Value，可衡量組織價值）的定義與應用。講師透過價值鏈分析說明如何將專案目標與組織願景對齊，並詳細講解 MOV 的制定標準、實例及呈現格式。課程亦提及 PMBOK 第八版相關資訊與專案結案反思要求。

關鍵知識點

1. 專案生命週期 vs. 專案管理流程

• 專案生命週期 (Project Life Cycle)：包含醞釀、規劃、執行、監控、結案等階段（視模型而定，如瀑布式或重複發展模型）。
• 專案管理流程 (Project Management Process)：適用於任何活動管理的五個流程群組，可套用於生命週期的每個階段：
  1. 啟動 (Initiating)
  2. 規劃 (Planning)
  3. 執行 (Executing)
  4. 監控 (Monitoring & Controlling)
  5. 結案 (Closing)
• IPO 觀點：每個階段的產出 (Output) 成為下一個階段的輸入 (Input)，例如醞釀階段的產出是專案啟動的依據。

2. MOV (可衡量組織價值)

• 定義：專案成功與否的定義，指專案為組織帶來的價值，需可量化且客觀。
• 制定標準：
  • 可衡量 (Measurable)：需有具體數字或客觀指標。
  • 可同意 (Agreeable)：需獲得使用者端與開發端（或廠商）的共識。
  • 可實現 (Realizable)：需創造實際價值，而非無效勞動。
  • 有時限 (Timed)：需設定實現價值的具体時間點（非僅專案上線時間，可能需後續運作一段時間）。
• 呈現格式：可採條列敘述或表格方式（分階段實現，如 3 個月、6 個月、9 個月內的預期效益）。

3. 價值鏈分析 (Value Chain Analysis)

• 目的：確保專案目標配合組織整體戰略與願景。
• 案例（大學客戶系統）：
  • 組織願景：成為國際一流大學。
  • 處室目標：國際處（廣招國際生、雙聯學位）、教務處（通過 AACSB 認證）。
  • 系統需求：為滿足認證條文中與客戶相關的規範，開發客戶系統以協助教授與行政流程符合標準。
• 價值影響領域：
  • 顧客面（品質、服務體驗）
  • 策略面（市佔率、競爭關係轉合作）
  • 財務面（營收增加、成本降低）
  • 營運面（流程效率、錯誤減少）
  • 社會/環境面（知識共享、安全、環保）

MOV 實例參考

領域	範例描述	預期指標
行銷/促銷	促銷方案成功定義	三個月內回購率達到特定目標
研發/製造	開發新產品	成本比競爭對手便宜，於明年 4 月 1 日前製造出
銷售成長	智慧型手機銷售	下季結束前銷售成長從 3% 提升至 6%
財務/庫存	庫存管理系統	下一財務會計年度結束前，庫存週轉率改善 15%
工安/IE	工廠改善專案	公安事故率下降至特定標準
系統效率	資訊系統上線	系統上線 6 個月內，訂單處理量增加 1000 個

課程行政與證照資訊

• PMBOK 第八版：
  • 推出時間：2026 年 1 月（參考時間 2026-09-18 之「今年 1 月」）。
  • 內容重點：涵蓋 7 個效能領域（範圍、財務、風險、資源、利害關係人、不確定性、治理）。
  • 參考價格：約 4,500 元新台幣。
  • 會員費用：約 174 美金（加入會員後可下載相關資源）。
• 專案結案要求：
  • 專案結案時需準備反思報告，包含 4 項內容（具體項目需參照課程要求）。
  • 具備貢獻價值者可獲獎賞，目的是讓未來類似方案在規劃風險配置時能參考此資訊。
• 資料貢獻：鼓勵將專案完成後的真實數據（如上下班打卡、實際工時研報）貢獻給企業，用於強化 AI 預測功能與數據挖掘。

後續學習方向

• 下週主題：將深入探討醞釀階段與規劃階段的具體操作。
• 學習建議：
  • 理解 MOV 如何作為專案成功的最高指導原則。
  • 練習將專案目標與組織價值鏈對齊。
  • 有興趣考取管理證照者可自行查詢 PMBOK 第八版詳細資訊。
  • 撰寫結案報告時，應主動將課程所學之資格與標準納入。

核心概要

本課程主要講解專案管理中的決策分析與文件規劃流程，透過一個運輸服務系統開發的案例，演示如何從商業案例（BC）過渡到專案章程（PC）及專案計劃。內容涵蓋方案評估、總擁有成本（TCO）分析、關鍵績效指標（KPI）設定，以及不同專案文件（BC、PC、Plan）的區別與用途。

案例分析报告：系統開發方案評估

課程透過一個地區運輸服務系統案例，比較四種潛在方案，並進行財務與效益分析：

方案	描述	特點與成本結構
方案一	維持現狀	人工協調，服務規模有限（100 人），溝通成本高。
方案二	租用服務	租賃現有服務，需少量客製化（約 30 工時），初期成本較低。
方案三	購買套裝	一次性採購（約 2 萬多美金），含少量客製化（120 工時）。
方案四	客製開發	從無到有開發（360 工時），初期成本高，但長期擴展性佳。

• 評估維度：包含財務成本（4 年累計 TCO）、營運效率（請求處理時間從 8 小時縮減至 2 小時）、服務規模（從 100 人增至 150 人）。
• 分析結論：雖然方案二在初期成本較低，但從 4 年累計總成本（TCO）與長期效益評分來看，方案四（客製開發） 在長期表現上較優。
• 改進建議：案例報告需補充風險分析、現金流折現計算，以及評分標準的客觀性（避免主觀評分）。

關鍵文件與階段規劃

課程釐清了專案不同階段的核心文件及其區別：

• 商業案例 (Business Case, BC)
  • 階段：預釀階段。
  • 目的：論證專案必要性，提供高階決策依據（如董事會審批預算）。
  • 內容：高階目標、成本效益分析、方案比較。
• 專案章程 (Project Charter, PC)
  • 階段：規劃階段初期。
  • 性質：策略性文件，類似「憲法」，多方共享。
  • 內容：專案目標、主要里程碑、預算摘要、關鍵承諾、授權範圍、適用標準。
  • 生效日：案例中提到 9 月 18 日簽署，預計 10 月 10 日生效。
• 專案計劃 (Project Plan, PP)
  • 階段：規劃階段細節展開。
  • 性質：執行層級文件，可能包含內部風險與詳細進度。
  • 內容：工作分解結構（WBS）、詳細時程、資源分配、溝通計劃、質量保證措施。
  • 區別：PC 為原則性框架，PP 為詳細執行指南；PC 多方共享，PP 可能僅內部可見。

行動項

負責人	任務	時間
學員	複習案例內容，分析報告改進點（風險分析、折現計算等）	2 週內 (約 2026-10-02 前)
學員	準備下一次課程內容（專案計劃書、WBS 相關知識）	下次課程前

後續方向

• 下階段將進入詳細規劃，重點討論工作分解結構（WBS）、資源分配及風險管理。
• 將參考企業實際模板（如通過 CMMI 認證公司的專案計劃書範本）進行學習。
• 強調文件複用性，根據專案規模（大/中/小）調整計劃書內容深度。

核心概要

本文本源於一堂充滿現場互動與即興對話的軟體工程與專案管理課程，講師以美國 Standish Group 2023 年調查報告為切入點，揭示高達 68.8% 的 IT 專案面臨失敗或挑戰的殘酷現實，並將根源指向「溝通斷層」與「需求不明確」。課程核心衝突在於傳統線性開發模式與現代軟體開發中固有的「不確定性」之間的矛盾，講師通過解構 Waterfall、V-Model、Spiral 至 Agile（Scrum/XP/DevOps）等方法論的演進邏輯，主張從「控制思維」轉向「價值導向」與「擁抱變動」。最終，文本將技術流程昇華為一種組織學習機制，強調關鍵人員（Key Person）的協調、AI 作為協作角色的定位，以及透過回顧會議（Retrospective）將專案數據轉化為組織資產的必要性。其力量感源於將枯燥的管理理論置於真實的職場痛點（如工程師離職、需求無限變更、預算被砍）中進行反覆打磨，並用「鐵三角」的幾何約束與「滑板到汽車」的演化意象，具象化了專案管理的本質。

[殘酷的失敗數據與共同因子]

• 數據衝擊與定義重構：引用 Standish Group 2023 年針對 175,000 個專案的調查，赤裸呈現僅 16.2% 專案成功，31% 徹底失敗（Cancelled），52.8% 面臨挑戰（Challenged，指超時、超支或功能縮水）。講師特別釐清「挑戰」並非失敗，而是需要追加預算與時間的掙扎狀態。
• 失敗根源的深度歸因：列舉前十大失敗原因，包括缺乏用戶參與、需求不明確、資源不足、高層支持缺失等。講師引導學員穿透表象，指出所有原因背後的共同因子是「人」與「溝通」的斷裂——工程師在角落偷寫程式（Hiding in the corner）直到最後才確認，導致時間與資金的雙重浪費。
• 價值導向的思維翻轉：提出專案成功的三個維度：對公司的效益貢獻（Value）、關鍵人員的協調（Key Person/Coordination）、以及個人與組織的學習成長（Lessons Learned）。強調不能只問「做了什麼功能」，而要問「創造了什麼價值」與「學到了什麼教訓」。

[方法論的光譜：從線性鐵律到敏捷演化]

• 序列型模式的嚴謹與代價：
  • Waterfall（瀑布模型）：描繪為一條單向道，規劃、分析、設計、實作、測試嚴格依序進行。適用於需求極度明確、變動極少的場景（如飛安系統、生管系統），一旦需求模糊，此模式將導致巨大的返工成本。
  • V-Model 與雙 V 模型：強調「驗證與確認（V&V）」的對應關係。左側的需求分析對應右側的驗收測試，系統設計對應系統測試。雙 V 模型更進一步區分了子系統與整體系統的層級，確保每個開發階段都有對應的測試機制把關。
• 風險導向的螺旋上升：
  • Spiral Model（螺旋模型）：以 1988 年 Boehm 提出的理論為基礎，描繪專案沿著螺旋線向外擴張，每一圈都經歷「目標設定、風險分析、工程實作、評估」四個象限。特別適用於大型套裝軟體或市場競爭激烈的產品，核心在於不斷進行市場與技術的風險預判。
• 增量與迭代的敏捷革命：
  • 從滑板到汽車的隱喻：生動描述敏捷開發的精髓——與其讓客戶等待一年得到一輛完美的汽車，不如第一個月先交付一個能用的滑板，隨後逐步升級為滑板車、機車，最終演化成汽車。強調「早點看到成果」與「擁抱變動」。
  • 極限程式設計（XP）的雙人舞：詳細解說「結對程式設計（Pair Programming）」，由資深與資淺工程師、或業務與技術人員兩兩一組，共同面對螢幕編碼。這不僅是技術互補，更是為了防止關鍵人員離職導致專案停擺的知識備份機制。
  • Scrum 的節奏感：描繪 Sprint（衝刺）的循環，從 Product Backlog 挑選用戶故事（User Story），經過每日站會（Daily Stand-up）、衝刺審查（Review）到回顧會議（Retrospective），在短週期內交付可用的軟體增量。
  • DevOps 的自動化洪流：強調持續整合（CI）與持續部署（CD），透過自動化工具進行大量的迴歸測試（Regression Testing），解決人工測試無法負荷的瓶頸，實現開發與運維的無縫同步。

[專案管理的鐵三角與生命週期實戰]

• 鐵三角的幾何博弈：將範圍（Scope）、時間（Time）、成本（Cost）構建為一個三角形，品質（Quality）位於中心。講師用數學邏輯闡述：若客戶壓縮預算或時間（邊長變短），若不犧牲品質，則必須縮減範圍；反之，若要擴大範圍，則必須增加時間或成本。這是一個無法逃避的守恆定律。
• 生命週期的五個階段實錄：
  • 醞釀與啟動：定義專案價值，產出專案章程（Project Charter）。
  • 規劃：制定詳細的時程、資源、風險管理計劃，並獲取利害關係人的承諾。
  • 執行與監控：依照計劃實作，同時進行嚴格的變更控制與風險監控，產出測試報告與狀態報告。
  • 結案：無論是成功上線還是中途終止（Terminated），都需進行正式結案，確認交付物。
  • 檢討與知識沉澱：這是常被遺漏的一環。強調必須產出「專案檢討報告」，收集實際發生的成本數據、新發現的風險、最佳實踐（Best Practices）以及教訓（Lessons Learned），將個人經驗轉化為組織的資產庫，供未來專案調用。

下一步行動

• @授課講師：
  • 下週一晚上 6:30 繼續上課，介紹更多虛擬實作與案例討論 - [下週一 18:30]。
  • 安排教授專長介紹環節，協助學生選擇指導教授與題目 - [TBD]。
  • 發放並收集學生證、准考證簽名，以及回答問題同學的加分登記 - [TBD]。
• @學生/學員：
  • 組建專案小組（每門課需組隊，若無期末考則需完成兩個報告）- [TBD]。
  • 前往白板簽名確認加分資格（針對課堂提問者）- [TBD]。
  • 準備選修 AI 相關課程或論文題目，並與潛在指導教授進行初步諮詢 - [TBD]。
  • 領取證書（針對賴冠骨、陳佳穎等特定同學）- [TBD]。

啟示

1. 失敗的本質是溝通的斷層：專案失敗往往不是技術不夠先進，而是因為「工程師躲在角落寫程式」，缺乏與用戶及利害關係人的同步。
   • 原文金句：「你能不能看出這些原因有一個共同因素？...就是人，就是溝通。」
2. 擁抱變動勝過僵化計劃：在不確定的環境中，試圖一次性定義所有需求是徒勞的，唯有透過小步快跑、快速反饋的迭代（如從滑板到汽車），才能在變動中創造真實價值。
   • 原文金句：「敏捷的訴求就是擁抱變動...讓客戶在過程中可以很早就用到部分的系統。」
3. 知識沉澱是組織的唯一資產：專案結束不代表任務完成，若未將實際數據、風險教訓與最佳實踐轉化為組織知識庫，同樣的錯誤將在下一個專案中重複上演。
   • 原文金句：「Manager should always ask to capture lessons...選擇知識之上。」

核心概要

這堂課程始於對傳統「抓管理」模式的批判，講師陳老師開宗明義指出系統開發應是「抓導向」，需以 IPD（整合產品開發）方法論為核心，將規劃、風險監控與團隊協調前置，而非僅依賴後期補救。課程主軸從抽象的學理基礎（如需求發展、智慧財產權、安全議題）過渡到具象的實戰操作，透過引入企業流程再造、限制理論及反向工程等研究案例，試圖填補學術與產業現場的斷層。最終，課程轉化為一套嚴謹的行動框架：學生需組建五人團隊，透過每週輪替的深度報告、個人實務經驗分享及非同步論文研讀，將課堂所學投射至真實職場情境。其敘事邏輯的有效性源於將枯燥的專案管理條文，轉化為充滿「行車安全」、「咖啡機」、「截稿死線」等生活質感與職場張力的動態教學現場，強調「做中學」與經驗共享的價值。

[抓導向而非抓管理的思維重塑]

• 核心衝突的揭示：講師強烈對比了「抓管理」與「抓導向」的本質差異。他指出，若用管理後期事務的方式來對待資金系統或電子商務開發，注定失敗。系統開發必須在起始階段就進行高強度的規劃，涵蓋功能內容、開發路徑及預計實現的價值優勢。
• 風險與協調的質感：描述開發過程並非線性坦途，而是充滿了來自供應商、內部團隊及其他競爭單位的複雜博弈。講師強調，專案管理的精髓在於「過程中的記錄」與「平時的風險監控」，這需要領導者具備極高的協調能力，以應對團隊內外的摩擦與競爭。
• 方法論的導入：正式引入 IT 領域的黃金標準——IPD（Integrated Product Development，整合產品開發）方法論。這不僅是一套流程，更是一種從需求定義到產品上市的系統性思維，用以取代碎片化的開發模式。

[從抽象學理到血肉豐滿的產業案例]

• 知識版圖的擴張：課程內容不侷限於基礎規劃，更延伸至深層的學術與產業議題。包括「需求發展」中隱藏需求的挖掘（甚至開發 AI 工具輔助新進工程師）、「智慧財產權」在不同角色（主管、工程師、客戶）眼中的差異，以及橫跨 20 年的資安演變史。
• 研究案例的衝擊力：講師展示了一系列具象的研究成果，賦予理論血肉。例如：將軟體開發應用於「企業流程再造」、利用「限制理論」解構充滿簽字流程的官僚體制、透過「反向工程」窺探技術底層，以及探討「本體論」在需求分析中的應用。這些案例揭示了從古典決策模式到授權團隊的文化升級痛點。
• 教材的厚度：明確指定三本核心教材，涵蓋一般性介紹、學術深度探討及專案管理專論，並承諾每週更新投影片以追蹤 IT 領域的神速變化，確保課程內容的「CP 值」與時俱進。

[分組實戰與動態靜態交織的評分機制]

• 團隊組建的緊迫感：面對 50 位學員，講師要求迅速組建 10 個五人小組，強調「招兵買馬」的即時性。每組僅有一次上台機會，需進行 25 分鐘的深度分享與 5 分鐘的問答，且必須在當週四下班前提交兩道無答案的討論題庫，製造預先思考的壓力。
• 經驗分享的雙軌制：
  • 動態互動：課堂上的即時提問與回答，需於當天下課前向助教登記，考驗反應速度與參與度。
  • 靜態沉澱：鼓勵學員撰寫「個人心得業務」，將課堂理論與自身工作經驗（最佳實務、失敗教訓）結合。規定僅兩頁篇幅，需在每週四前上傳至限定區域，形成封閉式的知識共享圈。
• 評分權重的張力：總分 100 分中，課程參與佔 25 分（動態 + 靜態），小組報告佔 35 分，期末報告佔 40 分。講師特別強調「親力親為」，嚴禁委託 AI 或他人代寫心得與報告，並設定嚴格的逾期不受理原則，強化時間管理的紀律。

[時程節點與非同步學習的彈性安排]

• 時間表的微調與人性化：針對中秋節與連續假期，講師展現彈性，將原定同步課程改為「非同步學習」。學員需在假期間研讀精選論文並撰寫報告，既尊重學員的出國計畫，又維持學習密度。
• 關鍵節點的標記：
  • 10 月 2 日/10 月 10 日：第一組報告的關鍵時點。
  • 11 月：安排來自 ASML（愛斯摩爾）的資深經理進行實物演講，分享從紅海市場到晶圓廠長的跨領域專案管理經驗。
  • 12 月 18 日 19:00-20:50：期末報告展示，特別考量交通時間調整為晚間時段。
• 論文研讀的長尾效應：開放從即日起直至期末週均可繳交論文心得，鼓勵學員在修完相關單元後再回頭研讀，以獲得更深的領悟，但同時警告「時間拉越久越容易忘記」的心理陷阱。

下一步行動

• @全體學員 (修課學生)：
  • 立即進行分組，每組 5 人，並確認組員名單 - [下次上課前]。
  • 每週四下班前 (17:00) 上傳當週負責報告組別的兩道討論題目 (無答案) - [每週四]。
  • 每週四下班前 (17:00) 上傳個人心得業務 (限兩頁，含姓名學號) - [每週四，逾期不受理]。
  • 於課堂上積極參與動態提問，並於當天下課前向助教登記 - [每週上課日]。
  • 研讀指定論文並撰寫心得報告 - [即日起至 12/18 期末週]。
  • 準備期末小組報告，注意引用規範與反抄襲原則 - [12/18]。
• @陳老師 (授課講師)：
  • 每週五上午 9 點後更新課程投影片與教材 - [每週五]。
  • 邀請 ASML 資深經理進行專題演講 - [11 月]。
  • 主持期末報告評審與課程總結 - [12/18]。
• @助教與班代：
  • 協助統計分組名單並建立聯絡管道 - [下次上課前]。
  • 登記課堂動態發言名單並協助評分記錄 - [每週上課日]。
  • 管理課程平台討論區，確保內容僅限班級內部觀看 - [持續進行]。

啟示

1. 導向重於管理：在複雜的系統開發中，前期的「導向規劃」遠比後期的「補救管理」關鍵；缺乏前瞻性的風險監控與價值定義，再嚴密的管理也是徒勞。
   • 原文金句：「系統開發是抓導向，所以我們不用抓管理的方式來管理資金系統或者是電子商務。」
2. 經驗的流動價值：學習不僅發生在講台上，更發生在學員將理論與自身職場痛點（如官僚簽字、隱藏需求）對撞的過程中；封閉式的經驗分享能創造出超越教材的實務智慧。
   • 原文金句：「我認為還要有一個 space，讓大家可以分享一個就上課的內容來講，你工作的相關的一些經驗啊，做招的實用機驗或者是你們公司的最佳實務做法。」
3. 親力親為的不可替代性：在 AI 工具泛濫的時代，親自撰寫心得與深度思考的過程，才是將知識內化為能力的唯一途徑，任何捷徑都將削弱學習的本質。
   • 原文金句：「大家放一寫噢我們希望是你自己親自是的啊...不要叫別人來幫你寫噢。」