Yuri Gubin, CTO ที่ DataArt – ชุดสัมภาษณ์

Yuri Gubin, CTO ที่ DataArt เป็นผู้บริหารเทคโนโลยีระดับสูงและสถาปนิกซอฟต์แวร์ที่มีประสบการณ์กว่า 18 ปีกับ DataArt โดยได้ก้าวผ่านบทบาทต่าง ๆ ตั้งแต่สถาปัตยกรรมซอฟต์แวร์, สถาปัตยกรรมโซลูชัน, เทคโนโลยีคลาวด์, นวัตกรรม, และการเป็นผู้นำระดับบริหาร ก่อนจะขึ้นเป็นหัวหน้าฝ่ายเทคโนโลยี (Chief Technology Officer) ในเดือนมีนาคม 2026 งานของเขามุ่งเน้นการแก้ไขความท้าทายเทคโนโลยีที่ซับซ้อนในอุตสาหกรรมต่าง ๆ รวมถึงบริการทางการเงิน, การดูแลสุขภาพ, การเดินทาง, และ IoT โดยมีความเชี่ยวชาญเป็นพิเศษในคลาวด์คอมพิวติ้ง, AI, แพลตฟอร์มข้อมูล, และสถาปัตยกรรมซอฟต์แวร์ระดับองค์กร ก่อนขึ้นเป็นหัวหน้าฝ่ายเทคโนโลยี, Gubin ทำหน้าที่หัวหน้าฝ่ายนวัตกรรมของ DataArt มากกว่า 5 ปีและเป็นสมาชิกของคณะกรรมการพันธมิตรของบริษัทตั้งแต่ปี 2021 นอกจากนี้เขายังเป็นสมาชิกมืออาชีพของ Forbes Technology Council มีส่วนร่วมในกลุ่มผู้เชี่ยวชาญด้าน AI และ Cloud Computing และทำหน้าที่เป็นที่ปรึกษาทางเทคโนโลยีให้กับ Girls Who Code ซึ่งเขาให้คำแนะนำเกี่ยวกับสถาปัตยกรรม, การปกป้องข้อมูล, การกำกับดูแลแพลตฟอร์ม, และนโยบายเทคโนโลยี DataArt ปัจจุบันระบุเขาเป็นหัวหน้าฝ่ายเทคโนโลยีที่ตั้งอยู่ในนิวยอร์ก

DataArt เป็นบริษัทวิศวกรรมซอฟต์แวร์ระดับโลกและการแปลงข้อมูลและ AI ก่อตั้งในนิวยอร์กในปี 1997 บริษัทได้เติบโตเป็นผู้เชี่ยวชาญด้านเทคโนโลยีกว่า 6,000 คนที่ดำเนินงานในกว่า 20 ประเทศและทำงานกับลูกค้ามากกว่า 400 ราย โดยให้บริการในด้านต่าง ๆ รวมถึงปัญญาประดิษฐ์และการเรียนรู้ของเครื่อง, ข้อมูลและการวิเคราะห์, การแปลงคลาวด์, วิศวกรรมซอฟต์แวร์ตามสั่ง, ความปลอดภัยไซเบอร์, และการปรับปรุงระบบเก่า DataArt ทำงานในภาคส่วนเช่นบริการทางการเงิน, การดูแลสุขภาพและวิทยาศาสตร์ชีวิต, การเดินทาง, สื่อและบันเทิง, และการค้าปลีก และรักษาความร่วมมือทางเทคโนโลยีกับแพลตฟอร์มเช่น AWS, Google Cloud, Microsoft Azure, Snowflake, และ Databricks ในปี 2025 บริษัทประกาศการลงทุน 100 ล้านดอลลาร์สหรัฐเป็นเวลา 3 ปีในความสามารถด้านข้อมูลและ AI และต่อมาในปี 2026 เปิดตัว Artisyn ซึ่งเป็นโมเดลการดำเนินงานที่ใช้ AI เพื่อรวมเอาเอเย่นต์ AI, ตัวเร่งที่ใช้ซ้ำได้, การกำกับดูแล, ความปลอดภัย, และการปฏิบัติตามกฎระเบียบเข้าสู่การพัฒนาซอฟต์แวร์ระดับองค์กร

