CÁC KỸ NĂNG HỖ TRỢ CÔNG VIỆC BRSE/SE  [PHẦN 2]

CÁC KỸ NĂNG HỖ TRỢ CÔNG VIỆC BRSE/SE [PHẦN 2]

Các kỹ năng hỗ trợ công việc BrSE/SE

 

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. Mình xin được tiếp tục chia sẻ với mọi người về kinh nghiệm làm SE nói chung và BrSE nói riêng của mình.Ở phần 1 mình đã được chia sẻ với mọi người về những đặc điểm, vai trò của công việc BrSE cũng như những lưu ý khi thực hiện công việc trong thực tế. Ở phần 2 mình xin tiếp tục trình bày về những kỹ năng cần có của công việc BrSE và kinh nghiệm xử lý một số tình huống trong thực tế theo đánh giá của mình. Hi vọng sẽ cung cấp được những thông tin để mọi người có thể tham khảo được khi thực hiện công việc BrSE trong thực tế.

4. Các kỹ năng chính

4.1. Tiếng Nhật

- Tối thiểu: JLPT N2 hoặc JLPT N3 giao tiếp nghe nói tốt. Mình nghĩ trong tất cả kỹ năng cần có thì đây là kỹ năng quan trọng nhất. Trình độ tiếng Nhật của BrSE là một trong những nút thắt cổ chai của dự án, tiếng Nhật của BrSE giống như kênh đào Panama nối Đại Tây Dương với Thái Bình Dương, tất cả tàu thuyền spec, bug, tính năng của dự án đều phải đi qua. Bản thân tự mình trải nghiệm thấy BrSE mà tiếng nhật yếu thì làm việc thực sự khó.

+ Các cấp độ tiếng Nhật của BrSE theo thứ tự tăng dần :

i. Nghe hiểu được khái quát spec: đa phần là truyền tải nguyên yêu cầu khách đến đội phát triển, truyền tải có chút sai sót nhưng vẫn truyền đạt được những ý cơ bản.

ii. Nghe hiểu được spec và giải thích được vấn đề kỹ thuật/trạng thái dự án để khách hàng hiểu: bằng cấp độ trên + khả năng giải thích vấn đề/trạng thái của đội phát triển đến khách hàng.

Yêu cầu thêm: Tiếng Nhật IT và khả năng diễn đạt (theo phong cách Nhật)

iii. Có thể góp ý thảo luật cải thiện spec, đóng vai trò ngang hàng với thành viên đội khách hàng :

Yêu cầu thêm từ ii: kiến thức văn hoá Nhật và kiến thức xã hội bằng tiếng Nhật : cấp độ này yêu cầu mình sẽ phải thường giải thích và bàn bạc với khách về spec, mà nói về spec thì mindset phải như một user người Nhật thực sự, tức là những gì người Nhật biết thì mình cũng biết. Ví dụ như nếu làm website về nước hoa chẳng hạn, để đến mức độ trao đổi về spec được thì mình phải dùng và hiểu đa số các loại nước hoa nổi tiếng ở Nhật.

iv. Có thể tư vấn spec. Tự quyết định được và thuyết phục được spec đó :

Vai trò này tương đương với vai trò khách hàng ở 3 cấp độ trên. Còn khách hàng trong trường hợp này là người bị thuyết phục và trả tiền.

Yêu cầu thêm từ iii : kiến thức văn hoá Nhật và kiến thức xã hội bằng tiếng Nhật phong phú gấp cấp iii n lần.

4.2. Kỹ thuật

Tối thiểu cần kiến thức cơ bản về domain CNTT mà project yêu cầu và tiếng Anh Toeic > 600

Khác với tiếng nhật chỉ có một số domain về ngôn ngữ như từ vựng, kanji, ngữ pháp thì các domain riêng lẻ của CNTT rất nhiều : phần mềm, phần cứng, website, mobile app, blockchain, AI ..., không thể nắm hết tất cả trong khoảng thời gian đại học được, nên xác định thế nào là cơ bản là vấn đề tương đối, và nên đánh giá theo domain mà project đó yêu cầu.

