# 🎯 KPI Guide — Senior Software Engineer 2026 ## 📊 ภาพรวมโครงสร้าง KPI ``` KPI รวม 100% ├── Part 1: Corporate Target 15% │ ├── ด้านการเงิน (Revenue/Profit) 80% │ ├── ด้านลูกค้า (Mendix Churn) 10% │ └── ด้านกระบวนการ (IA Audit) 10% │ ├── Part 2: Department/Position Target 55% │ ├── ด้านการเงิน (Gross Margin) 15% │ ├── ด้านลูกค้า (Satisfaction) 20% │ └── ด้านกระบวนการ (Delivery/QA) 65% │ └── Competency: Core Value / Behavior 30% ``` > **Key Insight:** Part 2 คือหัวใจหลัก — ทำได้ดี = คะแนนพุ่ง > ส่วน Competency (30%) อย่ามองข้าม เพราะส่งผลถึง 30% ของคะแนนทั้งหมด --- ## 🏢 Part 1: Corporate Target (15%) > ⚠️ ส่วนนี้ **ควบคุมได้น้อย** — บริษัทกำหนดเป้า, เราทำได้แค่ "ไม่เป็นอุปสรรค" ### 1.1 ยอดรับรู้รายได้ (Recognized Revenue) - **Target:** 445 MB | Weight: 25% ของส่วนนี้ - ระดับคะแนน: <378 (1) → 378-421 (2) → 422-445 (3) → 445-489 (4) → >489 (5) ### 1.2 รายได้จาก Non-Mendix Product - **Target:** 65 MB | Weight: 25% - ระดับคะแนน: <50 (1) → 50-59 (2) → 60-69 (3) → 70-79 (4) → >79 (5) ### 1.3 กำไรสุทธิ - **Target:** 20 MB | Weight: 30% - ระดับคะแนน: <7 (2) → 15-20 (3) → 21-25 (4) → >25 (5) ### 2.1 อัตราการยกเลิก Mendix License (Churn Rate) - **Target:** ≤5% | Weight: 10% - ระดับคะแนน: >10% (1) → 6-10% (2) → 5% (3) → 3-4% (4) → <3% (5) ### 3.1 ตรวจสอบภายใน (Internal Audit SLA) - **Target:** แก้ครบ 100% ตาม SLA | Weight: 10% - IA ตรวจรายไตรมาส — ต้องแก้ภายในกำหนดทุกประเด็น ### 💡 แนวทางสำหรับ Part 1 - ส่งงานให้ตรงเวลาเพื่อให้บริษัท recognize revenue ได้ตามแผน - อย่าให้ลูกค้า Mendix ไม่พอใจจนยกเลิก license - เมื่อ IA แจ้งผล → ตอบรับและแก้ไขทันที อย่ารอให้เลย deadline --- ## 🎯 Part 2: Department / Position Target (55%) > ✅ ส่วนนี้ **ควบคุมได้เต็มที่** — คือ "งานจริง" ของ Sr.SE --- ### 💰 ด้านที่ 1: การเงิน — Gross Margin (Weight: 15%) #### ตัวชี้วัด 1.1 — Gross Margin งาน Implementation & TM | ระดับ | คะแนน | เกณฑ์ | |-------|-------|-------| | ต้องปรับปรุง | 1 | < 25% | | พอใช้ | 2 | 25% - 30% | | **มาตรฐาน** | **3** | **31% - 35%** | | ดี | 4 | 36% - 40% | | ดีเลิศ | 5 | > 40% | > หมายเหตุ: Exceptional Case (project ที่ GP ต่ำกว่า 35% มาตั้งแต่ต้น) = พิจารณา Case by Case #### 🔑 แนวทางรักษา Gross Margin ≥ 35% **วางแผนก่อนเริ่มงาน:** - ประเมิน effort ให้แม่นยำตั้งแต่ต้น — อย่า under-estimate - กำหนด scope ให้ชัด ป้องกัน scope creep ที่บั่นทอน margin - ถ้างานเพิ่มนอก scope → แจ้ง PM ทันทีให้มี change request **ระหว่างทำงาน:** - Track ชั่วโมงทำงานจริงเทียบกับ estimate ทุกสัปดาห์ - หาก margin เริ่มต่ำกว่า 30% → ยกเรื่องกับ PM ก่อน deadline - อย่า "ทำเพิ่มฟรี" โดยไม่บันทึก — ทุก extra hour กินทั้ง margin ของตัวเองและทีม --- ### 👥 ด้านที่ 2: ลูกค้า — Customer Satisfaction (Weight: 20%) #### ตัวชี้วัด 2.1 — คะแนนความพึงพอใจลูกค้า / Project Owner - วัด: ทุกครั้งที่ส่งมอบงวดงาน (milestone) - เป้าหมาย: **≥ 86%** (ระดับ 3 "มาตรฐาน"), **≥ 91%** (ระดับ 4 "ดี") #### ตัวชี้วัด 2.2 — คะแนน Internal Customer Satisfaction (360°) - วัด: ผู้ประเมิน 4-5 คน (เพื่อนร่วมทีม, PM, stakeholder) - เป้าหมาย: **≥ 86%** (ระดับ 3), **≥ 91%** (ระดับ 4) | ระดับ | คะแนน | เกณฑ์ | |-------|-------|-------| | ต้องปรับปรุง | 1 | < 80% | | พอใช้ | 2 | 80% - 85% | | **มาตรฐาน** | **3** | **86% - 90%** | | ดี | 4 | 91% - 95% | | ดีเลิศ | 5 | > 95% | #### 🔑 แนวทางรักษาคะแนน Satisfaction สูง **กับลูกค้าภายนอก:** - Update status ทุกสัปดาห์ แม้ไม่มีความคืบหน้าพิเศษ — ลูกค้าต้องการ "ไม่รู้สึกถูกทิ้ง" - เมื่อพบปัญหา → แจ้งลูกค้าก่อน พร้อม timeline แก้ไข อย่ารอให้ลูกค้าถามมาเอง - ก่อนส่งงาน → ทำ pre-review กับลูกค้าก่อน ป้องกัน surprise ในวันส่งจริง - จด "สิ่งที่ลูกค้าพูดถึง" ทุกครั้งในการประชุม → แสดงว่าเราฟัง **กับ Internal (ทีม/PM/stakeholder):** - ตอบ message ภายใน 2-4 ชั่วโมงในเวลางาน - เมื่อ block งานคนอื่น → แจ้งทันทีและให้ ETA - รับ feedback โดยไม่ defensive — ขอบคุณและปรับ - Help เพื่อนร่วมทีมเมื่อมีเวลา → 360° จะได้คะแนนกลับมา --- ### ⚙️ ด้านที่ 3: กระบวนการภายใน (Weight: 65% ของ Dept. Target) > ⚠️ นี่คือ **ส่วนที่หนักที่สุด** และ **ควบคุมได้มากที่สุด** — ต้องทำให้ดีที่สุด --- #### ตัวชี้วัด 3.1 — On-time Delivery (Software Development) **Weight: 10%** | ระดับ | คะแนน | เกณฑ์ | |-------|-------|-------| | ต้องปรับปรุง | 1 | ช้ากว่ากำหนด > 10% | | พอใช้ | 2 | ช้ากว่ากำหนด 10% | | **มาตรฐาน** | **3** | **ตรงตามกำหนด** | | ดี | 4 | เร็วกว่ากำหนด 10% | | ดีเลิศ | 5 | เร็วกว่ากำหนด > 10% | **แนวทาง:** - Break งานเป็น task เล็กๆ พร้อม due date ย่อย ก่อนถึง milestone จริง - ตั้ง personal deadline ไว้ 80% ของเวลาจริง — เผื่อ buffer เสมอ - ถ้าคาดว่าจะ delay → แจ้ง PM ล่วงหน้า ≥ 2 วัน ไม่ใช่วันส่งจริง --- #### ตัวชี้วัด 3.2 — Software Reliability ⭐ (Weight รวม: 45%) ##### 3.2a Bug Rate ก่อนขึ้น UAT (Weight: 20%) | ระดับ | คะแนน | Major Bug | Minor Bug | |-------|-------|-----------|-----------| | ต้องปรับปรุง | 1 | > 8% | > 20% | | พอใช้ | 2 | 6-8% | 16-20% | | **มาตรฐาน** | **3** | **5-6%** | **10-15%** | | ดี | 4 | 3-4% | 6-9% | | ดีเลิศ | 5 | < 3% | < 5% | > Major = Critical / Show Stopper จาก Program Error ที่เป็นความรับผิดชอบของ SE ##### 3.2b First Pass Acceptance Rate (Weight: 10%) - % งานที่ผ่าน UAT ในครั้งแรก - เป้า: **86-90%** (ระดับ 3) → **>95%** (ระดับ 5) ##### 3.2c Bug Resolution Time (Weight: 15%) - แก้ bug ตาม SLA ที่กำหนด - เป้า: ตรงตาม SLA (ระดับ 3) → เร็วกว่ากำหนด >10% (ระดับ 5) #### 🔑 แนวทางลด Bug Rate ให้ต่ำที่สุด **ก่อนเริ่ม code:** ``` 1. ทำความเข้าใจ requirement ให้ครบ — ถามทุกข้อที่ไม่ชัดเจน 2. วาง design/logic ก่อน code — อย่า code โดยไม่มี blueprint 3. กำหนด edge case ที่ต้องรองรับตั้งแต่ต้น ``` **ระหว่าง code:** ``` 1. เขียน unit test คู่กับ feature ที่พัฒนา 2. Self-review code ก่อน commit ทุกครั้ง 3. ทดสอบ happy path + negative case + boundary value 4. อย่า push code ที่ยังไม่ได้ test เองก่อน ``` **ก่อนส่ง QA / UAT:** ``` 1. ทำ checklist ครอบคลุม requirement ทุกข้อ 2. Test บน environment ใกล้เคียง production มากที่สุด 3. ทำ regression test กรณีแก้ bug ที่มีผลกระทบกว้าง 4. บันทึก test result ไว้เป็น evidence ``` **เมื่อพบ bug:** ``` 1. ตอบรับภายใน 1 ชั่วโมง — แม้ยังไม่แก้ได้ ให้แจ้ง ETA ก่อน 2. วิเคราะห์ root cause ก่อนแก้ — อย่าแก้แบบ patch เฉพาะจุด 3. แก้แล้ว → retest ให้ครบทุก case ที่เกี่ยวข้อง 4. บันทึก bug pattern → ป้องกันการเกิดซ้ำในครั้งต่อไป ``` --- #### ตัวชี้วัด 3.3 — Project Management On-time (Weight: 10%) | ระดับ | คะแนน | เกณฑ์ | |-------|-------|-------| | ต้องปรับปรุง | 1 | <80% หรือเสียค่าปรับ >200K | | พอใช้ | 2 | 80% หรือเสียค่าปรับ ≤200K | | **มาตรฐาน** | **3** | **90%** | | ดี | 4 | **100%** | | ดีเลิศ | 5 | 100% + โครงการดีกว่าเป้า 10% | > หมายเหตุ: การขยายเวลาเพราะลูกค้า ไม่นับ performance **แนวทาง:** - Track project timeline ด้วย tool (Jira, Asana, หรืออะไรก็ได้ที่ทีมใช้) - Flag risk ต่อ PM ทันทีที่เห็น — อย่ารอให้เป็น crisis - Document เหตุผลที่ขยายเวลาเสมอ โดยเฉพาะถ้าเกิดจากฝั่งลูกค้า --- ## 🧠 Competency: Core Value / Behavior (30%) > สำคัญมาก — 30% ของคะแนนทั้งหมด แต่คนมักมองข้าม ไม่มี Managerial สำหรับ Sr.SE มีเพียง **Core Value / Behavior** อย่างเดียว ### พฤติกรรมที่วัดผล | ด้าน | พฤติกรรมที่ต้องแสดงออก | |------|------------------------| | **ความรับผิดชอบ** | รับผิดชอบงาน, ไม่โยนโจทย์ให้คนอื่น, แก้ปัญหาด้วยตัวเอง | | **การทำงานเป็นทีม** | ช่วยเหลือเพื่อน, share knowledge, ไม่เก็บข้อมูลไว้คนเดียว | | **Communication** | อัพเดตสม่ำเสมอ, ชัดเจน, ตรงประเด็น | | **Learning Mindset** | เรียนรู้เทคโนโลยีใหม่, ปรับตัวได้ | | **Initiative** | เสนอ improvement โดยไม่รอให้สั่ง | | **Quality Mindset** | ภูมิใจในงาน, ไม่ส่งงานที่ "พอผ่าน" | ### แนวทาง Competency ``` สิ่งที่ทำได้เลยทุกวัน: - บันทึก/แชร์สิ่งที่เรียนรู้กับทีม (ใน meeting, Slack, Wiki) - เสนอ idea ปรับปรุง process ในทีม อย่างน้อยไตรมาสละครั้ง - ช่วย review code เพื่อนร่วมทีมเมื่อมีโอกาส - พูดตรงไปตรงมา แต่ professional เมื่อเห็นปัญหา ``` --- ## 📅 Action Plan รายไตรมาส ### Q1 (ม.ค. - มี.ค.) - [ ] ทำความเข้าใจ KPI ทุกข้อกับผู้บังคับบัญชา - [ ] กำหนด personal target สำหรับแต่ละ metric - [ ] Setup tracking: bug log, delivery timeline, hour tracking - [ ] สร้าง template checklist ก่อนส่งงาน QA ### Q2 (เม.ย. - มิ.ย.) - [ ] Review คะแนนกลางปี — ดูว่า metric ไหนต่ำกว่าเป้า - [ ] วิเคราะห์ bug pattern ที่เกิดขึ้นซ้ำ → แก้ต้นเหตุ - [ ] ขอ feedback จาก internal customer อย่างไม่เป็นทางการ ### Q3 (ก.ค. - ก.ย.) - [ ] Mid-year check: Gross Margin อยู่ที่เท่าไหร่ - [ ] ทบทวน project ที่จะส่งมอบ Q4 — เตรียม buffer - [ ] ทำ knowledge sharing session อย่างน้อย 1 ครั้ง ### Q4 (ต.ค. - ธ.ค.) - [ ] Focus: ส่งงานให้ครบตาม commitment ทั้งหมด - [ ] IA audit: เตรียมเอกสารให้พร้อม - [ ] Self-assessment: เขียน evidence ประกอบการประเมิน --- ## 🏆 สูตรสำเร็จ: ถ้าต้องการคะแนนระดับ "ดี" (4) ทุกข้อ ``` Part 2 (55%) — ควบคุมได้ 100%: ✅ Gross Margin ≥ 36% → บริหารเวลาและ scope อย่างเข้มงวด ✅ Customer Satisfaction ≥ 91% → communicate proactively ✅ Bug Rate: Major < 3-4% → test อย่างละเอียดก่อนส่ง QA ✅ First Pass UAT ≥ 91% → understand requirement ให้ครบก่อน code ✅ Bug Resolution เร็ว → ตอบรับเร็ว แก้แบบ systematic ✅ On-time Delivery → plan buffer, flag risk ล่วงหน้า Competency (30%) — ทำทุกวัน: ✅ รับผิดชอบ, สื่อสารดี, share knowledge, initiative ``` --- ## ⚠️ สิ่งที่ห้ามทำเด็ดขาด | ❌ ห้ามทำ | เหตุผล | |-----------|--------| | Push code โดยไม่ test เอง | Bug เข้า UAT → หัก 20% ของ Dept. Target | | ไม่แจ้ง delay ล่วงหน้า | กระทบ On-time Delivery + ลูกค้าไม่พอใจ | | ทำงานเกิน scope โดยไม่บันทึก | Gross Margin ต่ำลงทุกชั่วโมง | | ตอบ bug report ช้าเกิน SLA | หัก Bug Resolution Time โดยตรง | | Underestimate effort ตั้งแต่ต้น | ปัญหาทุกข้อตามมา cascade | --- *อัพเดตล่าสุด: พฤษภาคม 2026 | อ้างอิงจาก TBN Target Setting 2026 — Sr.SE*

SECURE_ACCESS

KPI ตำแหน่ง Sr. SE (Senior Software Engineer)

CONFIRM_DELETE