คุณได้ทำงานกับ DataArt เกือบสองทศวรรษ, เริ่มจากสถาปัตยกรรมซอฟต์แวร์และสถาปัตยกรรมโซลูชัน ไปจนถึงหัวหน้าฝ่ายนวัตกรรมและตอนนี้เป็น CTO. การเดินทางนี้ได้ส่งผลอย่างไรต่อวิธีที่คุณแยกแยะเทคโนโลยีที่เป็นการเปลี่ยนแปลงอย่างแท้จริงจากวงจรของการโฆษณาเกินจริง, และมันมีอิทธิพลต่อ “skeptical optimism” ของคุณต่อ AI อย่างไรในวันนี้?

เรามีโอกาสเห็นคลื่นเทคโนโลยีหลายรูปแบบตลอดหลายปีที่ผ่านมา, รวมถึงการเติบโตของคลาวด์และมือถือ, รุ่นต่าง ๆ ของ AI, ระบบอัตโนมัติ, DevOps และ SRE, และผมได้เขียนโค้ด, ออกแบบสถาปัตยกรรมและให้คำปรึกษาลูกค้าเกี่ยวกับหัวข้อเหล่านี้ตลอดเวลา สิ่งที่ผมตระหนักคือว่าใช่, คุณสามารถทำเกือบทุกอย่างด้วยเทคโนโลยี, และเทคโนโลยีมีพลังมาก, แต่ความซับซ้อนอยู่ที่รายละเอียดและคุณต้องรู้ว่าตัวเองกำลังทำอะไรเพื่อให้มันมีเหตุผลและทำงานได้

ผมได้เห็นสภาพแวดล้อมคลาวด์ที่มีค่าใช้จ่ายเพิ่มขึ้นเรื่อย ๆ, โมเดล AI ที่ไม่ทำงานตามที่คุณคาดคิด, และความพยายามในการอัตโนมัติวงจรการปล่อยเวอร์ชันที่ดำเนินการอย่างไม่ดี ผมได้เห็นผลกระทบของการตัดสินใจที่ดีและไม่ดี ดังนั้นเมื่อมีสิ่งใหม่เข้ามาและคุณอ่านประกาศ, สัญญาและการโฆษณาเกินจริง ผมจะกลับไปที่หลักการเดียวกัน: เกือบทุกอย่างเป็นไปได้ด้วยเทคโนโลยี, แต่คุณ ต้องการ รู้ว่าตัวเองกำลังทำอะไร

คุณจะเข้าใจเทคโนโลยีอย่างดีผ่านการวิจัยและพัฒนา (R&D) และที่สำคัญคือผ่านโครงการจริง, เพราะนั่นคือวิธีที่คุณเรียนรู้ว่ามีอะไรเป็นไปได้, อะไรไม่เป็นไปได้, และจุดที่อาจเกิดข้อผิดพลาด คุณนำบทเรียนเหล่านั้นจากทุกการทำงาน, พูดคุยกับเพื่อนร่วมงาน, สถาปนิกและนักวิเคราะห์คนอื่น ๆ, และพยายามเข้าใจว่ามีรูปแบบหรือไม่และคุณสามารถสร้างระบบบางอย่างรอบ ๆ พวกมันได้หรือไม่ ในที่สุดสิ่งนั้นจะกลายเป็นแนวทาง, แล้วคุณจะเห็นว่าการตัดสินใจที่คุณคิดว่าเป็นการตัดสินใจที่ดีจริง ๆ ให้ผลลัพธ์ที่ดีหรือไม่

นั่นคือแหล่งที่มาของความมองโลกในแง่ดีแบบมีความสงสัย ไม่ว่เทคโนโลยีจะสัญญาอะไร, คุณยังคงต้องรู้ว่าตัวเองกำลังทำอะไร, และความรู้นั้นมาจากประสบการณ์, ความร่วมมือ, และความพยายามอย่างต่อเนื่องในการเรียนรู้, พัฒนาตนเองและสร้างระบบบางอย่างเบื้องหลังการโฆษณาเกินจริง

AI ระดับองค์กรดูเหมือนกำลังเปลี่ยนจากขั้นตอนของการส่งเสริมการทดลองไปสู่การตัดสินใจว่าโครงการทดลองใดควรขยายขนาดจริง ๆ สัญญาณใดบ่งบอกว่ากรณีการใช้ AI พร้อมสำหรับการนำไปใช้ในวงกว้าง, และสัญญาณเตือนอะไรบ่งบอกว่าบริษัทกำลังขยายขนาดเร็วเกินไป?

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

