Technical Project Management

Scrum làm theo nhịp sprint cố định với cam kết đầu sprint; Kanban là luồng liên tục, giới hạn số việc đang làm (WIP limit) và tối ưu thời gian hoàn thành.

• Scrum hợp với phát triển sản phẩm có lộ trình, cần nhịp demo và lập kế hoạch đều đặn.
• Kanban hợp với việc đến liên tục và khó dự đoán: vận hành, hỗ trợ, bảo trì, xử lý ticket khách hàng.
• Chỉ số: Scrum thường nhìn velocity, burndown; Kanban nhìn lead time, cycle time, throughput.
• Nhiều team kết hợp: sprint cho tính năng, một làn Kanban cho bug gấp.

Người phỏng vấn muốn nghe: bạn chọn theo bản chất công việc, không theo sở thích. Ví dụ: "Team maintain hệ thống cho khách, yêu cầu đến mỗi ngày, em chuyển sang Kanban với WIP limit và cam kết thời gian phản hồi theo mức ưu tiên."

Estimate là việc của cả team, không phải PM tự đặt rồi giao xuống.

• Story point: đo độ lớn tương đối (khối lượng, độ phức tạp, rủi ro), so với một story mẫu. Hay dùng planning poker với dãy gần Fibonacci để cả team thảo luận chỗ hiểu khác nhau.
• Giờ/ngày công: cần khi báo giá dự án outsourcing, hợp đồng fixed-price hoặc lập kế hoạch nguồn lực.
• Với dự án lớn: chia nhỏ (WBS), estimate theo khoảng (lạc quan, khả dĩ, bi quan), cộng buffer cho rủi ro, tích hợp, test, sửa bug.
• Dùng dữ liệu cũ (velocity, dự án tương tự) để kiểm tra lại.

Hay sai: đổi story point ra giờ một cách cứng nhắc, hoặc dùng velocity để so sánh hiệu suất giữa các team.

Công cụ chỉ hữu ích khi team cập nhật thật và bạn nhìn đúng chỉ số.

• Cấu trúc: Epic cho tính năng lớn, Story/Task cho việc trong sprint, Bug riêng; có quy ước đặt tên và trạng thái thống nhất.
• Board phản ánh đúng workflow của team (To Do, In Progress, Code Review, Testing, Done).
• Theo dõi: burndown/burnup của sprint, việc bị kẹt lâu ở một cột, số bug mở theo mức độ.
• Dashboard hoặc báo cáo định kỳ cho khách hàng/sếp: tiến độ theo milestone, rủi ro, quyết định cần họ đưa ra.
• Kết hợp Confluence hoặc wiki cho tài liệu, biên bản họp.

Người phỏng vấn muốn nghe: bạn dùng dữ liệu để phát hiện vấn đề sớm (ví dụ ticket nằm ở cột Testing quá lâu là dấu hiệu thiếu tester), không chỉ để báo cáo.

Microservices giải quyết vấn đề tổ chức: nhiều team cần deploy độc lập và scale riêng từng phần. Nó không tự làm hệ thống nhanh hơn.

Nên cân nhắc tách khi:

• Nhiều team đụng nhau trong cùng codebase, deploy phải chờ nhau.
• Một phần có tải hoặc yêu cầu công nghệ rất khác phần còn lại.
• Ranh giới nghiệp vụ (bounded context) đã rõ ràng và ổn định.

Cái giá: gọi mạng thay vì gọi hàm (độ trễ, lỗi một phần), nhất quán dữ liệu phân tán, cần tracing, service discovery, CI/CD và vận hành phức tạp hơn.

Người phỏng vấn muốn nghe: "modular monolith" là bước khởi đầu hợp lý: chia module rõ ràng trong một ứng dụng, sau này tách theo đúng ranh giới đó. Tách sai ranh giới tạo ra "distributed monolith", tệ hơn cả monolith.

Cache giảm độ trễ và tải cho DB, đổi lại phải chấp nhận dữ liệu có thể cũ trong một khoảng thời gian.

• Cache-aside (phổ biến nhất): đọc cache, miss thì đọc DB rồi ghi vào cache kèm TTL. Khi cập nhật thì ghi DB rồi xoá key cache.
• Write-through: ghi qua cache rồi cache ghi xuống DB, dữ liệu cache luôn mới nhưng ghi chậm hơn.
• Write-behind: ghi cache trước, đẩy xuống DB sau; nhanh nhưng có thể mất dữ liệu.

Các vấn đề cần xử lý:

• Cache stampede: key nóng hết hạn, hàng nghìn request cùng đánh vào DB. Giải pháp: lock hoặc single-flight, làm mới sớm, thêm độ lệch ngẫu nhiên cho TTL.
• Cache penetration: truy vấn key không tồn tại liên tục. Giải pháp: cache cả kết quả rỗng, dùng bloom filter.

Hay sai: cập nhật cache thay vì xoá, dễ ghi đè giá trị cũ khi hai request chạy song song.

Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.

• Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
• Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
• Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
• Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
• Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.

Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.

Mỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.

• Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
• Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
• Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
• Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
• Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.

Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".

Nói chuyện riêng, sớm và dựa trên sự việc trước khi kết luận.

• Chuẩn bị ví dụ cụ thể (task nào, trễ bao lâu, ảnh hưởng gì), tránh nhận xét chung chung kiểu "em làm chậm".
• Hỏi để hiểu nguyên nhân: việc quá sức, thiếu kiến thức, yêu cầu không rõ, vấn đề cá nhân, hay mất động lực.
• Cùng thống nhất kế hoạch: chia task nhỏ hơn, ghép cặp với người kinh nghiệm, check-in thường xuyên hơn, hỗ trợ đào tạo.
• Theo dõi và phản hồi định kỳ. Nếu không cải thiện, phối hợp với line manager/HR theo quy trình của công ty.

Hay sai: góp ý trước cả team, hoặc lẳng lặng giao việc cho người khác làm thay. Cách đó làm người giỏi kiệt sức và vấn đề không được giải quyết.

Message queue tách bên gửi và bên nhận: xử lý bất đồng bộ, hấp thụ tải đột biến, cho nhiều hệ thống cùng phản ứng với một sự kiện.

• RabbitMQ: message broker truyền thống, định tuyến linh hoạt qua exchange (direct, topic, fanout), message bị xoá sau khi consumer ack. Hợp với hàng đợi tác vụ như gửi email, xử lý ảnh.
• Kafka: log phân tán chỉ ghi nối, message được giữ theo thời gian cấu hình, consumer tự quản lý offset nên đọc lại được. Thứ tự chỉ đảm bảo trong từng partition. Hợp với event streaming, thông lượng lớn, nhiều consumer group.

Lưu ý khi dùng:

• Mặc định nên coi là at-least-once, nên consumer phải idempotent.
• Có dead letter queue cho message lỗi lặp lại.
• Theo dõi consumer lag.

Người phỏng vấn muốn nghe: lý do chọn gắn với nhu cầu cụ thể, không chọn Kafka chỉ vì nghe "xịn".

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.