“BA có cần biến SQL?”
Câu hỏi này nhận được khá nhiều câu trả lời khác nhau từ cả những người trong nghề và những người ngoài nghề.
“SQL là 1 kiến thức chắc chắn BA cần phải biết”, “BA biết SQL thì tốt, không biết cũng không sao”, “Tại sao BA lại cần biết SQL” …. Vậy trong những câu trả lời này, liệu câu trả lời nào đúng?
Hãy cùng mình tìm hiểu về SQL đối với công việc của 1 BA để tự đưa ra được câu trả lời cho mình nhé!
1. SQL trong cuộc sống
Từ thời xa xửa xa xưa, thời mà các tổ chức còn vận hành rất thô sơ. Từ công ty, trường học, bệnh viện, nhà hàng, khách sạn, karaoke, bia ôm, mát xa…, mọi thứ được vận hành rất chi là thủ công.
Đó là cái thời mà mọi thông tin, tiến độ, kế hoạch đều được ghi trên giấy, lưu trong sổ, hoặc viết lên bảng để mọi người cùng theo dõi. Tuy nhiên càng về sau thì mức độ cạnh tranh ngày một tăng cao.
Các tổ chức cạnh tranh khốc liệt với nhau từng chút một. Từ vận hành nội bộ sao cho hiệu quả, đến việc phục vụ khách hàng sao cho ngon lành nhất.
Lúc này “công nghệ” phọt ra như một bài thuốc giúp nâng cao hiệu quả hoạt động, và dần “khẳng định chỗ đứng” trong bất kỳ tổ chức nào.
Tức, họ mang những thứ xưa giờ làm trên giấy, ghi trong sổ, viết lên bảng; quăng vào trong máy tính, thứ mà chúng ta hay gọi là “số hóa”. Và điều quan trọng là: một khi đã số hóa được những thứ này, tổ chức sẽ sở hữu được thứ tài sản quan trọng bậc nhất của họ, đó là data.
Có data trong tay,
Các tổ chức sẽ tự động hóa được quy trình làm việc của họ. Bằng cách nào?
Khi mọi thứ đã được quy về dữ liệu, con người và máy tính sẽ cùng hiểu chung một ngôn ngữ. Từ đó chúng ta sẽ lập trình được các ứng dụng, làm cho máy tính hiểu và làm theo những quy trình được thiết kế sẵn, theo đúng vận hành của tổ chức.
Có data trong tay,
Họ sẽ hiểu rõ bức tranh kinh doanh, vận hành của họ, thông qua các báo cáo, dashboard thường ngày.
Có data trong tay,
Các tổ chức sẽ kiểm soát được vận hành của họ. Thông tin nhân viên, nhà máy, thiết bị, lớp học, bệnh viện, quán ăn được minh bạch, rõ ràng, theo từng giai đoạn nhất định. Từ đó tối ưu được nguồn lực hay không là nằm ở đây.
Chưa hết, nếu thử nhìn sang góc độ cá nhân với mỗi người.
Tưởng tượng nếu cuối năm có ai đó gửi cho mọi người báo cáo chi tiêu của mình suốt cả năm qua thì sao?
Báo cáo chi tiết đến độ, mình mà mua cọng dây thun buộc quần nó cũng ghi. Nó chỉ ra cho anh em biết được đâu là khoản chi nhiều nhất, thu nhiều nhất, vào thời gian nào, nhân dịp gì, chi với ai…
Rồi dựa vào đống data đó, nó còn dự đoán được cho mọi người trong 30 ngày tiếp theo, mọi người có thể phải chi ngần này tiền. Từ đó, nó đưa ra kiến nghị chỉ nên chi nhiêu đây thôi… Quá hữu ích đúng không mọi người!!!
…
Chúng ta ai cũng hiểu rõ giá trị của data. Tuy nhiên, có data trong tay là một chuyện, làm gì với data mới là quan trọng.
Và thực tế là hầu như chúng ta chỉ có một cách duy nhất để nói chuyện và móc data ra, đó chính là thông qua SQL.
2. SQL là gì?
SQL – Structured Query Language – Ngôn ngữ truy vấn dữ liệu có cấu trúc. Chi tiết hơn thì nó dùng để truy vấn data từ những Relational Database.
Relational Database là cơ sở dữ liệu quan hệ.
Quan hệ là sao, tức nó được tổ chức dưới dạng nhiều bảng, mỗi bảng gồm nhiều dòng, mỗi dòng có một cái key riêng để định danh. Và các dòng dữ liệu ở các bảng nó quan hệ dây mơ rễ má với nhau thông qua các key này.
Vậy nên dữ liệu trong databse nó mới có cấu trúc chặt chẽ, và quan hệ mật thiết với nhau. Đó là Relational Database. Và chúng ta sẽ dùng SQL để lấy data từ các database này thông qua việc sử dụng các câu lệnh của SQL.
Vậy nôm na, SQL là ngôn ngữ để chúng ta nói chuyện với Database và để lấy data mà chúng ta mong muốn.
Câu hỏi tiếp theo: BA dùng SQL trong những việc cụ thể nào?
3. BA dùng SQL trong những việc cụ thể nào?
Trước hết, mình cần làm rõ 2 giai đoạn sau.
Đối với những khách hàng còn “trong trắng” và chưa từng sử dụng qua bất kỳ giải pháp công nghệ nào, BA chúng ta sẽ nhúng tay vào cả 2 quá trình:
- Trước khi có data
- Và sau khi có data.
Trước khi có data nghĩa là chúng ta (tức team dự án, gồm: PM, BA, Dev, QA, QC…) sẽ làm một phần mềm, có những tính năng A, B, C, D…, mà trong quá trình sử dụng phần mềm này, khách hàng sẽ có một lượng data nhất định.
Sau đó sang giai đoạn khi đã có data, chúng ta sẽ xào nấu những data này, rồi bày biện, sắp xếp nó thành những Report và Dashboard có ý nghĩa cho khách hàng. Để họ dòm vào một phát là có đúng ngay thông tin mà họ cần. Từ đó, họ có thể làm ABC, XYZ gì đó tiếp là tùy ý họ
Thông thường mình thấy: BA sẽ tham gia vào giai đoạn (1) nhiều hơn là giai đoạn (2).
Nếu có giai đoạn (2) thì chỉ là làm những dashboard và report không quá phức tạp, và theo đúng nhu cầu hiện tại của khách hàng.
Nhưng business thì luôn thay đổi. Khách hàng luôn có nhu cầu xào nấu dữ liệu theo nhiều chiều kích khác nhau, để cung cấp nhiều hơn thông tin cho họ, ở nhiều khía cạnh.
Nên ở giai đoạn này, thường thì khách hàng họ sẽ cần một người chuyên hơn về data như Business Intelligent Developer, hoặc Data Analyst để giúp họ giải quyết những bài toán bằng lượng data mà họ đang có.
Quay lại với BA (ở giai đoạn 1 – trước khi có data), mình sẽ note lại những thứ mà BA sẽ làm với SQL trong suốt quá trình dự án.
3.1. Đồng hành cùng Dev trong quá trình coding
Trong quy trình làm dự án, rồi cũng sẽ tới đoạn anh em Developer ngồi code từng tính năng một. Lúc này, việc chui xuống database lấy data là một điều rất cần thiết để BA giúp Dev kiểm tra lại những tính năng vừa mới code xong.
Ví dụ có một tính năng: Khi sales vừa tạo mới khách hàng, hệ thống sẽ tự động tạo dữ liệu chiết khấu mặc định và dữ liệu Customer Reference cho khách hàng này, theo công thức ABCXYZ…
Thì ngay khi Dev code xong tính năng này, BA có thể hỗ trợ verify bằng việc dùng SQL tạo dữ liệu khách hàng và query các dữ liệu liên quan như Chiết khấu mặc định và Customer Reference, để xem thử hệ thống đã tạo theo đúng công thức ABCXYZ quy định chưa.
Tuy nhiên đây là cách giúp BA theo sát được công việc của anh em Developer, từ đó hiểu dự án và hỗ trợ anh em nhiều hơn trong giai đoạn development.
3.2. Công cụ đắc lực trong giai đoạn Transition
Giai đoạn transition là khi mọi người đã làm xong phần mềm, và đưa phần mềm vào triển khai cho khách hàng sử dụng.
Giai đoạn này sẽ có rất nhiều thứ búa lua xua phát sinh trong quá trình training, support user sử dụng sau Go-live, hay thậm chí là trao đổi về các yêu cầu mới phát sinh.
Đây là giai đoạn mà nếu BA tận dụng SQL một cách hiệu quả, sẽ được lợi rất rất nhiều trong giai đoạn này.
Ví dụ trong các buổi training end-user.
Hệ thống thường sẽ có một số tính năng kiểu như: User tạo record A >> đứng trên record A, User tạo tiếp record B >> nhấn nút cái bụp >> hệ thống tự động tạo record C dựa trên thông tin của A và B. Mà màn hình không hiển thị record C này cho user thấy.
Vậy tình huống phát sinh là khi: anh em muốn training cho user một cách dễ hiểu hơn, cung cấp cho họ một bức tranh tổng quan hơn.
Thay vì chỉ nói: “…bla…bla…sau khi mọi người tạo record A, record B, hệ thống sẽ tự động tạo record C dựa trên thông tin từ A và B nè…” một cách sáo rỗng, khó mường tượng; thì mình sẽ minh họa bằng cách:
- Tạo dữ liệu A >> tạo dữ liệu B
- >> show cho user thấy thông tin của A và B trên front-end.
- >> chui xuống SQL, query ra dữ liệu C vừa được tạo tự động dựa trên A và B.
- Và cho họ thấy rõ tận mắt các trường dữ liệu của record C này ngay dưới database.
Từ đó, mình dễ dàng highlight được cho user những điểm cần chú ý hơn trong quá trình tạo A, và B; vì nó sẽ ảnh hưởng trực tiếp đến dữ liệu C phát sinh trong database.
…
3.3. Data Analysis
Đây là 1 phương pháp moi móc thông tin của BA.
Rõ ràng thông tin là một thứ rất quan trọng đối với BA. Ngoài những cách khai thác thông tin từ stake holder, moi móc thông tin từ DB cũng là 1 cách rất hữu ích trong công việc của BA.
Khi bạn muốn biết số lượng thuộc country nào nhiều nhất để ưu tiên phát triển trước, khi bạn muốn phân tích thói quen của người dùng để phát triển các tính năng phù hợp, khi bạn muốn biết liệu dữ liệu hiện tại của hệ thống có đang xào nấu được ra report mà stake holder đang yêu cầu… tất cả đều trở nên dễ dàng hơn hết BA biết các sử dụng SQL để tổng hợp thông tin trong DB
3.4. Đụng phát là có ngay thông tin
Đây là một công dụng thường thấy nhất khi BA dùng SQL. Đối với một người làm về digitalize thì việc lấy data lên để theo dõi là thường xuyên.
Đó có thể là yêu cầu từ sếp, từ các phòng ban hoặc thậm chí từ chính bản thân mình muốn theo dõi một số thông tin trên hệ thống. Khi đó, mình hoàn toàn có thể tự tin dùng SQL để lấy bất cứ data gì mình cần, mà không phải phụ thuộc vào anh em đì-ve-lốp-pơ.
Hoặc đối với mình, khi hệ thống Go-Live được độ 2-3 ngày, mình cũng hay query data xem thử mật độ records user tạo có nhiều hay không, user nào đã tạo record, user nào chưa,…(lúc chưa nhúng tracking tool). Từ đó, có ngay báo cáo về tình hình Go-Live cho sếp
3.5. Giúp sức làm reporting, và nói cho Dev hiểu bằng ngôn ngữ SQL
Đây là trường hợp hoàn toàn không bắt buộc với BA. Nhưng đối với các dự án bị overload về mặt resources, việc BA bay vô kéo report cũng giúp ích rất nhiều cho team.
Thực chất mình nghĩ: BA là người nên chủ động làm reporting cho dự án.
Vì BA là người tiếp cận các stakeholders nhiều nhất; là người nắm rõ requirement từ khách hàng, nên họ sẽ có hướng làm reports theo góc nhìn của business users. Tránh tốn thời gian truyền tải lại cho anh em dev (mặc dù vẫn phải có document rõ ràng).
Tuy nhiên, report nào chuối quá thì cũng phải nhờ anh em Dev ra tay.
Ngoài ra, nhìn vô dataset và các expression mà BA làm phần nào cũng giúp Dev hiểu được yêu cầu của report này là gì, mà không cần phải diễn đạt lại chi cho dài dòng, hehe.
…
Trên là những ứng dụng của SQL mà mình – một người BA đã áp dụng trong các dự án phần mềm từ trước đến giờ. Mình tin là còn rất nhiều những thứ khác nữa, mà mọi người có thể dùng SQL để phục vụ cho công việc hằng ngày.
Tuy nhiên, SQL thì cũng chỉ là điều kiện cần, điều kiện đủ là…
4. SQL chỉ là điều cần?
Suy cho cùng thì SQL cũng chỉ là công cụ, cái quan trọng nhất là mọi người:
- Phải hiểu được cấu trúc dữ liệu
- Và có tư duy giải quyết vấn đề dựa trên data.
Rõ ràng là mọi người phải hiểu được dữ liệu được tổ chức như thế nào, thì mới query được. Không thì thứ query được rất tréo que, và chả mang lại ý nghĩa gì cả.
BA (và team) là những người phân tích/ thiết kế hệ thống, nên chuyện hiểu được cấu trúc dữ liệu “behind the scenes” là điều chắc chắn.
- Hệ thống được tổ chức thành bao nhiêu table?
- Relationship giữa các table ra sao?
- Dữ liệu trong các table được định nghĩa như thế nào?
Đó chính là component và relationship, cấu thành bất cứ phần mềm nào.
Xong, một khi đã hiểu được cấu trúc dữ liệu, mọi người phải có được tư duy giải quyết vấn đề dựa trên data có trên hệ thống.
Nghĩa là sao?
Tức là khi vấn đề phát sinh, dựa vào cấu trúc dữ liệu và những record hiện có trên hệ thống, mọi người có suy ra được điều gì không? Điều này sẽ hình thành nên câu query mà mọi người sẽ dùng để lấy data.
Ví dụ nếu khách hàng phản hồi: “Tại sao bây giờ đơn hàng thuộc bộ phận A, kênh X, không chỉnh sửa được đơn giá. Trong khi trước giờ chỉnh được đơn giá bình thường?!?!?”
Khách hàng họ nói: “trước giờ chỉnh được giá bình thường”, thì mình sẽ cần xác minh xem thử: những đơn hàng trước giờ có thật sự chỉnh giá được hay không? ==> ra một câu query những đơn hàng thuộc bộ phận A, kênh X, mà đã được chỉnh giá thành công.
Sau khi đã xác minh đúng như khách hàng nói, thì mình sẽ tiếp tục query ra 2 đơn hàng thuộc bộ phận A, kênh X:
- Một chỉnh sửa được giá
- Một không chỉnh sửa được giá
Và bắt đầu so sánh, đối chiếu với nhau, xem thử tại sao dữ liệu này chỉnh được, mà dữ liệu kia không chỉnh được. Từ đó xem thêm Audit Log, check với Dev, và check thêm 1 số dữ liệu trên đơn hàng để làm rõ vấn đề.
Đó là cách mà mình dựa trên data để tư duy, kết hợp với SQL để lấy data, từ đó giải quyết vấn đề.
Và đó cũng là lý do mà tại sao hơn 500 trang BABOK v3.0 – quyển giáo khoa kinh điển của BA, chỉ nhắc đến từ “SQL” duy nhất đúng một lần.
Hơn 250,000 từ nói về nghề BA, một cách quy chuẩn nhất, mà chỉ có 1 từ nhắc về SQL (hay Structured Query Language). Tỉ lệ 0.0004%.
Mình tin rằng điều này nói rõ được một điều: SQL cũng chỉ là công cụ, mấu chốt là cách tư duy lấy data ra để làm gì!
Thành thạo công cụ sẽ giúp mình làm nhanh, nhưng không hiểu bản chất thì sẽ không làm được gì hết.
Ngoài ra, không phải BA nào cũng dùng SQL. Mà nó còn tùy vào công nghệ, vào sản phẩm, giải pháp mà mọi người đang làm nữa.
Nói về độ phổ biến thì SQL không cần phải bàn cãi nhiều. Từ Dev, BA, PO, Data Analyst, BI Developer, hay thậm chí là những anh em làm Marketing, HR…, tất cả đều cần SQL cho công việc của mình.
Theo một khảo sát trên Stackoverflow thì SQL là ngôn ngữ phổ biến thứ 2 nếu xếp chung với các ngôn ngữ lập trình khác (mặc dù nó là ngôn ngữ truy vấn dữ liệu, hổng phải ngôn ngữ lập tờ rình).
5. Tạm kết
Như tiều đề, bài này nằm trong phạm vi SQL. Đối với NoSQL, vì tác giả chưa có kinh nghiệm nên chưa dám chém lung tung.
Sau cùng, bài note này sẽ tạm kết ở 2 gạch đầu dòng sau:
Gạch đầu dòng 1: BA không nhất thiết phải biết SQL; nhưng BA phải hiểu được cấu trúc dữ liệu, và có tư duy giải quyết vấn đề dựa trên data.
Gạch đầu dòng 2: Con đường ngắn nhất để đi đến gạch đầu dòng1 là biết sử dụng SQL :)))
Tóm gọn lần 2, BA sẽ dùng SQL cho những việc sau:
- Hỗ trợ Dev trong testing, reporting, và những thứ linh tinh khác.
- Tìm ra root cause để giải quyết vấn đề dựa trên data query được.
- Móc data kịp thời, phục vụ nhiều stakeholders khác nhau.
- Data Analysis – hiểu một hệ thống bất kỳ dựa trên cấu trúc dữ liệu của nó.
- Cơ sở để đưa ra các phán đoán trong quá trình làm đề bài
Hi vọng qua bài này mọi người sẽ có góc nhìn chân thật hơn về bản chất của SQL đối với BA: dùng để làm gì và tại sao phải dùng SQL?
Cảm ơn anh em đã đọc tới đây!