Takai เช้าวันทำงานที่แสนธรรมดา ผมกำลังเพลิดเพลินกับการแก้บั๊กหรือพัฒนาฟีเจอร์ใหม่ในโปรเจกต์ที่คุ้นเคย แต่แล้ว เสียงแจ้งเตือนประชุมด่วนก็ดังขึ้น จู่ๆ Tech Lead ก็บอกว่า “เราจะเปลี่ยน Tech Stack กันครับ”
วินาทีนั้น ผมอึ้งอยู่นาน คำถามมากมายผุดขึ้นในหัว “แล้วโค้ดเก่าล่ะ?”, “เดดไลน์ที่ใกล้เข้ามาจะทำยังไง?”, “ต้องเริ่มเรียนรู้ใหม่หมดเลยเหรอ?” ความรู้สึกสับสน และกดดันถาโถมเข้ามาพร้อมกัน
หากคุณเคยรู้สึกเคว้งคว้างแบบเดียวกัน หรือแค่คิดตามก็ใจหายแล้ว ไม่ต้องกังวลไปครับ เพื่อนๆ ไม่ได้อยู่ตัวคนเดียวแน่นอน และบทความนี้คือขั้นตอนที่ผมใช้จริงซึ่งอยากจะแชร์ให้อ่านกันครับ
1. การเตรียมตัว
หลังจากคลื่นความช็อกซัดผ่านไป สิ่งแรกที่ผมทำไม่ใช่การแตกตื่น แต่คือการกลับมาตั้งสติและเปลี่ยนความสับสนให้กลายเป็นลิสต์คำถามที่ต้องหาคำตอบจาก Tech Lead ให้ได้ ซึ่งเป็นวิธีที่ผมใช้เสมอในการรับมือกับความเปลี่ยนแปลง
ตัวอย่างลิสต์คำถามที่ผมเตรียมไว้:
- เป้าหมายหลักของการเปลี่ยนแปลงคืออะไร? เพื่อ Performance ที่ดีขึ้น, ลด Technical Debt, หรือเพื่อเป้าหมายทางธุรกิจอื่นๆ? การเข้าใจถึง “ทำไม” จะทำให้ทีมเห็นภาพตรงกัน
- Timeline และเดดไลน์เป็นอย่างไร? แล้วงานที่ค้างอยู่เดิมจะจัดการอย่างไร?
- ขั้นตอนการเปลี่ยนผ่าน (Transition Process) จะเป็นอย่างไร? จากประสบการณ์ของผม กระบวนการที่ดีจะประกอบด้วย:
- การประชุมเพื่อวิเคราะห์และเลือก Tech Stack ที่เหมาะสม
- การทำโปรเจกต์ POC (Proof of Concept) เพื่อทดลองและพิสูจน์แนวคิด
- การประเมินผลจาก POC เพื่อหาปัญหาและทางแก้ไขร่วมกับทีม
- การทดลองนำไปใช้จริงกับฟีเจอร์เล็กๆ ก่อนขยายผล
การเตรียมคำถามเหล่านี้ไว้ล่วงหน้าช่วยให้ผมมีสติและไม่ฟุ้งซ่าน เพราะมันทำให้เห็นภาพรวม รู้ว่าต้องเจอกับอะไร และมีขอบเขตของเวลาที่ชัดเจนขึ้น
คุยกับทีม: เพื่อนๆไม่ได้สู้คนเดียว
นอกจากการลิสต์คำถามของตัวเองแล้ว อีกสิ่งที่สำคัญอย่างยิ่งคือการหันหน้าไปคุยกับเพื่อนร่วมทีมครับ ผมเชื่อว่าวินาทีนั้นไม่ใช่ผมคนเดียวที่รู้สึกสับสนและกังวล การได้แชร์ความรู้สึกและมุมมองกับคนอื่นๆ ในทีมไม่เพียงแต่ช่วยลดความกดดัน แต่ยังทำให้เราได้คำถามที่รอบด้านและเฉียบคมยิ่งขึ้นก่อนไปคุยกับ Lead
เพื่อนบางคนอาจกังวลเรื่องผลกระทบกับระบบที่ตัวเองดูแล บางคนอาจมีคำถามเกี่ยวกับเครื่องมือ (Tooling) หรือบางคนอาจแค่อยากได้ความมั่นใจว่าเราจะผ่านเรื่องนี้ไปด้วยกัน การรวมพลังกันตั้งแต่เนิ่นๆ แบบนี้ คือการสร้างรากฐานของความเชื่อใจและทำให้ทุกคนรู้สึกว่าเราเป็น “ทีมเดียวกัน” ที่พร้อมจะเผชิญความท้าทายนี้ไปด้วยกันครับ
2. การศึกษาและการทำ POC
หัวใจของ POC ไม่ใช่การสร้างโปรดักต์ที่สมบูรณ์แบบ แต่คือการทดลองในสเกลเล็กๆ เพื่อให้ได้คำตอบที่รวดเร็วที่สุด ดังนั้น ผมจึงเริ่มต้นด้วยโจทย์ที่เล็กและพื้นฐานที่สุด นั่นคือ การทำระบบ CRUD (Create, Read, Update, Delete) แบบง่ายๆ
ใช้ Generative AI ช่วยสร้างโครงโปรเจกต์: ตัวอย่าง Prompt
เพื่อให้โปรเจกต์ตั้งไข่ได้เร็วที่สุดและไม่ต้องเสียเวลากับการตั้งค่าที่ยุ่งยาก ผมใช้ Generative AI เข้ามาช่วยสร้างโครงโปรเจกต์เบื้องต้นขึ้นมาครับ
สมมติว่า Tech Stack ใหม่ของเราคือ Go (Golang) สำหรับ Backend และ PostgreSQL สำหรับฐานข้อมูล ผมจะใช้ Prompt ที่เฉพาะเจาะจงเพื่อให้ได้โค้ดที่ใกล้เคียงกับสิ่งที่ต้องการมากที่สุด
ตัวอย่าง Prompt:
“Create a simple CRUD API for a ‘product’ entity using Go with the Gin framework. The ‘product’ should have an ID, name, and price. Also, provide the code to connect to a PostgreSQL database, including a SQL script to create the ‘products’ table. The API should have the following endpoints:
POST /productsto create a new product.GET /productsto list all products.GET /products/{id}to get a single product by ID.PUT /products/{id}to update a product.DELETE /products/{id}to delete a product. Please include error handling and comments in the code.”
Prompt นี้มีข้อดีคือ:
- ชัดเจนและเฉพาะเจาะจง: ระบุทั้งภาษา (Go), เฟรมเวิร์ก (Gin), และฐานข้อมูล (PostgreSQL)
- ครบถ้วน: ขอทั้งโครงสร้าง API, การเชื่อมต่อฐานข้อมูล, และแม้กระทั่ง SQL script
- ระบุรายละเอียด: กำหนดฟิลด์ของข้อมูลและ Endpoint ที่ต้องการอย่างชัดเจน
- ขอแนวปฏิบัติที่ดี: การระบุให้ใส่ Error Handling และ Comment ช่วยให้โค้ดที่ได้มีคุณภาพดีขึ้น
เมื่อได้โค้ดที่ทำงานได้แล้ว ก็ถึงขั้นตอนของการ “ทดลองเล่น” ครับ ผมจะลองทำในสิ่งต่างๆ ที่ประหลาดๆ หรือลองนำไปเปรียบเทียบกับโค้ดเก่าเพื่อหาข้อดี-ข้อเสียที่ชัดเจน
ในกรณีของผมที่ต้องเปลี่ยนทั้งภาษาที่ใช้และฐานข้อมูล ผมจะเน้นการเปรียบเทียบใน 2 มิติหลักคือ:
- Performance: ทดสอบความเร็วในการทำงานของฟังก์ชันเดียวกัน
- Developer Experience: ประเมินความยากง่ายในการเขียนและแก้ไขโค้ด ซึ่งเป็นปัจจัยสำคัญในการทำงานระยะยาว
3. ก้าวแรกสู่โปรดักชัน: การนำไปใช้จริง
หลังจาก POC ประสบความสำเร็จและทีมมีความมั่นใจมากขึ้น ก็มาถึงคำถามสำคัญข้อต่อไป: “เราจะเริ่มนำ Tech Stack ใหม่ไปใช้กับโปรเจกต์จริงได้อย่างไร โดยไม่ทำให้ระบบเดิมพัง?”
คำตอบของเราคือ ไม่ทำแบบ Big Bang หรือการรื้อสร้างใหม่ทั้งหมดในคราวเดียว เพราะมันเสี่ยงและใช้เวลานานเกินไป แต่เราเลือกใช้กลยุทธ์ที่ปลอดภัยกว่าคือการ “ทยอยสร้างและแทนที่”
กฎเหล็กที่ทีมผมตั้งขึ้นมานั้นเรียบง่ายมากครับ: “ฟีเจอร์ใหม่ ให้สร้างด้วย Tech Stack ใหม่เท่านั้น”
วิธีนี้มีข้อดีหลายอย่าง:
- ลดความเสี่ยง: เราได้ทดลองใช้เทคโนโลยีใหม่กับงานจริงในสเกลเล็กๆ ที่ควบคุมได้ หากเกิดปัญหาขึ้น ผลกระทบก็จะจำกัดอยู่แค่ฟีเจอร์นั้นๆ ไม่กระทบกับระบบหลัก
- ทีมได้เรียนรู้จากงานจริง: ทีมจะได้ฝึกฝนและเรียนรู้การใช้งาน Tech Stack ใหม่กับโจทย์จริง ทำให้เกิดความเข้าใจที่ลึกซึ้งกว่าการทำ POC
- ส่งมอบคุณค่าได้ต่อเนื่อง: ไม่ต้องรอเป็นปีเพื่อการ Rewrite ทั้งหมด แต่จะได้รับฟีเจอร์ใหม่ๆ ออกไปอย่างสม่ำเสมอ
แน่นอนว่าช่วงแรกอาจจะเหนื่อยหน่อยครับ เพราะทีมต้องดูแลทั้งระบบเก่า (Legacy Code) และสร้างระบบใหม่ไปพร้อมกัน แต่แนวทางนี้คือการสร้าง “ชัยชนะเล็กๆ” ไปเรื่อยๆ ซึ่งช่วยสร้างโมเมนตัมและความเชื่อมั่นให้กับทีมในการเดินทางระยะยาวได้ครับ นอกจากนี้ผมแนะนำว่าถ้ามีปัญหาอะไรก่อนเริ่มทำควรปรึกษากับ Teach Lead ว่าควรทำแนวทางอย่างไร ถ้ามีข้อสงสัยก็ควรถามให้เคลียครับ
บทสรุป: จากวิกฤตสู่โอกาสในการเติบโต
จากวันแรกที่สับสนและรู้สึกเหมือนถูกโยนลงทะเล จนถึงวันที่เรามีฟีเจอร์แรกที่รันบน Tech Stack ใหม่ได้สำเร็จ มันคือการเดินทางที่ให้บทเรียนกับผมและทีมอย่างมหาศาล ผมขอสรุปบทเรียนสำคัญที่ได้เรียนรู้ไว้ดังนี้ครับ
- การเปลี่ยนแปลงทางเทคโนโลยี คือการเปลี่ยนแปลงของ “คน”: สิ่งที่สำคัญกว่าโค้ด คือการสื่อสาร พูดคุยถึงความกังวล และสร้างความเข้าใจร่วมกันในทีม
- แผนการที่ดีช่วยลดความกลัว: การเปลี่ยนความรู้สึกเคว้งคว้างให้เป็นลิสต์คำถามและแผนงานที่ชัดเจน จะทำให้ความท้าทายที่ดูใหญ่โต กลายเป็นสิ่งที่จัดการได้
- อย่าพยายามย้ายบ้านทั้งหลังในวันเดียว: เริ่มต้นจากสิ่งเล็กๆ (POC) และทยอยทำไปทีละส่วน (Incremental) คือกุญแจสำคัญในการลดความเสี่ยงและสร้างความสำเร็จในระยะยาว
- วิกฤตคือโอกาสในการเติบโตที่ดีที่สุด: แม้จะเริ่มต้นด้วยความรู้สึกเชิงลบ แต่ท้ายที่สุดแล้ว นี่คือโอกาสที่ยอดเยี่ยมที่สุดในการได้เรียนรู้เทคโนโลยีใหม่ๆ และอัปสกิลของตัวเองและทั้งทีม
ถ้าวันนี้เพื่อนๆกำลังยืนอยู่ ณ จุดเริ่มต้นของความเปลี่ยนแปลงแบบเดียวกัน ผมหวังว่าเรื่องราวและขั้นตอนเหล่านี้จะเป็นเหมือนแผนที่เล็กๆ ที่ช่วยนำทางและมอบความมั่นใจให้เพื่อนๆได้ ไม่ต้องกลัวครับ เพื่อนๆทำได้อย่างแน่นอน
