(*Trước hết đây là một bài viết dựa trên những bối cảnh cá nhân tôi muốn đưa lên để cùng thảo luận dưới góc nhìn của một cá nhân trong lĩnh vực công nghệ, có thể sẽ giống với bài toán nào đó, nhưng có thể chưa hoàn toàn đúng ở các mô hình phát triển của vô số những doanh nghiệp ngoài kia. *
Thế nhưng tôi thật sự muốn tìm kiếm một giải pháp để cân bằng mà vẫn phát triển trong bối cảnh AI bùng nổ và xuất hiện trong hầu hết các giai đoạn phát triển phần mềm.)
Có một sự dịch chuyển rất lớn đang diễn ra trong thế giới phát triển phần mềm từ khi AI bùng nổ những năm gần đây…
Trong nhiều năm, chuỗi giá trị phát triển phần mềm vận hành theo một nhịp khá quen thuộc. Bắt đầu từ khâu khám phá nhu cầu, phân tích bài toán, viết yêu cầu nghiệp vụ, chuyển hóa thành luồng trải nghiệm và thiết kế giao diện, rồi mới đi vào lập trình, kiểm thử, triển khai và cải tiến.
Trong cấu trúc đó, coding thường là công đoạn tiêu tốn nhiều thời gian nhất. Cả hệ thống vì thế vô thức được tổ chức quanh một giả định nền tảng: dev là “nút thắt cổ chai”, nên các bộ phận phía trước phải chuẩn bị đủ sâu, đủ rõ, đủ chi tiết rồi mới bàn giao.
AI đã làm rung chuyển xu hướng đó….
Khi lập trình viên có thể dùng AI để sinh mã, dựng màn hình, viết API, refactor logic, tạo test case hay thậm chí dựng nhanh một bản prototype chỉ trong vài giờ, thì công đoạn từng chậm nhất nay lại tăng tốc đột biến.
Năng lực sản xuất phần mềm không còn bị giới hạn như trước. Dev có thể đi rất nhanh. Thậm chí nhanh đến mức toàn bộ phần upstream của chuỗi giá trị bắt đầu lộ ra độ trễ của chính nó.
Ở đây, cần nhìn lại value stream phát triển phần mềm như một hệ thống hoàn chỉnh. Chuỗi này thường gồm năm lớp logic.
Lớp thứ nhất là khám phá vấn đề: hiểu người dùng là ai, nhu cầu nào đáng giải quyết, đâu là vấn đề thực và đâu chỉ là triệu chứng.
Lớp thứ hai là đặc tả nghiệp vụ: xác định mục tiêu, phạm vi, business rules, điều kiện biên, logic vận hành.
Lớp thứ ba là thiết kế trải nghiệm và giao diện: biến ý tưởng thành flow, thành cấu trúc màn hình, thành mô hình tương tác.
Lớp thứ tư là xây dựng giải pháp: code, tích hợp, cấu hình, kiểm thử kỹ thuật.
Lớp thứ năm là xác thực và tối ưu: UAT, đo phản hồi, phân tích hành vi, cải tiến sau triển khai.
Trong mô hình cũ, tốc độ giữa các lớp này chênh lệch không quá lớn. BA có thời gian viết tài liệu. UX/UI có thời gian nghiên cứu, wireframe, hi-fi design. Dev đi sau, nhận đầu vào tương đối đầy đủ rồi mới bắt tay làm. Toàn bộ chuỗi, dù có lúc chậm, vẫn giữ được một loại cân bằng vận hành nhất định.
## AI làm xuất hiện một điểm gãy đúng ở chỗ cân bằng đó…
Điểm AI mạnh nhất nằm ở lớp xây dựng giải pháp. Nó tăng tốc mạnh phần execution, tức phần biến ý tưởng thành hiện vật số. Một dev giỏi dùng AI hiện nay có thể dựng một giao diện CRUD rất nhanh, viết logic business phổ thông nhanh hơn trước nhiều lần, sinh skeleton cho backend, tạo unit test, viết migration script, rà lỗi cú pháp và thậm chí hỗ trợ debug ở tốc độ cao. Nói cách khác, AI đẩy mạnh năng lực “sản xuất”. Nhưng nó không tự động nâng cấp tương ứng năng lực “định nghĩa vấn đề” hay “kiến tạo trải nghiệm” ở cấp hệ thống. Chính ở đây, nghịch lý bắt đầu xuất hiện.
Khi coding trở nên quá nhanh, BA và UX/UI bỗng trở thành nút thắt mới. BA chưa kịp viết tài liệu thì dev đã sẵn sàng code. UX chưa kịp hoàn thiện flow thì dev đã hỏi API đâu, state thế nào, màn hình nào vào trước.
Nếu tổ chức vẫn giữ thói quen cũ là đòi BA phải viết rất chi tiết, UX/UI phải thiết kế rất đầy đủ rồi mới cho phát triển, thì hệ quả là dev có năng lực nhưng ngồi chờ. Tốc độ kỹ thuật tăng lên, nhưng tốc độ toàn hệ thống không tăng tương ứng. Thậm chí có nơi còn hỗn loạn hơn trước, vì phần nhanh nhất của hệ thống liên tục va vào phần chậm nhất.
Đây là một hiện tượng mang tính cấu trúc. Vấn đề không nằm ở chỗ BA yếu hơn hay UX chậm hơn. Vấn đề nằm ở việc kiến trúc vận hành của chuỗi phát triển phần mềm chưa được thiết kế lại để phù hợp với một môi trường mà chi phí build đã giảm mạnh nhờ AI.
Có thể hình dung bằng một ví dụ rất cụ thể. Trước đây, để làm một tính năng đặt món trong ứng dụng F&B, BA sẽ mất khoảng 1 tuần để viết yêu cầu, mô tả các trường hợp người dùng, logic giá, điều kiện áp mã giảm giá, trạng thái đơn hàng, ngoại lệ thanh toán. UX/UI sẽ tiếp tục mất thêm thời gian để vẽ flow chọn món, thêm topping, checkout, hiển thị lỗi, xác nhận đơn. Sau đó dev mới bắt đầu code. Cả quy trình đi tuần tự, nên không ai cảm thấy bất thường.
Nhưng nay, với AI hỗ trợ, một dev có thể dựng ngay bản demo flow đặt món trong một ngày, thậm chí nửa ngày. Nếu BA vẫn đang viết tài liệu theo logic cũ và UX vẫn đang cố “làm cho xong toàn bộ bộ màn hình” trước khi bàn giao, dev sẽ chờ. Hoặc nguy hiểm hơn, dev sẽ tự suy luận, tự lấp khoảng trống bằng giả định cá nhân. Bản build ra có thể đẹp, chạy được, nhưng sai ở tầng bản chất: sai user flow, sai logic nghiệp vụ, sai ưu tiên trải nghiệm, sai điều kiện vận hành thực tế. Như vậy, AI không làm tổ chức nhanh hơn một cách tự động. AI chỉ làm cho các điểm yếu của tổ chức lộ ra sớm và rõ hơn.
Điều này lý giải vì sao nhiều đội ngũ đang rơi vào một trạng thái rất lạ. Bề ngoài, năng suất kỹ thuật tăng. Nhưng bên trong, số lần sửa đi sửa lại cũng tăng. Tài liệu không còn theo kịp code. Thiết kế bị đuổi theo implementation. QA bị cuốn vào vòng kiểm tra những thứ chưa thật sự chốt. Stakeholder xem demo thì thích vì nhanh, nhưng khi đi sâu lại phát hiện hàng loạt khoảng trống. Hệ thống vận hành bắt đầu mất nhịp không phải vì thiếu năng lực, mà vì các mắt xích không còn đồng pha.
Từ đây, có thể thấy rất rõ đâu là điểm AI mạnh mẽ và đâu là giới hạn cần tỉnh táo. AI mạnh ở việc tăng tốc thực thi, giảm thời gian chuyển từ ý tưởng sang bản dựng, hạ chi phí làm thử, hỗ trợ kỹ thuật hóa nhanh một giả thuyết. Nhưng AI không tự giải quyết giúp tổ chức bài toán đồng thuận, bài toán lựa chọn đúng vấn đề cần giải, bài toán xây chuẩn trải nghiệm, hay bài toán ra quyết định chiến lược về sản phẩm. Nói đơn giản hơn, AI làm mạnh phần “làm”, nhưng không tự thay thế phần “nghĩ đúng” và “chọn đúng”.
Vì vậy, nếu tiếp tục giữ cách làm cũ, tức là yêu cầu BA phải cực kỳ chi tiết, UX/UI phải hoàn thiện đầy đủ, rồi mới cho dev bắt đầu, thì dự án đang dùng một mô hình vận hành được sinh ra cho thời kỳ chi phí build cao để quản trị một thực tại mới nơi chi phí build đã giảm rất sâu. Khi nền kinh tế của việc xây dựng thay đổi, mô hình điều phối cũng phải thay đổi theo. Đó là logic rất căn bản của quản trị hệ thống.
## Giải pháp nào cho xu hướng mới?
Từ góc nhìn này, giải pháp hợp lý không phải là ép BA và UX/UI chạy nhanh bằng mọi giá để đuổi theo dev. Giải pháp sâu hơn là phải thiết kế lại cách phối hợp giữa các vai trò.
Ở đây, đề xuất mà bạn đưa ra là một hướng rất đáng chú ý: thay vì BA đặc tả cực chi tiết và UX/UI vẽ mọi thứ từ đầu theo cách tuyến tính, tổ chức cần xây sẵn một bộ UI system đủ tốt, đủ chuẩn và đủ nhất quán; BA chỉ define ở mức logic cốt lõi, business rule chính và user flow trọng yếu; sau đó dev tận dụng design system cùng AI để code nhanh một bản demo chạy được; chính bản demo này sẽ trở thành công cụ để kiểm thử giả thuyết, thẩm định mức độ đáp ứng giải pháp, thực hiện demo với stakeholder hoặc thậm chí A/B test ở quy mô phù hợp.
Bản chất của cách làm này là gì? Đó là chuyển từ mô hình “phân tích & thiết kế thật kỹ rồi mới xây” sang mô hình “xây nhanh, sửa nhanh”. Thay vì dành phần lớn năng lượng để hoàn thiện tài liệu trước khi có bằng chứng, tổ chức dùng năng lực build nhanh của AI để biến giả thuyết thành hiện vật, rồi dùng phản hồi thực để tinh chỉnh. Khi đó, tài liệu không còn là mục tiêu tự thân. Tài liệu trở thành công cụ phục vụ cho việc ra quyết định, và chỉ cần chi tiết đến mức đủ để bảo toàn logic cốt lõi.
Trong mô hình này, vai trò của BA thay đổi trước tiên. BA không còn bị đẩy vào vị trí “người viết càng nhiều càng tốt”. Họ cần trở thành người xác định đúng vấn đề, đóng khung đúng bài toán, chỉ ra các business rule không thể vi phạm, nêu các giả thuyết cần kiểm chứng và làm rõ điều gì là bắt buộc, điều gì là có thể thử nghiệm. Giá trị của BA không còn nằm chủ yếu ở độ dày của tài liệu, mà nằm ở độ chính xác của tư duy nghiệp vụ và các nguyên tắc đảm bảo không lệch hướng.
Vai trò của UX/UI cũng thay đổi. UX/UI không còn gánh nhiệm vụ phải vẽ tất cả mọi khả năng trước khi có phản hồi thực tế. Thay vào đó, họ tập trung xây dựng design system, interaction pattern, nguyên tắc trải nghiệm, cấu trúc điều hướng, thành phần giao diện tái sử dụng và logic nhất quán toàn hệ thống. Khi phần này được chuẩn hóa tốt, việc thiết kế không còn là sản xuất từng màn hình thủ công từ đầu, mà là kiến trúc hóa trải nghiệm ở cấp hệ thống. Thậm chí UX có thể trở thành một đầu mối giao tiếp hiệu quả với khách hàng, users để thấu cảm và ra được các nguyên tắc, chiến lược tối ưu trải nghiệm. Đó là một bước trưởng thành quan trọng.
Vai trò của dev cũng thay đổi theo. Dev không chỉ là người nhận yêu cầu để code, mà trở thành người chuyển hóa giả thuyết thành demo với tốc độ cao. Nhưng tốc độ đó phải nằm trong khung chuẩn đã được xác lập: dùng đúng design system, đúng nguyên tắc sản phẩm, đúng tiêu chuẩn kỹ thuật, đúng dữ liệu giả lập phục vụ test. Nếu không có khung này, tốc độ của dev sẽ biến thành tốc độ tạo ra hỗn loạn.
Những nguyên tắc đảm bảo với giải pháp phát triển mới…
Giải pháp đề xuất vì vậy không thể chỉ hiểu đơn giản là “BA viết ít đi để dev code sớm hơn”. Nếu hiểu như vậy, mô hình sẽ đổ rất nhanh. Điều kiện tiên quyết là tổ chức phải có một số nguyên tắc đi kèm.
Thứ nhất là có design system đủ trưởng thành. Nếu không có một bộ UI system được chuẩn hóa, việc cho dev code demo sớm sẽ dẫn tới giao diện chắp vá, trải nghiệm thiếu nhất quán và chi phí sửa sau này rất lớn. Design system ở đây không chỉ là bộ màu, font hay button. Nó phải là một ngôn ngữ giao diện thống nhất, gồm component, pattern tương tác, rule hiển thị, hành vi trên mobile và desktop, trạng thái lỗi, trạng thái loading, trạng thái empty, các nguyên tắc accessibility ở mức phù hợp. Nói cách khác, system này phải đủ tốt để dev có thể build nhanh mà không phá vỡ bản sắc và chất lượng sản phẩm.
Thứ hai là BA phải biết define theo tầng. Có những thứ chỉ cần define ở mức giả thuyết để thử nhanh. Nhưng cũng có những thứ là business constraint, compliance rule, chính sách giá, logic doanh thu, nguyên tắc kiểm soát dữ liệu mà không thể để dev “đoán”. Nghệ thuật ở đây là phân biệt rất rõ phần nào cần mở cho thử nghiệm và phần nào là đường biên không được vượt qua. Nếu không làm rõ tầng này, bản demo rất dễ chạy được nhưng không dùng được.
Thứ ba là cần một cơ chế validate ngắn và rõ. Demo không thể chỉ để “cho vui” hay để tạo cảm giác tiến độ. Mỗi demo phải gắn với một câu hỏi cần trả lời. Chẳng hạn: người dùng có hiểu flow không; thao tác checkout có bị rối không; nhân sự vận hành có chấp nhận logic xử lý đơn này không; stakeholder có đồng thuận với thứ tự ưu tiên trên màn hình không; mức đáp ứng kỹ thuật có phù hợp để mở rộng tiếp không. Khi câu hỏi kiểm chứng rõ ràng, demo mới trở thành công cụ học tập của tổ chức, thay vì chỉ là sản phẩm trình diễn.
Thứ tư là cần thay đổi hệ thống đánh giá hiệu suất. Nếu vẫn đo hiệu quả bằng số lượng tài liệu hoàn thiện hoặc số story closed theo kiểu cơ học, tổ chức sẽ vô thức kéo mọi người quay lại mô hình cũ. Trong bối cảnh mới, chỉ số quan trọng hơn phải là tốc độ học của hệ thống: từ ý tưởng đến demo mất bao lâu, từ demo đến quyết định mất bao lâu, tỷ lệ rework sau khi đã validate là bao nhiêu, mức độ nhất quán trải nghiệm được giữ ở đâu, số giả định được kiểm chứng mỗi chu kỳ là bao nhiêu. Khi cách đo thay đổi, hành vi làm việc mới thực sự thay đổi.
Một số giả định hiệu quả và những thách thức đặt ra…
Nếu làm tốt, mô hình này mang lại nhiều lợi thế rất đáng kể.
Thứ nhất, nó tận dụng đúng thế mạnh của AI: build nhanh để học nhanh.
Thứ hai, nó giảm lãng phí tài liệu và thiết kế quá chi tiết khiến Dev bị “ngồi chơi”.
Thứ ba, nó khiến stakeholder tham gia sớm hơn, vì phản hồi trên một thứ đang chạy được luôn chất lượng hơn phản hồi trên tài liệu chữ hoặc ảnh tĩnh.
Thứ tư, nó ép tổ chức trưởng thành hơn ở năng lực chuẩn hóa hệ thống giao diện và năng lực tư duy vấn đề ở BA. Thứ năm, nó giúp giảm rủi ro “xây đúng thứ sai”, vốn là dạng lãng phí đắt đỏ nhất trong phát triển sản phẩm.
Tuy nhiên, nhược điểm cũng cần được nhìn thẳng. Nếu đội ngũ chưa có design system tốt, chưa có product principle rõ, chưa có người giữ trục logic sản phẩm, thì cách làm này rất dễ biến thành phát triển cảm tính. Dev sẽ demo rất nhanh nhưng mỗi lần demo lại là một nhánh khác nhau. Stakeholder sẽ phản hồi theo cảm xúc nhất thời. UX/UI bị kéo vào vai trò dọn dẹp hậu quả. BA bị biến thành người chạy theo giải thích những thứ đáng ra phải được định nghĩa ngay từ đầu. Khi đó, cái gọi là linh hoạt chỉ là hỗn loạn được gọi bằng một cái tên đẹp hơn.
Vì vậy, bài toán không nằm ở việc chọn giữa tài liệu chi tiết hay code sớm. Bài toán thật sự nằm ở việc tái cấu trúc value stream phát triển phần mềm sao cho phù hợp với thời đại AI. Khi coding không còn là điểm chậm nhất, tổ chức không thể tiếp tục điều phối mọi thứ như thể coding vẫn là nút thắt trung tâm. Phần cần nâng cấp lúc này là upstream operating model: cách BA define, cách UX systemize, cách dev build, cách stakeholder validate và cách cả hệ thống học cùng nhau.
Nhìn ở tầng sâu hơn, đây là một thay đổi mang tính triết lý sản phẩm. Mô hình cũ đặt niềm tin vào việc con người có thể nghĩ đủ đúng trước khi xây. Mô hình mới thừa nhận rằng trong môi trường bất định, con người thường chỉ hiểu sâu hơn sau khi nhìn thấy thứ gì đó đang hoạt động. Vì thế, thay vì cố hoàn hảo hóa tư duy trước khi hành động, tổ chức cần học cách tạo ra những hiện vật đủ đúng, đủ nhanh, đủ kiểm soát để suy nghĩ tốt hơn từ chính phản hồi thực tế.
Đó là lý do giải pháp “BA define cơ bản, dùng design system có sẵn, dev code nhanh bản demo để test và thẩm định ” không chỉ là một mẹo tăng tốc. Nếu được triển khai đúng, nó là một mô hình vận hành mới cho phát triển sản phẩm trong kỷ nguyên AI. Một mô hình trong đó tài liệu không biến mất, nhưng được viết đúng mức. Thiết kế không mất vai trò, nhưng được nâng lên cấp hệ thống. Dev không chỉ code nhanh hơn, mà trở thành công cụ giúp tổ chức học nhanh hơn. Và AI, thay vì chỉ là công cụ sinh mã, trở thành lực đẩy buộc toàn bộ chuỗi giá trị phát triển phần mềm thay đổi.
Trên đây là một vài suy nghĩ, phân tích của mình, ý tưởng thoáng qua mình nghĩ đến, có thể có những tác giả cũng đã có nghiên cứu sâu hơn về nó hãy comment để cùng thảo luận thêm nhé.
Cảm ơn các đọc giả 