BrSE, bạn có hiểu tình huống?

Một trong những chủ đề thường được nêu ra trong lĩnh vực IT outsourcing là sự phân biệt giữa một Comtor. và một BrSE. Trong thực tế, có không ít những ngộ nhận/ hiểu sai về hai vai trò này.

Bản thân tôi còn nhớ một lần phỏng vấn vị trí BrSE, ứng viên tiếng Nhật kém, không thể đảm đương được cuộc trò chuyện, khả năng kỹ thuật cũng chỉ làng nhàng. Khi được hỏi lý do thì bạn ấy nói: Do em đã biết kỹ thuật rồi và tiếng Nhật thì còn chưa giỏi nên em thấy mình phù hợp để làm BrSE !!!

Như thế, với nhiều người thì rất đơn giản: Biết ít kỹ thuật + Biết ít tiếng Nhật = BrSE, còn thì Giỏi tiếng Nhật = Comtor.

Tôi thì không nghĩ vậy, nhưng bài này không định đưa ra định nghĩa gì về BrSE hết, chỉ thử đi sâu vào một khác biệt giữa Comtor. và BrSE mà thôi.

Theo cá nhân tôi, có một khác biệt giữa Comtor. và BrSE là mức độ hiểu vấn đề:

. Trong khi Comtor. chỉ cần hiểu vụ việc ở mức độ có thể “truyền đạt” được thì,

. BrSE phải hiểu vụ việc ở mức độ có thể soi rọi vào bản chất của vấn đề đang đặt ra

Chỉ nói gọn như trên thì hơi khó hình dung, vì thế bài này sẽ dựa vào một tình huống mô phỏng để minh họa hai mức độ “hiểu vấn đề” nói trên.

I. Tình huống minh họa

Tình huống mô phỏng ở đây là một vấn đề vắn tắt như sau:

Bối cảnh: Báo issue dự án trong cuộc họp hàng tuần

Issue

Tình huống: 

Từ ngày 15 đến ngày 18 tháng 9, quá trình lưu trữ TD đã thất bại cả trên RUC và CAX.

Nguyên nhân:

.Ngày 14 tháng 9, phiên bản minor của MySQL đã tự động nâng cấp lên ver 8.0.28.

.Từ phiên bản 8.0.28, kết nối ssl/tls không hỗ trợ cho TLS v1.0/1.1 nữa.

.CAX đã không chỉ định phiên bản TLS ➞ Mặc định trở thành phiên bản TLS (TLS 1.1).

➞ Không thể xác thực qua ssl

➞ Digdag server không thể kết nối được với MySQL (CAX và RUC đồng bộ dữ liệu từ MySQL vào TD thông qua Digdag)

➞ Quá trình đồng bộ sang TD thất bại

Đây thực ra là nguyên văn một báo cáo vấn đề được team cung cấp cho BrSE.

II. Đánh giá mức độ hiểu

Tôi có đưa nguyên vẹn nội dung trên cho 2 bạn trainee (thực tập sinh) BrSE và yêu cầu:

Trước tiên, hãy đọc và tự nghiên cứu tình huống này, sau đó vẽ lại sơ đồ mô tả tình huống.

Kết quả bài làm một bạn gửi cho tôi sau đó như sau.

Thú thực tôi đã khá thất vọng với “bài làm” nói trên. Hoá ra vẽ sơ đồ là như vậy sao? Đơn giản là copy paste nguyên nội dung từ mô tả vào các khung text box rồi vạch mũi tên nối các text box đó lại với nhau?

Sau khi xem bài làm này, tôi đã gọi 2 bạn vào và làm một buổi training nhanh về Sơ đồ ER (Entity Relation Diagram Sơ đồ Thực thể – Quan hệ)

II. Tại sao lại là ER?

Cá nhân tôi thấy ý tưởng của ER đơn giản nhưng vẫn phổ quát, hữu dụng, có thể học nhanh, làm nhanh.

Về lý thuyết, ER Diagram vốn là một công cụ mô hình hóa được sử dụng để thiết kế cơ sở dữ liệu. Một sơ đồ ER chỉ gồm một ít các yếu tố chính:

• .Entity (Thực thể): Đại diện cho các đối tượng trong khuôn khổ được xem xét
• .Attribute (Thuộc tính): Mô tả đặc điểm của thực thể
• .Relationship (Mối quan hệ): Thể hiện cách các thực thể liên kết với nhau

Sử dụng ER Diagram cho phép chúng ta nhanh chóng:

