CHIA SẺ KINH NGHIỆM BRSE/SE 3 NĂM LÀM VIỆC TẠI NHẬT BẢN [Phần 1]

CHIA SẺ KINH NGHIỆM BRSE/SE 3 NĂM LÀM VIỆC TẠI NHẬT BẢN [Phần 1]

Đặc điểm vai trò BrSE trong thực tế

 

Xin chào tất cả mọi người, mình là Trần Văn Mỹ hiện tại đang công tác tại chi nhánh Rikkei Japan. Sau một thời gian làm việc tại đất nước mặt trời mọc, mình đã đúc kết học tập được rất nhiều kinh nghiệm làm công việc BrSE/SE muốn chia sẻ với các anh em Rịch Kê đang muốn và sắp đi onsite. Hi vọng qua bài viết mình có thể cung cấp cho mọi người hay đặc biệt là các bạn, các em khoá dưới có ý định tìm hiểu, nhập môn công việc BrSE onsite tại Nhật Bản. 

 

 

Nếu nói BrSE có 2 hướng là chuyên về quản lý và chuyên về kỹ thuật thì mình chuyên về kỹ thuật hơn, mình vốn làm Developer ở Nhật rồi sau đó chuyển dịch dần tỉ lệ công việc sang BrSE, hiện tại là 70% SE 30% BrSE. Các dự án mình làm đều là dự án nhỏ nên kinh nghiệm cũng dàn trải ở nhiều vai trò khác nhau trong dự án. Về thuật ngữ KH (Khách hàng) mà mình dùng trong bài viết, thì các dự án mình tham gia đều có đội kỹ sư Nhật riêng và giao tiếp của mình chủ yếu với đội kỹ sư của họ chứ không phải là người ra yêu cầu thực sự, do đó KH ở đây ý mình là đội kỹ sư của họ.Giao tiếp với kỹ sư người Nhật dễ hơn rất nhiều so với giao tiếp với "khách hàng cuối", bởi vì ta có thể dùng thuật ngữ kỹ thuật để truyền đạt ý hiểu được, và cùng là kỹ sư đánh giá được thông tin của nhau dễ hơn, dễ hiểu và tin tưởng nhau hơn.

Đầu tiên thì mình xin định nghĩa vai trò BrSE theo cách hiểu của mình.

1. Vai trò của BrSE

Công việc của BrSE là người ở giữa, phiên dịch để đội khách hàng Nhật nắm được tình hình của đội phát triển Việt Nam, và đội Việt Nam hiểu yêu cầu của khách Nhật.

Về giá trị của BrSE thì hiện tại ở Nhật thì nếu ta nói nhân lực ngành nào cũng cần cũng đúng, nhưng nếu xét số liệu thì mình cảm giác so với tỉ lệ khách Nhật và developer Việt Nam thì BrSE có vẻ vẫn chiếm tỉ lệ nhỏ nên hiếm hơn bình thường.

Về tầm quan trọng của BrSE trong dự án, mình xin trình bày qua ví dụ như sau :

Ví dụ dự án có cơ cấu thành viên là 3 khách Nhật, 1 BrSE, 3 Developer Việt:

+ Khách Nhật vai trò là hiểu và đảm bảo spec và thường ở 1 công ty rất nhiều người, nếu 1 người nghỉ thì mình thấy thực tế thay người khác vào làm quen dự án 1 đến vài tháng là được.

+ Developer nghỉ thì công ty hoặc là thay người khác, hoặc thoả thuận với bên KH giảm scope dự án lại, nói chung là có nhiều cách xoay sở được, có thể đi chậm hơn nhưng vẫn đi được.

Nhưng BrSE nghỉ thì do tỉ lệ ít nên khó thay thế, mà không có ít nhất 1 người thì dự án rất khó chạy. Nói yếu tố thị trường ở đây tức là nếu thị trường có nhiều BrSE (hoặc là google dịch thực sự đủ tốt) thì dễ thay thế hơn, độ hiếm và mức độ quan trọng sẽ giảm.

Về yếu tố thị trường thì là như vậy, tiếp tục mình xin trình bày tiếp về vai trò của BrSE trong dự án.

Để dễ hình dung vai trò của BrSE thì mình xin so sánh với một vai khá gần với BrSE là Comtor, để ta có thể nhìn tương đối xem BrSE có vai trò khác như thế nào. 

2. Điểm khác giữa BrSE và Comtor

2.1. Lợi thế BrSE

BrSE khác với Comtor ở chỗ BrSE 1 phần cũng là SE, có thể hiểu được các vấn đề kỹ thuật. Điều này có 1 số ý nghĩa sau :

+ Giảm chi phí, tăng tính chính xác khi Communication về vấn đề kỹ thuật :

