SoftSQ · Engineering · Probation 120 Days

AI Workflow Lead — ระบบงานและ Roadmap 120 วัน

สรุปเชิงภาพจากเอกสาร Job Description · KPI · Probation ฉบับ 18 สิงหาคม 2026 ของคุณ Chaipipat Pidej — ใช้เป็นแผนที่อ้างอิงเดินงานตลอดช่วงทดลองงาน ไม่ใช่เอกสารทดแทนต้นฉบับที่ลงนามจริง

Reports to

Engineering Manager

Direct reports

ไม่มี

Work model

Hybrid · WFH 1 วัน/สัปดาห์

Career path

AI Workflow Lead → Senior → EM

Core KPI

K1 · K3 · K5 · K6

§01 · ขอบเขตและจุดต่อกับทีมอื่น

ตำแหน่งนี้เป็นเจ้าของอะไร และส่งต่อใครที่ขอบเขตไหน

AI Workflow Lead เป็น enabler/coach ข้ามทีม ไม่ใช่สายบังคับบัญชา และไม่ถือความเป็นเจ้าของ project delivery, การ audit process, bidding หรือเอกสารฝั่ง proposal เส้นทึบคือความร่วมมือที่ทำงานอยู่ประจำ เส้นประคือขอบเขตที่ต้องประสานผ่านเจ้าของจริงหรือเป็นการส่งมอบในอนาคต

เส้นทึบ = ทำงานร่วมกันประจำ (สีเขียว = Software Engineer Project Lead/Dev) · เส้นประ = ขอบเขตที่ต้องประสานผ่านเจ้าของจริง หรือเป็นการส่งมอบ/รับโอนในอนาคต · กรอบข้อความบนเส้นคือความสัมพันธ์แบบย่อ รายละเอียดเต็มอยู่ในกล่องแต่ละตำแหน่งและตารางด้านล่าง

ไม่อยู่ใน scope ของตำแหน่งนี้ (ข้อ 1.2)

ความเป็นเจ้าของ project delivery — เป็นของ Software Engineer Project Lead / Dev
Process audit และการบังคับใช้ process — เป็นของ Process & Quality Lead
ความเป็นเจ้าของงานประมูล (bidding) การนำเสนอลูกค้า และ technical proposal ฉบับส่งลูกค้า — เป็นของ Solution Architect / EM รักษาการ
AI ฝั่งเอกสาร (proposal, minutes, เอกสารลูกค้า) — เป็นของ Document Specialist
การเป็น line manager — ไม่มีผู้ใต้บังคับบัญชาโดยตรง

§02 · ระบบความรับผิดชอบ

Part A–F: สิ่งที่ต้องทำเป็นหมวดหลัก

5 หมวดหลัก (A–E) คือแกนของตำแหน่ง วัดผลจากระดับการ adopt ของทีม ไม่ใช่ปริมาณงานที่ทำเอง ส่วน Part F เป็น "หมวกรอง" ที่ผูกเงื่อนไข sunset ไว้ชัดเจน

Part A

Agentic SDLC Pipeline Ownership

ใช้ MAS V3 ส่งงานจริงแบบ end-to-end ด้วยตนเองก่อนเสนอแก้ pipeline
เก็บ friction จาก Project Lead/Dev → ปรับปรุงเป็นรอบ release มี changelog
ทุกมาตรฐานใหม่ต้องผ่านอนุมัติ EM ก่อนประกาศใช้
รื้อ/แทนที่ของเดิมต้องมี current-state analysis note ก่อนเสมอ
ทำเอกสาร onboarding ให้ dev ใหม่ใช้ pipeline ได้เองโดยไม่พึ่ง EM

Part B

Prompt Library & Reusable AI Assets

ดูแล prompt library, skills, agent definitions แบบมี version control
คัดกรอง contribution จาก Project Lead/Dev แล้วประกาศเป็นมาตรฐาน
วัดการใช้ซ้ำจริง — asset ที่ไม่มีผู้ใช้ไม่นับเป็นผลงาน

Part C

AI Output Verification & Quality Gate

