Chuyển Từ Coder Sang Cầu Nối BRSE Tại Nhật

Share

• Facebook

Sắp 3 tháng làm ở công ty mới trong vị trí mới- BRSE. Hôm nay ngồi tâm sự 1 chút về sự khác nhau giữa 2 vị trí này.

Nói thêm: ad xuất thân là NonIT mà lại làm việc trong công ty Nhật. Nên thời gian đầu làm coder thấy cực nhọc. Cái gì cũng phải học, từ ngôn ngữ lập trình, tư duy logic, database… chưa kể cách làm việc của người Nhật, rồi cả tiếng Nhật. Nhưng khi quen rồi thì lại thấy nếu chỉ làm coder ở Nhật thì rất phí. Nên chuyển sang làm cầu nối BRSE. Và hiện tại thấy mình khá hứng thú và phù hợp với vị trí này.

★Coder tại Nhật

Hồi làm coder hay còn gọi là dev ad luôn có 3 mục tiêu để cố gắng:1. Việc gì chưa làm được thì phải cố gắng làm cho được2. Việc gì làm được rồi thì cố gắng làm nhanh hơn3. Những việc mới thì cố gắng xung phong nhận làm để tăng số việc mình có thể làm được

Muốn làm được mục tiêu 1 thì cẩn phải thật hiểu vấn đề và chia nhỏ công việc ra để giải quyết.

Thực hiện mục tiêu 2 bằng cách đặt thời gian trước khi làm mỗi việc.

Muốn có cơ hội để thực hiện mục tiêu 3 thì phải làm tốt mục tiêu 2. Làm tốt rồi thì quay ra nói vs leader: ○○さん、これから手が空いてしまいますが。。。từ giờ tôi rảnh rỗi rồi…

Vậy nên ngoài công việc chia theo WBS trong team, ad thường được a leader giao cho những việc tìm hiểu những vấn đề kỹ thuật ứng với yêu cầu của khách hàng. Hoặc những điều tra khi có bug ở 1 bộ phận mà cần phải rà soát lại cả hệ thống 横展開（よこてんかい）…

■Tóm lại về Coder

Túm váy lại: hồi làm dev thì chỉ cần biết nhiệm vụ của mình và làm tốt. Nếu làm nhanh, làm tốt thì làm thêm các task khác. Không cần care rộng nhưng phải biết thật sâu.

★BRSE- cầu nối

Vai trò của cầu nối là nối 2 team- Nhật -Việt. Đinh nghĩa đơn giản vậy nhưng theo ad: tùy theo level của BRSE mà phạm vi công việc cũng khác nhau rất nhiều. Nhưng cơ bản thì BRSE là người ở giữa, sẽ phải làm tất cả những việc để 2 bên có thể hiểu nhau và làm việc trơn tru.

Vậy những công việc đó là những công việc gì? Dưới đây là kinh nghiệm gần 3 tháng làm việc của ad:

■Những công việc thường gặp của BRSE

1 Quản lý giao tiếp giữa 2 team Việt- Nhật

Khi triển khai dự án về bên Việt Nam. Thời gian đầu của dự án, BRSE thường bị team VN hỏi rất nhiều về nghiệp vụ. Nhiệm vụ của BRSE lúc này là xác nhận chính xác phía VN muốn hỏi gì, rồi trả lời. Nếu trả lời không được thì sẽ chuyển về phía Nhật để có câu trả lời.

Tới đây các bạn sẽ thấy, nếu BRSE cứng và nắm được nghiệp vụ, thì sẽ trả lời được luôn và không cần tới bên JP phải trả lời. Vừa chính xác và nhanh chóng. Còn nếu còn lăn tăn hoặc không biết câu trả lời, phải xác nhận hoặc hỏi bên JP thì rõ ràng giao tiếp ở đây tăng lên rất nhiều và khả năng truyền thông tin không hoàn toàn chính xác cũng không phải là ít. Tới đây các bạn sẽ biết vì sao các công ty muốn tuyển BRSE có IT chứ không chỉ là các commutor thông thường. Nếu được chọn 1 người có IT mà tiếng Nhật kém hơn người có tiếng Nhật mà nonIT thì nên chọn người có IT.

