See the original English version of this article here
บทความนี้เป็นเรื่องราวของ Peter ซึ่งเป็น Programmer คนหนึ่ง ถึงแม้เขาจะมีความรู้ทางด้าน Technical ที่ไม่แตกต่างกับ Programmer คนอื่นๆ แต่ด้วยประสบการณ์ทำงานของเขา กลับทำให้เขามีความแตกต่างจาก Programmer คนอื่นๆ ขึ้นมา คือ เขารู้ว่า ปัญหาใดที่ “คุ้มค่า” กับการแก้ไข เขารู้ได้อย่างไร มาติดตามเรื่องราวของเขากัน
Peter ได้สร้าง Distributed Online Booking System (ระบบการจองออนไลน์) ที่ยอดเยี่ยมให้กับร้านค้า โดย User สามารถเลือกช่วงเวลาที่ต้องการจองได้ หรือ “Available Time Screen” ส่วน Mary เป็นคนที่จัดการ (Operator) กับ System ดังกล่าว โดยเธอมีหน้าที่จัดการกับคิวการจองของลูกค้า กับเสนอ Service ต่างๆ ที่มีอยู่ภายในร้าน
อย่างไรก็ตาม Booking System ก็เกิดปัญหาขึ้น แม้ว่าสถานะของ System จะ Update ทันทีใน Server แต่ User จะต้อง Refresh หน้า Page หรือเข้าไปที่ Website อีกครั้งเพื่อดูการ Update ตามเวลาที่เปิดให้จอง แต่ถ้ามี User 2 คนเข้ามาดู “Available Time Screen” พร้อมๆ กัน และทำการจองสิ่งเดียวกันในช่วงเวลาเดียวกัน หากสิ่งนั้นเกิดขึ้นในวันที่ Mary ยุ่ง เธอก็จะต้องจุ่งยากใจกับการแก้ไขปัญหาในร้าน สิ่งนี้อาจทำให้ลูกค้าไม่พอใจกับบริการ ทำให้เกิดปัญหากับ Mary ได้
Peter จึงต้องการแก้ไขปัญหาดังกล่าว โดยวางแผนที่จะ Develop ตัว In-Memory System ซึ่งจะ Update “Available Time Screen” ในทันที และส่ง Push Message ไปยัง Browser เพื่อให้สามารถ Update ตัว UI ได้แบบ Real Time แม้ว่ามันจะไม่เร็วมาก แต่ Code ก็สามารถระบุเพื่อตรวจสอบว่ามีการจองซ้ำซ้อนหรือไม่ก่อนที่จะดำเนินการจองให้ หากมี User ที่พยายามจองซ้ำขณะที่การ Update ไม่เร็วเพียงพอ ตัว System ก็จะแสดง Error ขึ้นมา
Mary เริ่มรู้สึกร้อนใจ เนื่องจากรู้สึกว่า Peter ใช้เวลาในการแก้ไขนานเกินไป แต่ผ่านไป 2 เดือน Peter ก็ส่งมอบงานส่วนที่แก้ไขปรับปรุงมาให้ หลังจากนั้นไม่กี่วัน Mary ก็สังเกตเห็นว่า ไม่มีการจองซ้ำซ้อนอีกต่อไป
2 เดือนหลังจากนั้น Mary โทร.กลับมาหา Peter อีกครั้ง ซึ่งที่จริง Booking System ก็ทำงานได้ปกติดี แต่มี User อยู่ 3 ราย (จาก User หลายพันราย) Complain ว่า พวกเขาพบ Error เรื่องการจองซ้ำซ้อน แต่ Peter คิดว่า การ Update ใน Booking System แบบ Real Time น่าจะเพียงพอแล้ว ซึ่งเห็นได้ชัดว่า ไม่น่าจะใช่สาเหตุนั้น
หลังจากการ Debug ไม่กี่ชั่วโมง รวมทั้งการวิเคราะห์อยู่หลายวันเนื่องจากความซับซ้อนของ Code และการตรวจสอบเรื่องการจองซ้ำซ้อน Peter ก็ยังไม่สามารถหาสาเหตุได้ว่ามันเกิดจากอะไรกันแน่ เขาไม่รู้ว่าจะทำให้เกิดปัญหานั้นอีกครั้งได้อย่างไรไร เนื่องจากมีเงื่อนไขที่เป็นไปได้มากเกินไป นั่นเป็นเพราะ Software มีความซับซ้อนมาก! ดังนั้นเขาจึงตัดสินใจที่จะเพิ่ม Log พิเศษเข้าไป ซึ่งน่าจะให้ข้อมูลเกี่ยวกับการ Debug ได้มากขึ้นเมื่อเกิด Error อีกครั้ง
หลังจากนั้น 6 สัปดาห์ ก็ยังมี User รายอื่นที่ทำการจองซ้ำซ้อนแถมยังข้ามขั้นตอนการตรวจสอบความถูกต้องไปด้วย แม้ว่าสุดท้ายจะไม่เกิดปัญหาในวันที่ Mary ยุ่ง แต่เธอก็ยังคงตระหนักถึงปัญหากรณีที่ลูกค้า 2 รายทำการจองในช่วงเวลาเดียวกันอยู่
ใน Log เอง ก็ไม่ได้แสดงข้อมูลอะไรที่เป็นประโยชน์เลย มีแต่ข้อมูลที่รู้อยู่แล้ว : จำนวนคนที่ถูกจำกัดไว้ว่าสามารถข้ามขั้นตอนการตรวจสอบได้ รวมทั้งการจองที่ซ้ำซ้อน และเป็นไปไม่ได้ ที่จะทำให้เกิดปัญหานั้นอีก
Peter เชื่อว่า เขาสามารถแก้ไขปัญหาได้ทุกอย่าง แต่ความจริงไม่เป็นเช่นนั้น ความแตกต่าง ก็คือ เขาสังเกตเห็นเมื่อสายเกินไปแล้ว
อีก 10 ปีต่อมา Peter ได้พูดถึง สิ่งที่เขาได้เรียนรู้จาก Booking System นั้นว่า
“ผมได้เรียนรู้จากเพื่อนร่วมงานที่ชื่อ Jusmin ว่า มีข้อจำกัดทางด้าน Technical บางอย่างใน Distributed Systems สำหรับข้อจำกัดก็เช่น การป้องกันการจองที่ซ้ำซ้อน มันเป็นไปไม่ได้ที่จะแก้ไขได้อย่างมีประสิทธิภาพได้โดยปราศจากค่าใช้จ่าย เนื่องจากมีปัจจัยเรื่องจำนวน Computer มาเกี่ยวข้อง และ Network Latency เป็นต้น เมื่อคุณทำงานกับ Distributed Booking System ที่มี Scale ใหญ่ๆ คุณต้องยอมรับว่า อาจมีคน 2 คนที่พยายามทำในสิ่งเดียวกันซ้ำกัน หากมีความจำเป็นทางธุรกิจที่ไม่ต้องการให้เกิดขึ้น เช่น ไม่ควรมีการจองที่ซ้ำซ้อน คุณจะต้องนำข้อจำกัดเหล่านั้น ไปแจ้งกับผู้มีส่วนได้ส่วนเสียทางธุรกิจ( เช่น เจ้าของ/หุ้นส่วน/ผู้บริหาร) และทำความเข้าใจกับพวกเขาว่าต้องการให้แก้ไขอย่างไรบ้าง
หากคุณอนุญาตให้ Program สามารถสร้างสิ่งที่ซ้ำกันได้ ในขณะเดียวกันก็ควรสร้าง Process ที่เปิดให้ Operator ของ System สามารถเข้าไปแก้ไขปัญหาด้วยตนเองได้ ซึ่งจะทำให้ User ที่ทำการจอง จะได้ไม่ต้องเจอกับประสบการณ์แย่ๆ อย่างเช่น Error เป็นต้น เมื่อเกิดค่าใช้จ่ายสูงเกินไปสำหรับ Operator ที่เป็นผู้แก้ไขปัญหาการจองที่ไม่ถูกต้อง คุณก็จะมีปัญหาที่เหมาะสมในการแก้ไข และในระหว่างนี้ คุณก็สามารถทุ่มเทเวลาเพื่อเขียน Program ให้สิ่งที่สำคัญกว่าได้
มันไม่สมเหตุสมผลที่คุณจะทุ่มเทพลังทั้งหมดของคุณ ก่อนที่จะมีหลักฐานมากเพียงพอเกี่ยวกับค่าใช้จ่ายที่จะต้องจ่ายออกไป”
และ Peter ก็ยังยกตัวอย่างให้เห็นอีก
“ตัวอย่างเช่น Server อาจไม่ส่งการแจ้งเตือนไปยัง User จนกว่า Operator จะทำการยืนยันก่อน หาก Operator มี UI เพื่อรับแจ้งว่า มีการจองซ้ำซ้อนกัน พวกเขาก็จะสามารถพูดคุยกับ User ทั้งสองและทำการเปลี่ยนเวลาใหม่ให้ User คนใดคนหนึ่งได้ สิ่งนั้นอาจจะเกิดขึ้นล่วงหน้าหลายชั่วโมงหรืออาจเป็นวันก่อนที่พวกเขาจะมาที่ร้าน
เมื่อค่าใช้จ่ายในการเปลี่ยนเวลาใหม่ดูจะมากเกินไป คุณก็สามารถใช้การ Process แบบ Automate (อัตโนมัติ) แทนได้
อย่างเช่น คุณสามารถสร้าง System ที่ดู Database และแสดง List ของการจองที่ซ้ำซ้อนกันทั้งหมดออกมาได้ จากนั้นคุณสามารถเขียน Code เพื่อส่งการแจ้งเตือนไปยังผู้เกี่ยวข้องที่สามารถแก้ไขการจองที่ซ้ำซ้อนนั้นด้วยตนเอง หรือแม้แต่ส่งไปยังแผนกอื่น หากค่าใช้จ่ายในการแก้ปัญหาการจองที่ซ้ำซ้อนด้วยตนเองเริ่มสูงมากเกินไป คุณก็สามารถสร้าง System ที่ส่ง SMS หรือ Email ถึง User โดยอัตโนมัติว่า “ขออภัย เราไม่สามารถให้บริการคุณในช่วงเวลา 10.00 น. ได้ โปรดจองในช่วงเวลาอื่น” คุณสามารถเปลี่ยนค่าใช้จ่ายสูงๆ ของ Operator ไปเป็น ความไม่สะดวกเล็กๆ น้อยๆ ของ User แทนได้
หากคุณไม่สามารถยอมรับค่าใช้จ่ายที่เกิดกับ User ได้ คุณก็สามารถหาวิธีการตรวจสอบที่ซับซ้อนมากขึ้น
ด้วยแนวทางนี้ คุณจะสามารถใช้เวลาในการเขียน Software ที่ใช้แก้ปัญหาที่สมควรแก้ไขจริงๆ เท่านั้น ไม่ต้องเสียเวลาในการแก้ไขปัญหาที่อาจไม่มีอยู่จริง”
ตอนนี้ Peter ได้เรียนรู้แล้วว่า มันจะคุ้มค่ากว่า ในการยกข้อจำกัดบางอย่างทางด้าน Technical เข้ามาในแง่มุมของธุรกิจ และใช้การพัฒนาเพิ่มเติมแทนที่จะพยายามแก้ไขปัญหาทั้งหมดในคราวเดียว ก่อนที่จะพยายามแก้ไขปัญหาทุกอย่าง อยากให้ Focus ไปที่ปัญหาสำคัญก่อน หากมี Requirements ที่คุณต้องใช้ความพยายามอย่างมากในการแก้ไขปัญหา ก็ลองจัดการมันให้อยู่ในแง่มุมของธุรกิจดู เมื่อคุณมีหลักฐานมากเพียงพอที่จะลงทุนกับเวลาและความพยายามในการแก้ไขปัญหาแล้ว ก็ถือว่า ตอนนี้ปัญหาที่คุณมี ก็เหมาะสมที่จะแก้ไขมันแล้ว
ณ ตอนนั้น Peter เคยคิดว่าเขาเป็นคนเก่งมีความสามารถแล้ว แต่สุดท้ายเขาก็ต้องใช้ประสบการณ์ทำงานหลายปี เพื่อให้เข้าใจว่า … Programmer เก่งๆ ไม่ได้เป็นคนที่แก้ไขทุกๆ ปัญหา แต่เป็นคนที่เข้าใจว่า ปัญหาใดที่คุ้มค่ากับการแก้ไข…
เป็นเรื่องปกติที่จะคิดว่านี่เป็นงานของ “Product Manager” แต่ที่จริงมันเป็นงานของคุณ ครั้งต่อไปที่คุณมีปัญหาทางธุรกิจที่ต้องแก้ไข ก็ให้ดูขอบเขตของมันและดูว่าคุณจะสามารถเปลี่ยนปัญหาเหล่านั้น ให้อยู่ในแง่มุมของธุรกิจได้หรือไม่
ทุกๆ Industry ล้วนต้องการ Programmer ที่สามารถเข้าใจ Value ที่จะมอบให้ และรู้จักการ Tradeoff แทนที่จะแกล้งทำเป็นว่าสามารถแก้ไขปัญหาทุกอย่างได้
คุณอาจตระหนักได้ในเวลาไม่กี่เดือนหรือไม่กี่ปีว่า Code ที่คุณเขียนในวันนี้ มีข้อผิดพลาด ในช่วงเวลานั้นคุณจะได้เรียนรู้สิ่งเดียวกับสิ่งที่ Peter เคยทำ อย่างไรก็ตาม การเรียนรู้ด้วยความผิดพลาดของตัวคุณเองนั้น หมายถึงว่า คุณต้องลงมือทำมันก่อน แล้วสุดท้ายเชื่อว่า คุณจะได้เรียนรู้บางอย่างจากประสบการณ์ของตัวคุณเอง
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 28 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่