Những kỹ năng và yêu cầu đối với nghề BRSE

Bài đăng này đã không được cập nhật trong 5 năm

Mình mới chính thức bước chân vào nghề BRSE được hơn 1 năm. Dưới đây mình sẽ chia sẻ những kỹ năng và yêu cầu đối với ngành BRSE mà mình đã cảm nhận được thông qua thời gian tiếp xúc.

Nghề BRSE cần những kỹ năng gì?

1. Phân tích, nắm vững, hiểu rõ requirement

Đây là kỹ năng quan trọng nhất mà một BRSE cần phải có. BRSE sẽ là cầu nối giữa khách hàng và đội ngũ phát triển. Là người nói chuyện trực tiếp với khách hàng để hiểu khách hàng mong muốn một sản phẩm như thế nào, sau đó truyền đạt lại cho kỹ sư. BRSE là người đầu tiên tiếp nhận tài liệu thiết kế, đọc hiểu và clear toàn bộ nội dung thiết kê. Sau đó sẽ dịch và truyền đạt lại cho kỹ sư. Thông thường lúc này sẽ tổ chức một buổi họp giải thích của spec. Vậy sự khác nhau của một BRSE và comtor là gì. Comtor cũng dịch spec, BRSE cũng dịch spec kia mà? Comtor không có nhiệm vụ clear spec, họ chỉ cần dịch spec ra và trao cho kỹ sư, như vậy là hết nhiệm vụ. Tuy nhiên, BRSE phải là người vừa dịch, vừa hiểu, vừa nghiên cứu spec. Nếu có gì conflict, những gì chưa cụ thể, còn mù mờ hay thiếu thông tin thì BRSE có trách nhiệm làm rõ nó ra cho kỹ sư.

Việc clear spec ngay từ đầu sẽ giúp tiết kiệm thời gian hơn so với việc vừa code vừa confirm.

2. Communicate, negotiate

Kỹ năng communicate và negotiate (thương thảo). Communicate ở đây vừa là đối với khách hàng vừa là đối với team phát triển dự án. Đối với khách hàng, BRSE cần phải báo cáo tình hình phát triển dự án mỗi ngày để khách có thể nắm được tình hình nhanh, kịp thời. Đây là một trong những yếu tố để nâng cao tỷ lệ thành công trong dự án. Ngoài báo cáo, BRSE có trách nhiệm nhiệm suggest các phương án cho khách. Bạn không chỉ đơn giản là nhận yêu cầu từ khách rồi truyền đạt lại cho team. Mà còn phải suy nghĩ mong muốn của khách có phù hợp hay chưa? Có thể làm cho nó tốt hơn được không?

Đối với team, vừa là người kết nối mọi người trong team với nhau để mọi người có chung một mục tiêu, chung một mindset. Vừa là người truyền tải những nguyện vọng, ý kiến của team đối với khách hàng.

Đối với kỹ năng thương thảo. Khách hàng là thượng đế. Nếu có thể chiều thì sẽ chiều. Tuy nhiên, đôi khi requirement của khách vượt quá khả năng của team. Thì BRSE là người phải biết được team có thể đáp ứng được bao nhiêu phần trăm yêu cầu của khách. Và đưa ra một phương án vui vẻ cả đôi bên để không phải ép team của mình.

Việc đồng ý mọi yêu cầu của khách (về thời gian hoàn thành task chẳng hạn) mà ko xem xét khả năng của team sẽ dẫn đến việc khách hàng thì đi uống bia, team thì hục mặt OT. Đôi khi BRSE phải đứng ở giữa khách hàng và team phát triển, bị cả 2 bên ép chặt thì việc cư xử khéo léo để làm hài lòng cả 2 bên sẽ là yếu tố quan trọng để dự án thành công.

3. Management

Kỹ năng quản lý. Trước đây, khi đi phỏng vấn vị trí BRSE mình đã đi phỏng vấn ở 2 công ty. Một công ty đã nói với mình rằng BRSE không cần phải có kỹ năng quản lý. Chỉ cần kỹ năng 1 và 2 là được. Chính vì vậy mình đã quyết định không làm việc ở công ty đó. Theo suy nghĩ của mình đã là BRSE thì cần phải có kỹ năng quản lý. Còn ít hay nhiều tùy thuộc vào mỗi công ty. Có những công ty mỗi dự án có PM riêng, đó mới là người quản lý dự án. Có những công ty BRSE giống như PM vây.

