sgui-stakeholder-update

name

sgui-stakeholder-update

description

ใช้เมื่อผู้ใช้ต้องการแปลงสถานะ/ความคืบหน้า/risk/decision/event ดิบ เป็น stakeholder update ที่ reframe ตาม audience, cadence, channel และปิดท้ายด้วย "so what + the ask" เช่น executive/sponsor update, weekly/status update, Slack status, escalation/risk flag, decision request, delay/timeline change, launch/milestone notice, planned downtime/maintenance notice, customer/partner notice หรือคำไทยอย่าง "เขียนอัปเดต", "รายงานสถานะ", "อัปเดตผู้บริหาร", "แจ้งทีม", "แจ้งคู่ค้า", "make this exec-friendly". ห้ามใช้กับ full report/deck, postmortem/incident report, retrospective, requirement/spec, release note ละเอียด, meeting minutes ถอดคำ, หรือ performance review.

Stakeholder Update

แปลงสถานะงานให้เป็นข้อความที่ผู้ฟังอ่านแล้ว "รู้ว่าต้องทำอะไรต่อ" ไม่ใช่ log ของสิ่งที่ทีมทำ

หลักคิดแกน: อัปเดตที่ดีตอบ "แล้วไง" (so what) ของผู้ฟัง แล้วปิดท้ายด้วย the ask — ทุกอัปเดตต้องบอกได้ว่า (1) มีอะไรใหม่/เปลี่ยน/เกิดขึ้น (2) มันแปลว่าอะไรสำหรับ "คนอ่านคนนี้" (3) คุณอยากให้เขาทำอะไร/ตัดสินใจอะไร หรือแค่รับทราบ — อัปเดตที่อ่านจบแล้วไม่รู้ว่าจะทำอะไรต่อคืออัปเดตที่ยังไม่เสร็จ

When NOT to use this skill

อย่าใช้ skill นี้เมื่อเป้าหมายหลักคือ:

• เขียนรายงานฉบับสมบูรณ์ / สไลด์นำเสนอเต็ม (full report, pitch deck) — อันนี้เป็นเอกสารยาว ไม่ใช่ update สั้น
• postmortem / incident report / root cause analysis — ใช้ template เฉพาะของมัน
• retrospective หรือ team health review
• เขียน requirement, spec, release note ละเอียด, หรือ meeting minutes แบบถอดคำต่อคำ
• performance review / feedback รายบุคคล

ถ้างานปนกัน (เช่นมี incident แล้วต้องแจ้ง stakeholder ด้วย) ให้แยกส่วน "สื่อสารสั้นถึง stakeholder" ออกมาทำด้วย skill นี้ ส่วนเอกสารเต็มทำแยก

Default interaction pattern

ถ้ามีข้อมูลพอ:

1. สรุปสั้นๆ ว่าเข้าใจสถานการณ์อย่างไร
2. ยืนยัน 3 ตัวแปร: ใครฟัง (audience) / จังหวะหรือโอกาส (cadence) / ช่องทาง (channel) — ใช้ กฎ guess-vs-ask (ด้านล่าง): infer ได้ชัดให้เดา+ระบุว่าเดา, เคสเสี่ยงให้ถามก่อน
3. ผ่าน Input Quality Gate — ถ้าขาดข้อมูล blocking ให้ถามเฉพาะข้อนั้น
4. ออก update ตาม Output Contract ที่เหมาะ
5. ตรวจ Review checklist + ปิดท้ายด้วย Final label

ถ้าข้อมูลไม่พอ: ถามทีละคำถามเฉพาะที่ขาดจริง พร้อมเสนอคำตอบที่เดาได้ อย่าถามสิ่งที่ infer จากบริบทได้ สิ่งที่เดาเองให้ระบุชัดว่าเป็นการเดา

ถ้าผู้ใช้สั่งให้ทำรวดเดียว / วางข้อมูลดิบมาเยอะ: อย่าหยุดถามยาว ทำ draft ที่ดีที่สุดจากข้อมูลที่มี แล้วระบุท้ายว่าจุดไหนเดาไว้และควรยืนยัน

กฎ guess-vs-ask (ใช้กับ audience/channel/cadence):

• infer ได้ชัด → เดาแล้วระบุว่าเดา (อย่าถาม) — เช่น บริบทบอกอยู่แล้วว่าส่งหัวหน้า
• ถามก่อน เมื่อ audience เปลี่ยน framing อย่างมีนัยสำคัญ หรือเสี่ยงสับสน internal/external (เช่น ไม่รู้ว่าเป็นคนในหรือคู่ค้า — เพราะ guardrails ต่างกันมาก)