Kinh nghiệm của mình khi chuẩn bị năng lực kỹ thuật cho một dự án đó là làm thử tutorial và đọc document liên quan đến kỹ thuật đó vài tuần. Ví dụ dự án website với Framework X thì ta tự làm 1 website với tutorial của Framework X đó, nếu project về mobile app thì có thể tự tạo 1 project hello world trên OS đó.

5. Các kỹ năng phụ

5.1. Kỹ năng xã hội

5.1.1. Kỹ năng mềm

Kỹ năng mềm ý mình bao gồm các kỹ năng đối nhân xử thế như giao tiếp, chào hỏi, để ý, quan tâm giúp đỡ mọi người trong team, khách hàng, đi nhậu, đá bóng cùng v.v...Mặc dù đây là kỹ năng mình thấy vai trò nào cũng cần nói chung chứ không chỉ BrSE. Đối với dự án, kỹ năng mềm giúp cho trao đổi thông tin trong dự án trở nên dễ dàng hơn. BrSE có kỹ năng mềm tốt sẽ làm cho mọi người trong dự án cảm thấy thoải mái khi chia sẻ thông tin cùng, các bên có sự tin tưởng và phối hợp ăn ý với nhau hơn. Ví dụ thoải mái đến mức độ bạn phát triển việt nam có thể nói "thứ 2 tuần sau mình đi xe từ quê ra nên xin nghỉ buổi sáng nhé" thay vì "sáng thứ 2 mình nghỉ buổi sáng", khách hàng bảo "mai anh lên viện khám chút, đến muộn vài tiếng nhé" thay vì "mai anh nghỉ sáng nhé". Những thông tin liên quan không phải là không có giá trị, bạn developer đi xe máy cả trăm cây buổi sáng lên công ty, đến đã mệt rồi thì mình không nên đến phát giao 1 đống task logic nặng đầu, anh khách hàng đi khám về mà kết quả xấu thì khả năng là tâm trạng không tốt, dự án nên xem xét điều chỉnh giảm việc 1 chút hôm đó chẳng hạn. Hoặc đôi khi nhờ đó mà ta có những thông tin quan trọng ảnh hưởng nhiều đến dự án, đi uống bia cùng mới biết bạn developer có thể tự làm design 1 số ảnh đơn giản, anh khách trước du học người ngoài nên tiếng Anh rất tốt chẳng hạn v.v... Những thông tin đó với môi trường ở Nhật thì thường ở văn phòng mọi người tránh nói các vấn đề cá nhân nên chỉ họp dự án thôi thì không biết được.

5.1.2. Kỹ năng xử lý tình huống

BrSE cho dự án nhỏ thì thường kiêm làm luôn PM nên những kỹ năng xử lý tình huống ở đây chủ yếu liên quan đến công việc của PM.

Nếu trước đây với vai trò SE ta chỉ cần xử lý những task phát triển thì giờ xử lý cả ví dụ những tình huống như sau :

+ Từ đội phát triển:

- Giữa chừng dự án đổi người

- Member phát triển nghỉ đúng thời điểm gấp

- Kỹ năng đội phát triển không thực sự khớp với kỹ năng dự án cần

+ Từ phía khách hàng :

- Giải thích về tình trạng/kỹ năng member phát triển ảnh hưởng đến dự án

- Đánh giá khả năng đội phát triển nếu nhận task khó hơn, thời gian phase bị điều chỉnh ngắn lại

- Ước lượng nhanh thời gian làm task của member

+ Các tình huống khách quan :

- Lịch nghỉ lễ của Việt Nam và Nhật Bản khác nhau, tính chia task trước vào ngày nghỉ

Để xử lý tốt các tình huống này ta cần kiến thức xã hội nói chung và kiến thức quản lý dự án nói chung một cách đa dạng.

5.2. Kỹ năng kỹ thuật phụ

5.2.1. Excel hoặc Spreadsheet

Dự án thực tế mình rất hay đóng cả vai Tester, phải làm các phép tính thống kê, những trường hợp này mình thấy dùng formula của Excel hay function của Spreadsheet cực kỳ tiện.

