Kỷ nguyên vibe coding đẩy vấn đề này lên mức độ mới
Nếu bạn đang là developer trong 2025-2026, bạn đang sống trong kỷ nguyên mà AI có thể generate code nhanh hơn bạn gõ phím. Vibe coding – mô tả yêu cầu bằng tiếng Anh, AI ra code – đang trở thành workflow phổ biến.
Vấn đề là: AI sẽ build đúng cái bạn mô tả. Không hơn, không kém. Nếu bạn mô tả sai – AI build nhanh cái sai đó cho bạn.
Trước đây, khi developer còn phải gõ từng dòng code thủ công, bạn có nhiều cơ hội "ngẫm" trong lúc code: "Ủa, cái này có đúng với business không nhỉ?" Bây giờ, khi AI generate cả một cái form trong 30 giây, bạn review xong ấn Enter – và 30 phút sau mới phát hiện mình đang build sai feature.
Tốc độ tăng. Khoảng trống trong yêu cầu cũng tăng tương ứng.
Một bài nghiên cứu từ dev.to mà tôi đọc gần đây có câu rất đắt: "The core skill is shifting from 'how to write code' to 'how to solve problems using code.' AI handles the 'how.' You need to own the 'what' and the 'why.'"
AI lo cái "how". Developer phải lo cái "what" và "why". Mà cái "what" và "why" chính là công việc của BA.
Kỹ năng BA cho developer: không phải để lên chức
Mỗi lần tôi nói với một developer rằng "bạn cần học kỹ năng BA", phản ứng đầu tiên thường là: "Ồ, vậy là em sắp chuyển sang làm BA à?"
Không. Học kỹ năng BA không có nghĩa là bạn sẽ thôi là developer. Giống như học kỹ năng đọc tài liệu tiếng Anh không có nghĩa là bạn sẽ trở thành phiên dịch viên.
Đây là những kỹ năng BA mà developer cần học chủ động – không phải để trở thành BA, mà để build đúng thứ ngay từ đầu.
1. Biết đặt câu hỏi "But WHY?"
Yêu cầu từ stakeholder thường đến ở dạng solution, không phải dạng problem.
"Tôi muốn thêm nút export Excel" – đây là solution. Bạn cần hỏi: tại sao cần export? Để làm gì? Ai sẽ dùng file này? Có cần format đặc biệt không?
Technique tôi hay dùng là 5 Whys – hỏi "tại sao" 5 lần liên tiếp cho đến khi tìm ra root need. Thường đến câu hỏi thứ 3 hoặc 4, bạn đã thấy rằng cái người ta muốn hoàn toàn khác với cái người ta nói ban đầu.
Ví dụ thực tế từ dự án của tôi:
- "Tôi muốn export Excel" → Tại sao? "Để gửi cho kế toán"
- Tại sao gửi cho kế toán? "Để họ reconcile với hệ thống của họ"
- Tại sao phải reconcile thủ công? "Vì hai hệ thống không sync tự động"
- Tại sao không sync tự động? "Vì chưa có API kết nối"
Và bây giờ bạn thấy vấn đề thật: không phải "thiếu nút export Excel" mà là "hai hệ thống không có integration". Solution thật sự có thể là API integration – không phải Excel export.
Nếu dev của tôi nhảy vào code "nút export Excel" ngay sau khi nghe yêu cầu đầu tiên, anh ấy đang giải quyết triệu chứng, không phải bệnh.
2. Viết user story – không phải để làm BA, mà để clarify với chính mình
User story format: "As a [user], I want [feature] so that [benefit]."
Tôi biết nhiều developer nghe xong sẽ nghĩ: "Viết cái đó làm gì, tốn thêm thời gian."
Thật ra, viết user story buộc bạn xác định được ba thứ quan trọng trước khi code:
- Who – ai là người dùng thật sự? (Kế toán hay sales manager? Câu trả lời ảnh hưởng hoàn toàn đến UX)
- What – họ muốn làm được cái gì cụ thể?
- Why – benefit là gì? (Nếu bạn không mô tả được benefit, có thể feature này không cần thiết)
Lần đầu tôi yêu cầu team developer tự viết user story trước khi code, không khí trong phòng khá căng. Vài người tỏ ra không hài lòng: "Đây không phải việc của mình." Nhưng sau sprint đầu tiên làm thử, chính ông dev hay phàn nàn nhất đó nói với tôi: "Hóa ra tôi đã build cả năm mà không biết khách hàng dùng feature mình làm để làm gì."
3. Viết acceptance criteria – để biết khi nào thì "xong"
Đây là cái developer thường bỏ qua nhất. Và đây cũng là nguyên nhân hàng đầu của kiểu lúng túng: "Em tưởng xong rồi mà."
Acceptance criteria trả lời câu hỏi: feature này được gọi là "done" khi nào?
Format EARS (Agile requirements) mà tôi hay dùng: "WHEN [condition], the system SHALL [behavior]."
Ví dụ:
- WHEN user nhập email không đúng format, the system SHALL hiển thị thông báo lỗi cụ thể và KHÔNG cho phép submit form.
- WHEN user đã đăng nhập, the system SHALL hiển thị tên user ở góc phải header.
- WHEN file upload lớn hơn 5MB, the system SHALL từ chối và hiển thị thông báo giới hạn dung lượng.
Không cần phải viết dài dòng. Nhưng ít nhất phải viết đủ để cả developer lẫn tester lẫn product owner nhìn vào đều đồng ý "điều kiện này pass = feature done".
Một bài viết về spec-driven workflow tôi đọc gần đây có nhận xét thú vị: "AI expands scope by default. The line you do not draw is the line AI will cross." Acceptance criteria chính là cái "line" bạn vẽ ra để AI – và chính bạn – không đi lạc.
4. Phân biệt functional requirements và non-functional requirements
Functional: hệ thống làm được gì?
Non-functional: hệ thống làm điều đó như thế nào, với chất lượng ra sao?
Nhiều developer chỉ nghĩ đến functional. Nhưng stakeholder thường bực bội vì non-functional: "Sao load chậm vậy?" "Sao không có thông báo khi có lỗi?" "Sao mobile trông khác desktop vậy?"
Kỹ năng BA cho developer ở điểm này là: khi nhận yêu cầu, chủ động hỏi về non-functional ngay từ đầu. Performance như thế nào là chấp nhận được? Cần support browser nào? Data retention policy ra sao?
Cách bắt đầu học BA skills khi bạn đang là developer
Tôi không nói bạn phải đọc sách BABOK hay đi học certification BA. Tôi nói bạn có thể bắt đầu ngay từ sprint tiếp theo.
Thứ nhất: Trước khi code bất kỳ feature nào, tự viết một câu user story. Dù không ai yêu cầu. Dù chỉ để ghi chú cho mình. Nếu bạn không viết được user story, đó là dấu hiệu bạn chưa hiểu đủ để code.
Thứ hai: Thực hành 5 Whys trong những cuộc meeting nhận yêu cầu. Không cần phải hỏi đủ 5 lần. Hỏi 2-3 lần thôi cũng đã khác rất nhiều.
Thứ ba: Sau mỗi feature, ngồi lại với người dùng thật hoặc BA/PM và hỏi: "Anh/chị dùng cái này thường làm gì?" Bạn sẽ bất ngờ vì nhiều thứ bạn tưởng là quan trọng – không ai dùng. Nhiều thứ bạn bỏ qua – họ cần hàng ngày.
Thứ tư: Tham gia vào những cuộc gọi với stakeholder nếu có thể, dù bạn không được "mời chính thức". Nghe trực tiếp business nói về vấn đề của họ là cách học nhanh nhất để hiểu context.
Một điều tôi quan sát sau nhiều năm: developer nào tham gia nhiều vào discovery phase – dù chỉ là ngồi nghe – thường build ra sản phẩm tốt hơn. Không phải vì họ code giỏi hơn. Mà vì họ hiểu tại sao mình code cái này.
Không phải lên chức – mà là build đúng thứ
Đây là điều tôi muốn các bạn developer nhớ nhất.
Trong 20 năm làm PM/BA, tôi chứng kiến nhiều dự án thất bại không phải vì developer không giỏi. Mà vì developer giỏi build sai thứ. Những anh chị senior code rất đẹp, rất chuẩn pattern, test coverage cao – nhưng feature xong ra thì không ai dùng.
Và tôi cũng chứng kiến những developer bình thường build ra product tuyệt vời, chỉ vì họ dành thời gian đặt câu hỏi đúng trước khi code.
Trong kỷ nguyên AI, khoảng cách này sẽ càng rõ hơn. AI giúp tất cả mọi người code nhanh hơn. Nhưng AI không thể thay bạn ngồi giao tiếp với stakeholder, hiểu nỗi đau thật của họ, và xác định đúng thứ cần build.
Đó là lý do tại sao tôi nói: great products come from great conversations. Không phải từ great code. Code là phương tiện. Conversation là nơi sản phẩm tốt được sinh ra.
Bạn không cần lên chức làm BA để học những kỹ năng đó. Bạn có thể học ngay hôm nay, từ sprint tiếp theo, từ ticket tiếp theo bạn được assign.
Bạn đã từng build xong một feature rồi mới phát hiện ra mình hiểu sai yêu cầu chưa? Cảm giác đó như thế nào, và bạn làm gì để tránh lần sau?
Tôi muốn nghe câu chuyện của bạn.
/My Ha – Great products come from great conversations
\#1percentbetter #productmanagement #businessanalysis #agile #careercraft
