ทำไมเราจึงวางแผนให้มี Bug?

ในบรรดากระบวนการสร้างซอฟแวร์ ขั้นตอนที่ผมว่าผิดปกติที่สุดคือการทำ UAT

เหตุใดจึงเป็นเช่นนั้น?

UAT นั้นย่อมาจาก User Acceptance Test แปลเป็นภาษาง่ายๆ ว่า “การทดสอบเพื่อตรวจรับโดยผู้ใช้” ซึ่งก็ดูจะไม่ผิดปกติอันใด เมื่อเราทำของให้เขา เขาก็ต้องมาตรวจรับ แต่สิ่งที่ผิดปกติ คือ “การทดสอบ”

ทำไม “การทดสอบโดยผู้ใช้” จึงเป็นเรื่องผิดปกติ?

สมมติ เราไปซื้อเครื่องใช้ไฟฟ้าสักอย่างหนึ่ง เช่น เครื่องปั่นน้ำผลไม้ เมื่อเราตัดสินใจซื้อแล้ว ผู้ขายก็จะทำการทดสอบให้เราดู ว่าเครื่องเปิดติดนะ ใช้ได้ และที่สำคัญคือ กระบวนการนี้เป็นไปเพื่อความสบายใจของผู้ซื้อมากกว่าจะเป็นการตรวจสอบอะไรจริงจัง เพราะ ถ้าเอากลับไปแล้วมีปัญหาก็ยังมีการรับประกันอีก อย่างน้อยๆ ก็ 1 ปี

ถ้าเราแนวทางการทำงานแบบทำกับซอฟแวร์ไปใช้ในร้านเครื่องใช้ไฟฟ้า ภาพคงเป็นประมาณนี้ พอเราเลือกเครื่องปั่นน้ำผลไม้แล้ว ผู้ขายก็บอกว่า “เชิญทำ UAT ถ้าหากภายใน 3 ชั่วโมง นี้ท่านพบข้อผิดพลาดใดๆ เราจะทำการแก้ไขให้ทันที หากว่าพ้นออกจากร้านไปแล้ว ท่านจะต้องรับผิดชอบค่าใช้จ่ายในการซ่อมเอง” เราเป็นคนซื้อคงรู้สึกเหวอพิลึก

นอกจากนั้นเรายังวางแผนจะมีความผิดพลาดเสียอีก

ในการวางแผน UAT นั้นสิ่งที่ผมพบเป็นประจำคือเราวางแผนว่า จะมีหลายครั้ง เช่น UAT1, UAT2, etc. พอถามเหตุผลว่าทำไมจึงมีหลายครั้ง ก็ได้คำตอบว่า ครั้งแรกคงจะมี Bug และ ทดสอบให้หมดทีเดียว แล้วแก้ทีเดียว แล้วก็จะมี UAT อีกรอบหนึ่ง พอผมถามว่า “ทำไมเราจึงวางแผนที่จะให้ซอฟแวร์ของเรามี Bug ล่ะ?” อีกฝ่ายมักจะทำหน้าแปลกใจประหนึ่งว่า “มันไม่เป็นอย่างนั้นได้ด้วยหรือ?”

ลองคิดภาพว่า เราไปซื้อเจ้าเครื่องปั่นน้ำผลไม้เครื่องเดิมนั่นแหละ แล้วผู้ขายก็บอกเราว่า “คุณมีเวลา UAT แค่ 2 รอบ โดยรอบแรกเจออะไร เราจะแก้ไขให้เท่านั้น แล้วรอบสองมีสิทธิ์ทดสอบแค่เท่าที่เราแก้ไข เข้าใจมั้ย?” เป็นผมคงเดินออกจากร้านไปเลย

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

การมีวางแผนให้มี UAT หลายรอบเป็นเครื่องยืนยันว่า เราในฐานะผู้สร้างซอฟแวร์นั้นไม่ได้มีความมั่นใจในคุณภาพ ของสินค้าของเราเลย นอกจากนั้นเรายังผลักภาระ การควบคุมคุณภาพไปให้ลูกค้าเสียอีก

ทำไมเราจึงต้องผลักภาระให้ลูกค้าแบบนี้?

เหตุผลหลักที่เราต้องผลักภาระการหา Bug ให้ลูกค้า มาจากเหตุที่ว่าเราไม่รู้ว่าลูกค้าต้องการอะไร เป็นเช่นนั้นจริงๆ สิ่งที่เราทำมาตลอดคือถามว่าลูกค้าอยากได้อะไร ด้วยกระบวนการเก็บ requirement แล้ว ทึกทักเอาว่านี่คือสิ่งที่คุณบอก งั้นคุณก็ต้องยอมรับมัน ถ้าไม่ใช่ก็แก้กันไป

ซึ่งนี่เป็นสิ่งที่ในธุรกิจทั่วไปไม่ทำกัน ในธุรกิจการทำเครื่องปั่นน้ำผลไม้ ผู้ผลิตคือผู้ที่มีความรู้เกี่ยวกับ การปั่นน้ำผลไม้มากที่สุด และธุรกิจอื่นก็เช่นเดียวกัน โตโยต้ารู้เรื่องรถยนต์เป็นอย่างดี เอสโซรู้เรื่องน้ำมันเป็นอย่างดี โออิชิรู้เรื่องอาหารญี่ปุ่น แต่ละธุรกิจต้องมีความรู้เกี่ยวกับสินค้าของตัวเองเป็นอย่างดี คงมีแต่ธุรกิจซอฟแวร์นี่แหละที่ไม่รู้อะไรเกี่ยวกันสินค้าของตนเอง จนต้องขอยืมมือลูกค้าในการรับรองคุณภาพสินค้าตนเอง

การพัฒนาซอฟแวร์ในแบบอไจล์ กับ Bug

สิ่งที่อไจล์เน้นย้ำคือการร่วมมือกันระหว่างภาคธุรกิจและภาคการผลิตเพื่อส่งถ่ายความรู้ซึ่งกันและกัน เมื่อทำงานร่วมกัน ฝ่ายผลิตก็จะเข้าใจเกี่ยวกับธุรกิจมากขึ้น ในทางกลับกับฝ่ายธุรกิจก็เข้าใจเทคโนโลยีมากขึ้น เมื่อส่งมอบงานก็หมายถึงเกิดความเข้าใจกันทั้งสองฝ่าย ในมุมของอไจล์นั้น ไม่มี Bug และไม่เคยวางแผนว่าจะมี ทุกอย่างคือการเรียนรู้ และรับฟีดแบคอยู่ตลอดเวลา จุดไหนที่ยังไม่เข้าใจ จุดไหนที่มีความคลาดเคลื่อน เมื่อทำงานร่วมกันไปเรื่อย ความคลาดเคลื่อนนั้นจะค่อยๆ ลดลงจนเกิดเป็นความไว้วางใจซึ่งกันและกัน

Advertisements

One thought on “ทำไมเราจึงวางแผนให้มี Bug?

  1. ตัดชุดก็มี UAT ตอนเราไปลองชุด ลองหลายรอบด้วย เพราะร้านก็ไม่มั่นใจว่า ตัดตามแบบออกมาจะโดนใจ หรือเราใส่ได้พอดีรึเปล่า ไรแบบนั้นปะคะ

ส่งความเห็นที่ Shompoo Betty Tr ยกเลิกการตอบ

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out /  เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out /  เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out /  เปลี่ยนแปลง )

Connecting to %s