Input Quality Gate

ข้อมูลขั้นต่ำก่อนเขียน — ถ้าขาด ให้แยก blocking / non-blocking:

Input	Required?	ถ้าขาดทำอย่างไร
สิ่งใหม่ที่ต้องสื่อสาร — progress / change / event / risk / decision / reminder	Required	ถามตรงๆ — ถ้าไม่มีอะไรใหม่เลย ก็ไม่มีอะไรให้ส่ง
สถานะรวม (on track / at risk / off track)	Required / infer if obvious	ประเมินจากข้อมูลที่มี แล้วให้ผู้ใช้ยืนยัน
Blocker / risk / decision ที่ค้าง	Required / infer if obvious	ถ้าไม่มีให้ระบุ "ไม่มี blocker" อย่างชัดเจน อย่าเว้นว่าง
The ask — อยากให้ผู้ฟังทำ/ตัดสินใจอะไร	Required / infer if obvious	infer ได้ถ้าชัด (เช่น downtime→preparation, escalation→decision/action/support) ถ้า infer ไม่ได้ค่อยถาม; ไม่มี action จริง→ระบุ "FYI"
Audience	Required / infer if obvious	เดาจากบริบท + ระบุว่าเดา; ถามเมื่อเสี่ยงสับสน internal/external (default: ผู้บริหาร/หัวหน้า)
Channel	Recommended	เดาจากความยาว/ความเป็นทางการ (default: email)
Cadence / โอกาส	Recommended	infer จาก event (default: general update ไม่ใช่ weekly เสมอ — หลาย prompt เป็น event-driven: delay/downtime/escalation)
สถานะครั้งก่อน (เทียบ delta ได้)	Optional	ถ้ามีช่วยให้เขียน "เปลี่ยนจาก X เป็น Y" ได้คม

กฎ infer-if-obvious: อย่าถามสิ่งที่ผู้ใช้สื่อมาชัดอยู่แล้วในบริบท — เช่น "แจ้ง planned downtime ให้คู่ค้า" บอก audience (คู่ค้า) + the ask (เตรียมตัว) มาในตัวแล้ว ให้ลงมือเขียน ไม่ต้องถามซ้ำ ถามเฉพาะตอน infer ไม่ได้จริงหรือเสี่ยงผิดทาง

กฎ delta (เฉพาะ recurring/weekly update): weekly/progress update ควร delta-first — เน้นสิ่งที่เปลี่ยนตั้งแต่ครั้งก่อน ถ้าไม่มี movement ให้พูดตรงๆ ว่า "ไม่มี movement เพราะ [เหตุผล]" ซึ่งตัวมันเองคือสัญญาณที่ stakeholder ควรรู้ — แต่ event-driven update (downtime, decision request, launch, escalation, first-time notice) ไม่ต้องมี "delta จากครั้งก่อน" เพราะตัว event/decision/risk คือสิ่งใหม่ที่สื่อสารอยู่แล้ว

Audience taxonomy — ปรับ "แล้วไง" ตามคนอ่าน

หัวใจของ skill นี้: ข้อเท็จจริงเดียวกัน เล่าต่างกันตามคนฟัง

Audience	สนใจอะไรจริงๆ	Framing	Detail level	ตัดอะไรทิ้ง
Exec / Sponsor	outcome, เงิน/เวลา/คน, risk ที่ต้องตัดสินใจ	"ผลลัพธ์และสิ่งที่ต้องการจากคุณ"	สูงสุด — 3-5 บรรทัดพอ	รายละเอียด implementation, ชื่อ ticket, ศัพท์เทคนิค
Peer / Cross-functional	dependency ที่กระทบงานเขา, timing	"อะไรกระทบทีมคุณ และเมื่อไหร่"	กลาง	เรื่องภายในทีมที่ไม่เกี่ยวเขา
Delivery team	scope, blocker, ลำดับงาน, ใครทำอะไร	"เราอยู่ตรงไหนและทำอะไรต่อ"	ละเอียดได้	การ spin เชิงบวก, exec framing
Customer / External	ผลกระทบต่อเขา, เมื่อไหร่ได้ใช้, ต้องทำอะไรไหม	"สิ่งนี้แปลว่าอะไรสำหรับคุณ"	กลาง-ต่ำ	internal blocker, ปัญหาภายใน, ภาษาตำหนิทีม

กฎ: audience เปลี่ยนทั้ง framing และสิ่งที่ตัดทิ้ง ไม่ใช่แค่ tone — ใช้กฎ guess-vs-ask: เดาได้ถ้าชัด, ถามเมื่อเสี่ยงสับสน internal/external

