Để trở thành BrSE cần những yếu tố gì?

Ở bài viết trước, mình có giới thiệu qua "Khái quát về nghề BrSE" ở link sau: https://viblo.asia/AnhNTN/posts/QpmlenXM5rd. Trong bài viết này có nói qua có 3 yếu tố để trở thành BrSe là: Năng lực ngôn ngữ (Khả năng giao tiếp); Năng lực kỹ thuật; Năng lực quản lý. Nhưng sau khi tìm hiểu các bài báo, tài liệu viết về nghề BrSE thì mình thấy cần bổ sung thêm 1 năng lực nữa là: Năng lực hiểu hiểu về sự khác biệt văn hóa giữa các phía tham gia dự án. Như vậy để trở thành BrSE chúng ta cần có 4 yếu tố sau:

• Năng lực ngôn ngữ (Khả năng giao tiếp)
• Năng lực kỹ thuật
• Năng lực quản lý
• Năng lực hiểu hiểu về sự khác biệt văn hóa giữa các phía tham gia dự án

Ở phần tiếp theo, mình sẽ phân tích cụ thể về 4 yếu tố này. Không thể nói là yếu tố nào là quan trọng nhất vì còn phụ thuộc vào đặc điểm của dự án, đội ở offshore và khách hàng. Điểm quan trọng nhất là mỗi người có các năng lực khác nhau sẽ cần được bố trí vào các dự án cho phù hợp, ở các dự án mà cần nhất những thế mạnh của người đó.

1. Năng lực ngôn ngữ (Khả năng giao tiếp)

Khả năng giao tiếp ở đây là giao tiếp với khách hàng, giao tiếp với team phát triển, ngoài ra với dự án lớn là giao tiếp với bên thứ 3. Thường với dự án to, thì cụ thể là giao tiếp với các đội phát triển hay đội test mà khách hàng thuê (middleware, framework, test...) hoặc có thể là giao tiếp với 1 đội phát triển đánh thuê ngoài (dự án to, khi công ty không đủ nguồn lực thì phải thuê ngoài thêm). Như vậy theo qui mô của dự án mà mật độ và độ phức tạp của việc giao tiếp tăng lên. Năng lực ngoại ngữ chỉ là 1 phần trong kỹ năng giao tiếp, việc truyền đạt nội dung với cấu trúc đơn giản, rõ ý để giúp người nghe hiểu được ý định truyền đạt và tránh sự hiểu lầm giữa các bên là cực kỳ quan trọng. Một số điểm cần chú ý trong quá trình giao tiếp với các bên:

• Tất cả các bên, tất cả mọi người liên quan đều đồng ý/ hiểu chưa?
• Đội phát triển ở offshore đã thành 1 team và cùng hướng tới cùng 1 mục tiêu hay chưa?
• Các vấn đề phát sinh đã được báo cáo kịp thời về when, where, how (5W1H nếu cần thiết) hay chưa?

Ở Việt Nam thì khi giải quyết 1 vấn đề gì đó, mọi người thường nói xét về tình, xét về lý... Ở Nhật thì cũng tương tự như vậy, có những thứ là theo các cam kết giữa các bên, có những thứ thì phải xử lý mềm dẻo. Và việc giao tiếp ở trên chỉ là trong công việc, ngoài ra còn là các việc giao tiếp ngoài công việc để có sự thấu hiểu lẫn nhau. Hiểu về tính cách, cách làm việc, hiểu về những áp lực của phía bên kia, tình hình phía bên kia. Khi các phía có sự hiểu nhau như vậy thì việc thông cảm với nhau cũng dễ dàng hơn. Có khi mình phải đành động viên anh em ở nhà OT vì lỗi gì đó của khách, hay chậm trễ so với cam kết ban đầu... Nhưng cũng có khi sản phẩm mình làm ra nhiều bug hay lỗi cơ bản, hoặc chậm giao hàng… Nên việc khi thì cứng, khi thì mềm trong quá trình giao tiếp là rất quan trọng, việc này phụ thuộc vào kinh nghiệm, và khả năng phán đoán tình huống của mỗi người mà không có tiêu chuẩn hay qui tắc cụ thể...

2. Năng lực kỹ thuật

Không cần ở mức Guru nhưng cũng cần có thời gian học IT trong trường đại học hoặc tiếp xúc với các dự án IT trong một khoảng thời gian nhất định. Để hiểu được những nội dung khách hàng nói liên quan tới kỹ thuật. Việc mức độ cần của năng lực này cũng tùy vào qui mô dự án. Ở những dự án nhỏ thì BrSE phải làm rất nhiều thứ từ comtor, là key member về nghiệp vụ của khách hàng, là key về technical... Nhưng ở những dự án to hơn thì vai trò của BrSE sẽ tách dần, dần dần rời khỏi các công việc comtor, key về nghiệp vụ hay key về technical mà chủ yếu tập trung vào việc quản lý tiến độ và giao tiếp với các bên liên quan. Vì càng dự án to việc quản lý tiến độ, tracking các task và giao tiếp, họp với các bên chiếm rất nhiều thời gian. Nếu phải làm thêm các việc khác nữa thì dẫn tới bị quá tải và khả năng dự án gặp vấn đề là rất cao. Túm lại thì nên học một ngôn ngữ lập trình nào đó và khi nào có thời gian rảnh thì nên đọc thêm các bài báo liên quan tới kỹ thuật. Vì làm BrSE nghĩa là trong tương lai sẽ làm PM của dự án, chứ làm BrSE rồi chuyển sang làm việc chuyên sâu về technical chắc không ổn vì không có đủ thời gian để tâp trung vọc về technical.