• .Giúp hiểu rõ mối quan hệ giữa các đối tượng
• .Dễ dàng truyền đạt thông tin giữa các bên liên quan
• .Hỗ trợ việc ra quyết định và tổ chức quy trình

Vậy thì ứng dụng ER vào phân tích tình huống như thế nào?

Theo lý thuyết, ta có thể sử dụng khung câu hỏi 5W1H cùng với một số câu hỏi chuyên biệt.

1. Xác định Thực thể (Entity)/ Thuộc tính (Attribute):

• What: Những đối tượng chính trong tình huống là gì?
• Who: Ai là người tham gia vào tình huống?
• Which: Những loại thông tin/ dữ liệu nào được trao đổi hay lưu trữ?
• Where: Những địa điểm/vị trí nào liên quan?

2. Xác định Mối quan hệ (Relationship):

• How: Các thực thể tương tác với nhau như thế nào? Thực thể nào có quan hệ trực tiếp với thực thể nào?
• When: Khi nào các tương tác này xảy ra? Thứ tự các tương tác đó như thế nào?
• Why: Tại sao cần có mối quan hệ này?

III. Câu hỏi phân tích cho tình huống minh họa

Sau khi training về ER, tôi đề nghị các bạn tạm thời quên đi cái sơ đồ đầu tiên các bạn ấy vẽ,

.tự về nghiên cứu lại đề bài và

. nghĩ ra các câu hỏi để phân tích tình huống minh họa theo hướng ER

Nhiệm vụ là liệt kê ra các câu hỏi hữu ích cho việc phân tích tình huống, càng nhiều càng tốt.

Xin nhắc lại tình huống minh họa để tiện theo dõi:

Tình huống: 

Từ ngày 15 đến ngày 18 tháng 9, quá trình lưu trữ TD đã thất bại cả trên RUC và CAX.

Nguyên nhân:

.Ngày 14 tháng 9, phiên bản minor của MySQL đã tự động nâng cấp lên ver 8.0.28.

.Từ phiên bản 8.0.28, kết nối ssl/tls không hỗ trợ cho TLS v1.0/1.1 nữa.

.CAX đã không chỉ định phiên bản TLS ➞ Mặc định trở thành phiên bản TLS (TLS 1.1).

➞ Không thể xác thực qua ssl

➞ Digdag server không thể kết nối được với MySQL (CAX và RUC đồng bộ dữ liệu từ MySQL vào TD thông qua Digdag)

➞ Quá trình đồng bộ sang TD thất bại

Sau đó vài hôm, tôi và 2 bạn trainee lại gặp nhau một lần nữa để cùng nhau xem xét/ thống nhất danh sách các câu hỏi phân tích. Do thời gian đã lâu, tôi không còn giữ danh sách chính xác đó, chỉ còn nhớ đại loại chúng như sau:

• .TD là gì?
• .RUC và CAX là gì? RUC và CAX là hai thứ hay là một thức?
• .Sự khác biệt giữa RUC / CAX và MySQL chẳng hạn là gì?
• .Những Actor nào tham gia vào tình huống? (MySQL, RUC, CAX, TD, Digdag)
• .Những yếu tố kỹ thuật nào liên quan? (SSL, TLS v1.0/1.1)
• .Ssl là gì? SSL và tls quan hệ với nhau thế nào?
• .SSL có quan hệ gì với Digdag ?
• .SSL có phải là một Entity (Actor) trong câu chuyện hay không?
• .RUC/ CAX có quan hệ trực tiếp với MySQL không?
• .RUC/ CAX có thuộc về hay nằm trong TD không?
• .Luồng dữ liệu giữa các Actor diễn ra như thế nào?
• .CAX và RUC tương tác với MySQL ra sao?
• .Digdag đóng vai trò gì trong quá trình đồng bộ?
• .Quy trình xác thực SSL/TLS diễn ra như thế nào?
• .Yêu cầu về phiên bản TLS là gì?
• .Các điều kiện để kết nối thành công là gì?

Như thế, xin tóm tắt lại một chút cách mà tôi mong muốn các bạn trainee BrSE phân tích vấn đề cho đến hiện tại:

. Nắm lý thuyết về ER diagram

. Áp dụng bộ câu hỏi mẫu của ER vào thực tế tình huống

. Lên danh sách các câu hỏi cụ thể cho tình huống đặt ra

. Tiến hành hearing/ xác nhận với Dev. team với danh sách câu hỏi nói trên

