Câu 1
Bạn nên hỏi gì đầu tiên?
- このチケットの範囲を確認させてください。
- このチケットはできません。
- すぐに全部直します。
Xem đáp án
Đáp án: このチケットの範囲を確認させてください。
Câu này mở phần xác nhận scope trước khi nhận định deadline hoặc bắt tay code.
Lộ trình tiếng Nhật IT - Tuần 1
Kiểm tra tuần 1: ticket, spec, bug và daily
Kiểm tra 7 ngày đầu của lộ trình tiếng Nhật IT: hỏi scope, priority, spec, bug report và daily blocker.
Chuẩn đầu ra tuần 1
Biết hỏi lại trước khi code, báo bug có căn cứ và nói daily report theo cấu trúc ngắn.
Nếu chưa đạt, quay lại bài học hoặc tình huống tương ứng trước khi mở thêm bài mới.
Câu hỏi tình huống tổng hợp
Đọc lựa chọn, tự trả lời trong đầu rồi mở giải thích
Câu 2
Muốn hỏi rule cho pending, chọn câu nào?
- pendingの場合も同じ文言を表示する理解で合っていますか。
- pendingは何ですか。
- pendingを消します。
Xem đáp án
Đáp án: pendingの場合も同じ文言を表示する理解で合っていますか。
Câu này nêu giả thuyết implementation để người phụ trách chỉ cần xác nhận hoặc sửa.
Câu 3
Expected/actual nên nói thế nào?
- 期待結果は保存成功ですが、実際は500エラーになります。
- 期待はいいです。実際はだめです。
- 結果は変です。
Xem đáp án
Đáp án: 期待結果は保存成功ですが、実際は500エラーになります。
Câu này tách rõ expected và actual, giúp PM hoặc QA hiểu lỗi nhanh.
Câu 4
影響範囲 nghĩa là gì?
- Phạm vi ảnh hưởng
- Câu hỏi spec
- Giờ daily meeting
Xem đáp án
Đáp án: Phạm vi ảnh hưởng
影響範囲 giúp người Nhật đánh giá severity và cần thông báo cho ai.
Câu 5
Muốn nhờ trả lời trong chiều nay, câu nào lịch sự?
- 午後までに回答をいただけると助かります。
- 午後までに答えてください。
- 今すぐお願いします。
Xem đáp án
Đáp án: 午後までに回答をいただけると助かります。
いただけると助かります mềm và tự nhiên khi nhờ hỗ trợ trong team.
Quay lại bài học còn yếu
Ngày 1
Hỏi scope ticket
Hỏi scope, màn hình liên quan và điều kiện done của ticket bằng một câu lịch sự, không tạo cảm giác đẩy việc lại cho PM.
Ngày 2
Deadline và priority
Hỏi priority, deadline và thời điểm gửi estimate bằng câu rõ nhưng vẫn giữ sắc thái hợp tác với PM Nhật.
Ngày 3
Hỏi lại spec
Nêu điểm chưa rõ trong spec, đưa case cụ thể và xin xác nhận rule trước khi implement logic.
Ngày 4
API và edge case
Xác nhận default, API response và edge case bằng câu ngắn có giả thuyết để giảm số vòng hỏi lại.
Ngày 5
Bug report cơ bản
Viết bug report ngắn gồm bước tái hiện, expected result, actual result và môi trường kiểm tra.
Ngày 6
Cause và workaround
Báo nguyên nhân điều tra được, phạm vi ảnh hưởng và workaround tạm thời mà không cam kết quá mức.
Ngày 7
Daily cơ bản
Nói daily report theo cấu trúc ngắn, có blocker rõ và không biến daily thành báo cáo dài khó nghe.