สามเหลี่ยม’ ที่จะช่วยจัดการ project ให้ดี

Doppio_Toasty-EDlT0R

QA

March 24, 2026

Table of Content

“สามเหลี่ยมกู้ชีพ” เคล็ดลับการบริหารโปรเจกต์และต่อรองฉบับสายเทค

ในการทำงานสาย Tech ไม่ว่าจะเป็น Developer, QA หรือ Software Tester ปัญหาที่พบบ่อยที่สุดคือ “เวลาไม่พอ” หรือ “สโคปงานที่เพิ่มขึ้นกะทันหัน” หลายคนเลือกที่จะแก้ปัญหาด้วยการทำงานหนักหรืออยู่ล่วงเวลา (OT) แต่วิดีโอนี้ได้นำเสนอทางออกที่ยั่งยืนกว่าผ่านแนวคิด “สามเหลี่ยมบริหารจัดการ”

1. รู้จัก 3 แกนหลักของสามเหลี่ยม

หัวใจสำคัญของการบริหารโปรเจกต์ประกอบด้วย 3 ส่วนที่สัมพันธ์กันคือ เวลา (Time), ขอบเขตงาน (Scope) และ ทรัพยากร (Resource)

กฎเหล็กของสามเหลี่ยมนี้คือ “ถ้าแกนใดแกนหนึ่งเปลี่ยน อีก 2 แกนที่เหลือต้องเปลี่ยนตามเพื่อรักษาความสมดุล”

ตัวอย่างเช่น หากเวลาลดลง (Deliver ช้าลง) สิ่งที่ต้องพิจารณาคือ: เพิ่ม Resource: อาจจะขอคนเพิ่ม แต่ต้องเป็นคนที่มีความรู้อยู่แล้ว (Knowledge) ถึงจะช่วยได้จริง ซึ่งในความเป็นจริงนั้นหาได้ยาก

ลด Scope: นี่คือสิ่งที่ควรตั้งคำถามกับ PM หรือลูกค้าว่า “มีส่วนไหนที่ตัดออกได้บ้างเพื่อให้เราส่งมอบงานได้ทันเวลา?”

2. อย่าใช้ “OT” เป็นทางออกแรก

หลายทีมมักเลือกการทำงานหนักหรือ Overtime เป็นช้อยส์แรกเมื่อเจอปัญหาเรื่องเวลา แต่ในความเป็นจริงแล้ว OT แทบจะไม่อยู่ในแกนของสามเหลี่ยมนี้เลย สิ่งที่ควรทำคือการ Educate หรือให้ความรู้แก่คนรอบตัว ไม่ว่าจะเป็น Project Manager (PM) หรือลูกค้า ให้เข้าใจถึงข้อจำกัดตามหลักสามเหลี่ยมนี้ เพื่อหาทางออกที่สมเหตุสมผลร่วมกัน

3. “ท่าไม้ตาย” ในการต่อรอง: การปรับระดับการทดสอบ (Testing Intensity)

หากไม่สามารถเพิ่มคนหรือลดสโคปงานได้ “ท่าไม้ตาย” ที่อยู่ในมือของคนทำงานสายเทค (โดยเฉพาะ QA/Tester) คือการปรับเปลี่ยนแผนการทดสอบ

ยอมรับความเสี่ยงมากขึ้น: หากเวลาลดลงหรือสโคปเพิ่มขึ้น แต่ทรัพยากรเท่าเดิม เราสามารถเสนอว่า “ผมจะเทสน้อยลง แต่จะเลือกเทสอย่างตั้งใจและมีเหตุผล (High Risk First)”

การเจรจาอย่างมีเหตุผล: การบอกว่า “จะเทสน้อยลง” ไม่ใช่การประชดประชัน แต่เป็นการนำเสนอทางเลือกเพื่อให้งานเดินหน้าต่อได้ภายใต้ข้อจำกัด บางครั้งเมื่อเราเสนอแบบนี้ ฝ่าย Business อาจจะยอมขยายเวลาให้เองเพราะกังวลเรื่องคุณภาพงาน

4. สร้างวัฒนธรรมการทำงานใหม่ด้วยความสม่ำเสมอ

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

เมื่อเวลาผ่านไป ทีมและฝ่าย Business จะเริ่มเรียนรู้และเข้าใจเองว่า “ถ้าอยากได้อันนี้เพิ่ม ต้องเอาอันนั้นออก” หรือ “ถ้าอยากได้งานครบ ต้องเพิ่มเวลาให้”

สรุป

การใช้สามเหลี่ยม (Time, Scope, Resource) เป็นเครื่องมือสื่อสาร จะช่วยให้เราไม่ต้องแบกรับภาระงานหนักจนเกินไปเพียงลำพัง การกล้าที่จะต่อรองและเสนอทางเลือกบนพื้นฐานของเหตุและผล จะช่วยให้เราส่งมอบงานที่มีคุณภาพและรักษาความสัมพันธ์ที่ดีในทีมไว้ได้ในระยะยาว

Related Blog

Other

QA career — Soft Skill กับ Attitude นั้นสำคัญไฉน