Ví dụ như khi task là kiểm tra chức năng vừa mới phát triển, đưa thông tin giá 100 sản phẩm ra màn hình đã đúng công thức chưa chẳng hạn.

Thông thường để làm task này thì ta có thể vào Database bằng command line hoặc tool, select ra vài cột sản phẩm liên quan, copy từng số ra rồi thực hiện cộng trừ nhân chia, cuối cùng là xem số tính ra đã khớp với hiển thị chưa. Xong rồi thì lại làm tương tự với vài sản phẩm khác. Đối với trường hợp này thì thay vì phải cộng trừ lại từng cột thì ta có thể chỉ cần tạo 1 formula sẵn cố định, rồi copy dữ liệu cho đúng cột là có thể tiết kiệm được rất nhiều công sức cho các sản phẩm sau. Ngoài ra thì trường hợp này nếu thông thạo sql ta có thể làm hiệu quả hơn nữa bằng cách xuất kết quả sql dưới dạng csv, bật csv bằng Excel và tạo cột formula ở cạnh, ta có thể tính cho cả nghìn sản phẩm trong vài phút.

5.2.2. Regular Expression (Regex)

Đây là kỹ năng mà chắc chỉ BrSE xuất thân từ SE mới biết, và khá cơ bản với SE. Regex là kỹ năng mình đã dùng rất nhiều từ khi còn thuần SE, cho đến giờ chuyển sang "1 nửa BrSE" thì vẫn còn dùng, và mình nghĩ sẽ còn tiếp tục vì thấy phạm vi áp dụng rất rộng.Regex là gì bạn có thể search google để tìm hiểu rõ hơn.Với SE thì sự tiện lợi của kỹ năng này có lẽ quá rõ ràng, với BrSE thì có lẽ ứng dụng vào các task điều tra bug (調査) là nhiều. Ví dụ khi ta có 1 bug ở là ở giao diện hiển thị text "SE" thay vì "BrSE", nhưng trước khi sửa thì KH muốn ta báo cáo là tổng cộng có bao nhiêu chỗ, ở vị trí giao diện nào xuất hiện. Khách OK thì ta mới bắt đầu sửa. Và trong source có cả "BrSE" và "SE" với số lượng nhiều không định trước. Thông thường để làm task này thì ta sẽ dùng editor search cả source code xem chỗ nào có từ khóa "SE", tuy nhiên vấn đề ở chỗ là search "SE" thông thường thì ra kết quả bao gồm cả "BrSE", kết quả cả mấy trăm dòng, không thể filter bằng mắt thường hết được. Với regex ta có thể xử lý đơn giản với pattern "

5.2.3. Command Line

Một trong những công việc mình hay phải làm khi thực hiện task "điều tra bug" với vai trò BrSE đó là vào server phát triển kiểm tra. Công việc này tức là mình sẽ ssh vào server develop hoặc staging, vào kiểm tra log lỗi và đánh giá sơ bộ nguyên nhân rồi sau đó mới chuyển cho develop ở việt nam xử lý tiếp. Nếu hỏi vì sao BrSE làm việc này mà không phải SE làm thì:

+ Thứ nhất là server được config giới hạn IP mà phía Việt Nam không access được

+ Thứ hai là các bạn Developer thường đang bận làm dở task tính năng, chuyển sang làm task khác không tiện, mình thì BrSE task phát triển nhỏ hơn không có task nào dài thì dễ chuyển hơn.

+ Team ít người, không có vị trí riêng cho DevOp.

Nếu dự án nhỏ thì thường phạm vi xử lý công việc cũng không nhiều, ta có thể dùng tool ssh rồi thao tác trên đó là đủ, không cần đến kỹ năng này. Mình đề cập đến kỹ năng này vì xét đến trường hợp dự án lớn hoặc là một số task độ phức tạp cao hơn, ví dụ như:

a. Copy toàn bộ log định dạng tên aabbcc trong folder A được tạo từ ngày X,Y,Z và nén vào một file, chuyển về host

b. Trong file X lấy ra dòng log có định dạng aabbcc

