Những vấn đề xoay quanh team DA. Thực trạng hiện tại và giải pháp cho tương lai.

Hiện nay tại công ty chúng ta, team Tech & Product đang hoạt động theo mô hình scrum team. Tuy nhiên có một team duy nhất có một người và đang không theo mô hình đó. Đó chính là team Data Analyst (DA). Với những công việc đã đang diễn ra trong hai năm, và những năm tiếp theo, chúng tôi nhận thấy có những thực trạng và giải pháp có thể giúp team hoạt động tốt hơn.

1. Tổng quan về team DA – Mục đích ra đời và vai trò trong công ty.

       1.1  Mục đích ra đời team DA.

• Hỗ trợ ra quyết định bằng dữ liệu: Giúp ban lãnh đạo và các phòng ban có cơ sở dữ liệu đáng tin cậy để đưa ra quyết định nhanh chóng và chính xác hơn, thay vì dựa vào cảm tính hoặc kinh nghiệm cá nhân.
• Xây dựng văn hóa data-driven (ra quyết định dựa trên dữ liệu): Đưa dữ liệu trở thành một phần cốt lõi trong hoạt động của doanh nghiệp, giúp mọi bộ phận làm việc khoa học, bài bản hơn và có thể đo lường được kết quả.
• Hỗ trợ việc lấy dữ liệu dễ dàng: Nhu cầu cần số liệu của các team tăng nhanh và họ khó khăn trong việc dữ liệu lớn nên team DA có thể hỗ trợ lấy dữ liệu lớn nhanh chóng hơn.

      1.2   Công việc & chức năng team DA.

• Thu thập và tổng hợp dữ liệu: Team lấy dữ liệu từ thống nội bộ: database và nguồn thông tin từ team kinh doanh (tự điền dữ liệu file google sheets), đảm bảo dữ liệu đầy đủ, chính xác và kịp thời phục vụ nhu cầu xây báo cáo.
• Làm sạch và xử lý dữ liệu: Loại bỏ dữ liệu sai, thiếu, trùng lặp. Chuẩn hóa định dạng dữ liệu. Kết nối và đồng bộ dữ liệu từ nhiều nguồn khác nhau.
• Xây dựng báo cáo: Đây là công việc chính và quan trọng nhất của team. Thế mạnh của PBI (Power Business Intelligence) – công cụ chính của team là kết nối được nhiều nguồn dữ liệu, từ dữ liệu của scrum team này đến scrum team khác, cũng như lượng data từ team kinh doanh. Từ đó đáp ứng được nhu cầu của các stakeholder, có cái nhìn chi tiết cũng như liên quan đến các dịch vụ đang hoạt động. Báo cáo được xây dựng dựa trên nhu cầu của các team, tần suất hàng ngày/ tuần/ tháng/ quý. Dữ liệu được biểu hiện dưới dạng biểu đồ, bảng biểu để dễ đọc hiểu và sử dụng dữ liệu.
• Theo dõi và đo lường hiệu quả hoạt động: Việc đo lường KPI và được update hàng tuần sẽ giúp team kinh doanh biết thực trạng chạy số, vấn đề tồn đọng và kịp thời đưa ra giải pháp để đạt được KPI.

2. Thực trạng team DA.

       2.1  Hệ thống dữ liệu và công cụ.

• Hiện nay, hệ thống dữ liệu team đang dùng chưa hoàn toàn được cập nhật giống như bản “production”. Dữ liệu cho các báo cáo thường được chạy một giờ cố định, chủ yếu một lần trong ngày. Đối với kho dữ liệu lớn, dữ liệu thường chỉ chạy lại trong 5-7 ngày nên nhiều khi cần dữ liệu, hoặc số về thêm nhiều ngày trước đó, team phải chạy bằng tay. 
• Về công cụ, với gói hiện tại, thời gian update sẽ cách nhau 30 phút. Tuy nhiên chạy nhiều lần trong ngày sẽ dẫn đến “timed out”, ảnh hưởng đến quá trình update. Do vậy sự kết hợp thực trạng của hệ thống dữ liệu và công cụ đang dùng khiến báo cáo sẽ không được “real-time”,  hay chưa đáp ứng tốt nhất nhu cầu của các stakeholder, thường dữ liệu phản ảnh ngày hôm trước đổ lại, hoặc đang cut off theo tuần.

      2.2   “Một người làm tất cả”.

• Một người làm nhiều vai trò: Từ nhận yêu cầu, sắp xếp công việc đến phân tích, tổng hợp dữ liệu, xây dựng báo cáo, sửa lỗi từ các yêu cầu từ các team, các phòng ban liên quan.
• Không có leader chuyên môn về nghiệp vụ: Không có người review chất lượng phân tích, tư vấn giải pháp xử lý vấn đề mà đang tự đưa ra các giải pháp, tự xử lý.
• Phụ thuộc vào cá nhân: Hiện tại team chỉ có một thành viên nên nếu thành viên đó nghỉ việc thì sẽ không có người phụ trách công việc thay thế và khi có vấn đề xảy ra cần xử lý gấp có thể sẽ không xử lý kịp.

      2.3   Chưa có quy trình làm việc.