เพื่อทำความเข้าใจว่ากรณีการใช้ AI ทำงานได้หรือไม่, คุณต้องให้เวลามันและทำความเข้าใจว่ามันนำคุณค่าอะไรมาและเส้นทางผู้ใช้เป็นอย่างไร, เพราะจากนั้นคุณจะเห็นความเปลี่ยนแปลงแทนที่จะเห็นเพียงผลกระทบ ‘ว้าว’ ทันทีในทีมหรือกระบวนการทำงานเฉพาะ คุณต้องดูว่าผู้เดียวกันทำอย่างไรบ้างหลังจากหลายสัปดาห์ พวกเขายังคงใช้มันอยู่หรือไม่? พวกเขายังคงพอใจกับกรณีการใช้งานนั้น, การอัตโนมัตินั้น หรือทักษะ AI ที่พวกเขาสร้างขึ้นหรือไม่, หรือว่ามันเป็นเพียงจุดสั้นที่จริง ๆ แล้วไม่ควรขยายขนาด

บางอย่างเหล่านี้สามารถตรวจสอบได้เฉพาะเมื่อเวลาผ่านไปเท่านั้น จะมีผู้บุกเบิกคนแรกเสมอ ซึ่งมักเป็นคนที่มีความชำนาญด้านเทคนิคสูงและคนที่อยากรู้อยากเห็นมาก แล้วคุณต้องลองกับส่วนอื่น ๆ กับผู้ที่ตามหลังผู้นำร่องและต่อมาคือกลุ่มผู้ใช้ส่วนใหญ่ในช่วงแรก เมื่อมันพิสูจน์ตัวเองได้แล้ว ใช่ คุณก็สามารถเริ่มขยายขนาดและขยายกรณีการใช้งานนั้นไปยังแผนกอื่น ๆ ได้

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

นี่คือความมองโลกในแง่ดีแบบมีความสงสัยของฉันอีกครั้ง สมมติว่าคุณมีโมเดลอยู่แล้วและหลายพันคนใช้ AI ทุกวัน พร้อมด้วยโมเดลและเครื่องมือต่าง ๆ ที่มีอยู่แล้ว เมื่อโมเดลใหม่ออกมา เนื่องจากความฮือฮาและความอยากรู้อยากเห็นตามธรรมชาติ คุณอาจคาดหวังว่าทุกคนจะอยากทดลองมัน ซึ่งเป็นเรื่องดี แต่การทดลองนั้นอาจไม่ได้รับการชี้นำหรือมุ่งเน้นไปที่ผลลัพธ์เฉพาะใด ๆ และบางครั้งคุณอาจไม่สามารถวัดความแตกต่างได้

เมื่อขยายขนาด สิ่งนี้ก็สำคัญ ไม่ใช่แค่คนหนึ่งหรือสองคนที่ลองดูว่าโมเดลใหม่ทำงานอย่างไรเมื่อเทียบกับโมเดลเก่า มันอาจเป็นคนหลายพันคนที่ใช้เวลาในการทดลอง เมื่อสำหรับกรณีการใช้งานเฉพาะ ผลลัพธ์อาจไม่สำคัญมาก ในขณะเดียวกัน หากบางอย่างทำงานได้ดีจริง ๆ การเรียนรู้ว่าอะไรทำงานได้ดีในองค์กรของคุณอาจไม่ได้รับการอธิบายอย่างชัดเจนหรือมองเห็นได้โดยทุกคน

นั่นคือเหตุผลที่กลุ่มแรกที่ประเมินโมเดลใหม่ไม่ควรเป็นทุกคนในองค์กร ควรเป็นกลุ่ม R&D ที่ทำงานใกล้ชิดกับทีมที่เกี่ยวข้อง รวมถึงฝ่ายกฎหมายและความปลอดภัย เราประเมินโมเดลอย่างครอบคลุม ทำการประเมินอย่างรวดเร็ว แล้วจึงนำเสนอให้ผู้ชมกว้างขึ้นพร้อมกับความคิดเห็นและแนวทางเกี่ยวกับความปลอดภัย การปฏิบัติตามกฎระเบียบและเทคโนโลยี ด้วยโมเดลใหม่และการอัปเดตสำคัญที่เข้ามาอย่างต่อเนื่อง คุณต้องมีโมเดลและแนวคิดนี้อยู่เสมอ มันไม่ได้เป็นการทำครั้งเดียวหรือแบบชั่วคราว

