sgui 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
ถ้ามีข้อมูลพอ:
- สรุปสั้นๆ ว่าเข้าใจสถานการณ์อย่างไร
- ยืนยัน 3 ตัวแปร: ใครฟัง (audience) / จังหวะหรือโอกาส (cadence) / ช่องทาง (channel) — ใช้ กฎ guess-vs-ask (ด้านล่าง): infer ได้ชัดให้เดา+ระบุว่าเดา, เคสเสี่ยงให้ถามก่อน
- ผ่าน Input Quality Gate — ถ้าขาดข้อมูล blocking ให้ถามเฉพาะข้อนั้น
- ออก update ตาม Output Contract ที่เหมาะ
- ตรวจ 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 | ความยาว | น้ำเสียง | หมายเหตุ |
|---|---|---|---|
| ยาวได้ มีโครง | เป็นทางการกว่า | มี 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 ก่อนส่งมอบ
- มี the ask ชัดเจน (decision/action/FYI) พร้อม owner + by-when ถ้าต้องการ action — และไม่ใช่ ask ปลอม
- เปิดด้วยสิ่งที่คนอ่านสนใจสุด ไม่ใช่ลำดับเหตุการณ์
- สถานะ RAG มีเกณฑ์ และ 🟡/🔴 พ่วงเหตุ-ผลกระทบ-ทางแก้
- risk/ข่าวร้ายอยู่ตำแหน่งที่คนอ่านไม่พลาด (บนสุด/subject)
- framing ตรงกับ audience — ตัดสิ่งที่ผู้ฟังคนนี้ไม่ต้องการออกแล้ว
- ถ้าเป็น external: ผ่าน guardrails (ไม่เผย internal blocker, no-blame, ไม่ promise ที่ยังไม่ confirm, มี next update)
- ความยาว/น้ำเสียงเข้ากับ channel
- เริ่มด้วยสิ่งใหม่ก่อน (new-info first); ถ้า recurring/weekly เน้น delta ไม่ทวนของเก่าทั้งหมด
- ไม่มี overclaim — "เสร็จ" คือเสร็จจริง
- ถ้าเดาข้อมูลไว้ ระบุให้ผู้ใช้ยืนยัน
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 ก่อนส่ง