Bug นั้นสำคัญไฉน

อาจจะยาวหน่อยนะครับ ไม่ได้เขียนมานาน วันนี้จะมาเล่าประสบการณ์จริงกับการเชือดบั๊กไปประมาณสองพันตัวในระยะเวลาประมาณ 2 ปีให้ฟังกันเน้อ

เริ่มปู background หน่อยละกันครับ เหตุการณ์ในเนื้อเรื่องเริ่มขึ้นตั้งแต่เมื่อประมาณ 7–8 ปีที่แล้ว ก็ทำงานเป็นหัวหน้าทีม QA มีลูกน้องร้อยกว่าคน ทุกคนมี mindset ของ Quality for business ดังนั้นเวลาเจอ bug กับ feature ใหม่ๆเนี่ย เราก็จะคิด เอ๊ะ severity ของ bug ตัวนี้คืออะไร แล้วก็จะมี practice ในการคิดว่าถ้าไม่ได้เป็น bug ตัวใหญ่มากๆ ถ้าเรา log bug ไว้แล้วแก้ตามหลังเนี่ย feature นี้ถ้าออกวันนี้จะทำเงินได้เพิ่มหนึ่งล้านต่อวัน (สมมติ) ส่วน bug ตัวนี้ถ้าเราปล่อยไปอาจจะสร้างความเสียหายได้มากสุดสองหมื่นบาทต่อวัน แทนที่จะรอ fix bug สามวัน เราsign-off ไปก่อนแล้วค่อย fix ตามหลังได้ ได้มากกว่าเสียเห็นๆ ดังนั้น Go Go Go!

เอาจริงๆวิธีคิดแบบนี้มันก็ไม่ผิดนะครับ ณ ตอนนี้ก็ยังคิดว่า make sense อยู่นะ แต่ว่าปัญหาที่เกิดขึ้นคือ เราไม่ได้มีระเบียบวินัยที่ดีพอกับการไปไล่ fix bug หรือตาม track bug ที่เรา log ไว้ แล้วก็คิดถึงการก้าวไปข้างหน้าตลอดเวลากับ feature ใหม่ๆ และไม่มี Check and Balance มาคอยบอกเราว่า เอ๊ะ พี่น้องครับ เราควร slow down กับ feature แล้วกลับมา invest กับ quality กันเถอะครับ ทีนี้ เหตุการณ์แบบนี้เกิดขึ้นมาสามสี่ปี บริษัทก็โตขึ้นเรื่อยๆจาก feature ต่างๆที่เราปล่อยไป แต่ว่าเราเกิดจุดเอะใจจากการที่เราเริ่มหงุดหงิดกับการเล่น web ของตัวเอง กับการสังเกตุความหงุดหงิดจากการ raise bug จากผู้บริหารว่าดูเค้าหงุดหงิดกับ bugเล็กๆน้อยๆ ก็เลยเริ่มมานั่งดูข้อมูลจริงๆ กับใช้เวลาพินิจพิจารณนาดูซะหน่อยซิว่าเกิดอะไรขึ้นแล้วก็บรรลุว่าอ่อ web เราเนี่ย จริงๆมันก็ไม่ได้มีบั๊กอะไรที่แบบรุนแร๊งรุนแรง แต่ว่า มันมีหลาย bug จนน่าหงุดหงิดแล้วมันเจอได้ตลอดเวลากับ customer journey ที่ใช้งาน ซึ่งเอาจริงๆแล้ว bug พวกนี้ก็ถูก log ไว้หมดหล่ะนะ ก็เลยไปทำ query ดูจำนวน bug ทั้งหมดของ product นั้นและ underlying service ทั้งหมด ที่สามารถมีผลกระทบกับ customer experience ได้ ก็เจอว่า รวมๆแล้วมีสามพันกว่า bug อ่ะ ไหนลอง filter เอา low severity ออกหน่อยซิ ก็ยังเหลืออยู่สองพันนิดๆ เป็น high serv ซะร้อยนึง กับ medium serv ซะสองพันส่วน critical serv ไม่มีเพราะอันนี้วินัยดีอยู่ ถ้าเจอจะไม่ยอมให้ปล่อยออกไป ต้อง fix เลย ไม่มีใครกล้าเถียง (เพราะดุ)

