<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Stakeholder Mapping on Tarragon</title><link>https://tarrragon.github.io/blog/tags/stakeholder-mapping/</link><description>Recent content in Stakeholder Mapping on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Sat, 02 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/stakeholder-mapping/index.xml" rel="self" type="application/rss+xml"/><item><title>Stakeholder Mapping</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/stakeholder-mapping/</link><pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/stakeholder-mapping/</guid><description>&lt;p>Stakeholder mapping 的核心概念是「把誰需要知道什麼、由誰負責、在什麼節奏通知」先畫清楚。它和 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel&lt;/a> 以及 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/status-page/" data-link-title="Status Page" data-link-desc="說明事故期間對外狀態頁如何承接可用性承諾">status page&lt;/a> 一起決定通報的分層。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Stakeholder mapping 位在 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/escalation-policy/" data-link-title="Escalation Policy" data-link-desc="說明事故升級鏈與值班轉接規則">escalation policy&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review&lt;/a> 之間。它把內部、客戶、管理層、法務與監管需求拆開，避免事故中漏通知或重複通知。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要 stakeholder mapping 的訊號是事故時通知對象不固定、每次都靠記憶補。常見例子包括：客戶已受影響但 account team 沒收到、法務通報窗口被錯過、或補償政策需要臨時討論。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Stakeholder mapping 要定義角色群組、owner、通知頻率、升級條件與例外處理。它的目標是把責任鏈固定下來，名單長度本身沒有意義。&lt;/p></description><content:encoded><![CDATA[<p>Stakeholder mapping 的核心概念是「把誰需要知道什麼、由誰負責、在什麼節奏通知」先畫清楚。它和 <a href="/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel</a> 以及 <a href="/blog/backend/knowledge-cards/status-page/" data-link-title="Status Page" data-link-desc="說明事故期間對外狀態頁如何承接可用性承諾">status page</a> 一起決定通報的分層。</p>
<h2 id="概念位置">概念位置</h2>
<p>Stakeholder mapping 位在 <a href="/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel</a>、<a href="/blog/backend/knowledge-cards/escalation-policy/" data-link-title="Escalation Policy" data-link-desc="說明事故升級鏈與值班轉接規則">escalation policy</a> 與 <a href="/blog/backend/knowledge-cards/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review</a> 之間。它把內部、客戶、管理層、法務與監管需求拆開，避免事故中漏通知或重複通知。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要 stakeholder mapping 的訊號是事故時通知對象不固定、每次都靠記憶補。常見例子包括：客戶已受影響但 account team 沒收到、法務通報窗口被錯過、或補償政策需要臨時討論。</p>
<h2 id="設計責任">設計責任</h2>
<p>Stakeholder mapping 要定義角色群組、owner、通知頻率、升級條件與例外處理。它的目標是把責任鏈固定下來，名單長度本身沒有意義。</p>
]]></content:encoded></item></channel></rss>