Task thứ nhất thì khó ở chỗ là folder A rất nặng, nếu nhẹ thì dùng tool copy nguyên về host rồi xử lý tiếp sau cũng không sao, nếu nặng ví dụ đến vài chục GB chẳng hạn, thì copy cả sẽ tốn thời gian chưa kể dung lượng tải. Task thứ hai khó ở chỗ vị trí các log bị phân tán trong file chứ không tuần tự, không thể copy thủ công cả 1 đoạn bao hết được. Trường hợp này thì mình nghĩ khó dùng tool được vì các tool có lẽ không thiết kế độ sâu đến những thao tác mức độ đó, nhưng nếu dùng command line thì ta có thể làm như sau :

a. Sử dụng command find + grep để tìm, dùng tar để nén: https://stackoverflow.com/a/18339633

b. Dùng grep với regex cho format aabbcc: đối với công việc trước giờ mình làm thì command line thực sự rất hữu ích nhưng nói chung cũng tùy vào tính chất dự án. Dự án mobile app chẳng hạn thì có thể không cần dùng.

5.2.4. Sử dụng Editor

Nếu bạn là BrSE xuất thân từ SE thì Editor là tool rất quen thuộc rồi nhưng nếu bạn xuất thân Comtor thì mình khuyên nên học dùng 1 editor nào đó sẽ có ích rất nhiều khi xử lý liên quan đến tìm kiếm trong source code. Ví dụ đôi khi ta chỉ muốn tìm file template view để lấy ra text tiếng nhật trong màn hình thôi chẳng hạn, thông thường nếu phải mở từng folder một, mở từng cái ra xem thì rất mất thời gian. Trường hợp này ta dùng editor mở cả dự án rồi search trên đó là được. Đến đây mình xin kết thúc phần các kỹ năng mình đề xuất nên có khi làm BrSE. Tiếp theo mình xin chia sẻ kinh nghiệm xử lý một số tình huống mà một BrSE có thể sẽ hay gặp khi làm dự án.

6. Xử lý tình huống

6.1. Tiếng Nhật mình khách không hiểu, tiếng Nhật khách mình không hiểu.

Đây chắc là tình huống dễ xảy ra và hay xảy ra nhất với BrSE? Xử lý tạm thời bằng cách hỏi lại. Giả sử trường hợp khách nói về việc A mà mình không nghe ra thì có thể hỏi lại với những cái mình biết là có phải A1, A2 không, khách sẽ trả lời là A1 nhưng khác chỗ này, chỗ kia, 2 bên tiếp tục trao đổi đến khi mình hiểu A. Cũng có thể nhờ khách nói lại lần nữa, tuy nhiên cách này làm phiền họ hơn là cách hỏi A1,A2 ở trên nên mình nghĩ nên tránh. Trường hợp tiếng Nhật mình khách không hiểu thì mình dùng cách nói khác để mô tả vấn đề. Xử lý căn bản bằng cách rèn luyện tiếng Nhật. Đầu tư học tiếng Nhật thôi! (Đây là cái nói dễ hơn làm...). Xử lý cho trường hợp này mình nghĩ cũng đơn giản, chỉ chú ý là nên rút kinh nghiệm được nhanh và nhớ được cho lần sau, không nên để phải hỏi lại.

6.2. Bị khách quát

