vibecodingthailand

วิเคราะห์พนักงานออฟฟิศ

กรอบตัดสินใจเชิงธุรกิจ: วิเคราะห์ Pros Cons Risks พร้อม Recommendation

สร้างรายงานวิเคราะห์การตัดสินใจแบบมีโครงสร้าง ครอบคลุม pros, cons, risks ของแต่ละตัวเลือก พร้อม recommendation ที่มีเหตุผลรองรับและสามารถนำเสนอต่อผู้บริหารได้ทันที

6เทคนิค prompt engineering

4ตัวแปรปรับแต่งได้

ข้อความผลลัพธ์ตัวอย่าง

decision-makingpros-consrisk-analysisrecommendationstrategic-planningbusiness-analysisframework

ปรับและคัดลอกพรอมต์

เริ่มต้นที่นี่

ตัวอย่างผลลัพธ์ที่จะได้

ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ

ผลลัพธ์ที่จะได้จริง

Live preview

1. สรุปสถานการณ์

บริษัทกำลังตัดสินใจเลือกรูปแบบการพัฒนา Mobile Application ภายใต้ข้อจำกัดด้านทีม งบประมาณ และระยะเวลา การตัดสินใจนี้ส่งผลโดยตรงต่อความสำเร็จของ product และ capacity ของทีมงานในระยะสั้น

2. เมทริกซ์วิเคราะห์ตัวเลือก

ตัวเลือกที่ 1: พัฒนาเองภายในทีม

Pros:

ควบคุม code quality และ architecture ได้เต็มที่ (น้ำหนัก: สูง)
ทีมเข้าใจ business logic อยู่แล้ว ลด onboarding overhead (น้ำหนัก: สูง)
IP และ codebase อยู่ที่บริษัทเต็มที่ ไม่มี vendor dependency (น้ำหนัก: กลาง)

Cons:

ทีม 3 คนมีงานหลักเต็มอยู่แล้ว เกิด context switching สูง (น้ำหนัก: สูง)
เสี่ยงที่ timeline 6 เดือนจะไม่สำเร็จ (น้ำหนัก: สูง)
คุณภาพงานหลักอาจลดลงระหว่างโปรเจกต์ (น้ำหนัก: สูง)

Risks:

ทีม burnout: likelihood สูง / impact สูง
Timeline เกินกำหนด: likelihood สูง / impact สูง
งานหลักล่าช้า: likelihood กลาง / impact สูง

ตัวเลือกที่ 2: จ้าง Outsource บริษัทไทย

Pros:

สื่อสารได้ตรง timezone และภาษาเดียวกัน (น้ำหนัก: สูง)
ทีม in-house โฟกัสงานหลักได้เต็มที่ (น้ำหนัก: สูง)
ง่ายต่อการ follow-up และ maintenance หลัง delivery (น้ำหนัก: กลาง)

Cons:

ราคาสูงกว่า outsource ต่างประเทศ อาจใกล้เคียงงบ 1.5 ล้านบาท (น้ำหนัก: สูง)
ต้องใช้เวลา vetting vendor ก่อน (น้ำหนัก: กลาง)
ต้องลงทุนเวลาใน requirement clarification (น้ำหนัก: กลาง)

Risks:

งบประมาณไม่เพียงพอหาก scope ไม่ชัดเจน: likelihood กลาง / impact สูง
Vendor ส่งงานไม่ตรง spec: likelihood กลาง / impact สูง

ตัวเลือกที่ 3: จ้าง Outsource ต่างประเทศ

Pros:

ราคาต่ำกว่าอย่างมีนัย อาจอยู่ที่ 40-60% ของงบ (น้ำหนัก: สูง)
เข้าถึง talent pool ที่หลากหลายกว่า (น้ำหนัก: กลาง)
ทีม in-house ยังโฟกัสงานหลักได้ (น้ำหนัก: สูง)

Cons:

Timezone และภาษาเป็นอุปสรรคใน daily sync (น้ำหนัก: สูง)
ความเสี่ยงด้าน IP และ data security สูงกว่า (น้ำหนัก: สูง)
Handover และ maintenance หลัง delivery ซับซ้อนกว่า (น้ำหนัก: กลาง)

Risks:

Communication breakdown ส่งผลต่อ quality: likelihood สูง / impact สูง
ปัญหา IP หรือ data leak: likelihood กลาง / impact สูง

3. ปัจจัยตัดสินใจ (Decision Criteria)

ความสำเร็จของ timeline 6 เดือน (สำคัญที่สุด)
ผลกระทบต่องานหลักของทีม (สูง)
การควบคุม quality และ IP (สูง)
ความคุ้มค่าภายในงบ 1.5 ล้านบาท (กลาง)
ความง่ายในการ maintain ระยะยาว (กลาง)

