Sep 2026
✍️ Hana · 🗓️ Tháng 9/2026 📚 Series: Mindset 🔢 Order: 2
Poster workshop Requirement Clarification, GreenNode Internship Program 2026
Ngày 12/08 vừa rồi mình đứng một buổi training nội bộ cho 24 bạn vừa vào GreenNode theo chương trình Internship Program 2026. Chủ đề: Requirement Clarification. Trên poster có một câu mình rất thích, và cũng là thứ mình muốn các bạn nhớ nhất: right action needs right understanding, right understanding needs right questions.
Mình soạn buổi này theo hướng ít giảng, nhiều hoạt động. Phần lý thuyết chỉ đủ để gọi tên thứ các bạn vừa trải qua, còn lại là bài tập và câu hỏi ném ngược về phía các bạn. Ngồi nghe thì dễ gật, tự làm mới thấy mình hụt chỗ nào.
Nên mình mở màn bằng một bài khởi động. Luật đơn giản: mỗi người một tờ giấy, hai phút, viết tay, không bàn bạc. Liệt kê càng nhiều công dụng của cây bút chì càng tốt. Ai nhiều nhất có quà.
Cả phòng bắt tay vào viết ngay.
Hai phút sau mình chuyển slide. Trên đó là đề bài thật:
"Con tôi 3 tuổi. Tôi cần một thứ để bé tập cầm nắm và tô màu."
Và một dòng nữa: mình chính là khách hàng.
Không ai hỏi mình câu nào trong suốt hai phút đó. Mà mình thì ngồi ngay trong phòng.
Hana đứng lớp buổi Requirement Clarification cho intern GreenNode, các bạn làm bài tập trên giấy A3
Phần lý thuyết mình mượn Golden Circle của Simon Sinek, chia thành ba vòng: WHY, WHAT, HOW.
HOW là kiến trúc, code, thư viện, deadline. Đó là việc của dev, và cũng là chỗ dân tech hay nhảy thẳng vào. Nhận ticket, đọc xong, mở IDE.
WHY nằm trong cùng: vấn đề này của ai, không làm thì sao, đo thành công bằng gì. WHAT ở giữa: cụ thể cần gì, và cái gì không làm.
Mình chốt phần này bằng một câu:
Code sai thì fix được. Hiểu sai thì làm lại từ đầu.
Cây bút chì hồi nãy cũng vậy thôi. Ai cũng liệt kê được cả chục công dụng, nghĩa là năng lực không thiếu. Cái thiếu là một câu hỏi rất ngắn ở đầu: anh chị cần nó để làm gì, cho ai.
Đây là phần mình đầu tư nhiều thời gian nhất khi soạn, vì nó không phải vấn đề kỹ năng. Ai cũng biết nên hỏi. Nhưng tới lúc ngồi trong phòng họp thì im.
Mình liệt kê bốn lý do hay gặp, kèm câu trả lời cho từng cái.
"Hỏi vậy lộ ra mình không hiểu gì." Người không hỏi mới lộ, sau hai tuần code sai hướng.
"BA với manager bận lắm, hỏi làm phiền." Mười phút của họ hôm nay đổi được ba ngày của bạn tuần sau.
"Ticket viết rõ rồi mà." Ticket viết rõ cái phải làm. Nó hiếm khi viết vì sao.
"Chắc ý anh ấy là vậy." Chữ "chắc là" có lẽ là từ đắt tiền nhất trong ngành phần mềm.
Rồi mình vẽ chi phí sửa một hiểu lầm theo bốn mốc: lúc hỏi, lúc code, lúc test, lúc lên production. Cột sau luôn cao hơn cột trước. Mình có nói rõ với các bạn đó là hình minh hoạ chứ không phải số liệu đo được, nhưng ai đi làm rồi cũng biết hình dạng của nó đúng.
Câu mình để cuối phần này: câu hỏi ngu duy nhất là câu bạn hỏi sau khi đã code xong hai tuần.
Hana chỉ vào màn hình trình chiếu trong buổi workshop
Thứ tự mình đưa ra rất đơn giản. WHY hỏi trước, luôn luôn: nếu mình không làm cái này thì chuyện gì xảy ra, ai đang gặp khó, họ đang xoay xở bằng cách nào. WHAT hỏi thứ hai: cho em một ví dụ thật, và cái gì không nằm trong scope lần này. HOW hỏi sau cùng, vì đó mới là phần của mình.
Trước đó mình cũng nói với các bạn thứ tự tìm câu trả lời: tự tra trước, hỏi AI, rồi mới hỏi người. Hỏi người là bước cuối chứ không phải bước đầu, nhưng nó vẫn phải xảy ra.
Còn kỹ thuật mình muốn các bạn mang về nhất thì chỉ có một, và nó là một câu điền vào chỗ trống:
"Em hiểu là mình làm ____ để ____ có thể ____, đo bằng ____. Đúng không ạ?"
Playback. Nói lại điều mình vừa nghe bằng chữ của mình rồi hỏi ngược lại. Điền được hết bốn chỗ trống nghĩa là bạn thật sự hiểu. Điền tới chỗ thứ ba mà khựng thì đó chính là câu hỏi tiếp theo bạn cần hỏi.
Kỹ năng này mình dùng gần như mỗi ngày, và nó cũng là thứ nằm sau mọi bản PRD mình viết.
Phần thực hành mình để bốn phút. Ba người một nhóm, đề bài là một ticket đúng kiểu ngoài đời:
Ticket #3037: "Thêm chức năng Log History cho user."
Nhiệm vụ: viết ra ba câu hỏi bạn sẽ hỏi trước khi viết dòng code đầu tiên. Luật duy nhất là viết câu hỏi, không viết giải pháp. Sau đó mình gọi ngẫu nhiên ba nhóm đọc to.
Cái luật "không viết giải pháp" nghe nhỏ mà khó hơn mọi người tưởng. Nhận một ticket mơ hồ, phản xạ đầu tiên của người làm kỹ thuật là bắt đầu thiết kế trong đầu. Bắt tay giữ lại phản xạ đó bốn phút để chuyển sang chế độ hỏi, đó mới là bài tập thật.
Phần này mình cũng không giảng trước. Mình ném ra một câu hỏi mở rộng cho cả phòng nghĩ: bạn sẽ làm gì khi đang chạy dở sprint thì có yêu cầu mới nhảy vào? Đây là chuyện sẽ xảy ra với các bạn trong vài tuần tới thôi, nên để các bạn tự nghĩ trước sẽ thấm hơn nghe mình đọc đáp án.
Nghĩ xong rồi mình mới đưa công thức: đừng nói không, cũng đừng gật đầu. Hỏi ba câu.
Cái này phục vụ WHY nào? Không trả lời được thì yêu cầu đó chưa đủ chín để làm.
So với việc em đang làm thì cái nào quan trọng hơn? Câu này đẩy quyền ưu tiên về đúng người có quyền quyết.
Nếu thêm cái này thì mình hoãn cái gì lại? Câu này biến "thêm việc" thành một lựa chọn có giá.
Bạn không từ chối ai cả. Bạn chỉ hỏi đổi cái gì.
Kèm theo là ba thứ tối thiểu cần có trong cách làm việc: ưu tiên impact cao effort thấp, ghi lại mọi thay đổi ở nơi cả team nhìn thấy, và viết Definition of Done ra trước khi bắt đầu chứ không phải lúc sắp giao.
Mình không muốn các bạn ra khỏi phòng với một mớ mô hình. Nên phần đúc kết chỉ có một việc để làm từ ngày mai.
Trước khi code bất kỳ ticket nào, dành 5 phút viết ba dòng. WHY: vấn đề này của ai, không làm thì sao. WHAT: cụ thể làm gì, cái gì không làm. DONE: thế nào là xong, đo bằng gì.
Rồi gửi ba dòng đó cho người giao việc kèm một câu: "Em hiểu vậy đúng chưa ạ?"
Năm phút đó bắt lỗi hiểu lầm lúc nó còn miễn phí. Nó cũng làm người giao việc thấy bạn là người nghĩ cùng chứ không phải người nhận việc. Và khi yêu cầu đổi ba tuần sau, bạn có một bản ghi để đối chiếu, không cần cãi ai.
Xong phần training, mình nhường ghế cho hai anh khách mời: anh Nguyễn Duy Vũ, System R&D Manager, và anh Nguyễn Trung, SRE Manager. Hai anh ngồi lại để các bạn hỏi thoải mái về chuyện đi làm thật ở GreenNode.
Mình thích cách xếp này. Mình vừa dành cả buổi nói với các bạn rằng hỏi là việc nên làm, rằng mười phút của người có kinh nghiệm đổi được ba ngày của mình. Nói xong mà không cho các bạn một chỗ để hỏi ngay thì cũng chỉ là lý thuyết.
Nên phần cuối buổi, các bạn được thực hành đúng thứ vừa học, với hai người thật, về công việc thật của chính các bạn trong vài tháng tới.
Chụp hình cùng 24 bạn intern GreenNode sau buổi workshop, whiteboard phía sau còn nguyên phần WHY và WHAT
Soạn xong buổi này mình nhận ra một chuyện hơi ngược.
Mình từng bực khi nhận lại một tính năng làm sai ý, kiểu sao lúc đó em không hỏi. Nhưng nhìn lại bốn lý do khiến người ta im lặng thì ba trong số đó không nằm ở phía các bạn. Ticket không viết WHY là ticket của mình viết. Chuyện "hỏi làm phiền" phụ thuộc vào mình trả lời nhanh hay chậm, và mình phản ứng thế nào lần trước.
Nghĩa là muốn người ta hỏi nhiều hơn, việc hỏi phải rẻ đi. Người làm cho nó rẻ là mình chứ không phải các bạn intern.
Buổi trước mình đi nói về MCP cho hơn 30 bạn BA, buổi này nói về đặt câu hỏi cho 24 bạn mới vào nghề. Hai chủ đề khác hẳn nhau mà rốt cuộc rơi về cùng một chỗ: công cụ đổi liên tục, phần khó vẫn là hiểu đúng người ta cần gì trước khi bắt tay làm.
Người ta không im lặng vì lười hỏi. Người ta im vì hỏi thấy đắt hơn đoán. Muốn team hỏi nhiều hơn thì hạ giá câu hỏi xuống trước đã.
Cái ticket gần nhất bạn giao đi - trong đó có dòng nào nói vì sao cần làm không?
Hai buổi gần đây mình đều đứng lớp. Lần này thì ngược lại: VNG mở AI Innovation & Efficiency Workshop, trainer là anh Richard Chang từ Tencent Academy, và ...
Tối thứ Năm 23/07/2026, mình chia sẻ ở một buổi talkshow do BAC tổ chức, tên là BA × AI × MCP - Chuyển mình trước làn sóng AI Agent. Một tiếng, trên Zoom, ...
Cách đây mấy tuần, có bạn BA mới vào nghề đang làm bài toán onboarding partner cho một platform ecommerce. Bạn vẽ một cái BPMN 10 bước - hai swimlane, part...