Ví dụ khi KH (khách hàng) yêu cầu rằng ta cần thực hiện dự án bằng Javascript. Nếu không phải SE (Software Engineer) thì rất dễ nghe nhầm Javascript với Java là 2 ngôn ngữ lập trình hoàn toàn khác nhau. Từ đó dẫn đến hệ quả là tuyển nhầm cho dự án toàn các developer Java chẳng hạn.

Hoặc ví dụ khi KH yêu cầu ta "sửa lỗi api 500 abc ở trang admin" chẳng hạn. Là SE thì ta biết được khi nói trang admin thường là nói đến trang quản trị đặc biệt có nhiều quyền mà người dùng thường không có, nếu không phải SE thì có khả năng nhầm với "trang quản lý". Với trang web bán hàng, thường có trang quản lý xuất nhập các mặt hàng và giá. Giả sử mà cả 2 trang đều có lỗi này thì có thể rất dễ nhầm giữa 2 trang.

+ Giảm chi phí tiền xử lý :

Mình lấy ví dụ nếu chỉ đơn thuần dịch thì ta sẽ có flow như sau :

. Khách --> Comtor : Bạn hãy xử lý vấn đề X này cho tôi nhé?

. Comtor --> Khách : Tôi hiểu rồi, tôi sẽ nói với developer

. Comtor --> Developer : Bạn xử lý cho mình vấn đề X này nhé. (OK)

. Developer tìm hiểu 15p

. Developer --> Comtor : Bạn hỏi KH về môi trường xảy ra và tên nhánh, nội dung biến môi trường cho mình nhé?

. Comtor --> Khách : (Hỏi lại như trên)

. Khách --> Comtor : Thông tin là A, B, C nhé.

. Comtor --> Developer : (Truyền đạt lại)

. Developer thực hiện

Lấy trung bình mỗi giai đoạn giao tiếp cần 5p, tổng có 7 giai đoạn, vậy tổng thời gian từ khi có vấn đề đến khi thực hiện = 15 + 5x7 = 50p

Với BrSE thì trong nhiều trường hợp ta có thể cải thiện được thành flow thế này :

. Khách --> BrSE : Bạn hãy xử lý vấn đề X này cho tôi nhé?

. BrSE --> Khách : Tôi hiểu rồi.

. BrSE tìm hiểu 15p

. BrSE --> Khách : Bạn cho mình thông tin môi trường xảy ra và tên nhánh, nội dung biến môi trường cho mình nhé?

. Khách --> BrSE : Thông tin là A, B, C nhé.

. BrSE --> Developer : Nhờ bạn xử lý cho mình vấn đề X, các thông tin liên quan là A,B,C nhé.

. Developer thực hiện

So sánh với flow ở trên thì ta thấy đã cắt được 2 trao đổi, tổng = 15 + 5x5 = 40p, giảm được 10p = 20% thời gian.

Ở đây có 3 điểm đặc biệt làm cho điều này có ý nghĩa đối với dự án nhỏ :

+ ~80% các vấn đề kỹ thuật độ sâu thường ở mức tổng quát, BrSE đủ khả năng tự phán đoán được mà không cần hỏi Developer.

+ Mặc dù ở trên cắt giảm được chỉ 10p, nhưng tần suất những trao đổi thế này trong project là thường xuyên, nên tính tổng lại là đáng kể.

+ Ở trên là cắt giảm được 20%, nhưng nhiều trường hợp còn đạt được tỉ suất cao hơn.

2.2. Lợi thế của Comtor

So với BrSE thì mình nghĩ là các bạn Comtor hiểu biết nghiệp vụ và kỹ năng xã hội tốt hơn, nếu khách hàng của dự án không phải là đội kỹ sư người Nhật như mình mà là user Nhật bình thường không hiểu kỹ thuật thì Comtor có lẽ tỏ ra ưu thế hơn.

3. Những chú ý khi bắt đầu công việc BrSE (với dự án nhỏ và vừa)

3.1. Sẵn sàng thay các vai khác trong dự án, nội dung công việc không cố định

Với dự án nhỏ quy mô 3-5 người thì mình thấy BrSE thuờng kiêm luôn cả Tester, tìm hiểu vấn đề, quản lý dự án v.v...

Với dự án lớn thì có lẽ là ngân sách là thoải mái để tìm người chuyên môn cao cho một vị trí, nhưng dự án nhỏ ngân sách nhỏ thì một người trung gian đảm nhiệm nhiều vai trò tỏ ra hiệu quả hơn.

Một cách hình tượng thì nếu so với bóng đá thì BrSE có lẽ là tiền vệ trung tâm, công việc chính của tiền vệ là kết nối giữa 2 tuyến hậu vệ và tiền đạo, nhưng khi cần thiết thì có thể tham gia cả tấn công lẫn phòng thủ.