DataArt ได้สร้าง “AI SWAT” ข้ามฟังก์ชันที่รวมเทคโนโลยี, กฎหมาย, การปฏิบัติตาม, InfoSec และทีมอื่น ๆ กลุ่มนี้ทำงานอย่างไรในทางปฏิบัติ และประเภทของความเสี่ยงหรือคำถามใดที่ต้องแก้ไขก่อนที่เครื่องมือ AI ใหม่จะได้รับการอนุมัติให้ใช้ในวงกว้าง?

ตั้งแต่เริ่มต้น ฉันคิดว่าเราตั้งเป้าหมายต่าง ๆ ให้กับกลุ่มนี้ประมาณทุกสี่หรือห้าเดือน เราเปลี่ยนลำดับความสำคัญ เป้าหมาย และบางครั้งภารกิจ และหลายเป้าหมายเหล่านี้เกี่ยวกับ AI อาจเป็นการพัฒนาทักษะของพนักงาน การเข้าสู่ตลาดและความสามารถใหม่ ๆ ความร่วมมือ หรือการเปิดใช้ AI อย่างกว้างขวางภายในองค์กรและทั่ว ADLC

หัวข้อที่แน่นอนจะพัฒนาตามเวลา และฉันคิดว่านั่นเป็นเรื่องที่ดี เพราะคุณต้องทบทวนกลยุทธ์ของตนเองอย่างต่อเนื่อง ตรวจสอบสมมติฐานของคุณ และเข้าใจว่าคุณต้องเปลี่ยนทิศทางหรือไม่และหัวข้อถัดไปสำหรับทีมควรเป็นอะไร

กลุ่มนี้ประกอบด้วยตัวแทนจากหลายแผนก และหนึ่งในวัตถุประสงค์ของมันคือการทำให้ทุกคนรับทราบข้อมูล เมื่อมีการประกาศใหม่ คำถาม หรือโอกาสใด ๆ คนหนึ่งสามารถนำหัวข้อนั้นมาที่การประชุมปกติของเรา แม้ว่าจะดูเหมือนเป็นคำถามด้านเทคโนโลยีที่เกี่ยวข้องกับทีมแคบ ๆ ในปัจจุบัน หัวข้อเหล่านี้อาจมีผลต่อหลายส่วนขององค์กร

นั่นคือเหตุผลที่เมื่อเราประเมินความร่วมมือใหม่ เครื่องมือใหม่ หรือเร่งรัดใหม่ เราจะหารืออย่างเปิดเผยเพื่อให้ทุกคนเข้าใจทิศทางและมีโอกาสตั้งคำถามหรือให้การตรวจสอบ สำหรับเครื่องมือ AI ใหม่ เทคโนโลยีไม่สามารถประเมินได้แยกจากกัน ความปลอดภัย กฎหมายและการปฏิบัติตามก็ต้องเข้าใจว่ามันจัดการข้อมูลของบริษัทหรือคลายเอนท์อย่างไร มีข้อจำกัดอะไรบ้าง และสามารถใช้ได้อย่างปลอดภัยในระดับขนาดใหญ่หรือไม่

บางครั้งทีม AI SWAT ยังทำงานในโครงการเฉพาะ เช่น การพัฒนาทักษะ โดยเราตั้งเป้าหมาย วางแผนเส้นทางและตัดสินใจว่ากลุ่มต่าง ๆ จะเข้าร่วมอย่างไร นั่นคือวิธีการทำงานของเรา: ทำให้คนรับทราบข้อมูล ทำงานร่วมกันในโครงการเฉพาะ และให้คณะกรรมการมองเห็นสิ่งที่เกิดขึ้นกับ AI ทั่วทั้งบริษัท