ตั้งเกณฑ์ขั้นต่ำก่อน merge/ส่งมอบ (design/code/test) — EM คุมจุดตรวจ (gate)
สร้าง quality gate อัตโนมัติใน CI/CD และ n8n: test, security scan, AI-review
privacy-by-design ตั้งแต่ v1 — สอดคล้อง PDPA และ ISO 27001
รายงาน first-pass rate, defect หลุด และอัตราแก้ซ้ำผ่าน Plane

Part D

Token/Cost Visibility & Governance

รายงาน cost visibility ของ token/AI spend ต่อโปรเจกต์และ deliverable รายเดือน
เสนอทางเลือกโมเดล/เครื่องมือ โดยชั่งน้ำหนัก cost เทียบ capability
งบและเพดานเป็นอำนาจ EM — ตำแหน่งนี้เสนอและแจ้งเตือนเมื่อ trend ผิดปกติ

Part E

Coach Devs & Per-Role Enablement

Coach ผ่าน session กลุ่ม + ประกบรายคน + office hours
วัดผลจากจำนวน dev ที่ใช้ pipeline ได้ standalone ไม่ใช่ชั่วโมงสอน
ศึกษาวิธีทำงานเดิมก่อนสร้างเครื่องมือ — ไม่ทำงานแทนใคร
หลังทดลองงาน: ขยาย playbook ไป role อื่นผ่าน Project Manager Lead

Part F

Estimation & Solution Support

รับ estimate/solution ความยาก "ต่ำ–กลาง" ทั้ง internal และ external (easy feature) ผ่าน auto-route intake
ทุกชิ้นต้องมี boundary, assumption, เพดาน (บังคับ) + red-flag list (แนะนำ)
ทุกชิ้นผ่าน scope challenge (EM ช่วงแรก → PM Lead / SA เมื่อมีตำแหน่ง)
ไม่ใช้เกณฑ์ความแม่นยำเชิงตัวเลขของประมาณการกับตำแหน่งนี้

หมวกรอง — ทดลองงาน: ไม่กำหนดเพดานเวลา · sunset ทันทีเมื่อ Solution Architect เข้ารับตำแหน่ง หรือ EM เห็นว่าภาระงานหลักเต็ม → งาน solution ทั้งหมดกลับไปที่ Solution Architect

§03 · Roadmap ทดลองงาน 120 วัน

4 Phase · Proof Point · Gate

นับจากวันเริ่มงาน (D0) แบ่งเป็น 4 phase ละ 30 วัน ตัวเลขเป้าหมายทั้งหมดต้องยืนยันเป็นลายลักษณ์อักษรที่ Baseline Review (D14) ก่อน — ถ้าผล ② ที่ D120 จะมีการต่อขยายครั้งเดียวถึง D180

จุดกลม = milestone · เพชรแดง = Gate D30 (บังคับทบทวนทันทีถ้า P1.1 ไม่เกิดขึ้น) · เพชรเทา = checkpoint · debrief ระหว่างทางทุก 2 สัปดาห์ไม่แสดงในภาพ

Phase 1Learn & BaselineD0–D30

P1.1

ส่งงานจริงอย่างน้อย 1 ชิ้นผ่าน MAS V3 เต็มวง (mas-ba → mas-architect → mas-code → mas-test) ด้วยตนเอง โดยยังไม่แก้ pipeline

หลักฐาน: artifact ครบทุก phase ใน repo/Plane

P1.2

Friction log จากการใช้งานจริง + สัมภาษณ์ Project Lead/Dev อย่างน้อย 4 คน พร้อมจัดลำดับ pain

หลักฐาน: friction log ใน Plane

P1.3

Baseline report: ระดับการใช้ AI ของทีม, AI spend ปัจจุบัน, first-pass rate โดยประมาณ — ใช้เทียบ K1–K5

หลักฐาน: baseline doc + นัดหมาย Baseline Review D14

P1.4

Demo/walkthrough ผลงาน AI เดิมต่อ EM เชิงลึก 1 ครั้ง พร้อมสรุประดับความพร้อมใช้งานจริงของแต่ละโปรเจกต์

หลักฐาน: บันทึก session

P1.5

ส่ง estimate ชิ้นแรก (internal หรือ external) พร้อม boundary, assumption, เพดาน — red-flag list เป็นส่วนแนะนำ

หลักฐาน: estimate doc ใน Plane