Quản lý ở đây là quản lý tất cả mọi vấn đề trong dự án. Từ tiến độ dự án, resource, risk,... Một BRSE cần biết được dự án đang ở giai đoạn nào, tiến độ có đảm bảo hay không; lượng resource thừa thiếu đủ thế nào; giai đoạn nào cần chuẩn bị những gì để không xảy ra risk,... Đồng thời, khi có issue xảy ra thì kỹ năng giải quyết vấn đề là cần thiết. Nếu không tự giải quyết được thì phải báo cáo với sếp để sếp giải quyết hộ cho.

Bản thân mình cũng đang phải học hỏi rất nhiều kỹ năng này.

4. Japanese

Đương nhiên là phải có nếu muốn làm một BRSE. Tuy nhiên, mình đặt kỹ năng này cuối cùng vì đối với nghề BRSE tiếng nhật chỉ là một tool giúp bạn thực hiện công việc mà thôi. Đương nhiên nếu tiếng nhật tốt thì cũng là một lợi thế.

Làm thế nào để nâng cao những kỹ năng trên?

Mình xin nêu ra một số biện pháp của bản thân như sau: Đọc kỹ spec, tưởng tượng ra được flow của cả hệ thống.

Theo mình, nếu có thể trả lời được câu hỏi mỗi của chức năng của hệ thống dùng để làm gì và hoạt động như thế nào thì có thể gọi là hiểu spec. Ví dụ, hệ thống có chức năng login. Bạn hiểu được chức năng login dùng để đăng nhập vào hệ thống thì bạn hiểu được 50%. Nếu bạn hiểu được hệ thống sẽ lấy thông tin user input để so sánh với thông tin ở tbl abc, đúng thì cho login. Khi login được thì sẽ call api A để get và lưu thông tin vào local,... thì mới đạt yêu cầu.

Đặc biệt lưu ý quan trọng là không bao giờ được phán đoán spec. Nếu không biết thì phải hỏi, dù là những điểm nhỏ nhất cũng phải hỏi. Khách dễ tính thì không sao. Với khách khó tính chỉ hiển thị sai hình thức một chút thì họ cũng đã complain rồi. Và tuyệt đối không out of scope. Khách yêu cầu những gì thì làm nấy. Không được làm nhiều hơn. Nhiều khi ý tốt của bạn lại không đúng với requirement của người ta thì sẽ làm nảy sinh issue không đáng có.

Mỗi ngày trước khi ra về phải check lại tiến độ của team

Yêu cầu của mình đối với bản thân là theo sát team mỗi ngày. Việc này có thể thực hiện thông qua daily report của các member. Bản thân bạn cũng cần phải check lại tiến độ thực tế có khớp với nội dung báo cáo hay không nữa. Hoặc là tiến độ của thực tế có đúng với tiến độ yêu cầu hay không.

Làm thế nào để phát hiện ra vấn đề càng sớm càng tốt.

Kinh nghiệm xương máu

Có những thứ phải trải qua thì mới học được vì nó không thể có trong sách vở. Bản thân mình khá lười đọc sách. Nên mình thiêng về hướng học từ kinh nghiệm thực tế của chính bản thân hay của người khác. Những lúc không quá bận có thể đi lang thang ở các dự án khác xem người ta có gặp issue nào không, người ta giải quyết issue như thế nào. Hoặc đơn giản là học cách truyền đạt của người ta chẳng hạn.

Có sếp tốt

Cái này là vấn đề ăn ở thôi. Có một ông sếp tốt thì bạn sẽ học được nhiều thứ, định hướng phát triển sẽ rõ ràng hơn. Quan trọng là lỡ có issue gì không giải quyết được thì lôi sếp ra cho sếp giải quyết rồi ta đứng ngoài học hỏi. Đương nhiên là nếu đã gây ra issue to quá thì khả năng đợt tăng lương sắp tới sẽ không được tăng nhiều. Nhưng không sao, quan trọng là kiến thức mà =))