รวบรวมข้อมูลซักสองสามชั่วโมงก็เดินเข้าไปหาหัวหน้า แล้วก็บอกว่า “Hey boss, I think we’re suck” เริ่มแบบนี้ แล้วก็โชว์ข้อมูลกับสมมติฐานให้ดู นั่งหมกกันอยู่สองชั่วโมง ก็ได้ข้อสรุปรวมกันว่า “Okay, let’s fix it!”

อ่ะ ทีนี้ก็ได้เวลาสนุก เริ่มแรก เกณฑ์กองทัพให้ไล่รีวิวบั๊กสองพันกว่าตัวนั้นก่อนว่า Severity ถูกมั๊ย ถ้าไม่ถูกก็แก้ให้ถูก แล้วตัวไหนเป็น bug ที่ ไม่ valid แล้ว เช่น feature ที่มี bug obsolete ไปแล้ว ก็ออกมาว่าจำนวนลดลงนิดหน่อย bug จาก medium ย้ายมาอยู่ใน high อีกสิบกว่าตัว (เหมือนจะงานโหด แต่ให้คนร้อยคนทำ ก็แค่คนละยี่สิบกว่าตัวเอง ให้เวลาสองวัน น้องๆกรีดร้องบ่นงึมงำเล็กน้อย แต่ไม่เป็นไร พี่เอาแต่ใจ ยังไงสองวันก็ต้องเสร็จ 555)

ความสนุกขั้นถัดมาคือ ตั้งเป้าหมาย High serv bug ร้อยกว่าตัวเนี่ย ภายในสองเดือนต้องเหลือไม่เกิน 3 ตัว พอ set target ในใจตัวเองได้แล้วก็เดินไปคุยกับบอสใหญ่ คือคุณซีอีโอ กับบอสใหญ่ฝั่งโปรดัค (PO) ก็ใช้พลังขายของนิดนึงว่าทำไมต้อง invest กับเรื่องนี้กับสุดท้ายบอกว่าขอลองนะสองเดือน แล้วปกติที่บริษัททำทุก change เป็น AB test อยู่แล้ว ก็เลยบอกว่า bug fix เนี่ยก็ทำเป็น AB test ด้วยเลยจะได้ prove value กันให้เห็นๆ หลังจากขายของได้ สรุปเอาตามนั้น ลุย

เป็นสองเดือนที่สนุก ต้องใช้พลังกายพลังใจในการทำให้มันเกิดขึ้น คุยกับหัวหน้าเด็ป กับ Product Owner หลายสิบคนว่าเราจะไปทางนี้นะ เอา feature story เข้ามาน้อยๆหน่อย แต่ละอาทิตย์มี target fix bug เท่านั้นเท่านี้เพื่อให้สองเดือนเหลือ 3 ตัว ความยากอยู่ที่ตอนนั้น mindset ของทุกคนไม่ได้มาทางเดียวกัน ทุกคนไปทาง business driven mindset อยู่ (ซึ่งก็ดีนะ) แล้วยัง link ระหว่าง quality กับ business value ไม่ได้ขนาดนั้นก็เลยมีถกเถียงกันอยู่เรื่อยๆว่าทำไมต้อง slow down feature เพื่อ fix bug ก็เป็นช่วงเวลาที่สนุกสนาน ความพลาดอีกอย่างคือตอนทำแพลนเนี่ย คิดแต่ว่าจะลดบั๊กจากร้อยกว่าตัวที่มีอยู่ แต่ลืมคิดว่าแต่ละวันที่ของใหม่ๆออกไป (ที่นี่ deploy ของไป production กันวันละ สิบยี่สิบ package) มันก็จะมีบั๊กใหม่ๆมาด้วยนาจา ก็ทำให้ plan ที่จะเหลือ 3 ตัวในสองเดือนนี่ยิ่งยากไปอี๊ก

