Chapter 05 - Guiding Principles

本章目標

看完本章後，你應該可以回答：

• ITIL guiding principles 的用途是什麼？
• 七個 guiding principles 分別適合什麼情境？
• 如何用 guiding principles 判斷 PM、DevOps、AWS 的實務問題？
• 考試遇到「最佳下一步」或「最符合哪個 principle」時怎麼選？
• 為什麼 principles 不是口號，而是決策工具？

Key Terms

• Guiding Principles：不管組織、技術或流程怎麼變，都能協助決策的共同原則。
• Focus on Value：先確認工作是否真的幫 stakeholder 創造 value。
• Start Where You Are：先看現況、資料和已有能力，再決定下一步。
• Progress Iteratively with Feedback：用小步迭代和回饋降低不確定性。
• Collaborate and Promote Visibility：讓相關角色一起參與，並讓真實狀態可見。
• Think and Work Holistically：從 end-to-end service system 看問題，不只看單一工具或團隊。
• Keep It Simple and Practical：選擇足夠有效、可執行、低複雜度的做法。
• Optimize and Automate：先優化流程，再自動化。

Related: Chapter 04 先把 guiding principles 放進 ITIL Value System；本章負責把七個 principles 拆開。Chapter 06 的 Four Dimensions 和 Think and Work Holistically 很容易一起考。

一句話

Guiding principles 是遇到不確定情境時的決策準則，幫助團隊在不同產品、服務、技術、組織條件下，仍然能做出比較接近 value 的選擇。

核心概念

Focus on Value

先問：這件事對誰創造什麼 value？

這是最核心的 principle。它要求團隊不要只看任務、功能、工具或流程，而要回到 stakeholder outcome。

線上服務例子：

不夠好：我們要做服務狀態查詢頁
比較好：我們要讓客服查詢交易時間從 10 分鐘降到 30 秒

考題線索：

• 題目提到 客戶 / user / stakeholder outcome
• 團隊過度關注工具或流程
• 需要判斷工作是否真的有 value

Start Where You Are

先理解現有狀態，不要一開始就全部推倒重來。

這不代表保守，也不代表不能改。它的意思是：先看現有資料、流程、能力、痛點和已經有效的東西，再決定下一步。

例子：

• 想導入 AI chatbot 前，先看現有客服 ticket 分類
• 想重構核心服務前，先看 incident log、error rate、timeout pattern
• 想改 release 流程前，先看過去失敗 release 的原因

考題線索：

• 題目提到「重建整個系統」
• 沒有先評估現有能力
• 最佳選項通常是先觀察、評估、使用已有資料

Progress Iteratively with Feedback

不要一次做完所有東西，而是用小步迭代和回饋降低不確定性。

這個 principle 很適合處理新產品、AI、流程改善、風險高的 change。

例子：

不夠好：一次把所有客服流程交給 AI chatbot
比較好：先讓 chatbot 處理 10 個高頻 FAQ，觀察 resolution rate 和錯誤率

考題線索：

• 題目有不確定性
• 團隊想一次做很大改變
• 最佳選項通常是小範圍試行、收集 feedback、逐步調整

Collaborate and Promote Visibility

讓相關角色一起參與，並讓真實狀態可見。

很多 service management 問題不是技術不知道怎麼做，而是 stakeholder 沒對齊、資訊不透明、責任不清楚。

production incident 例子：

• 工程知道 API timeout
• 客服不知道怎麼回答使用者
• 客戶不知道操作是否成功
• PM 不知道 business impact

Promote visibility 不是多開會，而是讓對的人看到對的資訊。

考題線索：

• 團隊各自為政
• stakeholder 沒被納入
• 資訊不透明
• 應該建立 shared view、dashboard、溝通節奏、共同理解

Think and Work Holistically

不要只最佳化單一 team、單一工具或單一流程，要看整個 product / service system。

Related: 如果題目問「只看 technology 為什麼不夠」，通常會連到 Chapter 06 Four Dimensions。

例子：只提高 backend API speed，但客服查詢流程仍然要切四個系統，整體 value 不一定提升。

AWS 例子：

• 只加大 RDS instance 不一定解決核心服務 timeout
• 可能真正問題是 query、connection pool、retry、ALB timeout、frontend 重複送出、gateway latency

考題線索：

• 題目只看局部最佳化
• 問題橫跨 people、process、technology、partner
• 最佳選項通常是 end-to-end 分析

Keep It Simple and Practical

只做足以創造 value 的必要複雜度。

這不是偷懶，而是避免為了「看起來專業」而設計過重流程。

PM Reality：

老闆：今天晚上要上正式。
錯誤反應：臨時發明 12 層 approval。
比較好：依 change risk 決定必要檢查、rollback、monitoring、溝通方式。

考題線索：

• 解法過度複雜
• 流程或工具超過實際需求
• 最佳選項通常是簡單、可行、能創造 value 的做法

Optimize and Automate

先優化，再自動化。

這是考試很常見的陷阱。自動化壞流程，只會讓壞結果更快發生。

例子：

不夠好：直接用 AI 自動回覆所有資料修正請求問題
比較好：先清理 FAQ、定義轉人工規則、確認資料權限，再逐步自動化

DevOps 例子：

• CI/CD 前先確認 test quality
• 自動 deploy 前先確認 rollback strategy
• 自動 alert 前先降低 noisy alarm

考題線索：

• 題目提到 automation / AI
• 現有流程混亂
• 最佳選項通常是先理解與優化流程，再自動化

PM 視角

PM 可以把 guiding principles 當成日常決策檢查表。

需求評估