Reframing matrix — fact เดียว เปลี่ยน framing ทุก audience

ใช้เมื่อ "เหตุการณ์เดียว ต้องสื่อสารหลายกลุ่ม" (เช่น delay, downtime) — framing เปลี่ยน ไม่ใช่แค่ตัดให้สั้น:

Fact เดียว	Exec / Sponsor	Delivery team	Customer / Partner
งานเลื่อน 1 สัปดาห์	ผลต่อ timeline + risk + decision ที่ขอ	dependency, งานที่ทำต่อได้, owner	timeline ใหม่ + ผลกระทบ + next update
API ทีมอื่นยังไม่พร้อม	dependency risk (ไม่โทษทีม)	integration blocker + ระบุทีมตรงๆ	"internal dependency" ไม่ลงรายละเอียด
Planned downtime	ผลกระทบที่ควบคุมได้ + แผนเฝ้าระวัง	pre-check / monitor / post-check + owner	ช่วงเวลาใช้ไม่ได้ + สิ่งที่ต้องเตรียม
Defect ค้างหลายตัว	risk ต่อ go/no-go	fix + retest + severity + owner	ผลกระทบที่อาจเจอ + next update

ดูตัวอย่างเต็มที่ references/examples.md

Cadence × purpose — โอกาสกำหนดโครง

Cadence / โอกาส	โฟกัส	โครงที่เหมาะ
Weekly status	delta + blocker + next	สั้น: สถานะ → คืบหน้า → ติดอะไร → สัปดาห์หน้า → ask
Monthly / QBR	trend, outcome เทียบเป้า, ทิศทาง	progress vs goal → highlight → risk → ทิศทางถัดไป
Launch / milestone	เกิดอะไรขึ้น, ผลกระทบ, ต่อไปคืออะไร	what shipped → impact/ผล → ขอบเขต → next/known issues
Escalation / risk flag	ปัญหา, ผลกระทบ, ตัวเลือก, สิ่งที่ขอ	issue → impact → options → recommendation → decision/action/support needed by [when]
Scheduled change / maintenance	กำหนดการ, ผลกระทบ, สิ่งที่ต้องเตรียม/เฝ้าระวัง	window → impact → preparation → monitor/post-check → escalation

template เต็มของแต่ละโหมด (downtime, decision request, delay, PO ops, UAT, release readiness, customer) อยู่ที่ references/templates.md — โหลดเมื่อผู้ใช้ขอสถานการณ์นั้นโดยเฉพาะ

Channel format — ช่องทางกำหนดความยาวและน้ำเสียง

Channel	ความยาว	น้ำเสียง	หมายเหตุ
Email	ยาวได้ มีโครง	เป็นทางการกว่า	มี subject ที่บอก ask/สถานะตั้งแต่หัวเรื่อง
Slack / chat	สั้น scan ได้	กระชับ ตรง	bold คำสำคัญ, ใส่ ask เป็นบรรทัดท้ายชัดๆ
Standup line	1-3 บรรทัด	สั้นมาก	yesterday/today/blocker หรือ status/next/ask
Meeting talking points	bullet สำหรับพูด	พูดได้ลื่น	เรียงตามลำดับที่จะพูด + ประเด็นที่ต้องดันให้จบ

Status taxonomy — RAG ด้วยเกณฑ์ ไม่ใช่ความรู้สึก

สถานะ	เกณฑ์	ต้องมีอะไรประกอบ
🟢 On track	จะถึงเป้า/กำหนดตามแผน ไม่มี risk ที่เปลี่ยนผลลัพธ์	ระบุสั้นๆ ว่า "ตามแผน" พอ
🟡 At risk	มีปัญหาที่ "อาจ" ทำให้พลาดเป้า/เลื่อน ถ้าไม่จัดการ	cause + impact + สิ่งที่กำลังทำ + ask
🔴 Off track	พลาดเป้า/เลื่อนแล้ว หรือจะพลาดแน่ถ้าไม่มีการตัดสินใจ	cause + impact + options + recommendation + decision needed by [when]

กฎ:

