วังวนใหญ่ – เมื่อปักใจเชื่อ เวลาจะเป็นการพิสูจน์

บางครั้งในงาน Dev เราอาจเจอสถานการณ์ที่ solution ที่เสนอไปไม่ได้รับการ adopt ทันที แต่กลับวนกลับมาอีกครั้งหลังผ่านไปหลายปี ตัวอย่างหนึ่งที่น่าสนใจ ตามนี้

Auto Update

📌 idea แรก อยากให้ ClickOnce แต่เราบอกแล้ว มันไม่ work เลยทำ client app ตัวเล็กๆ มาให้ และดึง จาก port 80 นี่แหละ + check sum และมี flag บอกอะไรไหมเป็น mandatory ไหม เมื่อปี 2017 ตอนนั้นเอา Lib AutoUpdater.NET + เขียน Code เพิ่มฝั่ง Client และทำหน้า Manage ฝั้ง Spring ไว้

📌 Lead ยุคนั้นไม่กล้าทดสอบ และเสนอลูกค้า เนื่องจากการไล่ลงที่เครื่องมีความแม่นำยามากกว่า เลยได้ลองแต่ภายในวง BA ไป 3-4 ปี ท้ายที่สุด server ที่ใช้ถูกเอาไปทำ project อื่นที่มีความสำคัญมากกว่า และเป็นอีกวังวนใหญ่

📌 แล้วปี 2019 ปัญหานี้กลับมาอีกรอบจาก Site ลูกค้า แล้วมีน้องมาทำด้วย Idea ClickOnce ก่อนลาออกไปบอกทำสำเร็จแล้วด้วย แต่เมื่อ review จริงๆ พบว่ายังใช้งานไม่ได้ และได้ feedback ว่าทีมยังไม่มีความชำนาญในการ setup ClickOnce

📌 ปี 2025 มีทีมใหม่มา implement ต่อ และน่าสนใจที่ solution สุดท้ายกลับมาใช้แนวคิดเดิมจากปี 2017 แต่เขียน code ขึ้นมาใหม่ทั้งหมด

Dynamic Menu

📌 การออกแบบระบบที่รองรับหลาย platform (Desktop/Web/Mobile) มักมาพร้อมกับความท้าทายในการจัดการ configuration โดยเฉพาะเรื่อง menu และ feature management เรื่องนี้เป็นอีกหนึ่ง case study ที่น่าสนใจเกี่ยวกับการเสนอ solution ที่ดี แต่ถูกนำไปใช้ในเวลาที่ผิด

📌 แนวคิดเบื้องต้นที่ผมออกแบบไว้ตอนปี 2017 ตอนนั้นออกแบบให้ JSON-based configuration + พร้อมกลไกป้องกันการแก้ไข โดยมีรายละเอียด ดังนี้

• JSON structure สำหรับ flexibility ใน configuration - ฝั่ง Front End เอาไปใช้งานได้เลย และมีปรับให้มี Option ในการเก็บ config ลง database
• Checksum column เพื่อป้องกันลูกค้าแก้ไข config โดยไม่ได้รับอนุญาต
• Feature Flag สำหรับการควบคุม features
• นอกจากนี้ได้ทำระบบ Web สำหรับจัดการ Dynamic Menu ตามแต่ละ Project โดยมีหลาย Project เข้ามาลอง POC แล้ว

📌 แม้ว่า POC จะทำงานได้จริง แต่ในช่วงเวลานั้น 2019-2024 ยังไม่ได้รับนำไปใช้งานเต็มรูปแบบ มีเพียง Feature Flag ส่วนเดียวที่ถูกนำไปใช้ เนื่องจากมีความเกี่ยวพันกับ core system อยู่แล้ว ส่วนอื่นๆ ถูกพับเก็บไว้ก่อน

📌 แต่ในช่วงต้นปี 2024 feature Dynamic Menu กลับมาถูก implement อีกครั้ง แต่ process ของการทำให้ระบบพร้อมใช้งานจริงใช้เวลานานกว่าที่คาด

• Web สำหรับจัดการ Dynamic Menu (Configuration page) ใช้เวลาเกือบปีกว่าจะขึ้นจริง (กลางปี 2025) ระหว่างนั้นทีมงานก็ต้องทำมือกันไปก่อน
• ส่วนที่น่าเป็นห่วง ไม่มี checksum protection ทำให้ลูกค้าสามารถแก้ไข config ได้หากเข้าใจโครงสร้าง

App Modernization

เรื่องนี้ ผมโดนผู้บริหารแขวนมาหลายรอบว่าทำไม ต้องมาเสนอแผนทำซ้ำ ย้าย Module EQ / FI ขึ้น DOTNET ผมทำ First Round จบไปตั้งแต่ปี 2018 แต่ทว่า

📌 Business ไม่ยอมให้ลูกค้าใช้ บอกว่าต้องขาย ไปหา Project มา

• ผมเสนอทางออกว่า อย่างงั้นพวกหน้าจอแบบเดิมก็ได้ แล้วให้ยิง Job มาให้ dotnet ทำสิ เพราะไม่งั้นต้องมา maintain logic หลายจุด
  - Idea โดนปัดตกไป ซึ่งคนตัดสินใจไม่ใช่คนทำงาน เลยไม่ต้องมาจัดการ Code ที่ยุ่งเหยิง
• แล้วพอปี 2020/2022 ผมเสนอเรื่องเดิม ผมโดนผู้บริหารแขวนอีกรอบ จริงๆ PM ยุคนั้นรายงานสถานะที่ไม่สะท้อนความเป็นจริง ทำให้คนอื่นๆรับรู้ว่า Progress 100% แต่จริงๆมันประมาณ 50-60% และไม่มีการสื่อสารให้ชัดด้วยว่าระบบเดิมต้องย้ายมาให้ระบบใหม่ ไม่มีผู้บริหารที่ตัดสินใจ
• ปี 2025 กลับมาทำใหม่ โดยอีกทีม

📌 ตอนทำทุกคนห่วงเรื่อง Quality

• เราเลยดันเรื่อง Automate Test มาตั้งแต่ปี 2015 ซึงไม่ค่อยมีคนสนใจ
• สรุปมันขึ้นมาได้ เพราะ เวลาพัง หรือ Demo ที่ Site ลูกค้าทาง MKT เดินมาระเบิดลง Dev ที่อยู่แถวๆนั้นระบายอะไร ช่วงนั้นเรายังคิดบวก เลยทำ Test เพิ่มมาเรื่อยๆ
• แล้วโดนผู้บริหารสั่งเอาออกไปตอนปี 2020 เพราะมันขวางการพัฒนา Project วังวนใหญ่
• ปี 2023- ต้นปี 2024 ผมโดนเรียกไปด่าแบบงงๆเรื่อง Quality
• ปี 2025 QA ที่ต่อต้าน Automate Test ยอมทำแล้ว ...

สั้นๆเลยครับ แล้วทำไม ยอมใช้ตั้งแต่แรก

มันเหมือนเอาปัญหาเดิมมาแก้ซ้ำ ซึ่งเสียเวลาในการจัดการ