Mình thấy vấn đề thường gặp với đặc điểm này đó là khi BrSE cảm thấy không phù hợp hay không muốn làm những công việc ngoài chuyên môn SE và tiếng nhật, kiểu như "mình BrSE mà cứ bị bắt làm tester....". Mình cũng không chắc đây là vấn đề mặt nhân sự hay là mặt dự án, nhưng để giải quyết thì có lẽ cần bàn bạc với cả đội dự án và phía công ty chủ quản (nếu outsourcing), tuy nhiên mình nghĩ đối với dự án mà nói thì khả năng thay vai của BrSE là rất có ý nghĩa, bạn làm được thì bạn cũng xứng đáng nhận được cảm ơn từ quản lý dự án. 

3.2. Vai trò ứng biến theo hoàn cảnh project và công ty

Với khả năng thay vai trò ở trên thì từ góc độ công ty, công ty có thể điều chỉnh tỉ lệ tham gia dự án của BrSE để tăng tổng lợi ích.

Ví dụ nếu đang trạng thái có 2 dự án, 1 BrSE, 8 Developer (thiếu BrSE) thì có thể chia thành mỗi dự án 4 Developer và BrSE làm cả 2 mỗi cái 0.5.

Còn nếu trạng thái là 1 dự án, 1 BrSE 1 Developer (thiếu Developer) thì có thể điều chỉnh để BrSE làm 0.5 BrSE và 0.5 Developer.

Tức là với vai trò là BrSE thì ta nên hiểu rằng có thể sẽ nhiều lúc phải cân nhắc vì lợi ích của dự án và công ty nói chung mà sẽ có vai trò bị thay đổi. Như vậy mình thấy về mặt cá nhân cũng không hẳn là không tốt, có được kiến thức nhiều mảng khác nhau là điều cũng rất thú vị mà cũng là cơ hội không dễ có được khi làm SE.

Ngoài ra những chú ý chung ở trên, nếu là BrSE xuất thân kỹ thuật SE như mình thì mình có chú ý riêng như sau :

3.3. Mỗi dự án một khác

Khi bắt đầu một công việc mới thì thói quen thông thường là ta sẽ đi hỏi xin kinh nghiệm các đàn anh đi trước, bạn bè đồng nghiệp, cấp trên đã có kinh nghiệm làm. Đây là thói quen tốt và rất cơ bản, nhưng theo mình thì nếu hỏi thì nên hỏi 10-20 người thay vì 2 đến 3 người, vì thường mình thấy mỗi người sẽ trả lời một phần trong bức tranh, mà mỗi dự án lại là 1 bức tranh khác. Để hình dung thì giống như nếu tính "những điều BrSE cần biết khi làm dự án" tổng là 100 điều thì hỏi người A sẽ nhận được trả là 1,4,5,6, hỏi người B nhận được 2,4,96,97. Vấn đề là dự án cần 1,4,44,100, để biết được những cái đó thì ta phải hỏi thêm rất nhiều người khác để biết thêm 44, 100. Nếu hỏi vì sao dự án cho BrSE rất đa dạng thì có lẽ là do đặc thù yêu cầu công việc cho BrSE khác với SE chỉ làm với ngôn ngữ hay OS sở trường. Đối với BrSE thì yêu cầu chuyên môn ở mức độ ít sâu hơn cũng được, chuyên môn thì dành cho SE ở phía sau, làm được như vậy thì hiệu suất cả công ty cao hơn. Mỗi dự án lại là một ngôn ngữ, một framework, một OS, một đội khách hàng với tính cách khác nhau v.v..., kỹ thuật khác nhau cũng tác động làm tính chất dự án khác nhau. Cần chú ý bởi vì BrSE xuất thân SE thì ta thường có thói quen giải quyết vấn đề dựa trên những kiến thức stable - tĩnh, ví dụ như đọc document API, đọc tutorial v.v... đọc hiểu 1 lần thì có thể dùng xuyên suốt mấy năm sau được. Nhưng khi làm dự án với vai trò BrSE thì các dự án nhỏ thì mỗi dự án liên quan đến một lĩnh vực và cấu trúc dự án cũng khác nhau, để làm quen dự án mới thì cần có tâm lý chuẩn bị và sẵn sàng với những kiến thức hoàn toàn khác với những gì đã biết.

3.4. Cần khả năng "giải quyết vấn đề thực tế bằng kỹ thuật" ngoài "giải quyết vấn đề kỹ thuật"

Các vấn đề khách hàng truyền đạt cho BrSE thường có mức độ trừu tượng cao hơn các vấn đề khi ta còn làm SE.

A. Nếu trước là SE thì ta hay gặp yêu cầu ví dụ thế này : "Em thêm nút/link này vào giao diện X chỗ này nhé?"