4. Recommendation

ตัวเลือกที่แนะนำ: ตัวเลือกที่ 2 จ้าง Outsource บริษัทไทย

เหตุผลหลัก:

ปกป้อง capacity ของทีม: ทีม 3 คนที่มีงานหลักเต็มอยู่แล้วไม่สามารถแบกรับโปรเจกต์ใหม่โดยไม่กระทบ business continuity ได้ การ outsource เป็นทางเดียวที่ปกป้อง delivery ทั้งสองฝั่ง
ลด communication risk ที่ส่งผลต่อ timeline โดยตรง: Outsource ไทยลด friction ด้านภาษาและ timezone ซึ่งเป็นตัวแปรที่ทำให้โปรเจกต์ล่าช้าบ่อยที่สุด ต่างจากตัวเลือกที่ 3
ความสามารถในการ maintain ได้จริง: เทียบกับ outsource ต่างประเทศ vendor ไทยสร้างความต่อเนื่องหลัง delivery ได้ง่ายกว่า และความเสี่ยงด้าน IP ต่ำกว่า

เงื่อนไขที่ทำให้ recommendation นี้ยังสมเหตุสมผล:

งบประมาณ 1.5 ล้านบาทเพียงพอหลังกำหนด MVP scope ชัดเจน (ต้องยืนยันผ่าน RFQ ก่อน)
สามารถหา vendor ที่มีผลงาน mobile app ในลักษณะใกล้เคียงได้จากการ vetting

Next Steps:

สัปดาห์ที่ 1: จัดทำ scope document และ RFQ ส่ง vendor ไทย 3-5 ราย
สัปดาห์ที่ 2-3: ประเมิน proposal และทำ vendor shortlist
สัปดาห์ที่ 4: sign contract พร้อม milestone-based payment และ IP clause ที่ชัดเจน

5. Risk Mitigation

ความเสี่ยง	แนวทางลดความเสี่ยง
งบประมาณเกิน 1.5 ล้านบาท	กำหนด MVP scope ก่อน sign contract และแยก feature เพิ่มเติมเป็น phase 2
Vendor ส่งงานไม่ตรง spec	กำหนด milestone-based payment, acceptance criteria ที่วัดได้ และ weekly review session ในสัญญา

ขั้นตอนที่ 1

ปรับให้เข้ากับงานของคุณ

แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัพเดทอัตโนมัติพร้อมก๊อปไปวางใน Claude หรือ ChatGPT ได้ทันที

ตัวแปรปรับแต่งได้4 ค่า

{{สถานการณ์}}อธิบายสถานการณ์ที่ต้องตัดสินใจใน 1-2 ประโยค ระบุให้ชัดว่ากำลังเลือกอะไร

{{บริบท}}ใส่ข้อจำกัด ข้อมูลพื้นฐาน และปัจจัยแวดล้อมที่เกี่ยวข้องกับการตัดสินใจ

{{ตัวเลือก}}ระบุตัวเลือกที่กำลังพิจารณาทั้งหมด อย่างน้อย 2 ตัวเลือก

{{ผู้มีส่วนได้ส่วนเสีย}}ระบุผู้บริหารหรือกลุ่มคนที่จะรับทราบหรือใช้ผลการตัดสินใจนี้

พรอมต์ที่ปรับแล้ว พร้อมก๊อปไปวาง

คุณคือที่ปรึกษาเชิงกลยุทธ์ระดับอาวุโสที่มีความเชี่ยวชาญด้านการวิเคราะห์และตัดสินใจเชิงธุรกิจ

**สถานการณ์ที่ต้องตัดสินใจ:**
บริษัทต้องเลือกรูปแบบการพัฒนา Mobile Application สำหรับลูกค้า

**บริบทและข้อมูลพื้นฐาน:**
ทีม dev 3 คน มีงานหลักเต็มอยู่แล้ว, งบประมาณ 1.5 ล้านบาท, ต้องเสร็จภายใน 6 เดือน

**ตัวเลือกที่กำลังพิจารณา:**
1) พัฒนาเองภายในทีม  2) จ้าง Outsource บริษัทไทย  3) จ้าง Outsource ต่างประเทศ

**กลุ่มผู้รับผลการตัดสินใจ / ผู้ที่ต้องนำเสนอต่อ:**
CEO และทีม Product

---

วิเคราะห์และจัดทำรายงานการตัดสินใจตามโครงสร้างต่อไปนี้:

## 1. สรุปสถานการณ์
อธิบายว่ากำลังตัดสินใจเรื่องอะไร และทำไมการตัดสินใจนี้จึงสำคัญ (1-2 ประโยค)