Kể cả bạn là người có IT nhưng không theo giai đoạn thiết kế của dự án mà vào ngang hoặc cùng lúc vs team VN. Thì bạn phải dành thời gian để hiểu nghiệp vụ sẵn, như vậy mới chuẩn bị được cho trường hợp phía Vn hỏi .

Khi phía Nhật có yêu cầu mới hay có những thay đổi thì nhiệm vụ của BRSE là phải xác nhận thật rõ yêu cầu rồi mới triển khai về VN. Tránh tình trạng sai 1 li đi 1 dặm.

Vậy nên ở đây ad mới dùng từ Quản lý giao tiếp. Vì nó quan trọng và BRSE hoàn toàn có thể chuẩn bị và quản lý tốt được. Mục đích vẫn là truyền thông tin nhanh và chính xác nhất tới 2 bên. Giảm thời gian lãng phí của dự án.

2. Quản lý và báo cáo tiến độ của team Việt Nam

Thử đặt mình vào vai trò PM của Project- là người Nhật. Điều hắn quan tâm khi dự án đang được tiến hành là gì: đó chính là biết được tiến độ. Mà người quản lý tiến độ phía VN là BRSE. Nên 1 nhiệm vụ quan trọng của BRSE là phải nắm được tiến độ của dự án phía Việt Nam.

Tất nhiên PM không muốn nhận 1 cái báo cáo aimai- mơ hồ về tiến độ. Điều BRSE cần làm là xác định rõ ràng thực tế xem bên Vn làm tới đâu rồi, chứ không phải chỉ nhận báo cáo của phía Việt Nam rồi chuyển ngay sang phía Nhật. Nếu BRSE là người giỏi bóc tách công việc, thì sẽ bóc tách công việc nhỏ hơn để kiểm tra code hoặc tính năng xem, phía VN làm được bao nhiều % rồi.

Một ví dụ đơn giản: mẹ bạn trước khi đi ra khỏi nhà có qua lại nhắc bạn 1 câu: Mạnh ở nhà dọn dẹp nhà cửa đi nhé.Bạn vâng vâng, dạ dạ quét qua cái nhà. kết quả là tối về bị ăn đòn. Vì cùng là công việc dọn dẹp nhà cửa thì mẹ bạn nghĩ: phải quét nhà, lau nhà, giặt quần áo… còn bạn chỉ nghĩ là quét nhà. Bạn báo cáo làm xong 100% nhưng với mama thì mới chỉ có 20% thôi.

Nói tới đây các bạn sẽ hiểu chúng ta cần 1 cái chuẩn để 2 bên cùng nhìn vào và hiểu. Và BRSE sẽ là người nghĩ ra cái này để thống nhất vs 2 bên.Trường hợp BRSE không làm được tới mức độ này thì PM hoặc leader sẽ là người đưa ra chỉ thị: báo cáo công việc theo list…

Tới đây thì các bạn sẽ thấy: các commutor sẽ không thể làm tốt được việc này. Kể cả cho dù có IT thì việc 1 BRSE nghĩ ra và tự thống nhất vs 2 bên cũng ko chắc sẽ có nhiều.

3. Quản lý chất lượng của team Việt Nam

Thông thường trước khi bàn giao cho khách hàng. Bên Nhật sẽ test lại sản phẩm lần cuối. Tuy nhiên để tới lúc cuối mới test mà ra nhiều bug thì rất mệt mỏi. Có thể dẫn tới trễ dự án. BRSE có IT thì có thể test được ngay trong lúc bên VN vừa hoàn thành xong 1 tính năng hoặc 1 màn hình nào đó. Có thể không cần quá chi tiết, nhưng run cơ bản là phải pass thì mới ổn.