3. Năng lực quản lý

Năng lực quản lý dự án, quản lý tiến độ, quản lý rủi ro. Nhiều bạn thiếu kỹ năng này hoặc không để ý, khách hàng nói gì làm vậy. Đến lúc sản phẩm không thành hình hài thì cả team khổ theo. Cần xác định cuối cùng khách hàng cần là gì? Là sản phẩm được giao hàng đúng theo thời gian và sản phẩm có chất lương theo như đã cam kết ban đầu. Nên trong quá trình làm dự án, luôn ý thức về tiến độ, rủi ro từng mục phát sinh, từng ngày để có thể thông báo cho các bên liên quan cũng như điều chỉnh các yếu tố liên quan… Nói chung là bạn đóng vai trò như 1 PM, sẽ phải đảm bảo các yếu tố về quality, cost, delivery (QCD) với 1 sản phẩm. Trong khi thực hiện dự án thì có rất nhiều các yếu tố phát sinh, nhưng luôn phải tìm cách cân mình tam giác QCD cho phù hợp nhất, gần nhất với tam giác QCD mà khách hàng mong muốn. Trong thực tế quan trọng nhất là việc quản lý tiến độ, các tool như JIRA, Redmine, Backlog chỉ giúp được 1 phần trong quá trình quản lý tiến độ. Mà tự bản thân mỗi người nên có những góc nhìn khác, tạo các góc phân tích khác nhau để có cái nhìn rõ ràng và chính xác hơn về tiến độ hiện tại của dự án. Điểm thứ 2 là quản lý rủi ro của dự án, việc đánh giá rủi ro cũng không cần quá máy móc nhưng cũng nên có 1 file để tổng hợp các rủi ro làm ảnh hưởng tới dự án. Trong khi chạy rồi, thì việc phát sinh nhiều CR (change requirement) là một trong những thứ hay mắc phải làm dự án cháy hoặc sản phẩm không nên hình hài...

4. Năng lực hiểu hiểu về sự khác biệt văn hóa giữa các phía tham gia dự án

Đây là điểm mà mình bổ sung so với bài viết trước đây. Việc hiểu văn hóa đặc biệt là những dự án triển khai ở 2 nước offshore (thời gian gần đây là mô hình Nhật Bản-Việt Nam-Philippine hay Nhật Bản-Việt Nam-Myanmar...) thì cần hiểu rõ văn hóa, cách làm việc, cách trao đổi..của các nước để có phương pháp làm việc cho phù hợp với nước đó. Với các dự án thông thường thì chỉ cần hiểu rõ văn hóa của nước outsource (Nhật, Mỹ..) và nước offshore (Việt Nam...) là đủ. Đặc biệt trong bài viết này mình đề cập tới văn hóa Nhật. Nếu bạn nào chỉ học tiếng Nhật mà chưa sang Nhật thì sẽ gặp rất nhiều khó khăn, vì người Nhật có rất nhiều thứ riêng và nói chung trong công việc rất tỷ mỷ, cụ thể, chính xác. Nhiều khi anh em hay nghĩ họ "củ hành" mình, suốt ngày bắt viết báo cáo, hay đúng giờ một cách máy móc, hay họp hành nhiều... Nhưng những việc hay qui tắc họ đề ra đều có những hiệu quả nhất định. Viết báo cáo để tìm nguyên nhân gốc rễ vấn đề, giúp chia sẻ với cả team nhanh hơn. Hay họp hành nhiều cũng là để các bên cùng nắm bắt tình hình, rủi ro, nguy cơ của dự án. Từ đó tìm giải pháp và điều chỉnh kế hoạch cho phù hợp.

Như các bài trước mình cũng có đề cập, BrSE là 1 thành viên của team và một mình BrSE cũng không giúp cho dự án thành công được, BrSE vẫn rất cần sự hỗ trợ của các thành viên khác trong team. Trên đây coi như chỉ là liệt kê các yếu tố cần có để trở thành BrSE, và cùng làm vị trí BrSE nhưng mỗi người có tố chất, kinh nghiệm làm việc khác nhau mà năng lực của các yếu tố cũng khác nhau. Quan trọng nhất là bạn cần biết mình yếu điểm nào, mạnh điểm nào và cần người như thế nào để bổ trợ cho bạn. Từ đó mà chọn người làm cùng, hay yêu cầu cấp trên bố trí người để giúp bù đắp cho bạn những điểm yếu nội tại. Và vì là 1 team nên cần phải để ý tới yếu tố "teamwork" làm thế nào để dự án thành công, khách hàng trả tiền và release đúng hạn, số bug trong phạm vi qui định của dự án là điều mà BrSe nên nghĩ, và tư duy trong quá trình tham gia một dự án nào đó.

Thường thì dự án qui mô nhỏ, khoảng dưới 10 người thì cần BrSE có sự cân đối nhất định của cả 4 yếu tố trên, Nhưng ở dự án càng lớn, đặc biệt là dự án có team BrSE, nghĩa là khi đó BrSE làm công việc của BrSE leader thì việc họp với khách hàng, hay điều phối về con người, quản lý ở tiến độ... sẽ mất rất nhiều thời gian thì khi đó BrSE sẽ phải xa rời yếu tố kỹ thuật và nhường lại việc quản lý về kỹ thuật cho người khác. Yếu tố cần nhất ở trường hợp này là khả năng ngôn ngữ, khả năng quản lý dự án để có thể chèo lái những dự án kiểu này.