Gate D30: หาก P1.1 ไม่เกิดขึ้นภายใน D30 โดยไม่มีปัจจัยภายนอก → ทบทวน ramp plan ทันที ไม่รอถึง D60

Phase 2First Improvements + Standard DraftD31–D60

P2.1

ปรับปรุง pipeline อย่างน้อย 2 รายการจาก friction log — ทุกรายการมี current-state note + อนุมัติจาก EM

หลักฐาน: PR/changelog พร้อมผล before/after

P2.2

ประกาศใช้ prompt library v1 — โครงหมวด + asset ชุดแรกอย่างน้อย 5 ตัว พร้อม version control

หลักฐาน: repo library + ประกาศใน Plane

P2.3

AI Output Verification Standard ฉบับ draft ครอบคลุม design/code/test + PII/privacy-by-design พร้อมรีวิวรอบแรก

หลักฐาน: standard doc + minutes การรีวิว

P2.4

เริ่ม coaching: session กลุ่มครั้งแรก + ประกบ dev รายคนอย่างน้อย 2 คน

หลักฐาน: session note + feedback ใน Plane

P2.5

Cost tracking v1 — รายงาน AI spend/token ต่อโปรเจกต์ รอบเดือนแรก

หลักฐาน: cost report ฉบับที่ 1

P2.6

ส่งงาน solution/estimate ประเภท easy feature ของลูกค้า/งานประมูล อย่างน้อย 1 ชิ้นภายใน D60

หลักฐาน: estimate doc + บันทึก scope challenge

Phase 3Team Adoption + Gate ใช้จริงD61–D90

P3.1

โปรเจกต์ active อย่างน้อย 2 โปรเจกต์ใช้ pipeline/prompt library เวอร์ชันปัจจุบัน โดย Project Lead/Dev ดำเนินการเอง

หลักฐาน: Plane ของโปรเจกต์ + artifact

P3.2

ประกาศ verification standard v1 + quality gate อัตโนมัติทำงานจริงอย่างน้อย 1 gate ใน CI หรือ n8n

หลักฐาน: gate run log + ประกาศ standard

P3.3

Cost report ครอบคลุมอย่างน้อย 90% ของ AI spend ฝั่ง engineering พร้อม cost ต่อ deliverable

หลักฐาน: cost report ฉบับที่ 2–3

P3.4

Dev อย่างน้อย 2 คนขยับระดับการใช้ agentic workflow เทียบ baseline (P1.3) ตามเกณฑ์ที่ยืนยันที่ D14

หลักฐาน: ผลงานจริง + review ของ EM

P3.5

Estimate สะสมอย่างน้อย 4 ชิ้น (external ≥1 ชิ้น) ชิ้นหลังชิ้นแรกผ่าน scope challenge โดยไม่ขยาย scope นัยสำคัญ

หลักฐาน: estimate docs + บันทึก scope challenge

Phase 4Institutionalize & ตัดสินD91–D120

P4.1

เอกสาร onboarding ของ pipeline/library/standard ครบ — ผู้ใช้ใหม่เริ่มงานได้โดยไม่พึ่ง EM หรือผู้ดำรงตำแหน่งแบบ manual

หลักฐาน: onboarding doc + ทดสอบกับผู้ใช้จริง 1 คน

P4.2

รายงานผลรวมทดลองงาน: K1–K7 เทียบ baseline + แผนปีถัดไป + roadmap ของ per-role playbook ผ่าน PM Lead

หลักฐาน: summary report + นำเสนอต่อ EM

P4.3

รับโอนจากผู้รักษาการสมบูรณ์ — EM ไม่ต้อง operate pipeline รายวัน คงบทบาท approver ของมาตรฐาน

หลักฐาน: ข้อตกลง ownership เป็นลายลักษณ์อักษร

§04 · KPI Dashboard

K1–K7 — ตัดสินที่ D120

"ผ่าน" หมายถึงเป็นไปตามเกณฑ์ ณ D120 · core ใช้ตัดสินผลหลักช่วงทดลองงาน · system วัดสุขภาพระบบ · discipline วัดวินัยการทำงาน — K6 อยู่ในกลุ่ม core เฉพาะช่วงทดลองงานเท่านั้น

