Với công việc của 1 cầu nối thì việc trả lời hàng trăm câu hỏi của 2 bên là điều gặp phải hàng ngày. Đặc biệt là đầu dự án khi công việc chưa được định hình, và gần cuối dự án chuẩn bị cho release sản phẩm. Sau đây mình đưa ra 1 vài tình huống và cách ứng phó.
Yêu cầu đưa deadline
Làm gì khi khách hàng giao task cho team offshore và yêu cầu đưa deadline ?
Có 2 loại yêu cầu :trả lời ngay tức khắc (vị dụ trong buổi họp), trả lời sau. Với loại 2, việc trả lời không bắt buộc ngay và luôn thì dễ thở hơn. Các bạn có thể thảo luận với bên nhà mình để đưa ra mốc thời gian phù hợp với khối lượng công việc cũng như nhân sự dự án hiện có. Nhưng với loại 1 thì phải làm sao ? đối với task tương tự mà đã từng làm rồi thì đối chiếu theo đó, nhưng oái oăm là không phải lúc nào cũng vậy. Trường hợp này, hãy SUY NGHĨ KỸ trước khi trả lời, có thể dựa vào kinh nghiệm để chia task ra nhỏ, sau đó cộng time lại và trả lời 1 cách đại khái (không được nói chắc chắn khi chưa chưa có con số cụ thể) : tôi nghĩ là việc này sẽ bao gồm các việc abc, tổng thời gian là khoảng xx ngày, về con số chính xác thì sẽ tổng hợp và gửi qua mail – nói trực tiếp sau. Như vậy thì các bác khách hàng sẽ dựa vào con số ước lượng mình đưa ra và tiếp tục được buổi họp mà không bị gián đoạn.
Các bạn có thấy các mục tuyển dụng BrSE thường yêu cầu xx năm làm việc trực tiếp với KH Nhật ko ? Lý do thì như trên mình có nói, nếu có kinh nghiệm rồi thì việc đưa ra các câu trả lời phù hợp dựa theo kinh nghiệm sẽ rất dễ dàng. Nhưng với những bạn chưa có kinh nghiệm thì sao ? đừng lo lắng ! cái gì chắc thì nói, không chắc thì cần từ chối việc đưa ra con số, khách hàng ban đầu có thể không hài lòng, nhưng về lâu về dài họ sẽ rất tin tưởng bạn.
Yêu cầu đưa giải pháp
Việc yêu cầu đưa giải pháp thường xuất phát từ 2 phía, KH và team offshore. Cũng như deadline, trách nhiệm đưa ra giải pháp (phương án) để xử lý vấn đề cũng thường thuộc về BrSE.Vì sao không phải khách hàng hay bên PM ở nhà mình đưa ra mà lại là BrSE ? why always me ?
Đơn giản vì bạn là con cá nằm giữa dao – vs cái thớt ! ấy nhầm ! là CẦU NỐI giữa customer – offshore. Phía KH không ai hiểu team phát triển bằng bạn, còn phía mình thì bạn là người nắm rõ mông má … nhầm, mong muốn của KH nhất.
Cái này cũng chia ra 2 loại : ngay – luôn, từ từ trả lời sau. Đối với câu trả lời khi có nhiều thời gian, hãy chịu khó xem lại tài liệu – vì KH Nhật thường document rất kỹ. Còn trường hợp bắt buộc trả lời ngay những vấn đề nóng mà chưa nghĩ ra cách, hãy chạy tới thảo luận nhanh vs người rõ thông tin nhất để đưa ra giải pháp rõ ràng, nếu phương án này fail luôn (ông phụ trách đi du lịch …) thì chuyển cái ngay – luôn thành => từ từ, còn nếu không được nữa thì hãy nhường quyền quyết định cho người khác chứ đừng quyết bừa.
3 năm trước, lúc mình có làm brSE cho dự án về website. Khách hàng có yêu cầu mình đưa ra giải pháp cho vấn đề bảo mật để 30p sau bác ấy đi họp với end-user (lý do vì sao gấp vậy sau này đi nhậu bác í mới tâm sự là tụi end-user mới nghĩ ra !!!). Mà lúc đó cũng lơ mơ lắm, tuy biết sơ sơ “cross site scripting” (XSS) vs Cross-site Request Forgery (CSRF) nhưng làm sao để chống được 1 cách hiểu quả và áp dụng vào framework hiên tại thì quá khó. có 30p thì sao mà đưa ra giải pháp liền được ! tình thế ngàn cân treo sợi tóc. Lúc ấy mình mới xin hội ý rồi trả lời sau, may sao anh phụ trách technical ở bên VN vừa online, bị mình tóm luôn. Sau 20p trao đổi qua lại cuối cùng mình document lại mất 10p rồi gửi mail cho bác ấy. Buổi họp vs end-user diễn ra suôn sẻ, mừng phát khóc. Mấy ngày hôm sau đó là phải vật lộn để triển khai theo yêu cầu, nhưng vì giải pháp đã được sáng tỏ từ đầu, khách hàng đồng ý rồi nên cứ thế mà chiến thôi 😀
Tổng kết
- Làm người đứng giữa thường phải quyết rất nhiều thứ
- Giải pháp thì có nhiều nhưng hãy chọn phương án tốt nhất
- Luôn bình tĩnh phân tích vần đề trước khi đưa ra câu trả lời
- Nếu tình hình gấp gáp, hãy dùng kinh nghiệm để phán đoán. Và sau đó khi có thông tin rõ ràng hãy trả lời lại 1 cách cụ thể và thuyết phục.
- Đừng vì nghĩ khách hàng hay phía team offshore đánh giá thấp mà quyết bừa.
Có 1 vài tình huống dở khóc dở cười khác nữa nhưng mà để mình nhớ lại rồi kể sau, hôm nay viết đến đây thôi. Cảm ơn các bạn đã ráng đọc hết bài.
Tâm huyết chia sẻ đấy! Cám ơn anh đã share những kinh nghiệm của những con cá làm sao để nhát dao kia không buông xuông. Vì nếu buông xuống thì kiểu gì cũng có kẻ bị thương-cá hoặc thớt.
Hihi, nói chung né được thì tốt còn ko phải chấp nhận thương đau. Nhưng thà đau 1 lần rồi thôi 🙂
Thanks anh đã chia sẻ