คุณกำลังเห็นทัศนคติที่แตกต่างอย่างมากต่อการพัฒนาซอฟต์แวร์ที่ช่วยโดย AI โดยบางองค์กรกำลังขยายการพัฒนาแบบเอเจนต์อย่างจริงจัง ในขณะที่บางองค์กรยังห้ามโค้ดที่สร้างโดย AI สิ่งใดอธิบายความแตกต่างนี้ และต้องเปลี่ยนแปลงอะไรบ้างก่อนที่องค์กรที่ระมัดระวังความเสี่ยงจะรู้สึกสบายใจกับการให้ AI มีบทบาทที่ใหญ่ขึ้นในวิศวกรรมซอฟต์แวร์?

สิ่งที่ทำให้ความแตกต่างระหว่างผู้ที่บอกว่าไม่และผู้ที่บอกว่าใช่น่าจะเป็นความพร้อมรับความเสี่ยงและทัศนคติต่อความคลุมเครือและความไม่แน่นอน สิ่งที่ช่วยทั้งสองประเภทขององค์กรคือการศึกษาอย่างต่อเนื่อง การทดลองและการประเมิน แม้ว่าองค์กรหลายแห่งที่เราทำงานด้วยซึ่งยอมรับ AI และนำมันไปใช้ทุกที่ ยังเผชิญความท้าทายในการวัดผลลัพธ์และผลกระทบ อย่างตรงไปตรงมา คำถามเกี่ยวกับวิธีวัดผลกระทบของ AI และวิธีประเมินประสิทธิภาพของทีมบางครั้งก็ปรากฏขึ้นโดยไม่มีสัญญาณเตือน เหมือนกับว่าไม่มีใครเคยคิดถึงเรื่องนี้มาก่อน

เมื่อคุณเริ่มประเมินโครงการ AI อย่างครอบคลุมมากขึ้น คุณจะเริ่มเข้าใจผลกระทบและคุณค่าที่มันให้คุณจริง ๆ ซึ่งนำไปสู่การตัดสินใจที่ดีขึ้นเกี่ยวกับที่เทคโนโลยีนี้มีความหมาย สำหรับบริษัทที่ปฏิเสธ AI ยังต้องมีกระบวนการต่อเนื่องในการทบทวนว่าเทคโนโลยีสามารถทำอะไรได้บ้างและอยู่ในระดับใดในขณะนี้ คุณไม่ต้องการให้การตัดสินใจที่ทำเมื่อสามปีที่แล้วยังคงเป็นนโยบายของบริษัทเพียงเพราะไม่มีใครทบทวนสมมติฐานเบื้องหลังมัน

Agentic AI ทำให้ทีมแต่ละทีมสร้างเอเจนต์ของตนเองได้ง่ายขึ้นเรื่อย ๆ ซึ่งอาจทำให้มีเอเจนต์หลายตัวทำงานที่คล้ายกันเกือบเหมือนกัน จุดที่การทดลองกลายเป็นการกระจายเอเจนต์มากเกินไปคือเมื่อใด และต้องการชั้นการกำกับดูแลแบบใดเพื่อจัดการความเป็นเจ้าของ สิทธิ์ การทำซ้ำ และการจัดการวงจรชีวิต?

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

ในระดับโครงการ คุณสามารถกำหนดฐานความรู้และบริบท รวมถึงกรณีการใช้งานที่คุณเริ่มใช้ AI จากนั้นคุณสร้างทักษะและเอเจนต์ที่เป็นส่วนหนึ่งของกระบวนการพัฒนาและทุกคนสามารถนำกลับมาใช้ใหม่ได้ ดังนั้นคุณจึงสะสมความรู้และแนวปฏิบัติที่ดีที่สุดแทนการสร้างใหม่ทุกครั้ง ความพยายามในระดับโครงการนี้ควรถูกประสานงานโดยคณะกรรมการสถาปัตยกรรมองค์กร กลุ่มเทคโนโลยี CTO หรือทีมที่รับผิดชอบการนำ AI ไปใช้ คุณต้องการนำเอเจนต์ที่ทำงานได้ดีกลับมาใช้ใหม่ ตรวจสอบให้กระบวนการมั่นคง และให้การทำงานนั้นครอบคลุมทั่วทั้งองค์กร แทนที่จะกลายเป็นความวุ่นวายและเสียงรบกวน

ดังนั้นผมคิดว่าต้องเป็นความพยายามที่ประสานกันในระดับโครงการ อาจรวมถึงระดับโปรแกรม แล้วต่อด้วยระดับแผนกและระดับองค์กรด้วย