Trường hợp thế này mình cũng nghe nhiều lần từ bạn bè cũng có mà đàn anh cũng có, thường mình thấy là dễ xảy ra khi giao tiếp với "khách hàng cuối" hơn, còn với SE người Nhật thì thấy dễ hiểu nhau nên được thông cảm hơn. Vấn đề này có lẽ thuộc về mặt đối nhân xử thế, là kiến thức thông thường hơn chứ không riêng gì BrSE nên mình ban đầu cũng không định bao gồm vào bài viết nhưng thấy cũng hay xảy ra mà mức độ ảnh hưởng cũng tương đối nên cũng quyết định viết. Về cách xử lý thì chắc hẳn là bình tĩnh trao đổi với khách xem vấn đề ở đâu, xác định đúng vấn đề rồi thì tập trung vào giải quyết, có thể dành thêm resource để tập trung xử lý chỗ đó. Cách và hướng xử lý thì có lẽ mọi người đều biết, mình chỉ muốn chia sẻ thêm những gì mình nghĩ. Đó là mình thấy nếu được thì ta cũng nên có phần cố gắng hiểu tâm trạng khách hàng.Có ông bạn mình kể làm ở công ty sản phẩm có đội sale người Nhật, đội sale Nhật đó nhiều khi bị khách quát vì chất lượng sản phẩm bàn giao không như hợp đồng, quát rất thậm tệ, bên trong suýt khóc nhưng bên ngoài vẫn cố niềm nở chịu đựng. Tức là bản thân phía khách có thể cũng đang gặp khó, họ còn bị đối tác Nhật khác tạo áp lực kinh khủng hơn, dù rất khó chịu với mình nhưng phía họ còn chịu áp lực hơn nhiều. Ngoài ra thì đối với khách không chuyên kỹ thuật, việc đội phát triển thuê mà không làm được việc như hợp đồng đã thoả thuận, BrSE thì hỏi nhưng trả lời chậm thì có lẽ dễ nghi ngờ đến lừa đảo. Tức là tâm trạng khách ở đây không phải là họ đang cố ép mình làm mà là họ tức giận vì thấy đang bị lừa. Đối với mình thì thấy bị nghi ngờ là lừa đảo là cảm giác rất nhục nhã, so với đó cảm giác phải làm thêm giờ mỗi ngày cũng không đáng kể lắm. Dù sao thì ta cũng nên cố gắng hợp tác với khách khắc phục, chủ động horensou và tránh xảy ra những vấn đề này ngay khi nhận thấy có khả năng, có thể ngay từ giai đoạn hợp đồng.

6.3. Xuất hiện task mất nhiều thời gian Communication nhiều giữa 2 bên

Mình xin lấy ví dụ về một dự án mình đã làm mà phía khách đảm nhiệm Frontend, phía đội việt nam đảm nhiệm Backend. Ở frontend gọi API đến Backend trả về kết quả hiển thị. Vấn đề phát sinh khi mà ở task đó phía frontend nói họ gửi dữ liệu đúng format mà không được xử lý thành công, bên backend lại nói là đã cấu hình xử lý kiểm tra nhiều lần là nhận đúng format nhưng dữ liệu gửi lên không đúng, nói chung là 2 bên không xác định được là lỗi ở đâu. Sau đó thì 2 bên đưa ra rất nhiều giả thuyết và thử nghiệm kiểm tra xem đúng nguyên nhân không, thử đi thử lại chắc phải mất cả tuần cho task này nhưng vẫn chưa tìm ra được. Điểm khó ở đây là phía frontend không có kinh nghiệm server nên không tự dựng server local để tự check được, bên backend thì có kinh nghiệm làm mobile app nhưng cũng bận không có thời gian cài đặt môi trường, môi trường mobile app dùng XCode cấu hình cũng hơi phức tạp một chút. Mình thì chuyên backend nên cài đặt server backend trên local được, lại ở phía Nhật ngồi ngay cạnh developer frontend khách hàng nên nhờ họ hướng dẫn dựng mobile app cũng rất tiện, nên mình đề xuất là để task đó mình xử lý. Dựng cả 2 môi trường lên so sánh thì mình phát hiện vấn đề là do phía frontend encode64 file ảnh gửi lên server có vấn đề. Hàm encode64 thì đúng nhưng dữ liệu bị biến đổi khi gửi lên đến server do hàm gửi của AngularJS có tự động escape khi gửi lên, cái này phải override hàm gửi của AngularJS thì mới biết được. Sau đó thì mình cũng sửa luôn và vấn đề cũng xong ở đó. Tức là mình thấy có nhiều tình huống mà thay vì đơn thuần dịch nội dung cho cả 2 bên trao đổi với nhau thì mất rất nhiều thời gian, BrSE có lợi thể hiểu cả 2 bên có thể trực tiếp tham gia vào thay cả 2 bên giải quyết luôn được. Có lẽ công việc BrSE còn rất nhiều các xử lý tình huống khác nữa nhưng tạm thời mình xin dừng ở đây, có dịp sẽ bổ sung sau.