• 🟡 และ 🔴 ห้ามมาเดี่ยวๆ ต้องพ่วงเหตุ-ผลกระทบ-สิ่งที่ขอเสมอ และ ห้ามวางท้ายเอกสารให้คนอ่านพลาด — Red/risk ต้องอยู่บนสุดหรือใน subject
• ห้ามใช้ 🟢 ถ้ามี blocker ค้าง ที่กระทบ timeline/scope/quality/customer แม้ทีมจะ "รู้สึก" ว่าคุมได้
• Planned downtime/maintenance อย่าตีเป็น 🔴 อัตโนมัติ และอย่าใช้ 🟢 (สื่อว่า "ไม่มี impact" ทั้งที่ระบบเข้าไม่ได้จริง) — default ใช้ 🔵 Planned / Controlled impact (มี impact จริงแต่ตามแผน, communicate แล้ว, มี monitoring) · ขยับเป็น 🟡 At risk เมื่อ comms ยังไม่ครบ / window เสี่ยงพลาด / impact สูง · เป็น 🔴 เมื่อ unplanned, เกินเวลา, หรือกระทบเกินแผน

The Ask — ส่วนที่ขาดไม่ได้

ทุก update ต้องจบด้วยหนึ่งในนี้ ระบุชัด:

• Decision needed: [อะไร] จาก [ใคร] ภายใน [เมื่อไหร่]
• Action needed: [ทำอะไร] โดย [ใคร] ภายใน [เมื่อไหร่]
• FYI / no action: ระบุตรงๆ ว่าแค่รับทราบ ไม่ต้องทำอะไร

กฎสำคัญ: ถ้าไม่มี action จริง อย่ายัด ask ปลอม — awareness update, milestone recap, launch announcement ที่ไม่ต้องการการตัดสินใจ ให้ใช้ "FYI / no action" อย่างมั่นใจ การฝืนสร้าง ask ในทุกข้อความทำให้ผู้อ่านชินชาและมองข้าม ask จริงในครั้งที่สำคัญ

ถ้ามีหลาย ask ให้จัดลำดับและบอกว่าอันไหนด่วน/สำคัญสุด — อย่าทิ้ง ask ปนกันใน prose ให้คนอ่านไปขุดเอง

No-blame framing — สำคัญมากเมื่อมี dependency จากทีม/คู่ค้าอื่น

งาน PO/BA เจอ dependency เยอะ (API ทีมอื่น, vendor, partner ส่งข้อมูลช้า, business ยังไม่ sign-off) — ระบุ dependency ให้ชัดเพื่อ actionable แต่ เล่าแบบ fact + solution-oriented ไม่ใช่ชี้นิ้ว

❌ อย่าเขียน	✅ เขียนแบบนี้
"ทีม API ทำให้งานล่าช้า"	"timeline เสี่ยงเพราะ API dependency ที่ยังไม่พร้อมสำหรับ integration"
"vendor ส่งของไม่ทันอีกแล้ว"	"รอ environment จาก vendor — ขอ ETA ที่ confirm ได้เพื่อวางแผนต่อ"

ข้อยกเว้น: ฝั่ง delivery team ภายใน ระบุชื่อทีม/เจ้าของ dependency ตรงๆ ได้ เพราะต้อง actionable — แต่ยังคงน้ำเสียง fact ไม่ใช่ตำหนิ

External / customer / partner guardrails

เมื่อ audience เป็นลูกค้า/คู่ค้า/บุคคลภายนอก เพิ่ม guardrail:

• ห้ามเปิดเผย internal blocker ที่ไม่จำเป็นต่อการตัดสินใจของเขา
• ห้ามโทษทีม/คน/vendor ภายใน — ใช้ no-blame framing เสมอ
• ห้าม promise timeline ที่ยังไม่ confirm — ถ้ายังไม่นิ่งให้บอก "จะแจ้ง next update เมื่อ [เงื่อนไข]"
• ต้องมีครบ: expected impact + preparation/action (ถ้ามี) + next update (เมื่อไหร่จะได้ยินอีก)
• น้ำเสียง: calm, professional, non-defensive — ไม่อธิบาย internal process เกินจำเป็น

Output Contract — เลือกตามที่ผู้ใช้ขอ

โหมด	Output	เมื่อไหร่
Quick line	1-3 บรรทัด: สถานะ + delta + ask	standup, Slack, อัปเดตเร็ว
Standard update	สถานะ → คืบหน้า → blocker/risk → next → ask	weekly/ปกติ
Exec brief	บนสุด: สถานะ + the ask → ผล/outcome → risk ที่ต้องตัดสินใจ (ตัด detail)	ผู้บริหาร/สปอนเซอร์
Escalation	issue → impact → options → recommendation → decision/action/support needed by [when]	risk/blocker ที่ต้องการการ decide/act/escalate
Launch note	what shipped → impact → scope/known issues → next	ประกาศ launch/milestone
Scenario template	โหลดจาก references/templates.md	downtime, decision request, delay, PO ops, UAT, release, customer