## 2. เมทริกซ์วิเคราะห์ตัวเลือก
สำหรับแต่ละตัวเลือก ให้แสดง:
- **Pros (ข้อดี):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Cons (ข้อเสีย):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Risks (ความเสี่ยง):** ระบุความเสี่ยงหลักพร้อม likelihood (สูง / กลาง / ต่ำ) และ impact (สูง / กลาง / ต่ำ)

## 3. ปัจจัยตัดสินใจ (Decision Criteria)
ระบุ 3 ถึง 5 เกณฑ์สำคัญที่ใช้ประเมิน เรียงลำดับตามความสำคัญจากสูงสุดไปต่ำสุด

## 4. Recommendation
ระบุตัวเลือกที่แนะนำอย่างชัดเจน พร้อม:
- เหตุผลหลัก 3 ข้อที่ทำให้ตัวเลือกนี้ดีกว่าตัวเลือกอื่น
- เงื่อนไขที่ทำให้ recommendation นี้ยังคงสมเหตุสมผล
- Next Steps ที่ต้องดำเนินการทันทีหลังตัดสินใจ

## 5. Risk Mitigation
สำหรับความเสี่ยงระดับสูงของตัวเลือกที่แนะนำ ให้เสนอแนวทางลดความเสี่ยงที่เป็นรูปธรรม

---
**ข้อกำหนดสำคัญ:**
- ใช้เฉพาะข้อมูลที่ระบุไว้ข้างต้น ไม่เพิ่มข้อมูลที่ไม่มีในบริบท
- หากข้อมูลในส่วนใดไม่เพียงพอ ให้ระบุว่า "ต้องการข้อมูลเพิ่มเติม: [ระบุสิ่งที่ขาด]"
- Recommendation ต้องสามารถนำไปนำเสนอต่อ CEO และทีม Product ได้โดยตรง
- ห้ามใช้ภาษากำกวม เช่น "อาจจะ" หรือ "น่าจะ" โดยไม่มีเหตุผลรองรับ

ขั้นตอนที่ 2

เข้าใจเทคนิคที่ซ่อนอยู่

คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง

prompt



**สถานการณ์ที่ต้องตัดสินใจ:**
{{สถานการณ์}}

**บริบทและข้อมูลพื้นฐาน:**
{{บริบท}}

**ตัวเลือกที่กำลังพิจารณา:**
{{ตัวเลือก}}

**กลุ่มผู้รับผลการตัดสินใจ / ผู้ที่ต้องนำเสนอต่อ:**
{{ผู้มีส่วนได้ส่วนเสีย}}

---



## 1. สรุปสถานการณ์
อธิบายว่ากำลังตัดสินใจเรื่องอะไร และทำไมการตัดสินใจนี้จึงสำคัญ (1-2 ประโยค)

## 2. เมทริกซ์วิเคราะห์ตัวเลือก
สำหรับแต่ละตัวเลือก ให้แสดง:
- **Pros (ข้อดี):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Cons (ข้อเสีย):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Risks (ความเสี่ยง):** ระบุความเสี่ยงหลักพร้อม likelihood (สูง / กลาง / ต่ำ) และ impact (สูง / กลาง / ต่ำ)

## 3. ปัจจัยตัดสินใจ (Decision Criteria)
ระบุ 3 ถึง 5 เกณฑ์สำคัญที่ใช้ประเมิน เรียงลำดับตามความสำคัญจากสูงสุดไปต่ำสุด

## 4. Recommendation
ระบุตัวเลือกที่แนะนำอย่างชัดเจน พร้อม:
- เหตุผลหลัก 3 ข้อที่ทำให้ตัวเลือกนี้ดีกว่าตัวเลือกอื่น
- เงื่อนไขที่ทำให้ recommendation นี้ยังคงสมเหตุสมผล
- Next Steps ที่ต้องดำเนินการทันทีหลังตัดสินใจ

## 5. Risk Mitigation
สำหรับความเสี่ยงระดับสูงของตัวเลือกที่แนะนำ ให้เสนอแนวทางลดความเสี่ยงที่เป็นรูปธรรม

---
**ข้อกำหนดสำคัญ:**
- 
- 
- 
-

เทคนิค prompt engineeringตัวแปรที่ปรับได้