• Không có quy trình chuẩn: Mỗi request xử lý theo cách riêng, không có quy trình tường minh như Agile (Sprint, Daily report, Refinement, Planning, Retrospective).
• Không có tài liệu hóa: Không có tài liệu mô tả chi tiết mô hình lưu trữ dữ liệu, cách lấy dữ liệu, logic phân tích,… 
• Không có công cụ đánh giá hiệu suất: Hiện tại đang không có áp dụng các công cụ để log lại các task đã làm, log lại thời gian đã làm, không có các file evidence để đánh giá công việc, đánh giá năng lực làm việc, không biết DA đang làm tốt hay không, thời gian xử lý request có hợp lý không.
• So sánh với Scrum Team.

      Vậy rủi ro từ các thực trạng trên sẽ như thế nào? 

1. Rủi ro về nhân sự:

• Toàn bộ hệ thống phân tích phụ thuộc vào một cá nhân
• Nếu DA nghỉ việc đột ngột: Công ty mất ít nhất 3-6 tháng để training người mới
• Khi tuyển dụng mới: Ứng viên giỏi không muốn vào môi trường làm việc độc lập không có mentorship

2. Giảm chất lượng công việc:

• DA có thể sẽ bị quá tải nếu lượng công việc dồn vào cùng một lúc, dẫn đến sai sót trong phân tích số liệu.
• Thời gian phản hồi đến các team, các phòng ban khác sẽ bị chậm trễ, hoặc không phản hồi kịp, ảnh hưởng đến tiến độ công việc của các bên liên quan.

3. Rủi ro về kiến thức và chi phí chuyển giao cao:

• Tất cả kiến thức về hệ thống chỉ một mình DA đó biết, không có tài liệu mô tả lại, không có backup nếu DA nghỉ việc.
• Nếu tuyển DA mới sẽ mất nhiều thời gian training hơn trong môi trường không có document.

4. Rủi ro về chất lượng trong quy trình, quyết định khi không có người đánh giá, tư vấn:

• DA tự quyết định cách xử lý các request, phương pháp phân tích số liệu mà không có guideline, không có người đánh giá, review, có thể dẫn đến chất lượng phân tích dữ liệu không được tối ưu nhất, gây chậm trễ hoặc có thể dẫn đến sai sót số liệu nghiêm trọng.

3. Giải pháp cho team DA.

        3.1 Hệ thống dữ liệu và công cụ.

• Kỳ vọng của team sẽ được dùng dữ liệu được đồng bộ như môi trường production, giảm thời gian theo dõi số và tự chạy tay. Tương lai nếu PBI không đáp ứng được nhu cầu của stakeholder, tối ưu chi phí, team cũng nên tự xây dựng dashboard riêng.

       3.2  Quy trình làm việc.

       3.2.1 Tạo biểu mẫu nhận yêu cầu (Request Form)

• Công cụ: File Google/ Jira Ticket Template
• Mục đích: Thay thế việc nhận request qua tin nhắn, giảm thời gian nhắn qua nhắn lại.
• Yêu cầu các team gửi qua email theo form và có sự đồng ý từ leader/ manager.
• Thông tin cần thu thập:

3.2.2 Review & Ưu tiên request hàng ngày/tuần

• Sắp xếp theo thứ tự ưu tiên (deadline/ độ gấp/ mức độ ảnh hưởng), nếu không có thì theo thời gian yêu cầu.
• Báo cáo với leader quản lý để nắm các đầu việc, đưa thêm những lời tư vấn (nếu có).
• Chọn tối đa 3-5 task/ngày để tránh overload.

       3.2.3 Trao đổi lại với stakeholder

• Trường hợp chưa hiểu rõ logic, công thức, mục đích, cần trao đổi qua gọi điện/ nhắn tin (mà không tốn quá nhiều thời gian). 
• Ghi chú lại thông tin vào form để tránh hiểu lầm sau này.

       3.2.4 Xử lý dữ liệu, xây dựng báo cáo và self-test

• Tiến hành xử lý dữ liệu và làm báo cáo dựa trên những thông tin rõ ràng thu thập được.
• Sau bước làm, cần có sự kiểm định lại độ chính xác của thành phẩm.

       3.2.5 Gửi kết quả & nhận feedback.

• Gửi qua email kèm file hoặc dashboard. 
• Có file giải thích từ field/ logic.

      3.2.6 Thiết kế & Lưu trữ file Document.

• Thông tin chung về báo cáo: Team request, link PBI, các tài khoản PBI được quyền xem.
• Nguồn vào dữ liệu: Kiểu bảng (Dimension/ Fact), tên dữ liệu, nguồn lấy dữ liệu, mục đích lấy.
• Logic từng tab: Tên tab, logic tab, công thức và ghi chú.

=> Việc áp dụng các mục trên sẽ giúp team tránh quá tải trong cùng một thời điểm, xác định rõ những công việc quan trọng, thôi ôm đồn nhận tất cả các yêu cầu. Quy trình rõ ràng sẽ giúp giải quyết những thắc mắc, xung đột giữa các team được minh bạch, rõ ràng. Việc lưu trữ document giúp cho mọi người trong team nắm được công việc đầy đủ và triệt để. Còn việc đánh giá năng lực cũng như quá trình làm việc cần được các cấp cao xây dựng một cách khách quan và chuyên nghiệp hơn.

Tóm lại, việc xây dựng lại quy trình, lưu trữ thông tin của team DA sẽ giúp công việc của các thành viên được rõ ràng, minh bạch và hiệu quả hơn. Nhu cầu phát triển team còn tùy thuộc vào nhu cầu cần thiết của công ty, tuy nhiên vẫn cần xây dựng bài bản để việc phát triển team dễ dàng hoạt động cho tương lai.

.