สรุปสองเดือนจาก High serv bug ร้อยกว่าตัว จบได้ที่เหลือ 9 ตัว ไม่ได้ตามแพลน แต่เอาจริงๆก็ถือว่าเจ๋งสุดๆที่ทำกันได้ขนาดนี้ ที่สำคัญ ถึงเวลาขายของต่อเพื่อทำแพลนขั้นถัดไป! ความยากของสองเดือนที่ผ่านมาคือการ buy-in คนหลายๆคน (ไม่ใช่หัวๆนะ หัวๆ buy-in เรียบร้อย) ก็เลยคิดว่าถ้าจะให้เห็นภาพเดียวกันได้ ก็ต้องเชื่อมโยงสิ่งที่เค้าสนใจกับสิ่งที่เราอยากได้ให้ได้ พอคิดได้แบบนี้ก็ง่ายเลยสิ่งนั้นคือ business value นั่นเอง พอคิดได้แบบนี้ก็ลองไปหาข้อมูล พบว่า อุ๊ยยย Quarter ที่ผ่านมา AB test ที่ทำเงินหรือสร้าง business value ได้มากที่สุดคือการ fix bug นั่นเอง (เพลงมโหรีขึ้น) อันนี้เรื่องจริง ดาต้าไม่โกหก สำหรับคนที่ไม่รู้จัก AB test นะ คือการเอาเวอร์ชั่นเก่ากับใหม่ขึ้นไปให้ลูกค้าเจอด้วย traffic เท่าๆกัน ลูกค้าซื้ออันไหนมากกว่า อันนั้นชนะ ปกติใช้กับฟีเจอร์ เราก็เอามาใช้กับ bug fix ด้วยก็พบว่าลูกค้าซื้อจากเวอร์ชั่น bug fix มากกว่าเยอะ เยอะชนะฟีเจอร์รวมๆกันทั้งควอเตอร์อีกนะจ้ะ เจอแบบนี้ง่าย ขายของ buy-in ได้ตั้งแต่ผู้บริหารยันคนทำงานรากหญ้า เพราะไม่มีใครเถียงได้

แพลนถัดไปของข้าพเจ้าก็คือการเชือดบั๊ก medium severity สองพันตัวที่เหลือทิ้ง อันนี้วางแผนว่าให้เวลาปีครึ่ง จากสองพันตัวให้เหลือไม่เกิน 50 ตัว อันนี้สำคัญนะ คืออย่างบั๊ก high เราควรตั้ง aggressive เพราะ impact มันแรงชัดเจน แต่อย่าง medium bug ก็ต้องตั้ง target ให้มัน make sense ไม่ใช่ว่า เอ่ะอ่ะฟิกบั๊กสำคัญที่สุดในโลก สุดท้ายผ่านไปปีครึ่งก็ออกมาใกล้เคียงกับที่ตั้งเป้าหมายไว้นะ

ยิ่งกว่านั้น ผลสรุปจากทางฝั่งทีม product เองก็ออกมาว่า bug fixing เป็น story ที่ทำให้ได้เงินมากที่สุดตลอดทุก quarter จากผล AB test เป็นระยะเวลาปีกว่าๆ อันนี้คือชัดว่า quality มีผลกับ business

ที่เจ๋งที่สุดในเรื่องราวเกือบสองปีที่เกิดขึ้นคือ culture ที่เกี่ยวกับ Quality ของคนในบริษัทเปลี่ยนไปแบบหน้ามือเป็นหลังมือ คือไม่ต้องเถียงกันอีกว่าเจอ bug ต้อง fix มั๊ย ทุกคนมีภาพเดียวกันมีมุมเดียวกัน (คนใหม่ๆที่เข้ามาในบริษัทอาจมีงอแงบ้าง แต่ถ้า culture ของบริษัทดีแล้ว คนใหม่ก็จะเรียนรู้และปรับตัวตามได้เอง) มันเปลี่ยนไปถึงขนาดเด็ปรู้ว่าเทสคือความรับผิดชอบของชั้น เพราะไม่มีใครอยากปล่อยบั๊กออกไปที่ production

เสริมตบท้ายว่าเรามีการทำ check and balance ด้วยนะ ตอนแรกๆ ที่มี bugเยอะๆ เราส่งเวปตัวเองเข้าไปที่พวก bug bounty program ต่างๆ คือพวกให้คนทั่วไปมาหาบั๊กแล้วเราจ่ายตังค์เค้าตามจำนวนบั๊กที่เจอนั่นเอง (pay per bug) คือตอนนั้นให้ budget แค่บั๊กละ 5 เหรียญ เจอเพียบ มีคนรีพอร์ตเข้ามาอย่างรวดเร็ว ทีนี้พอผ่านไปปีครึ่ง เราฟิกบั๊กไปเกือบหมดแล้วเราเปิดโปรแกรมนี้อีกที ปรากฎว่าบั๊ก 5 เหรียญแทบไม่มีใครรีพอร์ตเข้ามาเลย ต้องปรับเพิ่มเป็นให้บั๊กละ 40 เหรียญถึงจะมีรีพอร์ตเข้ามาบ้างแต่มีน้อยมาก ดังนั้นนี่เป็นอีกวิธีนึงที่คอยเช็คว่า เวลาชั้นบอกว่าบั๊กของชั้นน้อยเนี่ย มันน้อยจริงป่าว ไม่ใช่ว่าหลอกตัวเอง

