Khoảng cách giữa ‘làm được’ và ‘làm đúng’: Bài học từ hành trình phát triển xe thông minh tại Việt Nam
Dưới góc nhìn thực tế từ chuyên gia VinFast, bên cạnh công nghệ, phát triển hệ thống xe thông minh cần sự hiệu quả trong cách tổ chức, phối hợp và tư duy hệ thống.
Chấm sáng nhỏ nhấp nháy trên màn hình — với người lái xe, đó chỉ là một cảnh báo buồn ngủ, một tín hiệu quen thuộc. Nhưng phía sau chấm sáng tưởng như đơn giản ấy là cả một hành trình đầy phức tạp của hàng chục hệ thống khác nhau vận hành cùng lúc.
Và cũng chính từ những chấm sáng nhỏ như vậy, nhiều đội kỹ thuật trên thế giới mới nhận ra điều quan trọng nhất: Phát triển xe điện thông minh không chỉ là lập trình tính năng, mà là hiểu đúng cách toàn bộ hệ thống vận hành.
Tại Vietnam Systems Engineering Day 2025 vừa được tổ chức ở Hà Nội quy tụ gần 100 chuyên gia, lãnh đạo doanh nghiệp, giảng viên và cộng đồng kỹ thuật hệ thống đến từ các trường đại học kỹ thuật lớn cùng đại diện từ nhiều quốc gia như Pháp, Australia, Ấn Độ, Đức, Singapore và Indonesia, ông Sơn Phan, Trưởng phòng Phát triển Phần mềm – Hệ thống giám sát trong cabin (In-cabin Monitoring System) VinFast trình chiếu một slide mô tả cách làm cũ, kết thúc ở “một tổ rối như tơ vò” khiến cả hội trường bật cười.
Theo ông Sơn, với cách làm cũ, một bản thử nghiệm có thể hoàn thành trong 3 tháng. Nhưng để trở thành tính năng an toàn trên hàng nghìn chiếc xe, mọi thứ lập tức thay đổi: Các nhóm AI – phần mềm – phần cứng không nói chung một “ngôn ngữ”, mỗi bộ phận hiểu hệ thống theo một cách khác nhau, và không ai cầm được bức tranh tổng thể.
Đó cũng là lúc những người phát triển phần mềm cho những chiếc xe thông minh nhận ra rằng cách làm truyền thống – vốn dựa vào kinh nghiệm, tốc độ và nỗ lực của từng nhóm – không còn phù hợp. Ông Sơn gọi đó là “khoảnh khắc phải thay đổi”, khi đội ngũ buộc phải tìm đến Systems Engineering và MBSE như một phương pháp để nhìn thấy toàn bộ hệ thống, thay vì từng mảnh rời rạc.
Sau hội thảo, chúng tôi đã cuộc trò chuyện dài hơn với ông Sơn Phan, không chỉ để hiểu vì sao Systems Engineering và MBSE trở thành xu thế trên toàn cầu, mà còn để khám phá những bài học thực tế từ “khoảng cách giữa làm được và làm đúng” – khoảng cách mà bất kỳ đội kỹ thuật nào cũng phải bước qua.
Thưa ông, tại hội thảo, ông nói về ADAS và Driver Monitoring System. Ông có thể chia sẻ ngắn gọn cho độc giả chúng tôi nó là gì, giúp ích gì cho người lái — và vì sao các hệ thống này lại khó phát triển đến vậy?
ADAS nói chung và DMS nói riêng là những hệ thống hỗ trợ với mục đích nâng cao trải nghiệm lái (comfort) cũng như tăng cường sự an toàn trong quá trình tham gia giao thông (safety) cho tài xế và người ngồi trên xe.
Nói ADAS hay DMS là một hệ thống khó phát triển bởi vì nó là những hệ thống phức tạp với sự kết hợp của nhiều yếu tố: Đa cảm biến, thuật toán AI mạnh mẽ, hệ thống nhúng phức tạp, yêu cầu xử lý trong thời gian thực, môi trường khó, nhiều tương tác với con người đồng thời phải đáp ứng các tiêu chuẩn an toàn cao.
Ông vừa chia sẻ rằng một bản thử nghiệm POC chỉ mất 3 tháng nhưng sản phẩm thật lại gặp rất nhiều rào cản. Khoảnh khắc nào khiến ông nhận ra cách làm cũ không thể đưa DMS ra sản phẩm thực tế?
Sau khi đạt được thành công với bản thử nghiệm đầu tiên (POC-Proof of concept) một thời gian, tôi nhận thấy cả team vẫn cứ loay hoay trong việc xác định cái mình cần phải làm tiếp theo là gì, dựa vào đâu để đánh giá sản phẩm. Lúc đấy, mọi người mới nhận ra là cứ tiếp tục như cũ thì sẽ không bao giờ tới được đích.
Trong bài trình bày, ông nói rằng đội AI – software – hardware “không cùng hiểu một thứ”. Điều gì xảy ra vào thời điểm đó khiến ông thấy cần phải thay đổi cách phối hợp?
Trong quá trình làm thì cả team có rất nhiều các cuộc họp để trao đổi về yêu cầu và giải pháp. Phần lớn các cuộc họp đều kéo dài hơn thời gian dự định và kết thúc bằng việc tạo ra nhiều “vấn đề” hơn là giải quyết các “vấn đề” ban đầu.
Lý do chính là vì mỗi người có một cách hiểu, một cách nhìn nhận về giải pháp, cả team không ai nói cùng một “ngôn ngữ”. Và mọi thứ cứ như vòng lặp không giải pháp.
Khi nhìn lại toàn bộ lifecycle của một hệ thống ADAS/DMS, theo ông giai đoạn nào là “dễ sai từ gốc” nhất — và điều gì khiến lỗi đó khó phát hiện khi dùng cách làm cũ?
Cũng như con người có Sinh - lão - bệnh - tử, thì hệ thống cũng sẽ có vòng đời của riêng nó: Từ lúc hình thành ý tưởng, sau đó đến phát triển, tích hợp, rồi đi vào quá trình sử dụng, bảo trì, sửa chữa và cuối cùng là phân rã, tái chế.
Tuy nhiên với hướng tiếp cận truyền thống, phần lớn mọi người chỉ thường tập trung vào giai đoạn “hệ thống đi vào hoạt động” (vì đây là nguồn gốc của các tính năng chính của sản phẩm), và thường bỏ qua các giai đoạn khác.
Đồng thời mọi người cũng chỉ quan tâm tới các kịch bản “thành công” (successful scenario) mà quên mất cần phải xem xét đến cả những kịch bản “thất bại” (failure scenarios). Chính điều này sẽ làm bỏ sót “yêu cầu” (needs) ngay ở khâu thiết kế hệ thống và dẫn tới giải pháp của sản phẩm trong tương lai không đáp ứng toàn bộ yêu cầu của các bên liên quan (stakeholders’s expecations).
Từ những vấn đề ông vừa chia sẻ, điều gì khiến ông và đội kỹ sư nhận ra rằng phải tìm một cách tiếp cận hoàn toàn khác thay vì tiếp tục sửa từng lỗi nhỏ?
Việc sửa từng lỗi nhỏ chỉ là một giải pháp ngắn hạn chứ không thể giúp mọi người nói cùng một ngôn ngữ, có cách hiểu giống nhau hoặc chung một cách nhìn về một bức tranh tổng thể của hệ thống. Do vậy cần một cách tiếp cận hoàn toàn khác và giúp cả team khắc phục những điều vừa rồi.
Theo ông, vì sao Systems Engineering và MBSE — một cách làm có vẻ mới mẻ tại Việt Nam — lại phù hợp với các hệ thống phức tạp như ADAS hơn cách phát triển truyền thống?
SE/MBSE phù hợp hơn cách truyền thống khi phát triển một hệ thống phức tạp như ADAS là vì một vài điếm sau:
- Quản lý tốt sự phức tạp đa lĩnh vực (phần cứng, phần mềm, thuật toán AI, điện tử-cảm biến, điều khiển, cơ khí, an toàn, bảo mật, giao tiếp mạng xe, ...)
- Quản lý yêu cầu tốt hơn
- Giúp dễ dàng phát hiện ảnh hưởng khi yêu cầu thay đổi
- Hỗ trợ phân tích an toàn ngay trong kiến trúc
- Cho phép mô phỏng từ sớm
- Giảm lỗi giao tiếp giữa các bên liên quan
- Tăng tốc kiểm thử và đảm bảo độ phủ của các bài test
- Giảm lỗi tích hợp và nâng cao chất lượng tổng thể
Và những điều trên sẽ giúp cho ra đời hệ thống ADAS chất lượng, đúng thời hạn, với ngân sách tối ưu và nguy cơ sai sót được giảm xuống mức thấp nhất có thể. Vì một hệ thống như ADAS thì sẽ không có chỗ cho những sai sót, dù là nhỏ nhất, bởi vì chỉ một sai sót nhỏ có thể ảnh hưởng tới an toàn, tính mạng của không chỉ tài xế mà còn là của những người tham gia giao thông xung quanh.
Khi áp dụng MBSE cho một đội ngũ đông và đa kỹ năng, thách thức lớn nhất ông đối mặt là gì: Thay đổi tư duy, thay đổi quy trình hay thay đổi cách giao tiếp?
Đó chính là thay đổi tư duy. Bởi vì đây là thứ bị cản trở bởi văn hóa, bối cảnh phát triển của nền khoa học kỹ thuật tại Việt Nam.
Nếu chỉ chọn một điểm mà MBSE giúp ông “dễ thở” nhất trong vai trò phát triển sản phẩm, thì đó là điều gì?
Đó là thay vì phải “viết quá nhiều” để mô tả hệ thống, dẫn đến việc diễn giải sai yêu cầu thì MBSE cho phép “mô hình hóa” (gọi vui là vẽ) hệ thống. Điều này giúp mọi người có cùng cách nhìn, cách hiểu về hệ thống. Thuật ngữ gọi là “single source of truth” (Một nguồn sự thật duy nhất).
Khi bắt đầu áp dụng Systems Engineering và MBSE, ông có tham khảo kinh nghiệm từ các nhóm quốc tế hay các dự án toàn cầu không? Và quá trình học hỏi đó giúp ông nhìn rõ hơn điều gì về vị trí của đội kỹ sư Việt Nam trong bức tranh chung của ngành?
Khi bắt đầu thì tôi không chỉ dựa trên kinh nghiệm từ các dự án trước đó mà bản thân có cơ hội được tham gia từ các tập đoàn ô tô tại Pháp mà còn tham khảo góc nhìn và lời khuyên từ các chuyên gia trong lĩnh vực oto và từ những lĩnh vực khác.
Và sau khoảng 4 năm làm việc tại VinFast nói riêng và Việt Nam nói chung thì tôi nhận thấy các kỹ sư Việt Nam rất năng động và có nhiều sáng tạo, giải quyết vấn đề rất nhanh và có tính thích ứng khá tốt.
Tôi tin là vài năm nữa, đội ngũ kỹ sư Việt Nam sẽ bắt được nhịp với thế giới và cho ra những sản phẩm có chất lượng.
Trong phiên thảo luận tại Vietnam Systems Engineering Day 2025, các chuyên gia từ Pháp, Đức, Singapore và Ấn Độ đều nói về “rào cản chung của ngành”. Với góc nhìn của ông, đâu là điểm chung, rào cản lớn nhất khiến nhiều dự án hệ thống phức tạp thất bại?
Điểm chung và cũng là rào cản lớn nhất trong các dự án hệ thống phức tạp không nằm ở công nghệ mà ở sự thiếu thống nhất trong cách con người phối hợp.
Khi mỗi nhóm vận hành theo ‘silo’, hiểu khác nhau về yêu cầu và không có một mô hình hệ thống chung, hệ thống tổng thể gần như chắc chắn sẽ gặp lỗi tích hợp, trễ tiến độ và vượt chi phí.
Nhiều chuyên gia toàn cầu khi nói về sức mạnh của Systems Engineering và MBSE nhấn mạnh rằng rào cản lớn nhất không nằm ở công nghệ mà nằm ở cách con người trong tổ chức phối hợp. Theo ông, đâu là bài học chung cho các doanh nghiệp khi phát triển những hệ thống lớn?
Một điểm dễ nhận thấy là các diễn giả trong phiên thảo luận về các thách thức và “cách giải toán” thì các chuyên gia đến từ những lĩnh vực rất khác nhau lại gặp nhau ở cùng phương pháp.
Bài học chung là phải có một tư duy hệ thống thống nhất, giao tiếp minh bạch và một mô hình chung để mọi nhóm làm việc trên cùng một “nguồn sự thật duy nhất”.
Khi con người phối hợp đúng, công nghệ mới có thể phát huy hết sức mạnh.
Với góc nhìn của người làm nghề, ông thấy vì sao Systems Engineering và MBSE lại có thể trở thành một hướng tiếp cận phù hợp cho nhiều tổ chức khi đối mặt với mức độ phức tạp ngày càng tăng của sản phẩm?
SE và đặc biệt là MBSE trở thành hướng tiếp cận phù hợp vì nó tạo ra một mô hình hệ thống thống nhất, giúp các nhóm nhìn chung một bức tranh, phối hợp tốt hơn và kiểm soát được rủi ro từ rất sớm.
Khi mức độ phức tạp tăng lên, điều quan trọng không chỉ là công nghệ mạnh hơn mà là khả năng quản lý sự phức tạp một cách có cấu trúc — đó chính là giá trị cốt lõi của SE và MBSE.
Xin chân thành cảm ơn ông!
