มีใครคิดว่าซอฟท์แวร์ที่ดีต้อง “Zero Defect” บ้างคะ
ระบบที่ดีที่จะเอาขึ้นได้ต้องเพอร์เฟค 100% ถ้าเจอบั๊กแม้แต่นิดเดียว ก็ต้องรีบขวางไว้ทันที
ผลคืออะไรรู้มั้ยคะ กลายเป็นเราทำงานเครียด รู้สึกต้องสู้ ต้องไฟท์ตลอดเวลา
อยากให้ทุกอย่างออกมาสมบูรณ์แบบที่สุด
แต่พอเราเติบโตขึ้น ก็ทำให้รู้ค่ะว่า เราไม่ควรหมกมุ่นกับความสมบูรณ์แบบที่จับต้องไม่ได้
แต่เราจะต้องทำงานแบบมีกลยุทธ์ คิดถึงRisk และ Cost ที่จะเกิดขึ้นเสมอ
ลองมาดูสถานการณ์ตัวอย่างกันค่ะ ว่าแบบไหนเราปล่อยได้ แบบไหนปล่อยไม่ได้ แล้วเราจะจัดการกับมันยังไง
🚨 เมื่อ Business Deadline สำคัญกว่า Minor Bug
ลองคิดดูว่าถ้าพรุ่งนี้บริษัทจะต้องปล่อยแคมเปญใหญ่ (เช่น 11.11) ที่ใช้งบการตลาดมหาศาล
ฟีเจอร์ที่กำลังจะออกมีมูลค่าสูงมากต่อยอดขาย แต่ดันมาเจอบั๊กในนาทีสุดท้าย แล้วเราจะทำยังไงกับบั๊กพวกนั้นดี
ถ้าแก้ก็อาจจะต้องมาเร่งเทสฟีเจอร์นั้นใหม่อีกรอบ แล้วอาจจะทำให้ปล่อยฟีเจอร์นี้ไม่ทัน
ขั้นแรกเราต้องประเมินก่อนค่ะว่าบั๊กนี้ “ร้ายแรง” แค่ไหน โดยอาจจะคุยกับฝั่ง Business หรือ PO เพื่อตกลงร่วมกันด้วยก็ได้
ถ้าบั๊กที่เจอเป็น Minor Bug เช่น “ปุ่มแชร์ลง Social Media ใช้ไม่ได้” หรือ “ตัวหนังสือโชว์ไม่ครบบนหน้าจอมือถือ”
- ❌ Average QA: สั่ง Dev แก้เดี๋ยวนี้! ถ้าไม่เสร็จไม่ให้ Deploy เด็ดขาด แต่เราอาจจะเสี่ยงทำให้แคมเปญหลักล้านต้องเลื่อนออกไป
- ✅ QA ร่างทอง: ประเมินกับทีมแล้วว่านี่ไม่ใช่ Critical Bug ลูกค้ายังสามารถสั่งของและชำระเงินได้ตามปกติ
แปลว่า Cost ในการเลื่อนแคมเปญ แพงกว่า Risk ที่จะเกิด… แบบนี้ก็ตัดสินใจปล่อยขึ้น Production ไปก่อนเลยค่ะ
แต่!!! ปล่อยบั๊กขึ้น Production ไปแล้ว ไม่ใช่ว่าปล่อยจอยได้เลยนะคะ อยากเป็น QA ร่างทอง ต้องมีแผนรับมือหลังจากนั้นด้วย เช่น
- บรีฟทีม Customer Support ล่วงหน้า: บอกให้ทีมรู้และเตรียม Workaround ไว้เลย ถ้ามีลูกค้าแจ้งปัญหาเข้ามา จะได้เตรียมตัวรับมือไว้ก่อน เช่น “พรุ่งนี้อาจจะมีลูกค้าทักมาเรื่องแชร์ลง Social ไม่ได้ ทีมกำลังแก้อยู่นะคะ น่าจะได้ภายในสัปดาห์นี้” หรือ “ถ้ามีลูกค้าทักมาเรื่องตัวหนังสือโชว์ไม่ครบ รบกวนแนะนำให้ลูกค้าหมุนจอเป็นแนวนอนไปก่อนนะคะ”
- วางแผนทำ Hotfix: คุยกับ Dev และ PO ให้ชัดเจนว่าจะทำ Hotfix ตามไปแก้ยังไง จะแก้ท่าไหน มีผลกระทบที่เราต้องเทสซ้ำตรงไหนบ้าง ต้องรีบแก้เลยหรือสามารถรอรอบหน้าได้
🔥 แล้วถ้าแจ็คพอทแตก เจอ “Critical Bug” วินาทีสุดท้ายล่ะ ทำยังไง!!!
สมมติว่า วันก่อนจะปล่อยแคมเปญดันเจอว่า
“ถ้าลูกค้ากดจ่ายเงินด้วยบัตรเครดิตบางประเภท จะทำให้แอพแครช ดับไปเลย แถมตัดเงินไปแล้วแต่สถานะของออเดอร์ไม่อัพเดตตาม”
ทำไงดีทีนี้
- ❌ Average QA: สติแตก โวยวายใส่ทีม บอกให้เลื่อนวัน Release ทันที กลายเป็นเรื่องใหญ่ ทำให้ทีมแพนิคไปอีก
- ✅ QA ร่างทอง: ดึงสติก่อน ประเมิน Impact ด่วนๆ ที่สำคัญคือ “ไม่เสนอแค่ปัญหา แต่เสนอทางออกควบคู่ไปด้วย”
เราอาจจะไปคุยกับ Dev ก่อนว่ามีวิธีแก้แบบไหนบ้าง
Permanent Fix ทำยังไง ยากมั้ย กระทบเยอะมั้ย
หรือมีวิธีแก้แบบเร็วๆ ด่วนๆ ไปก่อนได้มั้ย แล้วค่อยมาตามแก้อย่างถูกต้องทีหลัง
แล้วก็ไปคุยกับ PO และ Business พร้อมข้อมูลและทางเลือกให้พวกเขาตัดสินใจ เช่น
- ทำ Feature Toggle ปิดเฉพาะจุดที่พังไปก่อน: “ตอนนี้การเชื่อมต่อกับ Payment Gateway XXX พัง แต่ช่องทางจ่ายเงินอื่นยังใช้ได้ เราซ่อนปุ่มจ่ายเงินด้วยบัตร XXX ไปก่อนได้มั้ย เพื่อให้แคมเปญพรุ่งนี้ยังออกได้”
- แก้ด่วน แต่ขอยืดเวลา: “ถ้าจะต้องแก้จริงๆ ประเมินกับทีม Dev มาแล้วว่าต้องใช้เวลาแก้ และ รีเทส 3 ชั่วโมง รวมเวลาเตรียม Deploy ใหม่ น่าจะต้องเลื่อนเวลาประกาศแคมเปญออกไปเป็นช่วงสายๆแทน”
การที่เรามีทางเลือกไปให้ทีมแบบนี้ จะช่วยให้คุยกันง่ายขึ้น และฝั่ง PO จะสามารถตัดสินใจได้ตามผลกระทบและความเสี่ยงที่อาจจะเกิดขึ้น
เห็นมั้ยคะ มันไม่ได้แปลว่าเราทำงานหยาบ ปล่อยบั๊กขึ้น Production หรือ เทสไม่ละเอียดนะคะ
แต่เป็นการที่เรามองเห็นภาพรวมของธุรกิจและ Product ของเรา เพื่อช่วยให้ทีมตัดสินใจได้ง่ายขึ้น
เราไม่จำเป็นต้องเป็น “ผู้คุมกฎ” ที่คอยจับผิดทุกอย่างเพื่อเอาชนะ Dev
แต่เราคือ “Quality Advocate” ที่คอยช่วยทีมในการประเมินความเสี่ยง
เพื่อให้ทีมสามารถส่งมอบซอฟท์แวร์ที่มีคุณค่าให้ผู้ใช้ได้ตรงเวลา ในคุณภาพที่รับได้ค่ะ
🧘♀️✨ การรู้จักบาลานซ์ระหว่าง “ความสมบูรณ์แบบ” กับ “ความเป็นจริงของธุรกิจ”
นอกจากจะช่วยให้คุยกับฝั่ง Business ง่ายขึ้นแล้ว ยังช่วยเซฟคุณภาพจิตใจของเราไม่ให้ Burnout ไปซะก่อนด้วยนะคะ