1
Role assignment
“คุณคือที่ปรึกษาเชิงกลยุทธ์ระดับอาวุโสที่มีความเชี่ยวชาญด้านการวิเคราะห์และตัดสินใจเชิงธุรกิจ”
การกำหนด role ที่ชัดเจนและมีความเชี่ยวชาญเฉพาะทางทำให้โมเดลปรับโทนการตอบให้เป็นมืออาชีพ และใช้กระบวนการคิดที่เหมาะสมกับการวิเคราะห์เชิงกลยุทธ์แทนการตอบแบบทั่วไป
2
Output format constraint
“วิเคราะห์และจัดทำรายงานการตัดสินใจตามโครงสร้างต่อไปนี้:”
การกำหนดโครงสร้าง 5 ส่วนที่ชัดเจนช่วยให้โมเดลจัดระเบียบข้อมูลอย่างครบถ้วนและไม่ข้ามขั้นตอน ผู้ใช้สามารถนำผลลัพธ์ไปนำเสนอได้ทันทีโดยไม่ต้องปรับแต่งเพิ่ม
3
Context grounding
“ใช้เฉพาะข้อมูลที่ระบุไว้ข้างต้น ไม่เพิ่มข้อมูลที่ไม่มีในบริบท”
คำสั่งนี้ป้องกันไม่ให้โมเดลแต่งตัวเลขหรือสมมติสถานการณ์ขึ้นมาเอง ซึ่งเป็นปัญหาหลักในการวิเคราะห์ที่ต้องนำไปนำเสนอต่อผู้บริหาร
4
Negative constraint
“ห้ามใช้ภาษากำกวม เช่น "อาจจะ" หรือ "น่าจะ" โดยไม่มีเหตุผลรองรับ”
การห้ามภาษากำกวมบังคับให้โมเดลระบุจุดยืนอย่างชัดเจนหรืออธิบายที่มาของความไม่แน่นอน ทำให้ recommendation สามารถ defend ได้ในการประชุมจริง
5
Audience-aware output
“Recommendation ต้องสามารถนำไปนำเสนอต่อ {{ผู้มีส่วนได้ส่วนเสีย}} ได้โดยตรง”
การผูก variable ผู้รับเข้ากับเกณฑ์คุณภาพของ output ทำให้โมเดลปรับระดับรายละเอียดและภาษาให้เหมาะกับผู้อ่านจริง แทนที่จะเขียนแบบไม่มีเป้าหมาย
6
Calibrated uncertainty
“หากข้อมูลในส่วนใดไม่เพียงพอ ให้ระบุว่า "ต้องการข้อมูลเพิ่มเติม: [ระบุสิ่งที่ขาด]"”
การให้โมเดลระบุจุดที่ข้อมูลไม่เพียงพอแทนการเดาช่วยรักษาความน่าเชื่อถือของรายงาน และชี้ให้ผู้ใช้เห็นว่าต้องรวบรวมข้อมูลเพิ่มก่อนตัดสินใจจริง

ขั้นตอนที่ 3

เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค

คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้นๆ แบบฝั่งซ้าย แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบฝั่งขวาแก้ปัญหานี้ด้วยเทคนิคที่อธิบายข้างต้น

พรอมต์แบบที่ใช้กันทั่วไป

ช่วยวิเคราะห์ว่าควรพัฒนา mobile app เองหรือจ้าง outsource ดี

พรอมต์แบบที่ใช้เทคนิคข้างบน

กำหนด role ที่ปรึกษากลยุทธ์อาวุโส, ส่งบริบทผ่าน 4 variable (สถานการณ์, บริบท, ตัวเลือก, ผู้รับ), สั่งโครงสร้าง 5 ส่วนพร้อม weight และ likelihood, ห้ามภาษากำกวม, ผูก recommendation เข้ากับ stakeholder จริง, กำหนด fallback เมื่อข้อมูลไม่เพียงพอ

ทำไมแบบที่ใช้เทคนิคถึงดีกว่า

คำถามสั้นที่ไม่มีบริบทบังคับให้โมเดลสมมติข้อมูลขึ้นมาเอง ผลลัพธ์จึงเป็น framework ทั่วไปที่ใช้ไม่ได้กับสถานการณ์จริง prompt ที่ดีกำหนดบริบท ตัวเลือก และเกณฑ์ประเมินอย่างครบถ้วน บังคับให้วิเคราะห์จากข้อมูลที่มีแทนการเดา และผูก output เข้ากับผู้รับจริงเพื่อให้ได้ recommendation ที่สามารถ defend ได้ในการประชุม

พรอมต์ที่เกี่ยวข้อง

ลองพรอมต์อื่นในแนวเดียวกัน

วิเคราะห์

เปรียบเทียบข้อเสนอ Vendor 3 เจ้า เพื่อตัดสินใจคัดเลือกอย่างมีหลักการ

วิเคราะห์ข้อเสนอ vendor 3 รายพร้อมกันในมิติราคา คุณภาพ ระยะเวลา และการสนับสนุนหลังขาย โดยให้คะแนนถ่วงน้ำหนักและสรุปคำแนะนำที่นำไปรายงานผู้บริหารได้ทันที

