Đối với anh em sinh viên IT tại Đại học FPT, kỳ 5 luôn là một "cú vả" thức tỉnh với môn học mang tên SWP391 - Software Development Project. Khác hoàn toàn với những môn lý thuyết "chay" hay thi viết trên giấy, đây là "chiến trường" thực sự để bạn và team áp dụng kiến thức build một hệ thống phần mềm từ con số không. Và trùm cuối của môn này không gì khác chính là buổi báo cáo hội đồng SWP391.
Đây là thời khắc sinh tử quyết định điểm số cả kỳ của bạn. Tại devshare.pro.vn, mình không dám nhận là pro nhất, nhưng với con điểm 8.8 vừa "chốt sổ", mình tin rằng những kinh nghiệm thực chiến đẫm mồ hôi và nước mắt này sẽ là bí kíp "cứu rỗi" các nhóm đang loay hoay chuẩn bị bảo vệ dự án. Hãy cùng điểm qua cách để thuyết trình xịn xò và "bẻ lái" mượt mà những câu hỏi hóc búa từ hội đồng nhé!
Thời lượng báo cáo và cảm nhận "sau màn tra tấn"
Nhóm mình "lên thớt" tổng cộng 1 tiếng 15 phút, bao trọn gói từ lúc giới thiệu dự án, demo hệ thống cho đến phần Q&A (hỏi đáp) với các thầy cô. Vì là nhóm mở màn, áp lực là không thể tránh khỏi. Nhưng mấy bồ biết không? Nhờ phân chia task cực kỳ rõ ràng và "tập dượt" kỹ lưỡng, mọi thứ trôi qua khá êm đẹp. Cảm giác bước ra khỏi phòng bảo vệ ta nói nó nhẹ nhõm, và khi nhận điểm thì cả nhóm vỡ òa vì bao công sức cày cuốc ngày đêm đã được đền đáp xứng đáng.
Kinh nghiệm xương máu số 1: Chuẩn bị kịch bản thật kỹ, bạn sẽ không bị "khớp" dù giám khảo có "quay" cỡ nào!
Tuyệt chiêu làm Slide & Kịch bản thuyết trình "ăn điểm"
Nhiều anh em cứ nghĩ bê nguyên cái file Word tài liệu đập vào PowerPoint là xong. Sai lầm to! Slide chỉ là công cụ hỗ trợ để giám khảo dễ theo dõi chứ không phải là bản teleprompter để bạn đứng đọc. Để mình bật mí cách nhóm mình tối ưu slide nhé:
Slide tinh gọn, rõ ý, hình ảnh là chân ái
Bọn mình thống nhất ép slide xuống dưới mức 25 trang, và đẩy tỷ lệ hình ảnh lên 60-70%. Text chỉ để chốt ý chính. Màu sắc cũng được "độ" lại cho tone-sur-tone với giao diện web để tạo cảm giác chuyên nghiệp. Dưới đây là sườn cấu trúc slide mà nhóm mình đã dùng:
- Giới thiệu dự án: Tên đề tài và tên hệ thống phải tách bạch rõ ràng. Nhấn mạnh ngay "nỗi đau" thực tế của khách hàng và cách hệ thống của bạn giải quyết nó.
- Kiến trúc & Công nghệ: Khoe cái biểu đồ kiến trúc tổng quan ra. Điểm mặt chỉ tên những công nghệ "xịn xò" trọng tâm, đủ để hội đồng gật gù hiểu nền tảng bạn dùng.
- Chức năng chính: Tách ra từng module, quăng ảnh giao diện minh họa vào để thầy cô dễ mường tượng luồng trải nghiệm của người dùng.
- Kết quả & Hướng đi tương lai: Thẳng thắn chỉ ra tính năng nào đã hoàn thiện, cái nào đang "chắp vá" giới hạn và dự định nâng cấp gì nếu có cơ hội.
Xử lý "khủng hoảng" khi bị hội đồng hỏi xoáy
Đây là phần căng não nhất. Thầy cô FPT soi cực kỳ kỹ. Nhóm mình (làm đề tài hệ thống quản lý xe khách) đã bị "bế" vào những câu hỏi thực chiến sau:
1. Quản lý tuyến đường (Manage Routes)
Câu hỏi: "Hệ thống tính thời gian giữa các điểm dừng kiểu gì? Ví dụ Cần Thơ - Hậu Giang đi mất bao lâu?"
Trả lời: Bọn mình thú nhận luôn là hiện tại dữ liệu đang bị "hard code" (lưu cố định), chưa đồng bộ lên DB và chưa có công thức tính động theo thực tế. Đây là tính năng nhóm đưa vào backlog cải thiện sau.
2. Mã thanh toán đang... giả trân
Câu hỏi: "Ủa sao mã thanh toán chả quyết định gì đến tình trạng đặt vé vậy?"
Trả lời: "Dạ thưa thầy, vì tụi em chưa tích hợp API cổng thanh toán thật, phần này mới dừng ở mức giả lập luồng để demo chức năng cơ bản ạ."
3. Trải nghiệm người dùng (UX) còn lấn cấn
Góp ý: Đặt vé thành công xong thông báo không nảy lên đầu trang chủ, UX bị kém.
Phản hồi: Bọn mình ngoan ngoãn ghi nhận và hứa sẽ đắp thêm popup hiển thị cho nổi bật hơn.
4. Hủy vé thiếu logic
Câu hỏi: Hủy vé xong hệ thống thiếu thông báo xem tài xế đã đồng ý hay chưa?
Trả lời: Bọn mình giải thích rằng logic này chưa được triển khai triệt để, đúng ra phải bổ sung một trạng thái trung gian để tránh mâu thuẫn dữ liệu.
5. Cú "Twist" tình huống thực tế
Câu hỏi: "Khách xuống trạm đi vệ sinh ra trễ lỡ chuyến thì tài xế lưu trạng thái trên hệ thống thế nào?"
Trả lời: Hệ thống hiện tại chưa linh hoạt tính năng ghi chú khi check-in/out. Đây là case cực kỳ thực tế mà nhóm chưa lường trước, xin ghi nhận để nâng cấp.
6. Tài liệu Use Case, ERD, SDS bị soi rát
Bị nhặt một rổ sạn: Use Case thiếu chức năng (Guest không có view trip detail, bus ticket không nằm dưới manage ticket), ERD ký hiệu sai, chưa chuẩn hóa, thiếu khóa ngoại... SDS thì flow có bước chưa rõ đích đến.
Bí quyết xử lý: Không cãi cùn! Trung thực thừa nhận thiếu sót trong thiết kế, cảm ơn thầy cô đã chỉ ra lỗi để nhóm lấy đó làm bài học sửa sai.
Lưu ý cực gắt: Đừng bao giờ chém gió lấp liếm nếu bạn không biết. Thái độ cầu thị, thẳng thắn thừa nhận cái mình làm sai luôn được hội đồng đánh giá cao hơn!
Lời kết
Để sống sót và ôm điểm ngon ở môn SWP391, anh em cần một hệ thống code "ổn áp", một bản slide chuẩn chỉ, và trên hết là độ chín trong xử lý tình huống cùng sự ăn ý của cả team. Điểm số cao không phải do "may mắn" rơi xuống, nó là quả ngọt của những đêm chạy test, fix lỗi đến phút cuối cùng trước giờ G.
Mình hi vọng những "kinh nghiệm thực chiến" này từ DevSharePro sẽ tiếp thêm sức mạnh cho anh em khóa sau tự tin hơn, tránh đi lại vết xe đổ của các bậc tiền bối.
Nếu thấy bài viết này xịn xò, đừng ngần ngại share cho đồng bọn trong nhóm đọc để cùng bỏ túi mẹo bảo vệ nhé. Có câu hỏi gì khó cứ thả comment bên dưới, mình sẽ giải đáp "nhanh như chớp" cho anh em. Chúc anh em bảo vệ SWP391 thành công rực rỡ!