BRSE càng có nhiều kinh nghiệm trận mạc thì càng phát hiện được nhiều bug và giúp cho chất lượng của dự án tốt hơn. BRSE khủng hơn thì phải review code và bắt lỗi cách code của dev nhà mình. Sao cho code sạch, gọn để sau này có muốn sửa hay mở rộng dự án vẫn ngon lành và không tốn time. Điều này thì các commutor không thể làm được.

4 Quản lý những tình huống phát sinh và các công việc khác

Ví dụ như chuyện dịch tài liệu cũng thực sự tốn time. Ad chưa có nhiều kinh nghiệm làm BRSE, không hiểu các dự án khác thì thế nào. Chứ 2 dự án đang làm hiện tại tài liệu dịch cần nhiều quá trời. Hở ra là phải dịch. Thực sự tốn thời gian.

Trong quá trình quản lý dự án còn rất nhiều vấn đề mà BRSE là người ở giữa phải giải quyết. ví dụ như thằng leader Nhật đưa ra yêu cầu rất củ chuối hoặc mình biết luôn là ko hợp lý. Khuyên rồi mà nó không nghe thì lúc yêu cầu Vn mình làm, lại phải nhắn tin riêng cho dev là: a nghĩ cái đó không hợp lý, khuyên rồi nhưng bên jp không nghe, e cứ làm theo yêu cầu. Không viết vậy thì dev ở nhà nó chửi cho vỡ mặt. Nhiều dev hiền bảo gì cũng nghe, nhưng cũng nhiều ông ngang như cua á.

Phía trên là chút kinh nghiệm về những việc mà BRSE thường làm với kinh nghiệm ít ỏi của bản thân. Dưới đây xin chia sẻ 2 dự án thực tế mà ad đang làm BRSE.

■Các dự án hiện tại đang làm và kinh nghiệp rút ra

Mặc dù mới vào công ty chưa được 3 tháng, nhưng ad đang làm BRSE cho 2 dự án đồng thời. Dưới đây xin chia sẻ về một số điểm về 2 dự án này. Từ sự khác nhau giữa 2 dự án này, ad hiểu hơn về vị trí BRSE này.

1. Dự án 1- dự án về app cho Ipad

Vào công ty từ tháng 1/2020 ad đảm nhận 1 dự án nhỏ về App cho ipad . Project này kéo dài 3 tháng (từ tháng 1-3), có 4 người: 2 Nhật( ad vs lead Nhật) 2 dev Việt. Dự án này a theo từ giai đoạn 要件定義 – đi họp lấy yều cầu của khách, rồi về thiết kế design rồi triển khai với offshore. Tới thời điểm này mọi việc diễn ra tốt đẹp, và khách hàng đang test sản phầm.

Project này ad theo từ đầu, vừa tham gia lấy yêu cầu và thiết kế. Nên nghiệp vụ về dự án ad nắm = leader. Vì mình là người thiết kế chính, leader review xong mang đi review với khách hàng.

Nên việc làm trung gian giao tiếp Nhật – Việt không nhiều(1 Quản lý giao tiếp giữa 2 team Việt- Nhật). Vì cơ bản phía VN thắc mắc gì thì ad care gần như hết.

Việc quan trọng lúc này chỉ là: 2. Quản lý và báo cáo tiến độ của team Việt Nam và 3. Quản lý chất lượng của team Việt Nam

Về việc báo cáo tiến độ thì ad bóc tách công việc theo đầu mục trong WBS rồi cho bên JP review. Bên JP okie thì ad cho bên VN báo cáo theo list đó. Nói chung là ổn nhưng dù có vậy thì thời gian ngồi check tiến độ cũng mất khá nhiều.

Về việc quản lý chất lượng, check code thì cũng thực hiện khá ổn. Mặc dù chưa có code IOS bao giờ nhưng đọc code swift vẫn hiểu.