พนักงานออฟฟิศดูพรอมต์

วิเคราะห์

เลือก REST หรือ GraphQL ตาม Use Case จริง

วิเคราะห์และตัดสินใจระหว่าง REST กับ GraphQL โดยพิจารณา query complexity, caching, ประสบการณ์ทีม และ tooling เพื่อให้ได้คำแนะนำที่ชัดเจนและ actionable ตรงกับบริบทโปรเจกต์จริง

นักพัฒนาดูพรอมต์

วิเคราะห์

ออกแบบ Pricing Tier 3 ระดับพร้อมวิเคราะห์ Value Capture และ Anchor Effect

ออกแบบโครงสร้างราคา 3 Tier พร้อมวิเคราะห์กลไก Anchor Effect ทางจิตวิทยา คำนวณ Estimated Monthly Revenue และระบุ Value Leakage เพื่อให้เจ้าของธุรกิจ SaaS และ Digital Product กำหนดราคาที่ดึงดูดลูกค้าและเพิ่ม Revenue ได้อย่างเป็นระบบ

เจ้าของธุรกิจดูพรอมต์

วิเคราะห์

วิเคราะห์คู่แข่งด้วย SWOT + Porter's Five Forces เพื่อหาช่องว่างตลาด

กรอบวิเคราะห์คู่แข่งแบบครบวงจรที่รวม SWOT Analysis และ Porter's Five Forces เข้าด้วยกัน เพื่อระบุช่องว่างตลาดที่แท้จริงและข้อเสนอแนะเชิงกลยุทธ์ที่นำไปใช้ได้ทันที

เจ้าของธุรกิจดูพรอมต์

ดูพรอมต์ทั้งหมดในคลัง

Prompt Library

กรอบตัดสินใจเชิงธุรกิจ: วิเคราะห์ Pros Cons Risks พร้อม Recommendation

ปรับและคัดลอก

วิเคราะห์พนักงานออฟฟิศ

กรอบตัดสินใจเชิงธุรกิจ: วิเคราะห์ Pros Cons Risks พร้อม Recommendation

6เทคนิค prompt engineering

4ตัวแปรปรับแต่งได้

ข้อความผลลัพธ์ตัวอย่าง

decision-makingpros-consrisk-analysisrecommendationstrategic-planningbusiness-analysisframework

ปรับและคัดลอกพรอมต์

เริ่มต้นที่นี่

ตัวอย่างผลลัพธ์ที่จะได้

ผลลัพธ์ที่จะได้จริง

Live preview

1. สรุปสถานการณ์

2. เมทริกซ์วิเคราะห์ตัวเลือก

ตัวเลือกที่ 1: พัฒนาเองภายในทีม

Pros:

ควบคุม code quality และ architecture ได้เต็มที่ (น้ำหนัก: สูง)
ทีมเข้าใจ business logic อยู่แล้ว ลด onboarding overhead (น้ำหนัก: สูง)
IP และ codebase อยู่ที่บริษัทเต็มที่ ไม่มี vendor dependency (น้ำหนัก: กลาง)

Cons:

ทีม 3 คนมีงานหลักเต็มอยู่แล้ว เกิด context switching สูง (น้ำหนัก: สูง)
เสี่ยงที่ timeline 6 เดือนจะไม่สำเร็จ (น้ำหนัก: สูง)
คุณภาพงานหลักอาจลดลงระหว่างโปรเจกต์ (น้ำหนัก: สูง)

Risks:

ทีม burnout: likelihood สูง / impact สูง
Timeline เกินกำหนด: likelihood สูง / impact สูง
งานหลักล่าช้า: likelihood กลาง / impact สูง

ตัวเลือกที่ 2: จ้าง Outsource บริษัทไทย

Pros:

สื่อสารได้ตรง timezone และภาษาเดียวกัน (น้ำหนัก: สูง)
ทีม in-house โฟกัสงานหลักได้เต็มที่ (น้ำหนัก: สูง)
ง่ายต่อการ follow-up และ maintenance หลัง delivery (น้ำหนัก: กลาง)

Cons:

ราคาสูงกว่า outsource ต่างประเทศ อาจใกล้เคียงงบ 1.5 ล้านบาท (น้ำหนัก: สูง)
ต้องใช้เวลา vetting vendor ก่อน (น้ำหนัก: กลาง)
ต้องลงทุนเวลาใน requirement clarification (น้ำหนัก: กลาง)

Risks:

งบประมาณไม่เพียงพอหาก scope ไม่ชัดเจน: likelihood กลาง / impact สูง
Vendor ส่งงานไม่ตรง spec: likelihood กลาง / impact สูง