• Focus on value：這個需求對誰有 value？
• Start where you are：目前數據和流程怎麼樣？
• Collaborate and promote visibility：誰需要參與？

Roadmap

• Progress iteratively with feedback：是否能切成可驗證的小版本？
• Think and work holistically：這會影響客服、營運、財務、法務、工程嗎？
• Keep it simple and practical：MVP 是否足夠？

Release

• Optimize and automate：流程穩定後再自動化
• Focus on value：release 是為了什麼 outcome？
• Collaborate and promote visibility：上線狀態誰要知道？

Developer / DevOps 視角

Developer / DevOps 常會在以下情境用到 principles：

• Incident：先 restore value，再找 root cause
• Change：依風險決定 control，不是所有 change 都用同一種流程
• CI/CD：先優化 test、rollback、monitoring，再自動化 deploy
• Observability：dashboard 要服務 decision，不是展示所有 metrics
• Refactor：不要為了技術潔癖重寫整個系統，先看現有痛點和 value

例子：核心服務 timeout

Focus on value:
先恢復使用者最需要的服務能力

Start where you are:
先看 logs、metrics、recent changes

Collaborate and promote visibility:
讓客服、PM、on-call 共享狀態

Think and work holistically:
檢查 frontend retry、backend、DB、gateway、network

Progress iteratively with feedback:
先 hotfix / rollback，再逐步改善

Optimize and automate:
incident 後再補 alarm、runbook、自動化檢查

AWS 對照

Focus on Value

不要一開始就問「要用 Lambda 還是 ECS」，先問 service outcome 是什麼：低延遲？高可用？低成本？快速實驗？

Start Where You Are

先看 CloudWatch metrics、ALB logs、RDS Performance Insights、現有 incident pattern。

Progress Iteratively with Feedback

先在小流量或 staging 試行架構變更，不要一次全量切換。

Collaborate and Promote Visibility

讓 PM、DevOps、backend、security、support 看到相同 dashboard 和 rollout 狀態。

Think and Work Holistically

核心服務 timeout 不一定是 RDS 問題，可能是 gateway、retry、frontend、network、IAM、queue、connection pool 的組合。

Keep It Simple and Practical

小系統不一定需要 Kubernetes。先選足以支援 value 的架構。

Optimize and Automate

先讓 release / rollback / monitoring 清楚，再做自動化 deploy 和 auto-remediation。

實務對照

假設團隊想改善 production incident。

七個 principles 可以這樣用：

Focus on value:
目標是降低操作失敗影響，而不是增加更多 ticket 欄位。

Start where you are:
先整理最近 3 個月 incident、客服 ticket、CloudWatch alarm。

Progress iteratively with feedback:
先改善 top 3 問題，不要一次重做整個核心服務。

Collaborate and promote visibility:
讓客服、客戶營運、工程、PM 看到同一份 incident status。

Think and work holistically:
同時看 UI、API、gateway、DB、客服流程、客戶通知。

Keep it simple and practical:
先補 runbook 和清楚 status message，不急著做大型平台。

Optimize and automate:
先改善 alarm noise 和處理流程，再導入自動化通知或 AI triage。

常見誤解

誤解 1：Guiding principles 是背誦題

考試和工作都更重視情境判斷。你需要知道什麼情況適合哪個 principle。

誤解 2：Optimize and automate 代表立刻自動化

重點是先 optimize，再 automate。直接自動化混亂流程是典型陷阱。

誤解 3：Keep it simple and practical 代表隨便做

它不是降低品質，而是避免不必要複雜度。該有的風險控制、security、monitoring 仍然要有。

誤解 4：Start where you are 代表不要改變

它是要先理解現況，再做有根據的改變。不是保守，也不是拒絕 transformation。

誤解 5：Collaborate and promote visibility 代表所有人都要參加所有會議

Visibility 是讓對的人看見對的資訊，不是增加會議負擔。

Interview Angle

可能被問：

• Which ITIL guiding principle is most important when introducing automation?
• How would you apply guiding principles during a production incident?
• How do you avoid overengineering a release process?
• How do you decide whether to rebuild or improve an existing service?

回答方向：

• 用情境選 principle，不要只列清單
• 提到 value、feedback、visibility、holistic thinking
• 看到 automation 要說先 optimize
• 看到重建系統要說先 start where you are

Exam Tips

七個 principles 的考試判斷可以用這張速查表：

題目線索	最可能的 principle
問 客戶 / stakeholder outcome	Focus on value
想全部推倒重來	Start where you are
大型高風險改變	Progress iteratively with feedback
團隊資訊不透明	Collaborate and promote visibility
只看單一部門或工具	Think and work holistically
解法太複雜	Keep it simple and practical
想直接自動化	Optimize and automate

考試常見陷阱：

• 看到 AI / automation 就直接選自動化。正確做法通常是先優化流程。
• 看到流程問題就選大量 governance。正確做法可能是簡化並聚焦 value。
• 看到系統問題就選重建。正確做法通常是先理解現況。
• 看到 incident 就只找 root cause。實務上常先 restore service value。

Summary

Guiding principles 是 ITIL 中最實用、也最常考的部分之一。它們不是流程，而是決策準則。對 Technical PM 來說，七個 principles 可以直接用在需求判斷、roadmap、release、incident、AWS 架構、AI 導入和流程改善。考試時不要死背定義，要抓題目線索：value、現況、迭代、可視化、整體性、簡化、自動化。

References

• PeopleCert - ITIL Foundation (Version 5)
• ITIL - ITIL Foundation (Version 5)
• ITIL - Foundation Version 5 What's New

Quiz

請見 Chapter 05 Quiz。