การใช้โทเค็นและค่าใช้จ่ายการสรุปผลอาจดูเล็กน้อยในช่วงทดลอง แต่เมื่อระบบ AI ถูกนำไปใช้กับพนักงานหลายพันคนหรือเอเจนต์อัตโนมัติ ค่าใช้จ่ายเหล่านี้จะเพิ่มขึ้นอย่างมีนัยสำคัญ ธุรกิจควรคิดอย่างไรเกี่ยวกับการจัดการค่าใช้จ่าย AI และคุณคาดว่าจะมีแนวโน้มคล้าย FinOps ปรากฏขึ้นโดยเฉพาะสำหรับงาน AI หรือไม่?

ผมจะเริ่มด้วยการบอกว่า สถานการณ์ที่เกือบจะเป็นอุดมคติคือเมื่อค่าใช้จ่าย AI เพิ่มขึ้นถึงจุดสูงสุดแล้วค่อยเริ่มลดลงเล็กน้อยตามเวลา สิ่งนี้บ่งบอกว่าคุณสามารถคาดการณ์ ควบคุมค่าใช้จ่าย เข้าใจว่าคุณกำลังใช้จ่ายกับ AI จริง ๆ เท่าใด และเห็นผลลัพธ์ของการตัดสินใจของคุณ สถานการณ์ที่แย่คือเมื่อค่าใช้จ่ายขึ้นลงเรื่อย ๆ ซึ่งมักหมายถึงบางอย่างไม่ยั่งยืน หรือเมื่อค่าใช้จ่ายเพิ่มขึ้นแล้วลดลงอย่างเต็มที่ เพราะการนำไปใช้ไม่เกิดขึ้น สิ่งใดสิ่งหนึ่งทำงานไม่ถูกต้อง หรือผู้คนใช้สิ่งอื่นแทนและคุณไม่เห็นมัน

ดังนั้น FinOps เป็นเรื่องจริง และ AI FinOps ก็เป็นเรื่องจริงเช่นกัน เทคนิคบางอย่างมีความซับซ้อนสูง ในขณะที่บางอย่างค่อนข้างง่าย มันอาจเริ่มจากการเลือกโมเดลที่ต้องการเพื่อไม่ให้ต้องพึ่งพาโมเดลที่มีค่าใช้จ่ายสูงที่สุด และการตัดสินใจเหล่านั้นทีละขั้นจะเริ่มประหยัดเงินได้ในเวลาเดียวกัน อย่างไรก็ตาม การรู้วิธีประหยัดและควบคุมค่าใช้จ่ายเป็นเพียงครึ่งหนึ่งของสมการ FinOps ตามที่ผมมองคือเป็นระเบียบวิธีและกระบวนการที่รวมผู้นำผลิตภัณฑ์และธุรกิจด้วย เพราะคุณต้องกำหนดสิ่งที่วัดเมื่อประเมินความพยายาม AI

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

หลายบริษัทถูกขอให้แสดง ROI จาก AI แม้ว่าพวกเขาไม่เคยตั้งฐานข้อมูลที่เชื่อถือได้เกี่ยวกับประสิทธิภาพของทีมก่อนที่ AI จะถูกนำมาใช้ องค์กรควรวัดอะไรจริง ๆ หากต้องการกำหนดว่า AI สร้างคุณค่าทางธุรกิจที่มีความหมายหรือไม่?

ไม่ว่าคุณจะมีทัศนคติต่อ AI อย่างไร หรืออยู่ในขั้นตอนใดในขณะนี้ บางทีคุณอาจกำลังใช้เอเจนต์อยู่แล้วทั่วทุกที่ หรืออาจคิดว่าปีหน้าจะเริ่มใช้ AI การตั้งฐานข้อมูลเป็นสิ่งจำเป็นในยุคนี้

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