ตัวเลือกที่ 3: จ้าง Outsource ต่างประเทศ

Pros:

ราคาต่ำกว่าอย่างมีนัย อาจอยู่ที่ 40-60% ของงบ (น้ำหนัก: สูง)
เข้าถึง talent pool ที่หลากหลายกว่า (น้ำหนัก: กลาง)
ทีม in-house ยังโฟกัสงานหลักได้ (น้ำหนัก: สูง)

Cons:

Timezone และภาษาเป็นอุปสรรคใน daily sync (น้ำหนัก: สูง)
ความเสี่ยงด้าน IP และ data security สูงกว่า (น้ำหนัก: สูง)
Handover และ maintenance หลัง delivery ซับซ้อนกว่า (น้ำหนัก: กลาง)

Risks:

Communication breakdown ส่งผลต่อ quality: likelihood สูง / impact สูง
ปัญหา IP หรือ data leak: likelihood กลาง / impact สูง

3. ปัจจัยตัดสินใจ (Decision Criteria)

ความสำเร็จของ timeline 6 เดือน (สำคัญที่สุด)
ผลกระทบต่องานหลักของทีม (สูง)
การควบคุม quality และ IP (สูง)
ความคุ้มค่าภายในงบ 1.5 ล้านบาท (กลาง)
ความง่ายในการ maintain ระยะยาว (กลาง)

4. Recommendation

ตัวเลือกที่แนะนำ: ตัวเลือกที่ 2 จ้าง Outsource บริษัทไทย

เหตุผลหลัก:

ปกป้อง capacity ของทีม: ทีม 3 คนที่มีงานหลักเต็มอยู่แล้วไม่สามารถแบกรับโปรเจกต์ใหม่โดยไม่กระทบ business continuity ได้ การ outsource เป็นทางเดียวที่ปกป้อง delivery ทั้งสองฝั่ง
ลด communication risk ที่ส่งผลต่อ timeline โดยตรง: Outsource ไทยลด friction ด้านภาษาและ timezone ซึ่งเป็นตัวแปรที่ทำให้โปรเจกต์ล่าช้าบ่อยที่สุด ต่างจากตัวเลือกที่ 3
ความสามารถในการ maintain ได้จริง: เทียบกับ outsource ต่างประเทศ vendor ไทยสร้างความต่อเนื่องหลัง delivery ได้ง่ายกว่า และความเสี่ยงด้าน IP ต่ำกว่า

เงื่อนไขที่ทำให้ recommendation นี้ยังสมเหตุสมผล:

งบประมาณ 1.5 ล้านบาทเพียงพอหลังกำหนด MVP scope ชัดเจน (ต้องยืนยันผ่าน RFQ ก่อน)
สามารถหา vendor ที่มีผลงาน mobile app ในลักษณะใกล้เคียงได้จากการ vetting

Next Steps:

สัปดาห์ที่ 1: จัดทำ scope document และ RFQ ส่ง vendor ไทย 3-5 ราย
สัปดาห์ที่ 2-3: ประเมิน proposal และทำ vendor shortlist
สัปดาห์ที่ 4: sign contract พร้อม milestone-based payment และ IP clause ที่ชัดเจน

5. Risk Mitigation

ความเสี่ยง	แนวทางลดความเสี่ยง
งบประมาณเกิน 1.5 ล้านบาท	กำหนด MVP scope ก่อน sign contract และแยก feature เพิ่มเติมเป็น phase 2
Vendor ส่งงานไม่ตรง spec	กำหนด milestone-based payment, acceptance criteria ที่วัดได้ และ weekly review session ในสัญญา

ขั้นตอนที่ 1

ปรับให้เข้ากับงานของคุณ

ตัวแปรปรับแต่งได้4 ค่า

{{ตัวเลือก}}ระบุตัวเลือกที่กำลังพิจารณาทั้งหมด อย่างน้อย 2 ตัวเลือก

พรอมต์ที่ปรับแล้ว พร้อมก๊อปไปวาง

คุณคือที่ปรึกษาเชิงกลยุทธ์ระดับอาวุโสที่มีความเชี่ยวชาญด้านการวิเคราะห์และตัดสินใจเชิงธุรกิจ

**สถานการณ์ที่ต้องตัดสินใจ:**
บริษัทต้องเลือกรูปแบบการพัฒนา Mobile Application สำหรับลูกค้า

**บริบทและข้อมูลพื้นฐาน:**
ทีม dev 3 คน มีงานหลักเต็มอยู่แล้ว, งบประมาณ 1.5 ล้านบาท, ต้องเสร็จภายใน 6 เดือน

**ตัวเลือกที่กำลังพิจารณา:**
1) พัฒนาเองภายในทีม  2) จ้าง Outsource บริษัทไทย  3) จ้าง Outsource ต่างประเทศ