อ่ะ มาดูสิ่งที่อยากให้ได้จากเรื่องราวทั้งหมดที่เล่ามากัน

1. Bug แต่ละตัว ถึงตัวมันเองจะดู severity ต่ำ ไม่รุนแรงเท่าไหร่ แต่พอมันมาอยู่รวมกันใน customer journey เดียวแล้วมันมีการรวมพลังกันทำให้ impact สูงขึ้นแบบทวีคูณ พูดง่ายๆ มันทำให้คนใช้งานรู้สึกว่าโปรดัคนี้หรือเวปนี้มัน buggy จังเลย ส่วนใหญ่ลูกค้าจะทนใช้จนจบ เพราะเข้ามาแล้วและมันไม่ได้ถึงกับขนาดขัดขวางการใช้งานไม่ให้ใช้จนจบ แต่ภาพจำความห่วยนั้นจะคงอยู่กับลูกค้าตลอดกาล และสิ่งที่ impact จริงๆคือคุณจะสูญเสีย repeat customer ไป คือ ลูกค้าจะใช้ครั้งเดียวแล้วครั้งหน้าจะไม่กลับมาอีกเป็น long term negative impact กับธุรกิจ
2. การ fix bug มี business value ชัดเจน การไม่ปล่อย bug ออกไปตั้งแต่แรกเป็นสิ่งสำคัญ แต่ในชีวิตจริงมันก็เกิดขึ้นได้ยากที่จะไม่หลุด ดังนั้นก็พยายามป้องกันไม่ให้มันหลุดออกไป กับให้ความสำคัญกับการ fix มันให้สมดุลละกันนะ
3. ถ้าอยากจะเปลี่ยนแปลงอะไรซักอย่าง strategy ในการขายของเป็นสิ่งสำคัญ อย่างอันนี้ เราเริ่มจากจุดเล็กๆที่สำคัญ แล้วขายให้คนเห็น value ของมัน แล้วค่อย scale up ขึ้นไป การเชื่อมโยงสิ่งที่เราอยากได้หรือคิดว่าดี เข้ากับสิ่งที่คนอื่นเห็นเป็นเรื่องสำคัญเป็นเรื่องยาก แต่ถ้าหาจุดนั้นได้และทำได้เชื่อมโยงได้ ชีวิตจะง่าย หลายคนหลายบริษัทบ่นว่ารู้ว่าอะไรดี แต่บริษัทไม่เคยยอมทำ ให้ย้อนกลับมาคิดนิดนึงว่าเราลงทุนกับการขายของให้บริษัทเชื่อมากพอรึยังว่าควรเปลี่ยน และเปลี่ยนแล้วจะดียังไง (อันนี้ว่าเดี๋ยวจะเขียนเป็น topic แยกให้อีกทีนะ)
4. การตั้งเป้าหมาย ควรจะตั้งให้ ambitious but realistic เช่นถ้าอยู่ดีๆไปบอกประชาชนว่า เอ้า fix bug สามพันตัว ทุก severity ในสามเดือนกันเถอะ เรื่องราวต่างๆก็จะไม่มีทางได้เริ่ม และบทความนี้คงจะไม่เกิดขึ้น

ตั๊กแตนตัวเดียวดูไม่น่ากลัว แต่ถ้ามาทั้งฝูงก็ทำลายข้าวหมดทุ่งได้นะจ๊ะ

Bug แต่ละตัว ถึงตัวมันเองจะดู severity ต่ำ ไม่รุนแรงเท่าไหร่ แต่พอมันมาอยู่รวมกันใน customer journey เดียวแล้วมันมีการรวมพลังกันทำให้ impact สูงขึ้นแบบทวีคูณ

สุดท้ายถ้าคุณอ่านมาถึงตรงนี้ก็แสดงว่าคุณทนอ่านมาได้จนจบ ขอกราบขอบพระคุณจากใจจริง และขออภัยที่อาจจะเขียนด้วยภาษาสลับไทยอังกฤษแบบไม่สวยงาม แต่ถ้าไม่เขียนด้วยภาษาเยี่ยงนี้ก็จะฝืนตัวเองเกินไป เอาแค่นี้ก่อนละกันเน้อ ไว้นึกอะไรออกจะมาเล่าสู่กันฟังใหม่นะครับ

Natdanai Wiangwang — Doppio Tech “We build and serve expertise”