Có những yêu cầu nghe rất ngắn, rất nhẹ, tưởng như chỉ cần bắt tay vào làm ngay.
"Viết giúp mình một bài."
"Làm màn hình này đẹp hơn."
"Tối ưu workflow này cho gọn lại."
Trước đây, mình dễ thấy những câu như vậy là đủ để bắt đầu. Mình nghĩ nhanh một chút cũng tốt. Có bản nháp trước rồi sửa sau. Có gì chưa rõ thì trong lúc làm sẽ tự lộ ra.
Nhưng càng học về sản phẩm, UX/UI, Business Analysis và cách làm việc với AI, mình càng thấy một điều ngược lại: yêu cầu càng ngắn không có nghĩa là yêu cầu càng rõ.
Đôi khi nó chỉ đang giấu rất nhiều giả định bên trong.
Người viết bài này cho ai? "Đẹp hơn" là đẹp theo gu nào, phục vụ hành vi nào? "Gọn lại" là bớt bước cho người dùng, bớt thao tác cho team vận hành, hay bớt phức tạp trong code?
Nếu mình vội làm ngay, mình có thể làm rất chăm chỉ. Nhưng chăm chỉ không cứu được một đề bài bị hiểu sai từ đầu.
Nhanh quá đôi khi chỉ làm sai nhanh hơn
AI làm chuyện này càng rõ hơn.
Chỉ cần một prompt ngắn, AI có thể trả về một bản nháp rất mượt. Một bài viết có mở bài, thân bài, kết luận. Một danh sách user stories nghe khá hợp lý. Một màn hình có layout sạch sẽ. Một email lịch sự hơn bản mình tự viết lúc đang mệt.
Nhìn vào đó, mình dễ có cảm giác công việc đã đi được nửa đường.
Nhưng nếu đề bài ban đầu mơ hồ, sự mượt mà đó có thể đánh lừa mình. Một câu trả lời trôi chảy vẫn có thể sai trọng tâm. Một bản thiết kế nhìn ổn vẫn có thể không giải quyết đúng vấn đề. Một brief nghe chuyên nghiệp vẫn có thể thiếu điều quan trọng nhất: mình đang làm việc này để đạt mục tiêu gì?
AI không tự biết bối cảnh thật của mình. Teammate cũng không thể đoán hết điều mình chưa nói ra. Ngay cả chính mình, nếu không dừng lại để viết rõ hơn, cũng có thể tưởng rằng mình hiểu yêu cầu chỉ vì nó quen tai.
Mình bắt đầu nhận ra tốc độ chỉ có ý nghĩa khi hướng đi đã tương đối đúng.
Nếu chưa biết đang đi đâu, đi nhanh hơn đôi khi chỉ làm mình xa điểm cần đến hơn.
Một brief rõ không cần dài
Mình từng nghĩ brief rõ là một tài liệu rất dài, nhiều mục, nhiều thuật ngữ và nhìn hơi "người lớn". Nhưng thật ra, một brief tốt không nhất thiết phải phức tạp.
Nó chỉ cần có đủ điểm tựa để người làm không phải đoán quá nhiều.
Hiện tại, khi gặp một yêu cầu còn lỏng, mình thường tự hỏi năm câu rất cơ bản:
- Mục tiêu thật sự là gì? Mình đang cần tạo nhận thức, thuyết phục, giải thích, bán hàng, tiết kiệm thời gian, hay giảm lỗi?
- Người đọc hoặc người dùng là ai? Họ đã biết gì, đang cần gì, đang sợ gì, và sẽ dùng kết quả này trong tình huống nào?
- Bối cảnh hiện tại ra sao? Đây là việc mới hoàn toàn, cải thiện một thứ đã có, hay sửa một vấn đề đang gây khó chịu?
- Có ràng buộc nào không? Giọng văn, deadline, dữ liệu bắt buộc, nền tảng xuất bản, giới hạn kỹ thuật, điều không được nhắc tới?
- Thế nào là xong hoặc tốt? Khi nhìn kết quả cuối, dấu hiệu nào cho thấy nó đã đạt yêu cầu?
Năm câu này nghe đơn giản, nhưng mỗi lần trả lời nghiêm túc, mình thấy đề bài bớt mờ đi rất nhiều.
Ví dụ, "viết giúp mình một bài về AI" là một yêu cầu rất rộng. Nhưng nếu đổi thành: "viết một bài blog cá nhân bằng giọng gần gũi, cho các bạn trẻ đang học công nghệ, nói về cách dùng AI để học nhanh hơn mà vẫn giữ tư duy độc lập", công việc lập tức dễ đi đúng hướng hơn.
Nó chưa cần hoàn hảo. Nhưng nó đã có mục tiêu, người đọc, góc nhìn, giọng văn và ranh giới.
Với mình, đó là khác biệt giữa một câu nhờ vả và một brief có thể thực hiện.
Hỏi lại không phải làm khó
Có một thời gian mình hơi ngại hỏi lại.
Mình sợ người khác nghĩ mình chậm hiểu. Sợ làm cuộc trò chuyện dài hơn. Sợ câu hỏi của mình nghe quá cơ bản. Sợ nếu mình hỏi nhiều, người giao việc sẽ thấy mình chưa đủ năng lực.
Nhưng sau này mình thấy hỏi lại không phải là chống đối yêu cầu. Hỏi lại là một cách chăm sóc kết quả.
Khi mình hỏi: "Bài này viết cho ai đọc?", mình không làm khó người nhờ. Mình đang cố không viết một bài đúng ngữ pháp nhưng sai người đọc.
Khi mình hỏi: "Bạn muốn màn hình này đẹp hơn theo hướng tối giản, thân thiện, hay chuyên nghiệp hơn?", mình không bắt bẻ chữ "đẹp". Mình đang giúp cả hai bên tránh sửa qua sửa lại vì mỗi người tưởng tượng một kiểu khác nhau.
Khi mình hỏi: "Nếu chỉ được giữ một thông điệp chính, bạn muốn người đọc nhớ điều gì?", mình không làm chậm bài viết. Mình đang tìm trục để bài viết không bị lan man.
Hỏi đúng câu đôi khi tiết kiệm nhiều thời gian hơn làm ngay.
Vì sửa một giả định sai ở đầu thường nhẹ hơn sửa một sản phẩm đã đi gần xong.
Dùng AI như người giúp mình nghĩ rõ hơn
Điều mình thích ở AI không chỉ là nó có thể viết nhanh. Điều mình thấy hữu ích hơn là nó có thể giúp mình nhìn ra chỗ mình chưa rõ.
Thay vì bắt đầu bằng prompt: "Làm giúp mình", mình đang tập bắt đầu bằng những câu như:
- "Hãy hỏi mình những câu còn thiếu để làm rõ yêu cầu này."
- "Hãy chỉ ra các giả định mơ hồ trong brief này."
- "Nếu bạn là BA/Product Designer, bạn cần hỏi thêm gì trước khi thực hiện?"
- "Hãy biến ghi chú lộn xộn này thành một brief rõ, nhưng đừng tự bịa dữ liệu còn thiếu."
Cách hỏi này làm AI trở thành một người đồng hành trong phần suy nghĩ, không chỉ là một máy tạo bản nháp.
Nó cũng buộc mình thành thật hơn với chính mình. Nếu mình không biết người đọc là ai, mình phải thừa nhận là mình chưa biết. Nếu mình chưa có ví dụ thật, mình phải ghi rõ đó là phần cần bổ sung. Nếu mình đang dùng từ rất chung như "hay hơn", "xịn hơn", "tối ưu hơn", mình phải kéo nó xuống mặt đất bằng tiêu chí cụ thể hơn.
Mình thấy kỹ năng này rất gần với Business Analysis.
BA không chỉ ghi lại yêu cầu. BA giúp yêu cầu trở nên có thể hiểu, có thể trao đổi, có thể kiểm tra và có thể thực hiện. Product thinking cũng vậy: trước khi lao vào giải pháp, mình cần hiểu vấn đề, người dùng, bối cảnh và cách biết mình đã giải quyết đúng.
AI có thể hỗ trợ mạnh ở phần diễn đạt, tổng hợp và gợi ý cấu trúc. Nhưng phần chịu trách nhiệm với câu hỏi vẫn là của mình.
Brief rõ là một món quà nhỏ
Mình không nghĩ lúc nào cũng cần một quy trình thật nặng. Có những việc nhỏ chỉ cần vài dòng là đủ. Có những cuộc trò chuyện chỉ cần hỏi thêm một câu là sáng ra.
Nhưng mình muốn bớt xem sự mơ hồ là chuyện bình thường phải chịu.
Một yêu cầu rõ hơn là món quà nhỏ cho người thực hiện, vì họ không phải đoán quá nhiều.
Nó là món quà cho người nhận kết quả, vì thứ họ nhận được gần hơn với điều họ thật sự cần.
Và nó cũng là món quà cho chính mình sau này, vì khi nhìn lại, mình hiểu vì sao mình đã chọn hướng đó, đã bỏ qua hướng kia, và thế nào là hoàn thành.
Mình vẫn đang học cách hỏi rõ hơn. Có lúc vẫn hỏi thiếu. Có lúc vẫn vội. Có lúc vẫn thấy một yêu cầu quen quá nên tưởng mình đã hiểu.
Nhưng ít nhất bây giờ, trước khi bắt đầu làm, mình thường dừng lại một nhịp và tự hỏi:
"Mình đang có một yêu cầu thật sự rõ, hay chỉ có một câu nghe có vẻ dễ?"
Nhiều khi, chính một nhịp dừng đó làm công việc tử tế hơn.