ถ้าผู้ใช้ขอ "หลายเวอร์ชันให้เลือก" (เช่น เวอร์ชันนุ่ม vs เวอร์ชันดันให้จบ) ให้ทำหลาย variant พร้อม label บอกว่าแต่ละอันเหมาะกับสถานการณ์ไหน

หลักการที่ห้ามละเมิด

• มี the ask เสมอ — อ่านจบต้องรู้ว่าต้องทำอะไรต่อ หรือรู้ว่าไม่ต้องทำอะไร (แต่ห้ามยัด ask ปลอม)
• ไม่ซ่อน Red — risk/blocker/ข่าวร้ายอยู่บนสุด ไม่ใช่ท้ายเอกสาร และไม่กลบด้วย highlight เชิงบวก
• แยก fact จาก spin — รายงานสิ่งที่เกิดจริง ไม่ใช่สิ่งที่อยากให้เป็น; "เกือบเสร็จ" ที่ไม่มีเกณฑ์คือ spin
• no-blame — ระบุ dependency ได้ แต่ไม่ชี้นิ้ว โดยเฉพาะกับ external audience
• ไม่ overclaim "เสร็จ" — เสร็จคือผ่านเกณฑ์/ส่งมอบแล้ว ไม่ใช่ code เขียนเสร็จแต่ยังไม่ verify
• แปลตามคนฟัง ไม่ใช่ย่อเฉยๆ — exec update ที่แค่เอา detail ทีมมาตัดให้สั้นคือทำผิด ต้องเปลี่ยนเป็นภาษา outcome
• new-info first; delta-first สำหรับ recurring — เริ่มด้วยสิ่งใหม่ที่ต้องสื่อสารก่อนเสมอ (event/decision/risk); ถ้าเป็น recurring/weekly update ให้เน้น delta จากครั้งก่อน ไม่ทวนทุกอย่างซ้ำ
• ข้อมูลไม่พอให้บอกตรงๆ ว่าอะไรคือ fact, อะไรคือสิ่งที่เดาไว้และควรยืนยัน

Review checklist — gate ก่อนส่งมอบ

1. มี the ask ชัดเจน (decision/action/FYI) พร้อม owner + by-when ถ้าต้องการ action — และไม่ใช่ ask ปลอม
2. เปิดด้วยสิ่งที่คนอ่านสนใจสุด ไม่ใช่ลำดับเหตุการณ์
3. สถานะ RAG มีเกณฑ์ และ 🟡/🔴 พ่วงเหตุ-ผลกระทบ-ทางแก้
4. risk/ข่าวร้ายอยู่ตำแหน่งที่คนอ่านไม่พลาด (บนสุด/subject)
5. framing ตรงกับ audience — ตัดสิ่งที่ผู้ฟังคนนี้ไม่ต้องการออกแล้ว
6. ถ้าเป็น external: ผ่าน guardrails (ไม่เผย internal blocker, no-blame, ไม่ promise ที่ยังไม่ confirm, มี next update)
7. ความยาว/น้ำเสียงเข้ากับ channel
8. เริ่มด้วยสิ่งใหม่ก่อน (new-info first); ถ้า recurring/weekly เน้น delta ไม่ทวนของเก่าทั้งหมด
9. ไม่มี overclaim — "เสร็จ" คือเสร็จจริง
10. ถ้าเดาข้อมูลไว้ ระบุให้ผู้ใช้ยืนยัน

Final label — metadata หลัง draft (ไม่ใช่ส่วนของข้อความที่ส่ง)

หลัง draft ทุกครั้ง ให้แนบ readiness label แยกออกจากตัวข้อความที่จะส่งจริง (เป็นบันทึกถึงผู้ใช้ ไม่ใช่บรรทัดในอีเมล/Slack) — เขียนนอก code block หรือกำกับว่า "Label:" เสมอ:

• ✅ Ready to send — ข้อมูลครบ ส่งได้เลย
• 🟡 Needs minor confirmation — ส่งได้หลังยืนยัน 1-2 จุดที่ระบุ
• 🟠 Needs key detail — ขาดข้อมูลสำคัญ (เช่น the ask, วันที่, audience) ต้องเติมก่อน
• 🔴 Not ready — ข้อมูลไม่พอจะเขียนให้ไม่ misleading

ตัวอย่าง: หลังร่างอีเมล exec → Label: 🟡 Needs minor confirmation — ยืนยันวันใหม่ที่จะ ship ก่อนส่ง