Nói chung dự án này theo từ đầu nên kiểm soát được hết. Dự án này của khách hàng lần đầu làm việc với, nên công ty khá chú trọng. Nên bên JP được nhận 2 dev khủng IOS từ offshore.Tới hiện tại thì vẫn đang được đánh giá là ổn về tiến độ và chất lượng. Sắp tới khả năng nhận được thêm việc từ khách hàng này.

2 Dự án 2- Dự án web dùng Spring

Cuối tháng 2 đang làm dự án 1 thì bị gọi vào làm dự án này. Về cơ bản thì dự án này sếp bên trên bất thình lình nhận, cơ chế bất ổn ngay từ đầu. Ad nhớ ngày 19/2 triển khai về Việt Nam mà ngày đó mới gọi mình vào dịch tài liệu. Vừa làm dự án 1 vừa dịch và giải đáp thắc mắc cho phía VN và báo cáo tiến độ cho dự án 2, thực sự rất bận.

Đúng lúc dự án 1 đang bận nên giai đoạn đầu của dự án 2 này mình chỉ dịch tài liệu sao cho kịp triển khai ở VN. Bên VN có thắc mắc thì mình sẽ liên lạc vs bên Nhật và quản lý tiến độ thôi. Tuy nhiên trong lúc dịch thì mình vẫn cố gắng nắm nghiệp vụ để nếu bên VN có hỏi thì có thể trả lời liền. với những câu hỏi sâu thì không có thời gian tìm hiểu nên đá sang luôn cho bên JP.

Rất may leader VN của dự án 2 này rất hiểu cách làm việc với người Nhật nên mình thấy dễ dàng và tin tưởng khi làm việc cùng. Thêm 1 điểm mạnh nữa của leader Vn này có khả năng quản team. Làm việc với những người như vậy rất nhàn.

Hiện tại dự án 1 khách hàng đang test nên ad dành thời gian nhiều hơn cho dự án 2 này. Tìm bug khí thế và theo dõi tiến độ của team Vn sát hơn.

2 dự án cho ad 1 cái nhìn toàn cảnh hơn, lúc nào phải làm gì và cần làm gì. Ví dụ như dự án 1 vì mình làm cả thiết kế,nên quản lý giao tiếp cực dễ dàng. Nhưng dự án 2 thì mỗi lần bên VN có question, vì không theo từ đầu nên phải xem lại nghiệp vụ chút, rồi xem có trả lời được thì trả lời luôn. Không thì chuyển cho bên JP. Bên JP trả lời mình cũng phải xem và xác nhận thật chắc chắn rồi mới chuyển về VN. Thấy việc quản lý giao tiếp lúc này tốn rất nhiều thời gian. Tới đây mình hiểu vì sao nhiều dự án thất bại khi làm việc với offshore.

Dự án thứ 2 có 2 người bên Nhật làm thiets kế, nhưng ko thực sự cứng nên thiết kế cứ thay đổi liên tục. May mà dev mình ở nhà hiền. Không thì mình cũng vỡ đầu rồi.

■Tóm lại về BRSE

Bạn đọc tới đây có thê thấy, BRSE cần nhiều kỹ năng quản lý và sắp xếp công việc. Mặc dù vẫn phải nắm kỹ thuật để có thể làm design hoặc check sản phẩm, review code… Nhưng việc quan trọng hơn vẫn là quản lý giao tiếp giữa 2 bên và quản lý tiến độ của bên Việt Nam.

Ví dụ như dev bên VN mình có 4 người mà ngày mai hết việc mà không giao việc thì cả 4 ông ngồi chơi. Việc báo cáo liên lạc hay trao đổi cũng là cực kỳ cần thiết với 1 BRSE.

Từ lúc đi làm BRSE ad luôn tự nhủ: hãy làm việc như dự án này là dự án của mình vậy. Có tư tưởng đó thì thực sự tự mình sẽ nghĩ ra được rất nhiều việc có thể làm và nên làm để cho dự án tốt hơn.

Xin hết bài chia sẻ ở đây và hy vọng giúp ích được chút thông tin cho các bạn.

Comments

comments