AI đang thay đổi công việc của chúng ta từng ngày. Những việc từng tốn nhiều thời gian như dịch tài liệu, viết email, tổng hợp thông tin hay tìm hiểu vấn đề kỹ thuật, giờ chỉ cần vài câu lệnh là AI đã có thể hỗ trợ nhanh hơn rất nhiều.
Là một IT Comtor, tôi cũng dùng AI ngày càng nhiều: dịch và kiểm tra cách diễn đạt tiếng Nhật, tóm tắt nội dung kỹ thuật, phân tích requirement, tìm hiểu vấn đề mới. AI đã trở thành công cụ quen thuộc trong công việc hằng ngày của tôi.
Nhưng càng dùng AI, tôi càng nghĩ về một câu hỏi:
Nếu AI ngày càng làm được nhiều việc mà trước đây con người vẫn làm, thì bản thân tôi cần phát triển điều gì để tiếp tục tạo ra giá trị?
Đây không chỉ là câu hỏi của developer hay người làm công nghệ. Với một IT Comtor — người đứng giữa khách hàng và team phát triển — câu hỏi này cũng rất đáng suy nghĩ.
Không muốn chỉ “biết dùng AI”
AI giúp tôi tiết kiệm rất nhiều thời gian. Khi nhận nội dung kỹ thuật từ developer, tôi có thể nhờ AI giải thích lại, tóm tắt ý chính, hoặc chuyển thành cách diễn đạt dễ hiểu hơn để trao đổi với khách hàng Nhật. Khi viết message, AI giúp tôi kiểm tra cách diễn đạt đã tự nhiên chưa, có dễ gây hiểu nhầm không, hay có cách viết nào phù hợp hơn.
Nhưng tôi cũng nhận ra một điều:
Biết sử dụng AI và biết sử dụng AI đúng cách là hai chuyện khác nhau.
AI có thể đưa ra câu trả lời rất hợp lý, nhưng không có nghĩa là nó đúng với hệ thống hay dự án mình đang phụ trách. Nếu tôi không hiểu requirement, không nắm context dự án hoặc thiếu kiến thức kỹ thuật, tôi khó nhận ra chỗ nào AI đang sai.
Vì vậy, mục tiêu của tôi không chỉ là biết thêm công cụ AI, mà là hiểu công việc đủ sâu để biết khi nào nên dùng AI, nên yêu cầu AI hỗ trợ điều gì, và quan trọng nhất là có khả năng kiểm tra kết quả AI đưa ra.
Tôi muốn hiểu IT sâu hơn
Một điều tôi muốn cải thiện rõ nhất là kiến thức IT. Là IT Comtor đứng giữa khách hàng và team phát triển, tôi không cần trở thành developer, nhưng cần hiểu kỹ thuật đủ sâu để trao đổi chính xác với developer và giải thích lại cho khách hàng dễ hiểu.
Tôi thường gặp các khái niệm như API, Webhook, Database, AWS, S3, Batch, Job, Frontend, Backend, Testing, Deployment. Trước đây, biết nghĩa của thuật ngữ là đủ để dịch hoặc giải thích. Nhưng càng làm lâu, tôi càng thấy chỉ hiểu thuật ngữ là chưa đủ.
Khi developer giải thích một lỗi, nếu hiểu nguyên nhân kỹ thuật, tôi có thể đặt thêm câu hỏi để làm rõ vấn đề. Khi khách hàng đưa ra một requirement chưa rõ, tôi cũng chủ động nhận ra điểm cần confirm, thay vì chỉ chuyển nguyên văn cho developer.
Khi đó, vai trò của tôi không còn là “truyền đạt thông tin” đơn thuần — tôi muốn trở thành người thực sự hiểu thông tin mình đang truyền đạt.
Khả năng đặt câu hỏi cũng quan trọng không kém
Càng dùng AI, tôi càng thấy khả năng đặt câu hỏi rất quan trọng — không chỉ khi làm việc với AI mà cả trong công việc hằng ngày. Một requirement không rõ ràng có thể dẫn đến rất nhiều vấn đề về sau; đặt đúng câu hỏi ngay từ đầu có thể giúp team tiết kiệm nhiều thời gian implement và sửa lại.
Vì vậy, thay vì chỉ nghĩ:
“Tôi cần dịch nội dung này như thế nào?”
tôi muốn tự hỏi thêm:
“Khách hàng thực sự muốn giải quyết vấn đề gì?”
“Có điểm nào chưa được xác định rõ không?”
“Nếu developer bắt đầu implement ngay, họ có thể hiểu requirement theo một hướng khác không?”
“Có trường hợp đặc biệt nào chưa được đề cập không?”
AI có thể hỗ trợ tôi trong quá trình này: tôi đưa requirement cho AI và yêu cầu chỉ ra những điểm chưa rõ, những trường hợp có thể bị bỏ sót, hoặc những câu hỏi nên xác nhận thêm với khách hàng. Nhưng cuối cùng, tôi vẫn cần tự kiểm tra lại dựa trên context thực tế của dự án.
AI giúp tôi mở rộng góc nhìn, nhưng tôi vẫn là người đưa ra quyết định cuối cùng.
Giao tiếp vẫn là một kỹ năng rất quan trọng
Đây là một trong những kỹ năng mà IT Comtor cần tiếp tục phát triển, ngay cả khi AI ngày càng giỏi dịch thuật. Công việc Comtor không chỉ đơn giản là dịch tiếng Việt sang tiếng Nhật hoặc ngược lại.
Có lúc khách hàng không nói trực tiếp điều họ thực sự lo lắng. Có lúc một vấn đề kỹ thuật cần được giải thích sao cho khách hàng hiểu, nhưng không tạo cảm giác team đang đổ lỗi cho một cá nhân nào đó. Cũng có lúc developer giải thích rất chính xác về mặt kỹ thuật, nhưng cách diễn đạt lại quá khó hiểu đối với khách hàng.
Trong những tình huống như vậy, tôi cần hiểu cả hai phía và tìm ra cách truyền đạt phù hợp. Đó là lý do tôi muốn tiếp tục cải thiện khả năng lắng nghe, đặt câu hỏi, lựa chọn cách diễn đạt và nhìn vấn đề từ góc độ của người nhận thông tin.
AI có thể giúp tôi viết một câu tốt hơn. Nhưng để biết nên nói điều gì, nói với ai và nói như thế nào, tôi vẫn cần tự mình suy nghĩ.
Tôi muốn thay đổi cách làm việc hằng ngày nhờ AI
Tôi cũng muốn đưa AI vào công việc một cách có hệ thống hơn, thay vì chỉ sử dụng khi gặp một công việc cụ thể.
Ví dụ: trước một cuộc họp, tôi có thể nhờ AI tổng hợp những vấn đề chưa được giải quyết và những điểm cần xác nhận. Khi nhận requirement, tôi dùng AI để kiểm tra những điểm chưa rõ, những trường hợp có thể bị bỏ sót hoặc những câu hỏi nên hỏi khách hàng. Khi nhận được giải thích từ developer, tôi nhờ AI chuyển nội dung đó thành cách diễn đạt đơn giản hơn trước khi gửi cho khách hàng.
Ngay cả trước khi gửi một message, tôi cũng có thể nhờ AI review dưới góc nhìn của người nhận:
- Nội dung có dễ hiểu không?
- Có điểm nào dễ gây hiểu nhầm không?
- Có thông tin nào còn thiếu không?
- Cách diễn đạt có quá trực tiếp không?
Tôi nghĩ khi làm như vậy, AI sẽ không chỉ giúp tôi “làm nhanh hơn”, mà còn giúp tôi làm việc tốt hơn — tôi có thể dành ít thời gian hơn cho những việc lặp lại, và nhiều thời gian hơn cho những việc cần suy nghĩ và phán đoán.
Tôi muốn trở thành cầu nối giữa Business và Technology
Nếu nhìn về vài năm tới, tôi không muốn career path của mình chỉ tập trung vào khả năng tiếng Nhật hoặc dịch thuật. Tôi muốn hiểu business của khách hàng tốt hơn, hiểu hệ thống tốt hơn, và có thể tham gia sâu hơn vào quá trình phân tích requirement cũng như giải quyết vấn đề.
“Cầu nối giữa Business và Technology” không có nghĩa là tôi phải trở thành một developer hay một chuyên gia business. Điều tôi muốn hướng tới là có đủ hiểu biết ở cả hai phía để giúp hai bên hiểu nhau và đưa ra quyết định tốt hơn.
Từ “dịch requirement” sang “hiểu business problem”
Ví dụ, khách hàng nói:
“Chúng tôi muốn thêm chức năng PICK UP cho Cast.”
Nếu chỉ đứng ở vai trò Comtor, tôi có thể dịch yêu cầu này sang tiếng Nhật và chuyển cho developer. Nhưng nếu muốn trở thành cầu nối giữa Business và Technology, tôi muốn đi thêm một bước:
- Tại sao khách hàng cần chức năng PICK UP?
- Ai sẽ sử dụng chức năng này?
- Muốn ưu tiên Cast theo tiêu chí nào?
- PICK UP có ảnh hưởng đến thứ tự hiển thị hiện tại không?
- Admin có thể chọn bao nhiêu Cast?
- Nếu bỏ PICK UP thì chuyện gì xảy ra?
- User và Admin có hành vi khác nhau không?
Nói cách khác, tôi không chỉ muốn hiểu “Khách hàng muốn làm gì?” mà còn muốn hiểu “Khách hàng đang muốn giải quyết vấn đề gì bằng chức năng này?” Đây là điều tôi nghĩ mình cần rèn luyện nhiều hơn.
Kiểm tra Business requirement và Technical solution
Tôi cũng muốn tập cho mình thói quen không chỉ kiểm tra “Developer đã implement đúng requirement chưa?” mà còn kiểm tra “Technical solution này có thực sự giải quyết đúng business problem không?”
Ví dụ, khách hàng muốn sản phẩm có thứ tự ưu tiên khác nhau tùy theo từng category. Developer có thể đề xuất thêm một field priority. Khi đó, tôi có thể đặt thêm những câu hỏi như:
- Priority có áp dụng global hay mỗi category có một priority riêng?
- Nếu cùng một sản phẩm thuộc nhiều category thì xử lý thế nào?
- Nếu hai sản phẩm có cùng priority thì sort theo tiêu chí nào?
- Admin có cần thay đổi priority không?
- Nếu không thiết lập priority thì hệ thống xử lý như thế nào?
Tôi không cần tự đưa ra technical solution, nhưng tôi cần đủ hiểu để nhận ra rằng: một solution có thể implement được về mặt kỹ thuật nhưng chưa chắc đã đáp ứng đầy đủ business requirement.
Đây là khoảng giữa Business và Technology mà tôi muốn có khả năng đứng vào — chuyển từ:
Requirement → Translation
sang:
Requirement → Analysis → Question → Clarification → Solution
Xây dựng một workflow mới với AI
AI cũng có thể hỗ trợ tôi rất nhiều trong quá trình này. Ví dụ, sau khi nhận requirement, tôi có thể nhờ AI đóng vai BA và đặt câu hỏi:
“Hãy tìm những điểm chưa rõ trong requirement này.”
“Hãy đưa ra những edge case có thể xảy ra.”
“Nếu implement requirement này, những thành phần frontend, backend, database hoặc batch nào có khả năng bị ảnh hưởng?”
AI có thể giúp tôi mở rộng phạm vi suy nghĩ và phát hiện những góc nhìn mà tôi có thể chưa nghĩ tới. Sau đó, tôi sẽ kiểm tra lại dựa trên context thực tế của dự án, source code, business rule và những trao đổi trước đó.
Kết luận
Nhìn lại, tôi nghĩ hành trình phát triển của một IT Comtor trong thời đại AI có thể tóm gọn ở vài điểm chính:
- Dùng AI đúng cách, không chỉ dùng AI: hiểu công việc đủ sâu để biết khi nào cần AI, yêu cầu gì và tự kiểm tra được kết quả AI đưa ra.
- Hiểu IT sâu hơn: không chỉ nắm thuật ngữ, mà hiểu bản chất kỹ thuật để trao đổi chính xác với developer và giải thích đúng cho khách hàng.
- Rèn khả năng đặt câu hỏi: một requirement được làm rõ sớm sẽ tiết kiệm rất nhiều thời gian và công sức về sau.
- Giữ vững kỹ năng giao tiếp: lắng nghe, lựa chọn cách diễn đạt và đặt mình vào góc nhìn người nhận thông tin — điều AI chưa thể thay thế.
- Đưa AI vào workflow một cách có hệ thống: từ chuẩn bị họp, kiểm tra requirement đến review message, để AI hỗ trợ toàn diện chứ không chỉ xử lý việc lẻ tẻ.
- Hướng tới vai trò cầu nối Business — Technology: đi từ “dịch requirement” sang “hiểu business problem”, biết đặt câu hỏi để kiểm tra cả business requirement lẫn technical solution.
Nói ngắn gọn: AI giúp tôi làm nhanh hơn và nghĩ rộng hơn, nhưng người hiểu vấn đề sâu nhất và đưa ra quyết định cuối cùng vẫn phải là tôi. Đó cũng là hướng phát triển tôi muốn theo đuổi trong thời gian tới.