**กลุ่มผู้รับผลการตัดสินใจ / ผู้ที่ต้องนำเสนอต่อ:**
CEO และทีม Product

---

วิเคราะห์และจัดทำรายงานการตัดสินใจตามโครงสร้างต่อไปนี้:

## 1. สรุปสถานการณ์
อธิบายว่ากำลังตัดสินใจเรื่องอะไร และทำไมการตัดสินใจนี้จึงสำคัญ (1-2 ประโยค)

## 2. เมทริกซ์วิเคราะห์ตัวเลือก
สำหรับแต่ละตัวเลือก ให้แสดง:
- **Pros (ข้อดี):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Cons (ข้อเสีย):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Risks (ความเสี่ยง):** ระบุความเสี่ยงหลักพร้อม likelihood (สูง / กลาง / ต่ำ) และ impact (สูง / กลาง / ต่ำ)

## 3. ปัจจัยตัดสินใจ (Decision Criteria)
ระบุ 3 ถึง 5 เกณฑ์สำคัญที่ใช้ประเมิน เรียงลำดับตามความสำคัญจากสูงสุดไปต่ำสุด

## 4. Recommendation
ระบุตัวเลือกที่แนะนำอย่างชัดเจน พร้อม:
- เหตุผลหลัก 3 ข้อที่ทำให้ตัวเลือกนี้ดีกว่าตัวเลือกอื่น
- เงื่อนไขที่ทำให้ recommendation นี้ยังคงสมเหตุสมผล
- Next Steps ที่ต้องดำเนินการทันทีหลังตัดสินใจ

## 5. Risk Mitigation
สำหรับความเสี่ยงระดับสูงของตัวเลือกที่แนะนำ ให้เสนอแนวทางลดความเสี่ยงที่เป็นรูปธรรม

---
**ข้อกำหนดสำคัญ:**
- ใช้เฉพาะข้อมูลที่ระบุไว้ข้างต้น ไม่เพิ่มข้อมูลที่ไม่มีในบริบท
- หากข้อมูลในส่วนใดไม่เพียงพอ ให้ระบุว่า "ต้องการข้อมูลเพิ่มเติม: [ระบุสิ่งที่ขาด]"
- Recommendation ต้องสามารถนำไปนำเสนอต่อ CEO และทีม Product ได้โดยตรง
- ห้ามใช้ภาษากำกวม เช่น "อาจจะ" หรือ "น่าจะ" โดยไม่มีเหตุผลรองรับ

ขั้นตอนที่ 2

เข้าใจเทคนิคที่ซ่อนอยู่

prompt



**สถานการณ์ที่ต้องตัดสินใจ:**
{{สถานการณ์}}

**บริบทและข้อมูลพื้นฐาน:**
{{บริบท}}

**ตัวเลือกที่กำลังพิจารณา:**
{{ตัวเลือก}}

**กลุ่มผู้รับผลการตัดสินใจ / ผู้ที่ต้องนำเสนอต่อ:**
{{ผู้มีส่วนได้ส่วนเสีย}}

---



## 1. สรุปสถานการณ์
อธิบายว่ากำลังตัดสินใจเรื่องอะไร และทำไมการตัดสินใจนี้จึงสำคัญ (1-2 ประโยค)

## 2. เมทริกซ์วิเคราะห์ตัวเลือก
สำหรับแต่ละตัวเลือก ให้แสดง:
- **Pros (ข้อดี):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Cons (ข้อเสีย):** อย่างน้อย 3 ข้อ พร้อมระบุน้ำหนักความสำคัญ (สูง / กลาง / ต่ำ)
- **Risks (ความเสี่ยง):** ระบุความเสี่ยงหลักพร้อม likelihood (สูง / กลาง / ต่ำ) และ impact (สูง / กลาง / ต่ำ)

## 3. ปัจจัยตัดสินใจ (Decision Criteria)
ระบุ 3 ถึง 5 เกณฑ์สำคัญที่ใช้ประเมิน เรียงลำดับตามความสำคัญจากสูงสุดไปต่ำสุด

## 4. Recommendation
ระบุตัวเลือกที่แนะนำอย่างชัดเจน พร้อม:
- เหตุผลหลัก 3 ข้อที่ทำให้ตัวเลือกนี้ดีกว่าตัวเลือกอื่น
- เงื่อนไขที่ทำให้ recommendation นี้ยังคงสมเหตุสมผล
- Next Steps ที่ต้องดำเนินการทันทีหลังตัดสินใจ

## 5. Risk Mitigation
สำหรับความเสี่ยงระดับสูงของตัวเลือกที่แนะนำ ให้เสนอแนวทางลดความเสี่ยงที่เป็นรูปธรรม