KPI	Metric	เกณฑ์ผ่าน	กลุ่ม	หน้าที่
K1 Pipeline Adoption	จำนวนโปรเจกต์ active ที่เดินผ่าน MAS V3/มาตรฐาน	≥2 โปรเจกต์ภายใน D90 คงอยู่ถึง D120 ไม่มีทีมเลิกใช้กลางทางโดยไม่มีบันทึก	core	Part A
K2 Prompt Library ถูกใช้จริง	จำนวน asset ในไลบรารี + จำนวนที่ถูกใช้ซ้ำโดยผู้ที่ไม่ใช่ผู้สร้าง	≥8 asset และ ≥5 ตัวถูกใช้ ≥2 ครั้งโดยผู้อื่น (asset ไร้ผู้ใช้ไม่นับผลงาน)	system	Part B
K3 Verification Standard & Gate	ประกาศใช้ standard, first-pass rate, critical defect หลุด UAT/production	ประกาศใช้ภายใน D90 · first-pass ≥70% ช่วง D91–D120 · defect วิกฤต = 0	core	Part C
K4 Token/Cost Visibility	รอบ cost report รายเดือน + coverage ของ AI spend	≥3 รอบ · coverage ≥90% · ตัวเลขจริง ≥2 โปรเจกต์ + ข้อเสนอ optimize ≥1 รายการที่ EM รับไปใช้	system	Part D
K5 Coaching & Team Capability	จำนวน session/ประกบราย + จำนวน dev ที่ระดับ agentic ขยับขึ้น	session กลุ่ม ≥3 + ประกบ ≥2 คน · dev ถึงระดับ standalone ≥2 คน · feedback ผู้เรียนเฉลี่ยเชิงบวก	core	Part E
K6 Estimation & Solution Support Quality	จำนวนงาน intake, ตรงเวลา, ผ่าน scope challenge, ครบเอกสารบังคับ	≥5 ชิ้น (external ≥2) · ตรงเวลา 100% · ผ่าน scope challenge ≥2/3 ชิ้นหลังสุด · เอกสารครบ 100%	core · เฉพาะช่วงทดลองงาน	Part F
K7 Working Discipline	สัดส่วน current-state note ก่อนรื้อ, อัปเดต Plane รายสัปดาห์, แจ้งล่วงหน้าเมื่อเลื่อน	current-state note 100% · อัปเดต Plane ≥90% ของสัปดาห์ · แจ้งล่วงหน้า ≥2 วันทำการ 100%	discipline	ข้อ 1.6

Red Flags — ทำให้ "ไม่ผ่าน" ทันทีไม่ว่า KPI อื่นจะเป็นอย่างไร

รายงานสถานะ/ตัวเลขไม่ตรงข้อเท็จจริงใน Plane หรือปกปิดปัญหา
ส่งข้อมูลลูกค้า/ข้อมูลอ่อนไหวเข้า external AI service นอกแนวทางบริษัท
รื้อ/แทนที่เครื่องมือที่ทีมใช้อยู่โดยไม่มี current-state note และไม่ได้รับอนุมัติ EM จนกระทบงานส่งมอบ

§05 · การตัดสินที่ D120

ลำดับการพิจารณา ①②③

ตรวจ red flag ก่อนเสมอ — ถ้าพบ จบที่ ③ ทันที ถ้าไม่พบจึงไล่ตรวจเงื่อนไข ① ก่อน แล้วจึง ② เมื่อไม่เข้าเงื่อนไขใดเลย ผลเป็น ③ เสมอ

เส้นแดงบนขวา = ทางลัดเมื่อพบ red flag ตัดตรงไปที่ผล ③ โดยไม่ต้องตรวจเงื่อนไขอื่นก่อน

① ผ่านการทดลองงาน

K1,K3,K5,K6 ผ่านครบ 4 ตัว และ K2,K4,K7 ผ่าน ≥2/3 (ตัวที่ไม่ผ่านต้อง ≥80% ของเกณฑ์ ไม่มี red flag) → รับ ownership เต็ม ตั้ง KPI ประจำปีใหม่ K6 ออกจากกลุ่ม core

② ขยายการทดลองงาน

