สามเหลี่ยม’ ที่จะช่วยจัดการ 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

Woody in house mobile farm เมื่อไม่มีถูกใจ ก็สร้างมันขึ้นมาซะเลย

เรื่องมันมีอยู่ว่า ผมจำได้ดีเลยวันนั้นเป็นวันหนึ่งในฤดูหนาว ที่อากาศหนาวกว่าทุกๆวัน……ไม่ใช่ละ…นิยายผีญี่ปุ่นปะนิ….เอาใหม่….จริงๆสิ่งที่อยากจะเอามาเล่าในวันนี้เป็นสิ่งที่ใช้ใน Doppio มาประมาณสักปีนึงแล้วแหละ แต่ไม่มีเวลาได้มาเขียนมาแชร์ ช่วงนี้พอมีเวลา เลยอยากเอามาแชร์ให้เพื่อนๆได้อ่านกัน เรื่องมีอยู่ว่า ตอนที่ Doppio ตั้งบริษัทขึ้นมาแรกๆ แล้วเริ่มมีงาน automation ของ Mobile application เข้ามา ด้วย Concept ว่า Automation ที่ทำไปต้องใช้งานได้จริง มี reliability และ stability ที่ดี เราจึงต้องมีการ setup CI ขึ้นมาเพื่อ keep running test เพื่อจุดประสงค์ และเนื่องด้วยพอเป็น mobile application automation ซึ่งเราใช้ Appium เป็น framework หลัก เราเลยจำเป็นที่จะต้องมีเครื่องที่รัน Emulator หรือ Simulator ของ iOS / Android ไว้ทำการรัน ในยุคแรกเราก็ใช้วิธีแบบลูกทุ่งๆ…

QA

รวมสิ่งที่ควรรู้เกี่ยวกับ Regression Test EP.1

สรุป Regression Test คืออะไร? พร้อมเทคนิคการเลือก Test Case ให้มีประสิทธิภาพตามหลัก 80/20 ในการพัฒนาซอฟต์แวร์ เมื่อมีการเปลี่ยนแปลงเกิดขึ้นในระบบ สิ่งที่ชาว QA หรือ Software Tester ต้องเผชิญคือการตรวจสอบว่าสิ่งที่เปลี่ยนไปนั้นส่งผลกระทบต่อส่วนเดิมที่มีอยู่หรือไม่ ซึ่งกระบวนการนี้เรียกว่า Regression Test นั่นเอง Regression Test คืออะไร? โดยนิยามแล้ว Regression Test คือการทดสอบเพื่อหา Bug (Defect) หรือผลกระทบ (Impact) ที่เกิดจากการเปลี่ยนแปลง (Change) ซึ่งในโลกของการพัฒนาซอฟต์แวร์ การเปลี่ยนแปลงสามารถเกิดขึ้นได้จาก 2 ปัจจัยหลัก คือ: 1.การเพิ่มฟีเจอร์ใหม่ (Add new feature) เข้าไปในระบบ 2.การแก้ไขBug (Bug fix) หรือการปรับปรุงโค้ดต่าง ๆ ดังนั้น ในการทดสอบซอฟต์แวร์จึงมักประกอบด้วย 2 ส่วนสำคัญ คือการทดสอบฟีเจอร์ใหม่ว่าทำงานได้ปกติหรือไม่ และการทำ…

QA

Software Tester/QA 100.1

วันนี้มาด้วยชื่อ blog แปลกๆ คือปกติมันต้องเริ่มด้วย 101 แต่ว่าอันนี้มันยิ่งกว่า 101 มันเป็นจุดเริ่มต้นยิ่งกว่านั้นเอาเป็นชื่อ 100.1 ละกันนะ Inspiration เริ่มมาจากมีน้องๆหลายคนมากมาสมัครงานแบบที่ไม่มีประสบการณ์ software testing เลย มีทั้งแบบ new grad และแบบที่อยากเปลี่ยนสายงาน จาก IT support มั่ง Sale มั่ง Admin มั่งทั้งที่จบตรงและไม่ตรงสาย เอาจริงๆเห็น potential น้องๆหลายคนเลยนะ ที่สามารถเรียนรู้และเปลี่ยนสายงานได้ (แล้วก็หางาน QA ให้ได้สำเร็จ ของไม่ตรงสายได้แล้วหนึ่งคน เย่) คือที่เห็น น้องๆหลายคนอยากเปลี่ยนสาย ก็พยายามไปหาความรู้ บางคนเริ่มไปดู automate บางคนไปอ่านกับเรียนวิธีการ test text box ต่างๆ เอาจริงๆก็ดีใจที่เห็นน้องอยากเปลี่ยนสายแล้วลงทุนเรียนรู้ แต่อีกมุมนึงก็รู้สึกว่าหลายๆคนไปกันแบบโหวงๆ ยังไม่รู้ด้วยซ้ำว่าจุดที่ชั้นไปอ่านไปเรียนมันคือตรงไหนของงาน ไม่เข้าใจลักษณะงานหลักๆเลยด้วยซ้ำ ก็เลยตั้งใจเขียนอันนี้ไว้เป็น guideline ให้มือใหม่อยากเข้าวงการ ให้อ่านแล้วเห็นภาพใหญ่ ก่อนจะเจาะลึกแต่ละส่วนละกันนะ…