Bản tin cộng đồng ngày 12/10/2026

Có bạn hỏi trong group: nhận dự án outsource mà không có tài liệu, chỉ có prod đang chạy, không được access code base, dev mới vào cũng không nắm hệ thống, PO thì chưa liên lạc được vì vướng hợp đồng.

Mấy anh chị trong nhóm góp ý thế này:

👉 Việc đầu tiên là tìm xem còn ai ở lại từ dự án cũ không. Có thì hỏi người ta trước.

👉 Không còn ai thì trao đổi thẳng với sếp để được đọc code, trình bày rõ tình hình chứ đừng tự bơi.

👉 Bất đắc dĩ thì tự vào sản phẩm dùng như một user, rồi dùng AI detail lại để nắm flow, sau đó đi hỏi lại từng phần.

👉 Một hướng khác: ném code cho dev, dev phân tích rồi trả ngược lại cho BA viết SRS.

Có bác nói thẳng: đừng kỳ vọng đội cũ đưa lại gì tử tế. Tài liệu nhận được thường chỉ có hai loại — bùa mới tạo, hoặc sai.

Một anh kể từng nhận cả tập tài liệu in ra giấy A4 dày cộp, đọc như đọc từ điển. Có chị bảo bên mình còn in hẳn 5000 tờ, mà chỉ cho 3 ngày để đọc xong.

Riêng mình nghĩ: cách lành nhất vẫn là lấy code làm gốc rồi đi confirm lại từng phần với khách. Mất thời gian, nhưng ít nhất mình biết cái mình viết là đúng.

Một bạn hỏi cách research để improve product của mình, mà hỏi kiểu chung chung quá nên mấy anh lớn trong nhóm cũng trả lời chung chung theo.

Rồi có người hỏi ngược lại: sản phẩm của bạn giải quyết cái gì cho khách hàng?

Bạn trả lời: core engine dispatch, phát chuyến cho driver.

Thế là có người chỉ luôn hai chỗ cần đào:

✅ Value chain — sản phẩm của mình nằm ở khâu nào trong chuỗi giá trị của khách.

✅ Customer journey — khách đi qua những bước nào, chỗ nào đang đau.

Từ đó mới biết nên đi sâu hay đi rộng. Ví dụ đang làm loyalty thì cân nhắc đào sâu loyalty hơn, hoặc lấn sang retention.

Một anh còn vẽ luôn sơ đồ MECE breakdown để phân rã vấn đề: muốn tăng doanh thu thì tối ưu số hàng chở mỗi chuyến, tăng năng lực của hệ thống TMS, vân vân.

Cách làm cụ thể được khuyên: dành vài tiếng đập nhỏ bài toán ra, rồi chọn đúng cái mà phần mềm bên mình giải quyết được. Vì không phải cái gì phần mềm cũng nhúng vào được.

Có bác chốt một câu mình thấy đáng ghi lại: benchmark tốt chưa chắc đã có lãi, phải có skin in the game mới hiểu.

Một bạn hỏi: đi phỏng vấn có nên làm slide research về công ty rồi đưa phương án giải quyết painpoint không, mà thấy chưa đủ thuyết phục.

Hai luồng ý kiến trong nhóm khá trái ngược.

Một anh kể lại trải nghiệm thật: đợt phỏng vấn vào một công ty chứng khoán, anh cũng làm slide tìm hiểu kỹ về công ty, quy trình, nghiệp vụ. Nhưng khi đề xuất cải tiến thì bị người phỏng vấn nói thẳng: "Em thì biết cái gì mà đòi vào cải tiến".

Lời khuyên từ anh đó: cứ làm slide tìm hiểu kỹ về công ty, quy trình và nghiệp vụ là đủ. Còn non thì đừng đề xuất giải quyết painpoint.

Một anh khác thì đặt câu hỏi ngược: liệu mấy bạn đang sao chép cách của một người từng phỏng vấn vào Figma không?

Rồi chủ đề xoay sang chuyện chứng chỉ. Có người bảo mấy năm trước ít ai học CBAP, CCBA. Giờ nhiều người đạt rồi mở lớp, thành ra nó thành tiêu chí lọc CV.

Nhưng cũng có ý kiến: outsource thì vẫn cần cert thật, vì công ty cần tên người có chứng chỉ để đi đấu thầu dự án.

Mình thì thấy: hiểu công ty là điểm cộng, còn đề xuất cải tiến khi chưa từng làm trong đó thì dễ tự bắn vào chân. Còn cert — có thì tốt, nhưng đừng để nó thay cho việc kể được mình đã thực sự làm gì.