Release plan
ช่วงนี้ผมกำลังแก้ไขระบบการเงินภายในบริษัท ที่ทำ payroll ซึ่งเกี่ยวกับการจ่ายเงินเดือนพนักงาน ผมแก้จากที่มัน optimize for write (ข้อมูลเข้ามายังไงก็ save แบบนั้น แล้วค่อยไป join กันตอน read) ให้มัน optimize for read (save ของด้วยโครงสร้างเหมือนตอนจะถูกอ่านตรง ๆ) ที่ทำไม่ใช่เพราะต้องการ improve performance เป็นหลัก แต่เป็นการเตรียมการเชื่อมต่อกับระบบอื่น ๆ ที่กำลังจะเข้ามาในอนาคต
บ่ายวันหนึ่ง ระหว่างที่ผมกำลังปรับแก้ระบบอยู่ ผมก็พบว่า test ที่เคยผ่านตอนใช้การคำนวนแบบเก่าที่ optimize for write มันทำงานถูก แต่เอมาใช้การคำนวนแบบใหม่ที่ optimize for read แล้ว เงินมันก็คำนวนได้ไม่เท่าเดิม ผมตกใจมาก เพราะนี่เป็นระบบการเงิน แต่ละบาทที่หายไปจะเป็นน้ำพักน้ำแรงของคนทำบัญชีที่ต้องไปหาว่าเงินหายไปไหน ต้องมีการโอนกลับไปกลับมาคืนกันระหว่างบริษัทกับบุคคล อาจจะเสียค่าโอนอีก ซึ่งเป็นระดับความเสียหายที่ผมรับไม่ได้ ผมไม่เกี่ยงค่าโอนนะ แต่ความมั่นใจที่พนักงานมีให้กับระบบ payroll จะเสียไปไม่ได้
ตอนนี้ผมรู้ตัวแล้วว่าการคำนวนแบบใหม่มันผิดพลาด และจาก unit test ที่เขียนมา มันบอกด้วยนะว่าผิดที่ field ไหน แล้วส่งผลกระทบให้ field ไหนอีกบ้างผิดตาม ๆ กันไป ที่ผมไม่รู้คือ field นี้มันผิดมาตั้งแต่เมื่อไหร่
ผมไล่ git log อยู่เกือบชั่วโมงก็หาไม่เจอ ตอนนั้นผมล้าไปหมดทั้งสมองและใจ ผมหันไปหาเพื่อนร่วมงานชื่อเจน แล้วขอความช่วยเหลือเบา ๆ ว่า “ช่วยหน่อย”
ผมเห็นเจนที่ทำอย่างอื่นอยู่หยุดของที่ทำ แล้วหันมาช่วยผมด้วยสมาธิเต็ม 100 ผมเดาว่าน่าจะมีอะไรในสีหน้า ท่าทาง หรือน้ำเสียงของผมตอนขอความช่วยเหลือที่สื่อออกไปว่า ผมอับจนหนทางแล้วจริง ๆ
เจนนั่งดูปัญหาด้วยกันกับผมประมาณ 5 นาที น่าตระหนักถึงความรุนแรงของความเสี่ยงที่เกิดขึ้นได้เช่นกัน เลยบอกออกมาว่า
พี่ทำแบบนี้ไม่ได้ ถ้าพี่เปลี่ยนวิธีคำนวนไป พี่จะรู้ได้ยังไงว่ามันยังคำนวนถูกเหมือนเดิม ถ้าเป็นผม ผมจะ release version นึงที่คำนวนทั้ง 2 แบบ เอามาเทียบกันก่อนสัก 3 เดือน แล้วค่อยสลับไปใช้วิธีใหม่ แล้วค่อยลบแบบเก่า
ผมตาสว่างทันที แผนการเดิมของผมที่จะ release ซอฟต์แวร์การเงิน โดยไม่ทำ A/B testing เปรียบเทียบกันว่าคำนวนถูกต้องเหมือนเดิมไหม เป็นแผนการที่สุ่มเสี่ยงมาก มากระดับที่เรียกว่าโง่เขลาก็ไม่เกินจริงไปนัก
พอผมเห็นแผนการ release ใหม่ที่ดีกว่า ส่งผลให้วิธีที่ผมพัฒนาซอฟต์แวร์ของผมเปลี่ยนไปหมดเลย ผมรู้ตัวทันที่ว่าโค้ดทั้งหมดที่ทำมาทั้งวันใช้ไม่ได้แล้ว เพราะผมแก้ไขระบบไปโดยไม่ได้ถนอมของเก่าไว้ ขณะนั้นในหัวผมมีภาพความทรงจำตอนผมกำลังโค้ชน้อง ๆ ทีมพัฒนา ผมเห็นตาใส ๆ ของน้อง ๆ มองมา ขณะที่ผมสอนพวกเค้าว่า
จำไว้นะ อย่าเผาสะพานเก่า ก่อนที่จะสร้างสะพานใหม่เสร็จ และประกาศให้ทุกคนมาเดินบนสะพานใหม่กันหมดแล้ว ค่อยลบสะพานเก่าได้
ที่ผมอยากเอาเรื่องนี้มาแบ่งปันเพราะ การแบ่ง release ใหญ่ ๆ อย่างการเปลี่ยนวิธีการคำนวนระบบการเงิน เป็น release ย่อย ๆ
- ลองเพิ่มวิธีการคำนวนใหม่โดยที่ยังไม่ใช้
- เปลี่ยนมาใช้วิธีการคำนวนใหม่
- ลบวิธีการคำนวนเก่า
มันเปิดโอกาสให้เราสามารถเอาไฟล์ payroll มาเปรียบเทียบกันได้ ซึ่งลดความเสี่ยงของการ release ได้มากมายมหาศาล ผมเห็นหลายทีมพัฒนาซอฟต์แวร์โดยรู้แค่ timeline แต่ไม่รู้กลยุทธ์การ release เลย ซึ่งสร้างทั้งความเสี่ยงและความเสียหายเยอะมากในธุรกิจโดยไม่จำเป็น
ผมเห็นด้วยว่าในบริบทของธุรกิจที่การแข่งขันสูง ทุกคนก็อยากวิ่งเร็ว ๆ ซึ่งก็เป็นธรรมดาที่จะต้องจ้องพื้นตรงหน้าชัด ๆ แต่อย่าลืมเงยหน้าไปมองเส้นชัยบ้างนะครับ เพราะวิธีที่จะ release อาจจะเปลี่ยนวิธีพัฒนาทั้งหมดไปเลย
