"User ID này phản ánh nhận email thông báo sai chương trình khuyến mãi. Điều tra nguyên nhân và fix."
Đó là toàn bộ requirement của task đầu tiên Phong nhận khi chuyển sang team mới để thử việc, trên một hệ thống microservices lớn với rất nhiều luồng. Đọc xong, Phong không hiểu một chữ nào. Hai ngày sau, khi anh senior hỏi "Sao đến giờ anh vẫn chưa thấy report nhỉ?", Phong đứng hình mất khoảng 20 phút.
Hôm nay, Nguyễn Tiến Phong là Developer tại ZIGExN VeNtura, người được tin tưởng giao những bài toán có requirement mơ hồ và mentor các bạn mới. Khi intern và fresher đang bị xem là nhóm dễ bị AI thay thế nhất, hành trình ấy gợi ra một câu hỏi đáng để dừng lại: nếu AI đã viết code nhanh hơn, người mới còn giữ được gì cho riêng mình? Câu trả lời Phong tìm ra không nằm ở tốc độ gõ phím, mà ở cách đối diện với những điều mình chưa biết.
"Em đang tìm hiểu" không phải là trạng thái làm việc
Ngày mới vào thực tập, Phong là sinh viên năm 3 Đại học Công nghệ - ĐHQGHN, trong tay chỉ có HTML, CSS, JavaScript và chút framework cơ bản. Đi kèm là một nỗi sợ giấu kín: đừng làm phiền ai, và đừng để ai thấy mình đang gặp khó khăn.
Vì sợ hỏi nhiều sẽ ảnh hưởng kết quả thử việc, suốt hai buổi daily Phong chỉ trả lời: "Dạ, em đang tìm hiểu, có gì em report lại sau ạ." Đến khi được gọi vào phòng họp riêng, Phong mới thú nhận: "Thật ra em đọc requirement mà em không hiểu mình phải làm gì cả anh ạ." Report vẫn kịp gửi khách hàng, nhưng cái giá là một buổi OT đến 9 giờ tối, điều Phong hoàn toàn tránh được nếu lên tiếng sớm hơn.
Bài học đầu tiên: "em đang tìm hiểu" không phải là một trạng thái làm việc. Kẹt thì nói sớm, và nói rõ mình kẹt ở mắt xích nào. "Không ai đánh giá bạn vì bạn đặt câu hỏi cả. Người ta chỉ thực sự lo lắng khi không biết bạn đang kẹt ở đâu để giúp đỡ thôi."
Không phải đáp án, mà là một "tấm bản đồ"
Anh senior không giải thích từng flow như Phong tưởng. Anh bắt Phong liệt kê mọi chỗ chưa hiểu trong spec, bóc tách thành từng keyword, rồi với mỗi keyword sẽ cung cấp tài liệu của team để Phong tự đọc, tự điều tra. Khi đọc, Phong tự xâu chuỗi được gần như toàn bộ requirement.
"Anh senior không cho em một đáp án có sẵn. Anh ấy ném cho em một tấm bản đồ chỉ đường để em tự đi."
Một tháng sau, Phong nhận feature mới với requirement đúng một dòng: "Hiển thị tổng chi phí ước tính trên trang chi tiết." Lần này, Phong tự áp dụng cách cũ: bóc keyword, lần theo tài liệu và code cũ, rồi ghép thông tin lại. Chỉ sau một buổi sáng, Phong đã nắm toàn bộ flow của tính năng.
Bài học thứ hai: gặp bài toán khó, đừng hoảng. Bẻ nhỏ nó thành từng keyword và chủ động tìm context xung quanh.
Đi hỏi thì mang theo phương án
Khi nhìn được bức tranh tổng thể, Phong phát hiện 3 điểm spec chưa nhắc tới:
- Thiếu dữ liệu một khoản phí thì giao diện hiển thị ra sao?
- Chữ "ước tính" có khiến user hiểu lầm đó là con số cuối cùng không?
- Số tiền lẻ làm tròn thế nào?
Thay vì hỏi "Em phải làm thế nào ạ?", Phong chuẩn bị 2 phương án cho mỗi điểm, kèm ưu nhược và một đề xuất. Với điểm đầu tiên, phương án A là ẩn tổng chi phí, phương án B là vẫn hiển thị nhưng chú thích khoản nào chưa được tính. Phong chọn B để user vừa có thông tin hữu ích, vừa không bị hiểu lầm.
Bấm gửi mà tim vẫn đập thình thịch, Phong nhận về câu trả lời: điểm đầu tiên khách hàng cũng chưa lường tới, và team chốt theo phương án của Phong. Từ "Em phải làm gì?", Phong đã chuyển sang "Em nghĩ bài toán này nên làm thế này". Một phương án chủ động dù chưa tròn trịa vẫn giá trị hơn nhiều so với một câu hỏi thụ động.
Thời AI, người giữ bản đồ là người khó bị thay thế
Thứ cứu Phong trong task đầu tiên là tài liệu các anh chị đi trước để lại. Vì vậy, xong task nào Phong cũng ghi lại:
- Keyword nghĩa là gì
- Luồng chạy ra sao
- Chỗ nào dễ bug
- Đã confirm với BrSE những gì
Một bạn trong team từng nhắn: "May quá, em đọc tài liệu anh viết mới hiểu được đoạn này!"
Theo anh Hồ Văn Hải, Software Engineer dẫn dắt buổi TechTalk, những ghi chép ấy không chỉ cần cho người mới mà còn cho cả AI, vì một trong những thứ AI cần nhất ở dự án chính là business knowledge.
Anh Hải cũng cho rằng rào cản ngôn ngữ lập trình đang dần thu hẹp trong thời AI. Phong trải nghiệm điều đó khi team nhận dự án dùng Python, PHP và .NET, trong khi Phong chỉ biết Ruby. Lần này, Phong không đợi ai đưa bản đồ mà dùng AI để ánh xạ những gì đã biết, chẳng hạn Gem/Bundler bên Ruby tương ứng với pip, Composer hay NuGet. Phong nhận ra mình không phải học lại từ đầu, vì bản chất vẫn là những khái niệm cũ mang tên khác.
AI giúp Phong đi nhanh hơn. Nhưng hiểu bài toán, nắm nghiệp vụ và nối kiến thức cũ với cái mới vẫn là phần Phong tự làm.
Bản đồ dẫn đến niềm tin
Tháng 11/2024, Phong trở thành nhân viên chính thức. Tháng 4/2025, Phong nhận danh hiệu Young MVP Quý 1/2025, gần một năm sau ngày vào thực tập. Ba lời nhận xét dành cho Phong đều có câu chuyện phía sau:
- "Sẵn sàng nhận việc khó" bắt đầu từ ngày thú nhận mình không hiểu gì.
- "Thích nghi công nghệ mới" là những ngày tra cứu ba ngôn ngữ lạ.
- "Dám nghĩ dám làm" là lần gửi hai phương án khi tay còn run.
Với Phong, thứ lớn nhất nhận lại là sự tin tưởng: được giao những bài toán có requirement chưa rõ, được mentor các bạn mới. Mỗi lần nghe một bạn ấp úng "em đang tìm hiểu", Phong lại trao tấm bản đồ mình từng được nhận.
"Cơ hội lớn không tìm đến người giỏi nhất ngay từ đầu. Nó đến với người đã làm thật cẩn thận từng việc nhỏ nhất."
Ba điều bắt đầu từ hôm nay
Phong gói hành trình của mình thành ba việc có thể bắt đầu từ hôm nay:
- Kẹt thì nói sớm và nói rõ: "Em đang kẹt ở chỗ này, đã thử cách A, và cần hỗ trợ việc B."
- Gặp vấn đề mới thì chia nhỏ và tự hỏi: "Cái này giống với thứ gì mình đã từng biết?"
- Đi hỏi thì mang theo phương án, xong task thì ghi lại để người đến sau có bản đồ.
Young MVP cũng chưa phải đích đến, chỉ là một cột mốc trên tấm bản đồ Phong vẫn đang vẽ tiếp. Tấm bản đồ của bạn có thể bắt đầu từ câu hỏi đầu tiên bạn dám nói ra hôm nay.
Xem lại [TechTalk Growth Stories #1: From Intern to Young MVP] | Khám phá [các vị trí đang được tuyển dụng tại ZIGExN VeNtura]