B. Còn giờ nếu là BrSE thì ta có thể gặp yêu cầu thế này : "Bây giờ chúng tôi đang muốn làm chức năng A này, các bạn làm được không?"

Ta có thể thấy vấn đề A đã khá cụ thể về mặt kỹ thuật và hầu như khá chắc chắn làm được, vấn đề B thì từ đó sẽ tách ra thành các task con mà có thể 1 trong các task con đó chính là A, nhưng người hỏi cũng chưa chắc chắn làm được, hay nói cách khác là trừu tượng hơn A. Vấn đề ở đây là ta cần có khả năng đánh giá tính khả thi của B và tách được B thành các task con A đó. Để làm được việc này thì đơn giản nhất là ta cần có hoặc là kinh nghiệm hoặc là thông tin. Kinh nghiệm tức là trước đó mình từng làm hệ thống tương tự rồi, lần này mình cũng làm tham khảo theo đó. Thông tin tức là dù nghiệp vụ đó mình chưa phát triển bao giờ, nhưng mình có một chút chuyên môn về nghiệp vụ đó rồi, hoặc là mình tham khảo các nghiệp vụ khác thì thấy thường là nó sẽ làm như thế C, D này. Tức là ta sẽ cần phải tích lũy kinh nghiệm và kiến thức về các lĩnh vực nghiệp vụ đến một mức độ nhất định, ngoài việc tích lũy kiến thức kỹ thuật.

3.5. Cần truyền đạt không chỉ công việc mà cả cảm xúc.

Trước đây thì đôi khi mình nghĩ đơn giản BrSE chỉ cần truyền đạt nội dung công việc là đủ, nghĩ lại nếu chỉ như vậy thì e là dự án có thể vẫn chạy được nhưng không chạy hiệu quả được. Mình ở bên Nhật ngồi cạnh khách người Nhật thì có thể nghe trực tiếp họ truyền đạt, cảm xúc, giọng điệu khi nói mình đều cảm nhận được. Ví dụ độ gấp, độ quan trọng của task mình nghe họ nói trực tiếp cảm thấy rất hiểu và muốn khắc phục cùng với họ. Vấn đề ở chỗ là lẽ ra thì ta cũng cần truyền tải toàn bộ "nội dung" đó cả công việc cả cảm xúc đến developer thì thông thường ta chỉ làm được mỗi phần công việc, như vậy thì không đủ.

Để giải quyết vấn đề này thì theo mình nên làm được 2 việc sau :

a. Hoặc là message text thật là nhiều, hoặc là chat video.

Message text có giới hạn thông tin thì ta message thật nhiều cho đủ.

Chat video thì ta truyền đạt bằng hình ảnh và âm thanh, dễ bao gồm cả cảm xúc.

b. Developer tích cực nắm bắt thông tin khách hàng.

Tức là developer thay vì suy nghĩ là "hiểu nội dung task là được" thì giờ là "sẵn sàng nghe về nội dung task và các thông tin liên quan nếu có. Và BrSE có nói nhiều 1 chút thì cũng tích cực nắm bắt chứ không đơn thuần là chỉ hiểu nội dung công việc.

Liên quan đến phần truyền đạt cảm xúc này thì mình thấy còn 1 điểm nữa cần lưu ý, đó là thông thường nếu không để ý thì BrSE dễ mắc vấn đề là chỉ truyền đạt sự gấp gáp, quan trọng của task mà không truyền đạt được sự đánh giá, cảm ơn của khách hàng khi hoàn thành task. Như vậy thì rất dễ làm cho Developer cảm thấy bị áp lực trong thời gian dài, hoặc là BrSE nói dối (lúc nào cũng giục là điều khá bất thường). Ngược lại nhận được lời khen ngợi hay tán dương thì thực hiện công việc cũng vui vẻ hơn, BrSE ta nhận điều đó thì KH rồi và cũng cần có trách nhiệm truyền đạt lại điều đó cho Developer phía sau.

Kết

Comtor hay BrSE hợp với dự án hơn thì có lẽ là tuỳ dự án, và cũng tuỳ theo năng lực của từng cá nhân cụ thể. Mình biết những bạn học kỹ thuật nhưng rất giỏi ngôn ngữ (cả Anh cả Nhật) và hiểu biết xã hội như Comtor, hay các bạn không học kỹ thuật, chỉ học ngôn ngữ ở đại học nhưng vẫn tự học kỹ thuật, làm PM cho dự án v.v... Dự án thực tế cần người giỏi không chỉ 1 kỹ năng, nên mình nghĩ ta không cần quan trọng mình làm vai gì, mà là mình có những năng lực gì, đến đâu và phù hợp với dự án như thế nào.

Tiếp theo mình xin chia sẻ những điều mình thấy cần chú ý khi bắt đầu công việc BrSE.