สิ่งที่ทำให้แตกต่างมากกว่าคือเมตริกที่อธิบายว่าการทำงานเสร็จเร็วแค่ไหนหรือดีแค่ไหน คิดถึงเมตริก DORA เช่น lead time หรือ MTTR ว่าคุณสามารถฟื้นตัวจากความล้มเหลวได้เร็วแค่ไหน แก้บั๊กในโปรดักชันได้เร็วแค่ไหน หรือเมตริกเหล่านั้นเปลี่ยนแปลงอย่างไรตามเวลา ตัวเลขหนึ่งค่าที่จุดใดจุดหนึ่งไม่บอกเส้นทางของมัน สถาปนิกคนหนึ่งของเรากล่าวเมื่อเร็ว ๆ นี้ว่า ในการพัฒนาซอฟต์แวร์ เมตริกที่ดีอาจรวมถึงความน่าเชื่อถือของการประมาณการเมื่อการนำ AI ไปใช้เพิ่มขึ้น เพราะนั่นบ่งบอกถึงความยั่งยืนของความพยายามเหล่านี้และประสิทธิภาพของทีมจริง ๆ คุณยังต้องติดตามค่าใช้จ่ายด้วย เพราะหากคุณพูดถึงประโยชน์เท่านั้นโดยไม่เข้าใจว่าต้องใช้ค่าใช้จ่ายเท่าไรเพื่อให้ได้ผลลัพธ์ คุณจะไม่มีภาพรวมที่ครบถ้วน

นอกเหนือจากการพัฒนาซอฟต์แวร์ ฉันคิดในลักษณะเดียวกัน ในทุกกระบวนการทำงานหรือขั้นตอน จะมีหน่วยงานของงานและคำนิยามของการเสร็จสิ้น ไม่ว่าคุณจะกำลังประมวลผลการเคลม ตรวจสอบเอกสาร หรือจัดการคำขอของลูกค้า ให้กำหนดสิ่งที่คุณส่งมอบและจากนั้นวัดระยะเวลาที่ใช้ก่อนมี AI ความเร็วและคุณภาพที่คุณทำได้ในขณะนี้ รวมถึงค่าใช้จ่าย สิ่งนี้จะให้จุดเริ่มต้นที่ดีสำหรับทั้งฐานข้อมูลพื้นฐานและกรอบเมตริก

DataArt ได้ฝัง AI ไว้ทั่ววงจรการส่งมอบซอฟต์แวร์ผ่านโครงการต่าง ๆ เช่น Artisyn เมื่อ AI เริ่มเข้ามาดำเนินการด้านการนำไปใช้ การทดสอบ และงานกระบวนการต่าง ๆ มากขึ้น ส่วนใดของวิศวกรรมซอฟต์แวร์จึงมีคุณค่ามากขึ้นสำหรับมนุษย์ และทักษะใดที่อาจเสี่ยงกลายเป็นสำคัญน้อยลง?

คุณสามารถใช้ AI อย่างมีประสิทธิภาพในการพัฒนาได้ก็ต่อเมื่อคุณยังจำคำนิยามของ ดี ได้อยู่ คุณต้องมีความเชี่ยวชาญนั้นเพื่อชี้นำเอเจนต์ของคุณ ตรวจสอบผลลัพธ์ ตั้งข้อจำกัดและกำหนดกฎเกณฑ์ คุณต้องเข้าใจว่ามาตรฐานที่ดีที่สุดคืออะไรและสถาปัตยกรรมที่ดีควรเป็นอย่างไร เพราะหากไม่มีสิ่งนั้น คุณอาจไม่รู้ว่ากำลังพัฒนาอะไรอยู่ และมูลค่าของความเชี่ยวชาญประเภทนี้กำลังเพิ่มขึ้นอย่างมากมาก

การเข้าใจรูปแบบสถาปัตยกรรมเป็นสิ่งสำคัญเช่นเดียวกับการเข้าใจสิ่งที่เหมาะสมในอุตสาหกรรม แอปพลิเคชัน หรือประเภทของโซลูชันใด ๆ คุณต้องรู้ว่าประเภทของสถาปัตยกรรมใดที่ดีในขณะนี้และประเภทใดที่จะยังคงดีเมื่อโซลูชันขยายขนาด เพราะบางครั้งสถาปัตยกรรมเดียวกันอาจไม่ทำงานตลอดอายุการใช้งานของโซลูชันหรือแพลตฟอร์ม

ความสมดุลของสิ่งที่เหมาะสมสำหรับโซลูชันเฉพาะเป็นส่วนของมนุษย์ นั่นคือรสนิยมและศิลปะการทำงานเบื้องหลังบริการและการพัฒนาซอฟต์แวร์ คุณต้องรู้ว่าตนกำลังทำอะไร และสิ่งนั้นมาจากการเข้าใจลูกค้าและอุตสาหกรรม