KPI core ผ่าน ≥3/4 และตัวที่ไม่ผ่านมี trend ดีขึ้นชัดเจน หรือมีปัจจัยภายนอกที่บันทึกไว้ → ขยายเฉพาะ KPI ที่ค้าง ครั้งเดียวไม่เกิน 60 วันถึง D180

③ ไม่ผ่าน

ทุกกรณีที่ไม่เข้า ① และ ② รวมถึงมี red flag → หากผล K6/solution โดดเด่น อาจเสนอปรับ role ไปทาง solution ถ้ามีตำแหน่งรองรับ มิฉะนั้นยุติการจ้าง

§06 · จังหวะ Check-in

เนื้อหาในแต่ละจุดตรวจ

D14

Baseline Review

ยืนยันตัวเลขเป้าหมาย K1–K7 เป็นลายลักษณ์อักษร, เกณฑ์ระดับ dev (K5b), เช็กลิสต์ระดับ detail (K6e), รายชื่อโปรเจกต์เป้าหมาย K1

D30

จุดตรวจ 1 + Gate

ผล Phase 1 ทั้ง 5 รายการ และ Gate D30 — ทบทวน ramp plan ทันทีถ้า P1.1 ไม่เกิดขึ้น

D60

จุดตรวจ 2

ผล Phase 2 + สถานะ K1–K7 เชิง leading indicator — KPI สถานะแดงต้องมีแผนแก้ไขร่วมกัน

D90

จุดตรวจ 3

ผล Phase 3 + ยืนยันว่า KPI ทุกตัววัดได้จริง — ตัวที่วัดไม่ได้ด้วยปัจจัยภายนอกให้ปรับเกณฑ์เป็นลายลักษณ์อักษร

D120

Final

ตัดสินตามผัง ①②③ พร้อมคำตัดสินเป็นลายลักษณ์อักษรและตัวเลขจริง

ทุก 2 สัปดาห์

Debrief ระหว่างทาง

สถานะงาน อุปสรรค และการสนับสนุนที่ต้องการ ใช้เวลา 30 นาที

§07 · ข้อผูกพันขององค์กรก่อนเริ่มงาน

Week-1 Pre-Flight Checklist

ต้องดำเนินการให้แล้วเสร็จภายในสัปดาห์แรกนับจาก D0 — ถ้าองค์กรไม่ทำตามข้อผูกพันนี้ KPI ที่ได้รับผลกระทบจะไม่ถูกนับเป็นผลลบของผู้ดำรงตำแหน่ง (ข้อ 2.6.3)

Walkthrough MAS V3 และ 18-Step SDLC พร้อมสิทธิ์เข้าถึง repo, Plane, เครื่องมือ AI ให้ครบภายใน D1–D3

Engineering Manager

K1, K3

มอบงานจริงชิ้นแรกสำหรับ P1.1 พร้อมรายชื่อโปรเจกต์และบุคคลสำหรับ friction interview

Engineering Manager

เปิดเผยตัวเลข AI spend ปัจจุบันเท่าที่มี และงบเครื่องมือ AI ของทีม

Engineering Manager

ประกาศต่อทีมถึงขอบเขตของ AI Workflow Lead พร้อมแนะนำต่อ Project Lead, Document Specialist, Consulting

Engineering Manager

K1, K5

ตั้งกลไก intake งาน solution กับ Sales ให้ auto-route มาที่ตำแหน่งนี้โดยตรง พร้อมกลไกคุมภาระงาน — ต้องเสร็จก่อนงานชิ้นแรกเข้า

Engineering Manager

กำหนดคิวงาน estimate ของหมวกรอง เริ่มชิ้นแรกภายใน D30, ตกลง template (boundary/assumption/เพดาน), เช็กลิสต์ระดับ detail

EM + Consulting

ทบทวนเอกสารในวันเริ่มงาน ยืนยันเป้าหมาย ลงนามรับทราบ และนัดหมาย check-in ทุกจุดลงปฏิทินล่วงหน้า

EM + ผู้ดำรงตำแหน่ง

ทั้งหมด

ดำเนินการค่าตอบแทน วันเริ่มงาน work model และ reference check ให้แล้วเสร็จก่อนลงนามสัญญาจ้าง

ฝ่ายทรัพยากรบุคคล

—