---
**ข้อกำหนดสำคัญ:**
- 
- 
- 
-

เทคนิค prompt engineeringตัวแปรที่ปรับได้

1
Role assignment
“คุณคือที่ปรึกษาเชิงกลยุทธ์ระดับอาวุโสที่มีความเชี่ยวชาญด้านการวิเคราะห์และตัดสินใจเชิงธุรกิจ”
การกำหนด role ที่ชัดเจนและมีความเชี่ยวชาญเฉพาะทางทำให้โมเดลปรับโทนการตอบให้เป็นมืออาชีพ และใช้กระบวนการคิดที่เหมาะสมกับการวิเคราะห์เชิงกลยุทธ์แทนการตอบแบบทั่วไป
2
Output format constraint
“วิเคราะห์และจัดทำรายงานการตัดสินใจตามโครงสร้างต่อไปนี้:”
การกำหนดโครงสร้าง 5 ส่วนที่ชัดเจนช่วยให้โมเดลจัดระเบียบข้อมูลอย่างครบถ้วนและไม่ข้ามขั้นตอน ผู้ใช้สามารถนำผลลัพธ์ไปนำเสนอได้ทันทีโดยไม่ต้องปรับแต่งเพิ่ม
3
Context grounding
“ใช้เฉพาะข้อมูลที่ระบุไว้ข้างต้น ไม่เพิ่มข้อมูลที่ไม่มีในบริบท”
คำสั่งนี้ป้องกันไม่ให้โมเดลแต่งตัวเลขหรือสมมติสถานการณ์ขึ้นมาเอง ซึ่งเป็นปัญหาหลักในการวิเคราะห์ที่ต้องนำไปนำเสนอต่อผู้บริหาร
4
Negative constraint
“ห้ามใช้ภาษากำกวม เช่น "อาจจะ" หรือ "น่าจะ" โดยไม่มีเหตุผลรองรับ”
การห้ามภาษากำกวมบังคับให้โมเดลระบุจุดยืนอย่างชัดเจนหรืออธิบายที่มาของความไม่แน่นอน ทำให้ recommendation สามารถ defend ได้ในการประชุมจริง
5
Audience-aware output
“Recommendation ต้องสามารถนำไปนำเสนอต่อ {{ผู้มีส่วนได้ส่วนเสีย}} ได้โดยตรง”
การผูก variable ผู้รับเข้ากับเกณฑ์คุณภาพของ output ทำให้โมเดลปรับระดับรายละเอียดและภาษาให้เหมาะกับผู้อ่านจริง แทนที่จะเขียนแบบไม่มีเป้าหมาย
6
Calibrated uncertainty
“หากข้อมูลในส่วนใดไม่เพียงพอ ให้ระบุว่า "ต้องการข้อมูลเพิ่มเติม: [ระบุสิ่งที่ขาด]"”
การให้โมเดลระบุจุดที่ข้อมูลไม่เพียงพอแทนการเดาช่วยรักษาความน่าเชื่อถือของรายงาน และชี้ให้ผู้ใช้เห็นว่าต้องรวบรวมข้อมูลเพิ่มก่อนตัดสินใจจริง

ขั้นตอนที่ 3

เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค

พรอมต์แบบที่ใช้กันทั่วไป

ช่วยวิเคราะห์ว่าควรพัฒนา mobile app เองหรือจ้าง outsource ดี

พรอมต์แบบที่ใช้เทคนิคข้างบน

ทำไมแบบที่ใช้เทคนิคถึงดีกว่า

พรอมต์ที่เกี่ยวข้อง

ลองพรอมต์อื่นในแนวเดียวกัน

วิเคราะห์

เปรียบเทียบข้อเสนอ Vendor 3 เจ้า เพื่อตัดสินใจคัดเลือกอย่างมีหลักการ

พนักงานออฟฟิศดูพรอมต์

วิเคราะห์

เลือก REST หรือ GraphQL ตาม Use Case จริง

นักพัฒนาดูพรอมต์

วิเคราะห์

ออกแบบ Pricing Tier 3 ระดับพร้อมวิเคราะห์ Value Capture และ Anchor Effect

เจ้าของธุรกิจดูพรอมต์

วิเคราะห์

วิเคราะห์คู่แข่งด้วย SWOT + Porter's Five Forces เพื่อหาช่องว่างตลาด

เจ้าของธุรกิจดูพรอมต์

ดูพรอมต์ทั้งหมดในคลัง

Prompt Library

กรอบตัดสินใจเชิงธุรกิจ: วิเคราะห์ Pros Cons Risks พร้อม Recommendation

ปรับและคัดลอก