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

Automation Test

คิดและเลือก automation framework อย่างไรในปี 2023

จริงถึงแม้จะจั่วหัวไว้ว่าเป็นปี 2023 แต่จริงๆหลักการนี้ใช้ได้ทุกปีแหละครับ แหะๆ ซึ่งบทความนี้ได้แรงบันดาลใจจากที่ว่า ช่วงนี้น้องๆ หลายคนที่เคยทำงานด้วยกัน ทักมาปรึกษาโน้นนี่นั่นกันอยู่เป็นระยะๆ หลายๆครั้งมีน้องบางคนเข้าไปทำงานในบริษัทที่ยังไม่มี Automation เลย พูดง่ายๆ คือการเข้าไปเริ่มตั้งไข่ให้เองนักเลงพอ และหลายคนจะกลับมาถามคำถามเดียวกัน (คำถามเดียวกันจริงๆนะ) บทสนทนาจะเป็นประมาณนี้ น้อง : พี่โอ ว่างไหมพี่โอ : ครับน้อง : สบายดีนะครับโอ : สบายดีครับ เราล่ะเป็นไงบ้างน้อง : พี่โอ cypress นี่ดีไหมครับ (ไม่พูดพร่ำทำเพลง get to the point ดีมาก) พอคุยไปคุยมา เรามักจะได้คำตอบว่า น้องได้รับมอบหมายว่าให้เริ่มต้นทำ Automation โดยเริ่มตั้งแต่เลือก Framework ไปจนถึงวาง Project structure วันนี้เลยอยากจะมาลองแชร์ว่า ปกติเวลาเราจะเลือก Framework มาใช้เนี่ยเราควรดูอะไรบ้าง แต่ก่อนจะเข้าเรื่องบอกก่อนเลยว่า มันไม่มีคำว่า “ดี” หรือ “ไม่ดี”…

QA

QA คนไหนมี Hardskill ดีแล้ว อย่าลืมฝึก Softskill ไว้ด้วยนะ #doppiotech #สายเทค #softwaretester

QA เก่งแค่ Hard Skill พอไหม? ทำไม Soft Skill ถึงเป็นอาวุธลับที่ทำให้คุณกลายเป็น "Star" ในทีม ในคอมมูนิตี้ของคนทำงานสายเทคและ QA มักจะมีคำถามยอดฮิตว่า "ถ้าอยากเก่งขึ้นต้องเรียนรู้อะไร?" หรือ "อยากย้ายสายต้องฝึกสกิลไหน?" ซึ่งคำตอบส่วนใหญ่มักจะพุ่งเป้าไปที่ Hard Skill เช่น การทำ Automation, การเรียนรู้เครื่องมือใหม่ๆ หรือเทคนิคการเขียน Test Case แต่ในมุมมองของผู้สัมภาษณ์งานและหัวหน้าทีม ความจริงที่น่าสนใจคือ มีผู้สมัครจำนวนมากที่ไปเรียนรู้ทักษะทางเทคนิคมาสารพัด แต่กลับไม่มีความโดดเด่นเพียงพอที่ทำให้บริษัทรู้สึกว่า "ต้องรับคนนี้เข้าทำงานให้ได้" Hard Skill คือพื้นฐาน แต่ความเก๋าอยู่ที่ "การจัดการ" สำหรับ QA ที่มีประสบการณ์ 4-5 ปี การเขียน Test Case ให้ดีเป็นเรื่องที่ควรทำได้อยู่แล้ว แต่ความแตกต่างระหว่าง Test Case ที่สมบูรณ์แบบ (Perfect) กับเกือบสมบูรณ์แบบนั้นไม่ได้สร้างความแตกต่างให้ตัวคุณดู "เฉิดฉาย" ในสายตาหัวหน้าเท่ากับ "สกิลในการจัดการ"…

Other

Shared library คืออะไร และทำไมเราจึงควรใช้ในทีมและองค์กร วันนี้อยากจะมาเล่าเรื่อง Doppio Common Library

สวัสดีครับ บทความนี้อยากจะมาแชร์ไอเดียซึ่งหลายๆ คนอาจจะมีประสบการณ์กับอะไรพวกนี้มาอยู่แล้ว แต่มือใหม่ในด้าน Automation หลายๆ คน อาจจะยังไม่รู้จัก หรือยังไม่เข้าใจว่ามันคืออะไร บทความนี้ผมจะมาอธิบายให้ฟังกันครับ จุดเริ่มต้น หลายๆ คนที่ทำ automation อาจจะเคยประสบพบเจอกับเหตุการณ์ว่า พอเราย้ายไปทำโปรเจค automation อันใหม่แล้วบางทีเราก็มักจะเจอกับสิ่งที่เราเคยทำไปแล้ว ยกตัวอย่างเช่น และเหตุการณ์อื่นๆ ในลักษณะคล้ายกัน คือ เรา หรือเพื่อนร่วมทีมของเราที่อาจจะอยู่คนละโปรเจคหรือคนละทีม ได้เจอโจทย์คล้ายๆกันมาบ้างแล้ว และสิ่งที่เราต้องการในสถานการณ์นี้ก็คือ ทำยังไงให้เราสามารถสิ่งที่เราหรือใครสักคนในองค์กรเราเคยทำมาแล้ว ให้ได้เร็ว ไม่ต้องไปเสียเวลาเหมือนทำใหม่อีกรอบ ณ จุดเริ่มต้น (แบบตั้งไข่เลยนะ) เรามักจะมีประโยคคลาสสิคที่เราส่งไปให้เพื่อน “เฮ้ยๆ ขอโค้ดหน่อยดิ” , “เฮ้ยๆ ไป copy ได้ที่ repo ไหนบ้าง” ประมาณนี้ ทีนี้ถามว่ามันก็ตอบโจทย์ที่เราต้องการได้นะ ก็คือ ไม่ต้องเสียเวลาไปทำใหม่ แต่มันก็มีข้อเสียที่ยิ่งใหญ่อยู่ก็คือการที่เราจะต้อง copy กันต่อๆ ไปเรื่อยๆ มันจะมีปัญหาว่า Solution จากปัญหาข้างต้นของการ copy โค้ดไปมา…