Tóm tắt nhanh
Waterfall không chỉ là "làm chậm và nhiều tài liệu". Trong nhiều công ty Nhật, waterfall là cách chia dự án thành các phase rõ ràng để giảm rủi ro: 要件定義, 基本設計, 詳細設計, 実装, テスト, リリース. Nếu bạn hiểu từng phase dùng để làm gì, bạn sẽ biết khi nào cần hỏi lại spec, khi nào cần báo risk và khi nào không nên tự ý đổi cách xử lý.
Bài này dành cho developer Việt Nam mới làm với dự án Nhật. Nếu chưa quen từ vựng IT, bạn có thể học song song tại Tiếng Nhật IT và luyện câu thực tế trong bài luyện IT.
Waterfall là gì trong dự án Nhật?
Waterfall là mô hình phát triển phần mềm theo từng bước nối tiếp. Team thường xác định yêu cầu trước, viết thiết kế, implement, test rồi release. Mỗi bước tạo ra tài liệu hoặc output để bước sau dùng tiếp.
Trong dự án Nhật, waterfall thường xuất hiện ở các hệ thống doanh nghiệp, ngân hàng, bảo hiểm, sản xuất, chính phủ, hệ thống nội bộ hoặc dự án có nhiều bên tham gia. Lý do là các dự án này cần audit trail, phê duyệt, phân chia trách nhiệm và kiểm soát thay đổi rõ ràng.
- Phase
- Requirement
- Tiếng Nhật
- 要件定義
- Mục tiêu
- Chốt cần làm gì
- Output thường gặp
- 要件定義書, scope, rule nghiệp vụ
- Phase
- Basic design
- Tiếng Nhật
- 基本設計
- Mục tiêu
- Thiết kế từ góc nhìn user
- Output thường gặp
- screen design, API overview, flow
- Phase
- Detail design
- Tiếng Nhật
- 詳細設計
- Mục tiêu
- Thiết kế để developer code
- Output thường gặp
- logic, DB, validation, batch detail
- Phase
- Implementation
- Tiếng Nhật
- 実装
- Mục tiêu
- Code theo thiết kế
- Output thường gặp
- source code, unit test
- Phase
- Test
- Tiếng Nhật
- テスト
- Mục tiêu
- Kiểm tra đúng spec
- Output thường gặp
- test case, bug report
- Phase
- Release
- Tiếng Nhật
- リリース
- Mục tiêu
- Đưa lên môi trường thật
- Output thường gặp
- release note, rollback plan
Điểm quan trọng là phase sau thường dựa vào tài liệu của phase trước. Nếu 要件 định nghĩa sai, 基本設計 và 詳細設計 sẽ sai theo. Nếu thiết kế mơ hồ, implement và test sẽ bị trả lại nhiều lần.
Vì sao công ty Nhật coi trọng tài liệu?
Tài liệu không chỉ để "cho đủ quy trình". Trong nhiều dự án Nhật, tài liệu là căn cứ để xác nhận với khách hàng, chuyển giao giữa team onsite và offshore, viết test case, review code và xử lý dispute khi có bug.
Một developer Việt Nam dễ cảm thấy "code nhanh hơn viết tài liệu". Điều này đúng với task nhỏ, nhưng với dự án nhiều bên, nếu không có tài liệu, mỗi người sẽ hiểu khác nhau. Khi đó team mất thời gian sửa lại, họp lại và giải thích lại.
Từ khóa cần nhớ là 認識合わせ. Nghĩa là làm cho cách hiểu của các bên khớp nhau. Waterfall dùng tài liệu và review từng phase để giảm 認識違い trước khi đi quá xa.
Developer Việt Nam dễ hiểu sai điểm nào?
1. "Đã sang phase implement thì không được hỏi nữa"
Không đúng. Nếu spec thiếu hoặc có mâu thuẫn, bạn vẫn phải hỏi. Điểm khác là câu hỏi nên cụ thể: phần nào của tài liệu, case nào, bạn đang hiểu ra sao.
2. "Waterfall không có thay đổi"
Thực tế vẫn có 仕様変更. Nhưng thay đổi cần được ghi nhận, đánh giá ảnh hưởng và có approval. Bạn không nên tự sửa logic ngoài spec rồi nghĩ là đang linh hoạt.
3. "Tài liệu là việc của PM hoặc BrSE"
Developer vẫn cần đọc, phát hiện điểm mơ hồ và đôi khi cập nhật tài liệu kỹ thuật. Nếu chỉ code theo miệng, bạn dễ bị lệch với tài liệu chính thức.
4. "Test chỉ bắt đầu sau khi code xong"
Trong waterfall, test case thường được chuẩn bị từ thiết kế. Khi đọc thiết kế, developer nên nghĩ trước test sẽ kiểm tra gì. Cách này giúp giảm bug trước khi PR.
Ví dụ trong dự án thật
Ticket yêu cầu thêm trường "ngày hết hạn" cho hợp đồng. 基本設計 ghi màn hình hiển thị ngày theo định dạng YYYY/MM/DD, nhưng 詳細設計 ghi API trả về YYYY-MM-DD. Developer tự chọn format API và hiển thị trực tiếp lên màn hình.
Khi test, QA báo lỗi vì màn hình không đúng thiết kế. Cách xử lý tốt hơn là hỏi trước:
- Tình huống
- Thiết kế mâu thuẫn
- Câu tiếng Nhật nên dùng
- 基本設計と詳細設計の内容が異なるため、確認させてください。
- Nghĩa
- Basic design và detail design khác nhau, cho tôi xác nhận.
- Tình huống
- Muốn tóm tắt cách hiểu
- Câu tiếng Nhật nên dùng
- 画面表示はYYYY/MM/DD、APIはYYYY-MM-DDという理解でよろしいでしょうか。
- Nghĩa
- Tôi hiểu màn hình và API dùng format khác nhau, có đúng không?
- Tình huống
- Chờ xác nhận
- Câu tiếng Nhật nên dùng
- ご確認後に実装を進めます。
- Nghĩa
- Sau khi được xác nhận, tôi sẽ tiếp tục implement.
Điểm chính: không tự quyết khi tài liệu mâu thuẫn. Hãy chỉ ra chỗ mâu thuẫn và đề xuất cách hiểu.
Câu tiếng Nhật nên nhớ
- 日本語
- 要件定義を確認します。
- かな
- ようけんていぎをかくにんします
- Nghĩa tiếng Việt
- Tôi sẽ xác nhận requirement definition.
- Dùng khi nào
- Trước khi hiểu scope
- 日本語
- 基本設計を確認しました。
- かな
- きほんせっけいをかくにんしました
- Nghĩa tiếng Việt
- Tôi đã kiểm tra basic design.
- Dùng khi nào
- Sau khi đọc thiết kế
- 日本語
- 詳細設計に記載がありません。
- かな
- しょうさいせっけいにきさいがありません
- Nghĩa tiếng Việt
- Detail design chưa ghi nội dung này.
- Dùng khi nào
- Khi thiếu logic
- 日本語
- 仕様変更として扱いますか。
- かな
- しようへんこうとしてあつかいますか
- Nghĩa tiếng Việt
- Có xử lý như thay đổi spec không?
- Dùng khi nào
- Khi có yêu cầu mới
- 日本語
- 影響範囲を確認します。
- かな
- えいきょうはんいをかくにんします
- Nghĩa tiếng Việt
- Tôi sẽ kiểm tra phạm vi ảnh hưởng.
- Dùng khi nào
- Khi đổi logic
- 日本語
- この認識で合っていますでしょうか。
- かな
- このにんしきであっていますでしょうか
- Nghĩa tiếng Việt
- Cách hiểu này có đúng không ạ?
- Dùng khi nào
- Khi xác nhận lại
Checklist trước khi implement trong waterfall
- Đã đọc ticket, 要件定義 và thiết kế liên quan chưa?
- Điều kiện hoàn thành của task có rõ không?
- Có mâu thuẫn giữa tài liệu, ticket và comment không?
- Có case exception, quyền user, timezone, format dữ liệu không?
- Nếu có thay đổi, đã hỏi đó là bug fix hay 仕様変更 chưa?
- Đã biết cần test unit, integration hay manual test nào chưa?
Học tiếp trên JLPTVN
Sau bài này, nên đọc thêm Dự án IT với công ty Nhật khác gì?, 仕様書 là gì?, 基本設計 và 詳細設計. Nếu muốn luyện câu giao tiếp, học mẫu câu spec, mẫu câu ticket và làm bài luyện IT.
Khi luyện xong, mở Review để giữ lại câu sai về specification và tiến độ.
FAQ
Waterfall có còn phổ biến ở Nhật không?
Có. Nhiều công ty đã dùng Agile hoặc hybrid, nhưng waterfall vẫn rất phổ biến trong hệ thống doanh nghiệp, dự án SIer và dự án cần phê duyệt rõ ràng.
Developer mới nên tập trung vào phase nào?
Hãy bắt đầu từ cách đọc 仕様書, 基本設計, 詳細設計 và cách báo cáo khi phát hiện mâu thuẫn. Đây là kỹ năng dùng được ngay trong task hằng ngày.
Waterfall có nghĩa là không được chủ động không?
Không. Bạn vẫn nên chủ động phát hiện rủi ro, hỏi lại, đề xuất cách xử lý. Chỉ khác là mọi thay đổi quan trọng cần được xác nhận rõ.