ทักษะใดบ้างที่สำคัญน้อยลง? ฉันบอกได้ยากจริง ๆ แม้อาจจะเป็นความเร็วในการพิมพ์โค้ด ฉันพูดเล่นนะ แต่โค้ดตอนนี้สามารถสร้างได้เร็วมากขึ้นมาก และความรู้เฉพาะของไลบรารีหรือภาษาหนึ่งก็สามารถเรียนรู้ได้เร็วขึ้นมากด้วย AI

ฉันเคยเห็นนักพัฒนา .NET ฝึกใหม่เป็นนักพัฒนา Java อย่างรวดเร็ว และห้าหรือสิบปีที่แล้วฉันคงบอกว่าการทำเช่นนั้นในระดับใหญ่เกือบเป็นไปไม่ได้ ปัจจุบันคุณทำได้แล้ว นักพัฒนาระดับอาวุโสที่แข็งแกร่งสามารถย้ายระหว่างภาษาได้มากขึ้น เพราะสิ่งที่สำคัญจริง ๆ คือความเข้าใจของพวกเขาในเทคโนโลยี สถาปัตยกรรม แนวปฏิบัติที่ดีที่สุดของโซลูชัน SDLC และ ADLC

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

ฉันชอบแนวคิดของการทำงานร่วมกันโดยไม่มีการตำหนิและความรับผิดชอบร่วมกัน เพราะทุกคนในองค์กรมีส่วนร่วมในแนวปฏิบัติที่ดีที่สุด กรอบสถาปัตยกรรมและโซลูชัน แม้ว่านักพัฒนาคนหนึ่งจะสร้างโค้ดด้วย AI หรือโดยไม่มี AI นักพัฒนาคนอื่นก็จะตรวจสอบมัน ผู้นำทีมให้คำแนะนำ สถาปนิกจัดสถาปัตยกรรมและข้อจำกัด และทีมกำกับดูแลมีส่วนในการตัดสินใจเกี่ยวกับงบประมาณ เวลาและการเปิดตัว ทุกคนมีส่วนร่วมในบางรูปแบบ

บ่อยครั้งที่เมื่อมีสิ่งผิดพลาด มันมักเป็นกระบวนการที่ไม่ทำงาน ดังนั้นในความหมายนี้ ความรับผิดชอบจึงถูกแบ่งปันระหว่างบทบาทต่าง ๆ แต่หากคุณเพียงบอกว่าความรับผิดชอบถูกแบ่งปันและจึงไม่มีการตำหนิ นั่นไม่เพียงพอ ยังต้องแยกเป็นความรับผิดชอบเฉพาะแต่ละส่วน

นักพัฒนามีความรับผิดชอบต่อโค้ดที่พวกเขาส่งเป็น pull request และต้องเข้าใจว่ามีอะไรเกิดขึ้นที่นั่น สถาปนิกมีความรับผิดชอบต่อการตัดสินใจที่ทำและต่อการตัดสินใจด้านสถาปัตยกรรมที่มอบให้กับเอเจนต์และนักพัฒนา ทีมแพลตฟอร์มมีความรับผิดชอบต่อความน่าเชื่อถือของโซลูชันโดยไม่คำนึงว่าใครหรืออะไรเป็นผู้สร้างบรรทัดโค้ดนั้น

ดังนั้นความรับผิดชอบก็มีอยู่แล้ว แต่คุณต้องกำหนดอย่างละเอียดตามทีม บทบาท และแผนก สิ่งที่คุณทำไม่ได้คือหยุดการวิเคราะห์ที่ “AI ทำสิ่งนี้” คุณต้องถามว่าการควบคุม การทดสอบ หรือการตรวจสอบใดที่ทำให้ความล้มเหลวนั้นถึงผลิตได้

หากการขาดการทดสอบหน่วยทำให้โค้ดที่ไม่ดีถูกผลักดันเข้าสู่การผลิต หรือการขาดการตรวจสอบและรีวิวทำให้เหตุการณ์เกิดขึ้น คุณไม่สามารถโอนความรับผิดชอบนั้นไปให้ AI ได้ คุณก็ไม่สามารถโทษผู้ให้บริการโมเดลหรือผู้ให้บริการคลาวด์สำหรับบั๊กหรือการหยุดทำงานทุกกรณีได้

ขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม DataArt.