ทำไมเราเลือกเทคโนโลยีน่าเบื่อ: เหตุผลที่ระบบของ SME ควรสร้างบนของที่พิสูจน์มาสิบปี ไม่ใช่ของที่เพิ่งดังสิบเดือน

มีคำถามหนึ่งที่ลูกค้าที่ทำการบ้านมาดีมักถามเรา: ทำไมไม่ใช้ตัวนั้น เห็นว่ากำลังมาแรง และคำตอบของเราก็มักทำให้แปลกใจ: เพราะมันกำลังมาแรงนี่แหละ เราเลือกเทคโนโลยีด้วยเกณฑ์ที่วงการเรียกกันติดตลกว่า boring technology — ของที่พิสูจน์ตัวเองมาเกินสิบปี เอกสารหนา ชุมชนใหญ่ และพฤติกรรมทุกอย่างเป็นที่รู้กัน ไม่ใช่เพราะทีมเราตามของใหม่ไม่ทัน (เราทดลองของใหม่กันทุกเดือนในโปรเจกต์ภายใน) แต่เพราะเรามองระบบของลูกค้าด้วยไม้บรรทัดคนละอันกับงานโชว์เคส: ระบบขาย ระบบสต๊อก ระบบบัญชีของ SME ไม่ใช่ของที่สร้างเสร็จแล้วจบ มันคือโครงสร้างพื้นฐานที่ต้องมีชีวิตอยู่เจ็ดถึงสิบปี ผ่านมือนักพัฒนาหลายคน ผ่านการอัปเดตนับร้อยรอบ และผ่านวันที่ทีมที่สร้างมันอาจไม่อยู่แล้ว การเลือกเทคโนโลยีจึงไม่ใช่คำถามว่าอะไรเจ๋งสุดวันนี้ แต่คือคำถามว่าอะไรจะยังแข็งแรง หาคนดูแลได้ และไม่กลายเป็นภาระ ในปีที่เจ็ดของอายุระบบ

เกณฑ์ที่สำคัญกว่าเบนช์มาร์ก: ตลาดแรงงานไทย

เวลาเทียบเทคโนโลยี วงการชอบเทียบความเร็วและฟีเจอร์ แต่สำหรับระบบที่ต้องอยู่สิบปี เกณฑ์ที่ชี้ขาดกว่ามากคือคำถามธรรมดา ๆ ว่า ในเชียงใหม่หรือในไทย หานักพัฒนาที่ทำงานกับของตัวนี้เป็น ได้ง่ายแค่ไหน เพราะสถานการณ์ที่ลูกค้าต้องเจอสักวันมีจริงเสมอ: อยากต่อยอดระบบแต่ทีมเดิมคิวเต็ม อยากมีคนในทีมตัวเองดูแลบางส่วน หรือกระทั่งอยากย้ายทีม (สิทธิ์ที่เราเขียนไว้ในเรื่องการส่งมอบว่าลูกค้าควรมีเสมอ) เทคโนโลยีที่แพร่หลายทำให้ทุกทางเลือกนี้เปิด เทคโนโลยีเฉพาะทางที่เท่แต่หายาก ทำให้ลูกค้าถูกล็อกกับทีมเดิมโดยไม่มีใครตั้งใจล็อก — ซึ่งขัดกับหลักการทำงานของเราตรง ๆ นี่ยังไม่นับความจริงเชิงเศรษฐศาสตร์ที่คนพูดถึงน้อย: นักพัฒนาสายของหายากคิดแพงกว่า และควรคิดแพงกว่า เพราะตลาดของเขาเล็ก ทุกชั่วโมงดูแลระบบในอนาคตของลูกค้าจึงถูกทำให้แพงขึ้นตั้งแต่วันเลือก stack โดยที่ไม่มีใครเห็นบิลใบนั้นในวันเซ็นสัญญา

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

คำถามเรื่อง stack ที่ลูกค้าควรถามทุกทีม

ลูกค้าไม่จำเป็นต้องรู้จักชื่อเทคโนโลยีสักตัวเพื่อประเมินเรื่องนี้ได้ — ถามสามคำถามนี้พอ หนึ่ง: เทคโนโลยีหลักที่จะใช้ อายุกี่ปีแล้ว และบริษัทใหญ่ ๆ ที่ใช้อยู่มีใครบ้าง (คำตอบที่ดีคือชื่อที่คุ้นและอายุเป็นสิบปี) สอง: ถ้าอีกสามปีผมอยากให้ทีมอื่นหรือคนของผมเองดูแลต่อ หานักพัฒนาสายนี้ในไทยยากแค่ไหน (ทีมที่ตอบด้วยภาพตลาดแรงงานจริง คือทีมที่คิดเรื่องนี้มาแล้ว) และสาม: มีส่วนไหนของระบบที่เลือกใช้ของใหม่ เพราะอะไร (คำตอบที่ดีไม่ใช่ไม่มีเลย — แต่คือมีอย่างมีเหตุผล ในส่วนที่แยกได้ พร้อมแผนถอยถ้าของตัวนั้นไปไม่รอด) สังเกตว่าทั้งสามข้อไม่มีข้อไหนถามหาความเจ๋ง มันถามหาความรับผิดชอบต่ออนาคตของระบบ — ซึ่งคือสิ่งเดียวที่การเลือกเทคโนโลยีเป็นมาตลอด แค่ถูกบังด้วยแสงของของใหม่เป็นระยะ ๆ