Exclusive Interview จิรายุส นิ่มแสง CEO Opsta เมื่อโลก Tech กำลังเปลี่ยน สิ่งที่ Developer ต้องรู้คือ “การปรับตัวให้ทัน”
8 ปีกับการเป็นผู้บุกเบิก DevSecOps ในไทย คือเส้นทางที่น่าจับตาของ จิรายุส นิ่มแสง หรือ ‘เดียร์’ CEO ของ Opsta บริษัทที่เริ่มต้นจากความหลงใหลในการดูแลระบบมาตั้งแต่สมัยเรียน
“ผมชอบดูแลระบบมาตั้งแต่สมัย ม.ปลาย ตอนนั้นดูแลตั้งแต่ร้านเกม ทำยังไงให้ร้านเกมไม่พัง คนเล่นเยอะขนาดนี้ ทำยังไงให้มันเสถียร” เดียร์เล่าถึงจุดเริ่มต้นของความสนใจด้านนี้ ที่นำพาเขามาสู่การก่อตั้ง Opsta จากจุดเริ่มต้นที่เป็นบริษัทแรกๆ ในประเทศไทยที่จับงานด้าน DevSecOps ตอนที่คำนี้ยังใหม่มากในตลาด จนถึงวันนี้ที่บริษัทกำลังก้าวเข้าสู่การเปลี่ยนแปลงครั้งสำคัญ
“ตั้งแต่กลางปีที่ผ่านมา และปีหน้าเป็นต้นไป เราจะเริ่มบอกคนอื่นว่าเรากำลังจะเปลี่ยนตัวเองเป็น Product-based Company เป็นบริษัทที่เน้นโปรดักต์มากกว่าเซอร์วิส” จิรายุสเผยถึงทิศทางใหม่ของบริษัท พร้อมอธิบายว่าการเปลี่ยนแปลงนี้เกิดจากการมองเห็นโอกาสในการสร้างอีโคซิสเต็มสำหรับ DevSecOps ในประเทศไทย
“ถ้าทำเซอร์วิส เราต้องเริ่มจากศูนย์ทุกครั้ง แต่ความรู้ของเรา 8 ปีที่ เราลงลึกมาขนาดนี้ ถ้าเราต้องเริ่มจากศูนย์ทุกครั้ง มาโฟกัสทำโปรดักต์ที่มันดี เพื่อให้คนเอาไปใช้งานได้เลยดีกว่า”
จาก Traditional Operations สู่ Modern DevOps: บทเรียนจากประสบการณ์จริง
การเปลี่ยนผ่านจากการปฏิบัติการแบบดั้งเดิมสู่ Modern DevOps เป็นเส้นทางที่เต็มไปด้วยบทเรียนสำคัญ จิรายุสได้แบ่งปันประสบการณ์ตรงจากการเห็นการเปลี่ยนแปลงนี้มาตลอด 8 ปี
“Traditional ทุกอย่างทำแมนนวล Governance ก็ต้อง Follow แบบแมนนวล ตาม Infrastructure กับ Security ที่เขาจะสร้างมาให้” เขาเล่าถึงรูปแบบการทำงานแบบเดิม “ปัญหาคือ lead time กว่าจะขึ้น production ได้ต้องรอ 3 เดือน 6 เดือน เราพูดกันอย่างนี้เลย code ที่คุณเขียนตรงนี้ กว่าจะขึ้นโปรดักชั่นได้ 3-6 เดือน ทั้งที่ Google, Facebook ขึ้นในวันนั้นเลย เขาเขียนวันนั้นขึ้นวันนั้นเลย”
ปัญหาสำคัญอีกประการของระบบเดิมคือการขาดความเชื่อมั่นในการ deploy “เราจะได้คำนี้เป็นมีมในเน็ตบ่อยมาก ‘It works on my laptop’ คือ Dev พัฒนาในแล็ปท็อปหรือเซิร์ฟเวอร์ดีเยี่ยม แต่พอขึ้น Production เท่านั้นแหละ รู้เรื่อง”
การเปลี่ยนผ่านสู่ Modern DevOps เกิดขึ้นเพื่อแก้ปัญหาเหล่านี้ เขายังเน้นย้ำว่าการเปลี่ยนแปลงนี้ไม่ได้เกี่ยวกับเทคโนโลยีเพียงอย่างเดียว แต่เป็นเรื่องของ mindset และวัฒนธรรมองค์กร “มันเกิด culture เกิด mindset DevOps ขึ้นมา บอกว่าไม่เอาแล้ว traditional กว่าจะรอ lead time กว่าจะขึ้น production ได้ต้องรอ 3 เดือน 6 เดือน
“การเปลี่ยนแปลงนี้ต้องทำทุกอย่างให้เป็น automate อย่างแรกก็คือเร็ว อันที่สองคือเชื่อถือได้” จิรายุสสรุป พร้อมเน้นย้ำว่าการเปลี่ยนแปลงนี้เป็นการเดินทางที่ต้องอาศัยทั้งเวลาและความมุ่งมั่นจากทุกฝ่ายในองค์กร
DevSecOps: จากอดีตถึงอนาคต
การเปลี่ยนแปลงของ DevSecOps ในช่วง 8 ปีที่ผ่านมา สะท้อนให้เห็นวิวัฒนาการของการพัฒนาซอฟต์แวร์ที่น่าสนใจ จากยุคที่การพัฒนาและการดูแลระบบถูกแยกออกจากกันอย่างชัดเจน มาสู่ยุคที่ทุกอย่างต้องทำงานประสานกันอย่างไร้รอยต่อ
“สมัยก่อน เวลาจะเริ่มโปรเจกต์ใหม่ Developer ต้องคลานเข่าไปหา Infrastructure บอกว่าช่วยสร้างเครื่องให้ผมหน่อย เปิดไฟร์วอลล์แบบนี้ให้ผมหน่อย เตรียมเครื่องแบบนี้ให้ผมหน่อย” เดียร์เล่าถึงความยุ่งยากในอดีต “ต้องมานั่งกรอกเอกสารเพียบ กว่าจะสร้างได้ใช้เวลาอีกหนึ่งเดือน สร้างมาเสร็จยังไม่พร้อมอีก ต้องตามมาแก้ แก้ แก้”
ปัญหาอีกอย่างที่พบบ่อยคือเรื่องของความไม่สอดคล้องระหว่างสภาพแวดล้อมการพัฒนาและการใช้งานจริง
การเปลี่ยนแปลงครั้งสำคัญเกิดขึ้นเมื่อแนวคิด DevOps เริ่มได้รับความนิยม และพัฒนามาเป็น DevSecOps ที่ให้ความสำคัญกับความปลอดภัยตั้งแต่เริ่มต้นกระบวนการพัฒนา “เมื่อก่อน Security จะโผล่มาตอนสุดท้าย ประชุมก็ไม่ประชุม อยู่ๆ โผล่มาตอนจะขึ้น Production แล้วบอกว่า ‘ไม่ได้ คุณต้องไปแก้ ไม่ให้เอาขึ้นพรุ่งนี้'”
แต่การเปลี่ยนแปลงที่สำคัญที่สุดกำลังจะเกิดขึ้น เมื่อ Security ไม่ใช่แค่ขั้นตอนสุดท้าย แต่ต้องถูกผนวกเข้าไปในทุกขั้นตอนของการพัฒนา “Security ต้องทำตั้งแต่วันแรก ไม่ใช่ขั้นกลาง ต้องบอกว่าตั้งแต่วันแรกจนถึงวันสุดท้าย เป็น automate ให้หมดให้มากที่สุด”
“ซึ่งแต่ละส่วนจะ automate ในเวลาที่ต่างกัน กล่องแรกจะ automate ตอนเขียนโค้ด ตัวที่สองคือ automate ตอนสร้าง infrastructure ตัวที่สามคือ automate ตอนขึ้น production” เดียร์อธิบายถึงอนาคตของ DevSecOps ที่กำลังจะเกิดขึ้น
ความท้าทายด้านความปลอดภัย
ภัยคุกคามด้านความปลอดภัยในโลกดิจิทัลกำลังเปลี่ยนรูปแบบไปอย่างน่าสนใจ เดียร์เผยว่าแฮกเกอร์เริ่มเปลี่ยนกลยุทธ์จากการโจมตีองค์กรโดยตรง มาเป็นการเจาะผ่าน Supply Chain แทน
“ถ้าไปเสิร์ชข่าวจะเจอเยอะมากว่าเขาเริ่มเจาะที่ Supply Chain คำว่า Supply Chain หมายถึงเจาะตั้งแต่คนเขียนโปรแกรมเลย แล็ปท็อปเขา หาทางวางช่องโหว่ วางแรนซัมแวร์ วางอะไรพวกนี้”
ตัวอย่างที่น่าสนใจคือกรณีที่แฮกเกอร์พยายามแทรกซึมเข้าไปในองค์กรที่พัฒนาซอฟต์แวร์ “มีตัวหนึ่งที่ผมเจอบ่อยมากคือ องค์กรสร้างของใหญ่มาก แต่ของใหญ่ที่สร้างทั้งหมดวางอยู่บนฐานแค่เล็กๆ คนเดียว ที่เป็นผู้พัฒนาโนเนมคนเดียวในรัสเซียที่ไม่มีใครรู้จัก แล้วถ้าอยากเจาะเราแค่ไปเจาะคนเดียวคนนั้น แล้วคุณจะทลายของทั้งหมดที่อยู่ในเอนเตอร์ไพรส์ได้ทั้งหมด”
การโจมตีรูปแบบใหม่นี้มีความซับซ้อนมากขึ้น “มีเทคนิคแปลกๆ เช่น ปลอมตัวเข้ามา บอกว่า ‘คนนี้พัฒนาไม่ดี ไม่ค่อยมีเวลา เดี๋ยวผมเข้ามาช่วยดูแลแทนนะ’ อาสาเข้าไปเลย แล้วก็แอบไปวางช่องโหว่ไว้”
เพื่อรับมือกับภัยคุกคามรูปแบบใหม่นี้ เครื่องมือด้านความปลอดภัยยุคใหม่จึงต้องดูแลตั้งแต่ต้นน้ำ ไม่ใช่แค่ปลายน้ำอีกต่อไป “เราจะเห็นหลายบริษัท ที่เมื่อก่อนเขาดูแลแค่ปลายน้ำ แต่ตอนนี้เขาบอกว่าไม่ใช่แล้ว ผมดูตั้งแต่วันแรกที่ Dev เขียนโค้ดบรรทัดนั้นลงบนแล็ปท็อปของเขา แล้วเริ่มสแกนตั้งแต่ตรงนี้เลย”
การป้องกันในยุคใหม่จึงต้องครอบคลุมตั้งแต่ระดับ Developer จนถึงระดับ Production โดยมีระบบตรวจจับและป้องกันที่ทำงานแบบ real-time เพื่อให้สามารถตอบสนองต่อภัยคุกคามได้อย่างทันท่วงที
Platform Engineering: เมื่อการพัฒนาซอฟต์แวร์ต้องการมากกว่าแค่การเขียนโค้ด
Platform Engineering กำลังกลายเป็นคำตอบสำหรับองค์กรขนาดใหญ่ที่มีทีมพัฒนาหลายทีม เดียร์อธิบายว่านี่คือการยกระดับจากการทำ DevSecOps แบบดั้งเดิม สู่การสร้างแพลตฟอร์มกลางที่ทุกทีมสามารถใช้ร่วมกันได้
“การ์ดเนอร์ให้คำนิยามชัดเจนว่า อนาคตของทีมเอนเตอร์ไพรส์ คุณจะต้องแบ่งออกมาเป็น 3 ทีมใหญ่ๆ ทีมที่เราคุ้นเคยกันดีแล้วคือทีมพัฒนา ทีมที่สองคือ Platform Engineering Team และทีมที่สามคือ SRE (Site Reliability Engineering)”
Opsta เริ่มพัฒนา Internal Platform มาตั้งแต่ 3 ปีที่แล้ว ก่อนที่การ์ดเนอร์จะมีคำนี้ด้วยซ้ำ “เราพัฒนาตัวนี้ขึ้นมาเพราะเจอปัญหาซ้ำๆ ในการทำ DevSecOps มา 5 ปี ทำไมผมต้องมาเริ่มใหม่แบบนี้ทุกครั้ง ทำไมมันไม่มีอะไรแค่กดคลิกแล้วใช้ได้เลย”
ปัญหาที่ Platform Engineering กำลังแก้ไขคือความไม่สอดคล้องกันระหว่างทีมต่างๆ ในองค์กร “เราเจอปัญหาปัจจุบันคือ มีทีมแอพ 10 ทีม แต่ละทีมใช้ tools ไม่เหมือนกัน ใช้ cloud ไม่เหมือนกันสักเจ้าเลย แล้ว governance จะเป็นยังไง?”
แพลตฟอร์มกลางจึงเกิดขึ้นเพื่อสร้างมาตรฐานให้กับองค์กร “Platform Team พัฒนา product เหมือนกัน แต่พัฒนา product ให้คนข้างในใช้ เพื่อเพิ่มความเร็ว มันกลายเป็นแพลตฟอร์มกลางขององค์กร”
“ฝั่งอเมริกา ยุโรป เขาไปไกลกว่าเรา เราเพิ่งเริ่มตั้งคำถาม ฝั่งเขาตั้งคำถามเรื่องนี้มานานแล้ว เขาก็เลยออกมาเป็น Platform Team ที่พัฒนาตัวนี้เพื่อตอบโจทย์ทีมแอพว่า อย่าไปคิดเอาเอง ทำเอาเอง มาใช้เครื่องมือนี้ดีกว่า มาใช้แพลตฟอร์มของเราที่จะไปตอบโจทย์ security ต่อ”
Observability: เมื่อการมอนิเตอร์ระบบต้องมองให้ลึกกว่าแค่ตัวเลข
การเปลี่ยนแปลงของระบบในยุคดิจิทัลทำให้วิธีการติดตามและตรวจสอบระบบต้องพัฒนาไปอีกขั้น เดียร์อธิบายถึงการเปลี่ยนผ่านจาก Traditional Monitoring สู่ Observability ที่ให้ภาพรวมที่ครอบคลุมมากขึ้น
“ถ้าเป็นเอนเตอร์ไพรส์ Monitoring ถือเป็นสิ่งลึกลับ” เดียร์เริ่มต้น “ถ้าเป็นบน cloud ปัจจุบัน Dev ก็จะใช้ของบน Cloud นั้นแหละ ซึ่งก็จริง ดูเท่าที่มันสามารถทำให้ได้ แต่ผมอยากให้ศึกษาเรื่อง Observability”
Observability มีหลักการสำคัญที่แตกต่างจาก Monitoring แบบดั้งเดิม “Data ทั้งหมดมี 3 แบบ metrics, logs, tracing ซึ่ง Monitor กับ Observe ต่างกัน Monitor คือที่เราทำอยู่ปัจจุบันนี้แหละ มี data ให้เยอะที่สุดเท่าที่เป็นไปได้ เกิดปัญหาขึ้นมาก็ไปไล่ดูให้หมด
“แต่ Observability สมัยใหม่เราเน้นไปที่ Experience ของผู้ใช้งาน เราเรียกว่า RED – R คือ Request จำนวนคนที่กำลังเข้าเว็บเราอยู่ E คือ Error และ D คือ Duration หรือ Latency ว่าเขาใช้งานเร็วช้าแค่ไหน”
เขายังยกตัวอย่างที่น่าสนใจเกี่ยวกับความซับซ้อนของระบบสมัยใหม่ “สมมติมีเครื่อง 100 เครื่อง แต่เผอิญว่ามีคนสะดุดปั๊บ เครื่องนึงดับ แล้วมันส่งผลเป็นลูกโซ่ว่า แอปตัวนี้ดับเพราะว่ามีคนสะดุดปลั๊กตัวนี้ดับ แล้ว Alert ถูกสร้างขึ้นมาสัก 20 ตัว แล้วส่ง Alert 20 ตัวนี้ คนที่มีประสบการณ์จะมองออกว่า อ๋อ ปลั๊กหลุดครับ…
“ผมยังไม่เห็น AI ตัวไหนทำได้ทำได้ขนาดนี้ แต่คนมีประสบการณ์มานั่งดู โอ้ 20 ตัว อ๋อ ปลั๊กหลุดครับ”
นี่คือตัวอย่างที่แสดงให้เห็นว่าทำไม Observability จึงต้องการมากกว่าแค่การเก็บข้อมูลและการแจ้งเตือน แต่ต้องการความเข้าใจในระบบอย่างลึกซึ้ง
การพัฒนาตัวเองของ Developer: จาก T-Shape สู่ Comb-Shape
การเปลี่ยนแปลงของเทคโนโลยีกำลังสร้างความท้าทายใหม่ให้กับ Developer ทุกคน เขามองว่าโมเดลการพัฒนาทักษะแบบเดิมที่เน้นความเชี่ยวชาญเชิงลึกในด้านเดียวอาจไม่เพียงพออีกต่อไป
“คนเราทั้งหมด ไม่ว่าตำแหน่งอะไรก็ตาม ต้องมี T-Shaped Skills ที่เป็น general แล้วก็ deep หนึ่งอัน แต่คนที่จะเติบโตเป็นซีเนียร์หรือพวกนี้ มันจะไม่ใช่ T-Shaped Skills แต่ต้องเป็น Comb-Shaped Skills คือเป็นหวี มีความลึกหลายๆ ด้าน”
ในยุคที่ AI กำลังมาแรง หลายคนอาจกังวลว่า AI จะมาทดแทนงานเขียนโค้ด แต่เขามองว่านี่คือโอกาสในการพัฒนาตัวเองให้มีทักษะที่หลากหลายและลึกซึ้งมากขึ้น
“ยุคอนาคตข้างหน้า มันจะไม่ใช่ T-Shaped Skills อีกต่อไป ต้องเป็น Comb เท่านั้น คุณจะเป็นเดฟขั้นเทพสุดยอด แต่ไม่เคยดู infrastructure ทำ container ไม่เป็น เป็นไปไม่ได้แล้วในอนาคต หรือแม้กระทั่ง infrastructure ดูแต่ infrastructure ยุคเก่า VM เนี่ย ต้องดู cloud ไป แล้ว cloud ไปแล้ว พอ container เสร็จ container มาเสร็จ ต้องเขียนโปรแกรมเป็น”
การพัฒนาตัวเองในยุคนี้จึงต้องมี “Role หลัก” แต่ต้องพัฒนาสกิลที่ 2 ที่ 3 อยู่เสมอ “สุดท้ายคุณค่าของคุณจะอยู่ที่ Main สกิลของคุณนั่นแหละ ว่าคุณไปตำแหน่งอะไร แต่ต้องมีความรู้ด้านอื่นประกอบด้วย”
ในไอที การลึกสายเดียวจะอยู่รอดได้ต่อไปได้ยาก “ยกเว้นคุณจะลึกแบบสุดสุดเลย อย่างเช่นเป็นนักวิจัย แต่ไม่ใช่ฝั่งคนทำงานไอที” การพัฒนาทักษะแบบ Comb-Shaped จึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับ Developer ยุคใหม่
AI กับอนาคตของ DevSecOps
ท่ามกลางกระแส AI ที่กำลังเข้ามามีบทบาทในทุกวงการ เขามองว่า DevSecOps ก็หนีไม่พ้นการเปลี่ยนแปลงนี้ แต่การใช้ AI อย่างมีประสิทธิภาพต้องเข้าใจทั้งศักยภาพและข้อจำกัดของมัน
“สุดท้ายผมพูดอย่างนี้ AI ยังมาแทนเราไม่ได้หรอก ในปีหน้า แต่ 2 ปีข้างหน้าก็ไม่แน่ มันพัฒนาไปเร็วมาก แต่ด้วยแนวโน้มที่เห็นในปัจจุบัน เรายังต้องเป็นผู้ใช้ AI”
โดยเฉพาะในด้าน Security ที่ต้องการการวิเคราะห์เชิงลึกและประสบการณ์ “DevSecOps อาจจะ automate ได้มากที่สุดเท่าที่เป็นไปได้ แต่ ณ ปัจจุบัน ไม่มีทาง automate ได้ร้อยเปอร์เซ็นต์ จะมีหลายสเต็ป เช่น Penetration Test ที่แม้แต่ AI ก็ทำระดับนี้ไม่ได้”
ยกตัวอย่างสถานการณ์ที่ AI ยังไม่สามารถทดแทนมนุษย์ได้ “เช่น พอดีเจาะเจอช่องโหว่ตัวนี้ แล้วมันเป็นแค่ gathering information เพื่อไปสู่ช่องโหว่อันถัดไป เพื่อไป gathering information อีก เพื่อเข้าสู่ตรงนี้ ตรงนี้ tool ไหนก็ทำไม่ได้ทั้งนั้น ต้องเป็นคน”
อย่างไรก็ตาม AI สามารถเป็นเครื่องมือที่มีประโยชน์มากถ้าใช้อย่างถูกวิธี “ทุกวันนี้ผมใช้ AI เพื่อยกระดับความรู้ของผม เจอ keyword ตัวใหม่ที่ผมไม่รู้ แล้วแบบ search หา เฮ้ย คำนี้ไม่มีโค้ดตัวอย่าง ให้ AI มันเจนแล้วเพื่อหา keyword อะไรบางอย่าง เพื่อให้ผมสามารถยกระดับสกิลตัวเองไปศึกษาเรื่องนี้ต่อได้”
“เราต้องเป็นผู้ใช้ AI ที่ตามมันทัน ถ้าเราไม่เท่าทันมัน เราก็จะโดนมันพอง” เดียร์ทิ้งท้ายประเด็นนี้ด้วยการเน้นย้ำว่า AI ควรเป็นเครื่องมือที่ช่วยให้เราพัฒนาตัวเอง ไม่ใช่สิ่งที่เราพึ่งพาโดยไม่เข้าใจ
เมื่อองค์กรต้องการเปลี่ยนเทคโนโลยี วิธีการนำเสนอไอเดียให้ผู้บริหารเห็นด้วย
การเปลี่ยนแปลงเทคโนโลยีในองค์กรไม่ใช่เรื่องง่าย โดยเฉพาะเมื่อต้องนำเสนอต่อผู้บริหารที่มองในแง่ธุรกิจเป็นหลัก เดียร์ในฐานะที่เป็นทั้ง CEO และผู้มีพื้นฐานด้านเทคนิค ได้แบ่งปันมุมมองที่น่าสนใจในประเด็นนี้
“มันเป็นเรื่องที่ยากมากโดยเฉพาะสำหรับคนที่เป็น Technical จริงๆ แต่ถ้าเป็น Business เขาจะตั้งคำถามเรื่องนี้อยู่แล้ว”
กุญแจสำคัญในการนำเสนอคือการพูดในภาษาที่ฝ่ายบริหารเข้าใจ “คุณกำลังมาลงทุนกับอะไรบางอย่าง ใช้เวลานานแค่ไหน แล้วได้ผลตอบแทนอย่างไร สมมติเป็นตัวเลข อย่างเช่น ผมใช้เวลาพัฒนา 3 เดือน แล้วใช้เงินนี้ไปกับการ Automate ในทุกควอเตอร์ ถ้าทำ Manual ใช้เวลาอาทิตย์เดียว คำตอบมันจะชัดขึ้นมาเอง”
ในกรณีที่ต้องการเปลี่ยนภาษาโปรแกรมมิ่ง เขาแนะนำให้นำเสนอในแง่ของการประหยัดทรัพยากร “เช่น ถ้าเปรียบเป็น Dev ผมกำลังจะเปลี่ยนไปใช้ Rust ครับ จากปัจจุบันใช้ Java ช่วยประหยัดเมมโมรี่ ผมรันแค่ร้อยเม็ก ฝั่งนี้ต้องใช้แรมเริ่มต้นที่ 4 กิ๊ก เหลือร้อยเม็ก Infrastructure เราจะลดลงมาจาก 5 worker เหลือ 2 worker 3 worker ที่หายไปคิดเป็นราคาเท่าไหร่ต่อวัน”
อย่างไรก็ตาม การนำเสนอต้องคำนึงถึงความเป็นจริงด้วย “แต่จะเปลี่ยนได้ต้องใช้เวลาอีก 6 เดือนครับ ด้วยทีม 3 คน นี่คือฟันดาเมนทัลเป็นตัวเลขเลย ฟันดาเมนทัลที่ business ที่จริงๆ แล้ว เมื่อก่อนสมัยผมเป็นเด็กก็แบบ ทำไมกูคิดไม่ได้นะ”
เดียร์ยังเน้นย้ำว่าการเจรจาต้องพร้อมที่จะหาจุดกลางร่วมกัน “Business บอกหก 6 เดือนไม่ได้หรอก 2 เดือนได้ไหม มาคุยกัน เมื่อกี้จะเห็นว่าต้องใช้ 3 คนไง เออใช้เวลาทำ 6 เดือน มันก็แบบหาทางตรงกลางลงด้วยกันได้ไหม”
คำแนะนำและบทสรุป เส้นทางสู่การเป็น Developer ยุคใหม่
การเลือกใช้เทคโนโลยีและการพัฒนาทีมเป็นสิ่งที่ต้องทำอย่างมีกลยุทธ์ เดียร์แบ่งปันประสบการณ์ที่สำคัญในฐานะผู้บริหารที่มีพื้นฐานด้านเทคนิค โดยเฉพาะเรื่องการตัดสินใจเลือกใช้เทคโนโลยีใหม่
“From ของเด็กสมัยนี้คือการใช้เทคโนโลยีเพราะมันเท่ ใช้เทคโนโลยีมาแบบ full platform มี tools ต้อง 20 ตัว integrate กันแบบ seamless แต่จริงๆ แล้ว ต้องถามว่า คุณเลือกใช้เทคโนโลยีตัวนี้เพราะอะไร?”
เขาแนะนำให้ย้อนกลับไปที่พื้นฐานสำคัญ “คุณต้องมีปัญหาก่อน ถ้าคุณเขียนประโยคออกมาไม่ได้ว่าปัญหาของคุณคืออะไร คุณก็ไม่ควรเลือกใช้เทคโนโลยีใหม่ แค่นั้นเลย ทำไมต้องใช้ตัวนี้ บางครั้งเขาตอบไม่ได้เลย”
ในมุมของธุรกิจ การตัดสินใจเลือกใช้เทคโนโลยีต้องคำนึงถึง ROI และผลกระทบระยะยาว “เหมือน automation ครับ เวลาพูดทำ automation คุณกำลังมาลงทุนทำ automation ตัวนี้ ใช้เวลานานแค่ไหน สมมติเป็นตัวเลขขึ้นมาเลย automation ตัวนี้ผมใช้เวลาพัฒนา 3 เดือน แล้วคุณใช้ตัวนี้บ่อยแค่ไหน”
สำหรับผู้บริหารที่ต้องดูแลทีม Dev เดียร์แนะนำให้เข้าใจความต้องการของคนรุ่นใหม่ “ต้องเข้าใจเด็กสมัยใหม่ที่เขาแบบอยากเท่ คิดดูแบบเขียน Java, JSP มาตลอด คุยกับเพื่อนแล้วไม่เท่เลย เขาก็ไม่อยู่แล้ว”
แต่การบริหารจัดการต้องหาจุดสมดุล “เราในฐานะคนมี maturity สูงกว่า CEO CTO ก็ต้องหาจุดกึ่งกลางให้เขา เช่นถ้าโครงการใหม่เป็นต้นไป เราเขียนเป็นภาษานี้กันดีกว่าไหม เดี๋ยวได้ทำตรงนี้ แต่ขอเป็น 50-50 นะ โค้ดเก่าก็เขียนอันเก่าประมาณ 50% อีก 50% คุณเอาเวลาไป invest”
สุดท้าย เดียร์ทิ้งท้ายด้วยมุมมองที่น่าสนใจเกี่ยวกับอนาคตของวงการ “เทคโนโลยีใหม่เกิดขึ้นตลอด แต่สิ่งสำคัญคือต้องรู้จักเลือก รู้จักปรับตัว และที่สำคัญที่สุดคือต้องเข้าใจว่าทำไมเราถึงใช้เทคโนโลยีนั้นๆ ไม่ใช่แค่ตามกระแส แต่ต้องตอบโจทย์ธุรกิจและการพัฒนา”
