Lập kế hoạch từ briefing

Khi nhận được briefing cho một tính năng mới, chúng ta thường được đưa design kèm một vài requirement. Câu hỏi thường gặp là “Bạn có làm được không?” và “Khi nào xong?”.

Nhưng trong System Design, câu hỏi quan trọng hơn nhiều là “Bạn sẽ làm nó như thế nào?”.

Chương này hướng dẫn bạn cách tiếp cận một briefing, phân tích requirement, và lên kế hoạch kỹ thuật vững chắc — trước khi viết dòng code đầu tiên.

1. Đề bài mẫu

Hãy tưởng tượng bạn nhận yêu cầu xây dựng một màn hình cho ứng dụng học tập (Course App).

Tính năng: Học viên kết nối với tutor qua các buổi 1-on-1 và làm bài tập được giao.

Màn hình chính bao gồm:

Thông tin khóa học và tutor
Danh sách bài tập (TODO list) với trạng thái hoàn thành
Lịch học cho các buổi 1-on-1 sắp tới
Nút Join call và Reschedule
Callout message từ tutor

Những điều chưa rõ

Nhìn vào design, ta thấy giao diện khá hoàn chỉnh. Tuy nhiên, có rất nhiều “known unknowns” — những điều ta biết là mình chưa biết:

Data: Lấy từ đâu? Có cache không? Offline mode thế nào?
Edge cases: Chưa có lịch học thì hiển thị gì? Tutor chưa giao bài tập thì sao?
Device: Tablet hiển thị ra sao? Landscape? Dark mode?
Action: Nút “Message” mở app mới hay mở chat trong app?

2. Các cách tiếp cận thường gặp

Khi bắt đầu, chúng ta thường muốn nhảy vào code ngay. Hãy xem xét các cách phổ biến và cạm bẫy của chúng:

Bắt đầu từ UI?

Cách làm: Mở IDE, code UI ngay.
Vấn đề: Dễ bị cuốn vào chi tiết (màu sắc, padding) mà quên bức tranh lớn. Rất khó refactor kiến trúc khi đã code xong.

Tập trung vào data?

Cách làm: Thiết kế model, database, API response trước.
Ưu điểm: Hiểu rõ data flow.
Lưu ý: Đừng cố tạo model “hoàn hảo” quá sớm.

Dựng app skeleton?

Cách làm: Tạo navigation, tab bar, các màn hình rỗng.
Lưu ý: Tốt cho hình dung flow, nhưng nếu chỉ làm một feature nhỏ thì hơi thừa.

Chọn architecture trước?

Cách làm: “Dùng MVVM hay MVC?”, “Dùng RxSwift hay Combine?”
Vấn đề: Quá sớm! Architecture nên phục vụ feature, không phải ngược lại.

✅ Khuyến nghị: Hiểu rõ vấn đề trước

Cách tốt nhất là hiểu rõ vấn đề trước khi code. Hãy dùng diagram để phác thảo hệ thống.

3. Phác thảo Landscape Graph

Thay vì chọn ngay một architecture, hãy vẽ một Landscape Graph — sơ đồ toàn cảnh hệ thống:

Liệt kê các component dựa trên UI
Xác định mối quan hệ giữa chúng

Ví dụ decomposition:

Course: Component cha, chứa mọi thứ.
Tutor: Avatar, tên, message.
Calendar: Events, rescheduling, join call.
TODO List: Danh sách bài tập và trạng thái.
- Lưu ý: Những phần chưa rõ (dashed lines) cứ đánh dấu và xử lý sau.

Quy tắc: Decompose cho đến khi bạn đủ tự tin để bắt đầu code. Không cần decompose quá chi tiết.

4. Tìm secondary requirements

UI chỉ là bề nổi. Secondary requirements — phần chìm của tảng băng — mới là thứ “giết chết” tiến độ nếu không phát hiện sớm.

Làm việc với designer

Designer là đồng minh. Hãy trao đổi để hiểu rõ hơn và tìm ra edge cases.

Các câu hỏi nên đặt ra:

Data xấu: Design luôn dùng data đẹp (tên ngắn, ảnh đẹp). Thực tế thì tên rất dài, ảnh thiếu, server lỗi. UI có bị vỡ không?
Empty states: Khi chưa có data thì hiển thị gì?
Partial error: Nếu load được info nhưng TODO list bị lỗi thì sao?
Prioritization: Không phải mọi thứ trong design đều quan trọng như nhau. Feature “Đổi khóa học” có cần ngay v1 không?

Kiểm tra component có sẵn

Trước khi xây mới, hỏi team xem đã có component nào tương tự chưa.

Tóm tắt: Bước đầu tiên của System Design không phải là code, mà là clarify requirements. Biến những điều mơ hồ thành kế hoạch cụ thể bằng cách đặt câu hỏi và phác thảo Landscape Graph.