จากประสบการณ์การทำงานมา 20 ปีของพี่ (พูดแล้วก็รู้สึกแก่ 😅) ทำงาน QA มาตั้งแต่เรียนจบเป็น Junior ตัวกระจ๊อย จนมาทำงานในบริษัทยักษ์ใหญ่ สร้างทีม QA ร้อยกว่าคน จนสร้างบริษัทที่มี QA ร่วม 200 คน สิ่งที่สังเกตุเห็นมาตลอดและแอบเป็นสิ่งน่าเศร้าคือ ไม่ค่อยมีใครสอน หรือ พูดถึงความสำคัญของ Attitude หรือ Soft skill ที่จำเป็นสำหรับสายงานนี้ (จริงๆคือไม่ค่อยเห็นการพูดถึงเรื่องพวกนี้ในงาน Tech ทั้งหมดด้วยแหล่ะ) ทั้งๆที่มันเป็นสิ่งสำคัญมากนะ เริ่มตั้งแต่ทำให้คนๆนึงได้งาน ถัดมามันเป็น skill ที่ทำให้คนๆนั้นอยู่รอดกับการทำงานในช่วงแรก และในที่สุดมีส่วนสำคัญในการแยกความแตกต่างระหว่าง QA ธรรมดาที่เดินไปถึงจุดตัน (ถึงแม้จะมี technical skill ที่ดีเยี่ยมก็ตาม) กับ QA ที่เติบโตไปเรื่อยๆจนเป็น A player ใน market ทุกวันนี้ส่วนตัวพี่เอง แทบไม่ได้สอน Technical skill ให้น้องๆด้วยตัวเองละนะเพราะมีคนช่วยสอนเยอะหล่ะ แต่จะใช้เวลาส่วนใหญ่ในการค่อยๆสอน Soft Skill…

QA

Dev ส่งงานไม่ทัน ทำยังไงกะ QA ดี#doppiotech #softwaretester #สายเทค #QA #testing #DEV

เมื่อ Dev ส่งงานไม่ทัน... ควรทำอย่างไรกับ QA? ในสถานการณ์ที่ Developer (Dev) เล็งเห็นว่าไม่สามารถส่งงานได้ทันตามกำหนดเวลา สิ่งสำคัญไม่ใช่การปกปิดปัญหา แต่คือการบริหารจัดการร่วมกับทีม โดยเฉพาะฝ่ายประกันคุณภาพ (QA) ซึ่งมีแนวทางที่น่าสนใจดังนี - การสื่อสารที่โปร่งใสและตรงไปตรงมา: ทีมที่มีประสิทธิภาพควรมีการสื่อสารกันอย่างชัดเจน เมื่อรู้ว่างานจะล่าช้า Dev ควรเดินเข้าไปแจ้ง QA พร้อมขอโทษและระบุระยะเวลาที่คาดว่าจะดีเลย์ (เช่น ล่าช้าไป 2 วัน) เพื่อให้ทุกฝ่ายเตรียมตัวรับมือได้ทัน - การทำ Impact Analysis ร่วมกัน: แทนที่จะปล่อยให้ QA ต้องทดสอบตามแผนเดิมทั้งหมด Dev และ QA สามารถนำ Test Case มาพิจารณาร่วมกันเพื่อวิเคราะห์ผลกระทบ เช่น จากเดิมที่มี 500 เคส Dev สามารถช่วยระบุได้ว่าโค้ดส่วนไหนที่แก้ไขแล้วมีความเสี่ยงต่ำ เพื่อพิจารณาคัดเลือก Test Case บางส่วนออก ช่วยลดระยะเวลาในการทดสอบลงได้ - Dev…

Automation Test

เขียน Code เก่ง ใช่ว่าจะทำ Test Automation ได้ดี

บทความนี้เขียนสำหรับน้องๆสาย Automation หรือน้องๆที่กำลังศึกษาเพื่อก้าวเข้ามาในสาย Test Automation นะครับ เท่าที่เห็นส่วนใหญ่ๆเวลาเริ่มศึกษาหรือทำงานไปซักพัก เราจะ focus อยู่แค่ ใช้ framework อะไร ใช้ภาษาอะไรเขียน แล้วก็ไปเรียนการเขียนภาษานั้นๆ พอเรียนพอฝึกไปซักพัก เขียนได้คล่องก็ อุ๊ย เก่งแล้วเรา เขียน Automate ได้หล่ะ ของ web หรือ mobile app ผมได้หมด ส่งงานมาเลยพี่ ผมพร้อม! เอาจริงๆ ถ้ามาได้ถึงขั้นนี้ ก็ควรภูมิใจจริงๆหล่ะนะ แต่ว่า ถ้าหยุดอยู่แค่นี้ เราก็ทำได้เหมือนคนอีกหลายพันหลายหมื่นคน (และคนหลายพันหลายหมื่นคนที่ทำระดับนี้ได้ กำลังเพิ่มขึ้นเรื่อยๆทุกวัน) จากประสบการณ์ที่เห็นมา คนที่ทำ Automate ได้เจ๋งเนี่ย เขียน code/script automate ได้ คือ พื้นฐานที่จำเป็นต้องมี แต่บทความนี้จะพยายามเล่าถึงส่วนอื่นๆที่จะทำให้เราก้าวไปอยู่ในระดับถัดไปได้ให้ฟังละกันนะครับ ยกตัวอย่าง ถ้าเรามี website ซื้อของ online ตัวนึง…