IV. Luyện tập nhập vai để phân tích

Vậy là hiện tại chúng ta đã có danh sách các câu hỏi cụ thể, bước tiếp theo sẽ là hearing (hỏi/ xác nhận câu trả lời với Dev. team).

Để tiến hành bước này, tôi sử dụng nhập vai (role play), trong đó tôi đóng vai trò Dev. Team và trả lời các câu hỏi từ các bạn Trainee.

Kết quả mong muốn sau phần role play này là một mô tả đơn giản tình huống minh hoạ ở mức overview:

. Có các thực thể nào?

. Các Quan hệ giữa những thực thể ấy là như thế nào?

Và tôi khuyến khích các bạn mô tả 2 điều trên bằng một sơ đồ ER đơn giản, trong đó chủ yếu là Thực thể và Quan hệ, các thuộc tính đi kèm thì thuộc tính nào quan trọng đóng góp cho việc hiểu tình huống thì đưa vào, còn không có thể lược bỏ.

Trên hết, tôi yêu cầu nếu vẽ ER thì cần hạn chế các từ đưa vào, hạn chế ở mức độ chỉ đưa vào các danh từ/ cụm danh từ ngắn gọn, tối đa gồm 3 chữ là cùng.

Và đây là một kết quả vẫn từ bạn trainee đầu tiên, chưa hề chỉnh sửa bởi tôi:

Đến đây, chúng tôi đã sẵn sàng cho bước role play cuối: Cùng review Sơ đồ mô tả tình huống với team và chỉnh sửa

Lần này tôi lại đóng vai Dev. team để cùng xem xét/ rà soát lại sơ đồ nói trên từ BrSe, sơ đồ cuối cùng được finalized như sau với một vài chỉnh sửa nhỏ:

V. Từ “bề mặt” đến “bản chất”

Phần này xin tóm tắt lại hành trình phân tích tình huống ở trên.

1. Comtor. chỉ hiểu vụ việc ở mức độ có thể “truyền đạt” được:

2. BrSE phân tích tình huống với bộ câu hỏi ER

• .TD là gì?
• .RUC và CAX là gì? RUC và CAX là hai thứ hay là một thức?
• .Sự khác biệt giữa RUC / CAX và MySQL chẳng hạn là gì?
• .Những Actor nào tham gia vào tình huống? (MySQL, RUC, CAX, TD, Digdag)
• ….

3. BrSE hearing Dev. Team, phác thảo Sơ đồ mô tả tình huống và finalize sơ đồ đó với Dev. Team một lần nữa, kết quả

4. BrSE hiểu vụ việc ở mức độ bản chất của vấn đề

Vậy sự khác biệt giữa mức độ 1. và mức độ 4. là gì? Theo tôi, có thể tóm tắt như sau:

. Ở mức độ 1, có rất nhiều từ ngữ khác nhau và ta không biết cái gì quan trọng hơn cái gì, vì thế

. Với mức độ 1, người Comtor. bị phụ thuộc nhiều vào từ ngữ và cách diễn đạt cụ thể, do đó

. Nếu dừng lại ở mức độ 1., rất khó tóm tắt tình huống và dễ đi lạc trọng tâm

. Ở mức độ 4, ta có có chiếc bản đồ để hiểu overview tình huống, trong khi ở mức độ 1. ta chỉ có các mảnh ghép lẻ tẻ của “một thứ gì đó”

. Bản đồ ở mức 4 cho phép ta nhanh chóng xác định bất cứ giải thích hay câu hỏi nào liên quan (hoặc không liên quan) đến phần nào của vấn đề, không bị lạc lối giữa nhiều ý kiến/ câu hỏi được trao đổi qua lại.

VI. Thay lời kết

Đến đây, xin tổng hợp lại cách một BrSE có thể thật sự hiểu tình huống đến mức độ 4:

1. Nắm lý thuyết về ER diagram

2. Áp dụng bộ câu hỏi mẫu của ER vào thực tế tình huống

3. Lên danh sách các câu hỏi cụ thể cho tình huống đặt ra

4. Tiến hành hearing/ xác nhận với Dev. team với danh sách câu hỏi nói trên

5. BrSE hearing Dev. Team, phác thảo Sơ đồ mô tả tình huống

6. BrSE nhờ Dev. team review Sơ đồ đã phác thảo và finalize sơ đồ đó

Chúc các bạn phân tích tình huống hiệu quả

và hẹn gặp lại ở tình huống tiếp theo