Làm IT Comtor một thời gian, bạn sẽ nhận ra:
Cùng một yêu cầu từ khách hàng, người thì dịch lại lời của team và report lại cho khách hàng, người thì đào sâu và phản biện cho tới khi nhận được câu thuyết phục mới gửi nội dung đó đến phía khách hàng.
Cùng một cuộc họp, có người ngồi nghe và ghi chép, có người chủ động làm rõ vấn đề, dẫn dắt cuộc họp đi theo phương hướng rõ ràng và lấy được output từ các stakeholders/bên liên quan sau cuộc họp.
Cùng một vai trò “cầu nối”, có người là người truyền lời, có người trở thành người làm rõ bản chất.
Bạn muốn mình là ai trong số đó?
Thế nhưng, khi muốn trở thành người "làm rõ bản chất", rất nhiều bạn lại chùn bước.
Vì sao? Vì phần lớn chúng ta đều từng có một câu hỏi đau đáu trong đầu:
"Em không biết code, vậy em chỉ là người chuyển lời?"
Đây là suy nghĩ thường trực của rất nhiều bạn đang làm comtor hoặc BrSE non-tech.
Bạn không biết viết hàm, không hiểu OOP, không debug được, vậy thì liệu có đủ "công cụ" để phân tích nghiệp vụ cho khách hàng ?
Câu trả lời là có – nếu bạn chọn đúng thứ để hiểu sâu.
🔹 Vấn đề không nằm ở “biết code” hay “không biết code”, mà là ...
→ Bạn có đang hiểu cách hệ thống đang vận hành không?
Code chỉ là bề mặt – thứ bạn nhìn thấy khi đào rất sâu. Nhưng với BrSE, điều quan trọng hơn là:
Dữ liệu chảy như thế nào?
Khi người dùng thao tác, hệ thống đang xử lý và ghi nhận gì?
Quan hệ giữa các đối tượng nghiệp vụ đang phản ánh ra sao trong hệ thống?
Hiểu được hệ thống là bạn đang cầm trên tay chiếc “bản đồ tư duy” để dẫn dắt team.
Còn không, bạn sẽ chỉ có một “sổ tay ghi chú” – ghi lại từng lời nói rồi chuyển lại y nguyên.
🔹 Vậy BrSE non-tech nên hiểu điều gì để không còn bị động?
1. Tại sao BrSE cần hiểu ERD?
ERD (Entity Relationship Diagram) là sơ đồ biểu diễn quan hệ giữa các bảng trong database.
Hiểu ERD là biết dữ liệu đang được chạy, lưu và liên kết như thế nào trong hệ thống.
"Hiểu ERD là cách nhanh nhất để biết hệ thống hoạt động ra sao, mà không cần xem code."
🔎 Cách hệ thống lưu trữ và kết nối dữ liệu – thông qua DB và ERD
✍️ Hồi mới làm BrSE, mình từng rất tự tin:
“Mình đâu cần biết database, vì mình làm về phân tích nghiệp vụ mà”
Miệng thì bảo không cần.
Nhưng mỗi lần khách gửi câu hỏi:
“Cái số liệu chỗ này lấy từ đâu?”
“User có trạng thái A mà hệ thống lại xử lý theo B, vì sao?”
Mình lại phải lặng lẽ forward cho dev. Và chính trong sự lặng lẽ đó, mình nhận ra một nỗi sợ âm thầm mà nhiều BrSE non-tech từng gặp:
Mình là người nắm luồng nghiệp vụ, mà lại không dám đụng vào dữ liệu – thì có thật là mình hiểu hệ thống không?
Sự thật mình ngộ ra sau vài lần “toang”:
Database không phải phần kỹ thuật khô khan.
Nó là nơi hệ thống "nói thật" – là nơi bạn có thể nhìn thấy user đang có gì, chọn gì, đã làm gì.
Hiểu cấu trúc DB – giống như nhìn được bản đồ nội tạng của hệ thống.
Từ đó, bạn không chỉ "nghe" yêu cầu của khách, mà bạn bắt đầu "cảm" được logic vận hành thật sự bên dưới.
2. Cách hệ thống lưu trữ và kết nối dữ liệu – thông qua DB và ERD
ERD (Entity Relationship Diagram) không phải là thứ để cho “mấy bạn dev dùng chơi”.
Nó là nơi phản ánh:
Mỗi “nghiệp vụ” được lưu ở đâu?
Có bao nhiêu thực thể chính?
Một booking gắn với user bằng cách nào?
Khi người dùng thao tác “xóa” thì bản ghi được xóa thật, hay chỉ bị gắn flag?
Bạn không cần hiểu câu lệnh SQL siêu cấp, nhưng bạn cần hiểu rằng:
Một bảng là một câu chuyện.
Một foreign key là một mối quan hệ giữa các thực thể đang có tương tác với nhau ngoài đời thực.
3. Tư duy logic: Mỗi chức năng trên UI đều là phản ánh của một dòng dữ liệu
Khi bạn click “Tạo lịch hẹn” → điều gì đang diễn ra?
→ Dữ liệu được ghi vào bảng nào?
→ Dữ liệu nào là bắt buộc? Có validate không?
→ Có ghi log lại thao tác không? Nếu lỗi thì rollback thế nào?
👉 Biết được điều đó không cần bạn viết code, chỉ cần biết hỏi đúng câu hỏi với dev, với QA, với BA.
Và bạn sẽ không hỏi được nếu bạn không biết hệ thống có cấu trúc gì, dữ liệu đang nằm ở đâu.
 
4. Vấn đề thực sự không phải bạn không giỏi kỹ thuật – mà là bạn không hiểu được ranh giới của mình cần vững ở đâu
Một BrSE non-tech mạnh không phải người biết code.
Mà là người hiểu hệ thống tốt đến mức biết được nên hỏi gì – và hỏi ai.
Bạn không sửa được bug, nhưng bạn biết ảnh hưởng của bug đó sẽ lan ra đâu.
Bạn không viết được SQL join 3 bảng, nhưng bạn hiểu vì sao bảng booking không liên kết được với bảng doctor_schedule.
 
5. Lộ trình học: Không học để thành dev – học để biết dẫn dắt và đặt câu hỏi đúng
Nếu bạn thật sự nghiêm túc:
1. Bắt đầu từ việc học đọc ERD:
Xin sơ đồ ERD của hệ thống bạn đang làm
Dùng marker tô màu:
Màu đỏ: các bảng chính
Màu xanh: bảng phụ, lookup
Màu vàng: bảng log/history
Tự hỏi:
Có mối quan hệ 1-N nào đặc biệt?
Có bảng nào dùng chung khóa chính với bảng khác?
Dữ liệu “trạng thái” đang được lưu trong bảng nào?
2. Học SQL đủ dùng để “ngó vào DB”
SELECT, JOIN, WHERE, ORDER BY, COUNT, GROUP BY
Tự thử viết query trả về:
Số booking theo tháng
Danh sách bệnh nhân khám trong 7 ngày gần nhất
Học từ:
SQLBolt.com
w3school.com
Thực hành: hỏi dev xin quyền access DB test và tập query nhẹ nhàng
Học khóa học online trên coursera
Refer viết giới thiệu khóa học về database của Meta trên coursera:
https://www.facebook.com/groups/441834957370096/permalink/1010991127121140
 
🌱 Đúc kết lại
Bạn không code được, không sao.
Nhưng bạn không thể không hiểu hệ thống.
Nếu bạn muốn vượt khỏi cái bóng "chuyển lời" – bạn phải chọn:
Trở thành người dẫn dắt suy nghĩ, chứ không phải người ghi chép lại lời nói.
Học cách hiểu hệ thống, không phải để trở thành dev – mà là để trở thành người BrSE có trọng lượng trong team. Một người đủ hiểu để kết nối – đủ sâu để phản biện – và đủ tôn trọng kỹ thuật để tạo ra tiếng nói chung.
 
✍️ Gửi đến những bạn IT Comtor đang đứng trước ngã rẽ mang tên “BrSE non-tech”
Mỗi người chúng ta đều có hành trình và lựa chọn riêng.
Có người chọn đi bằng con đường này, có người sẽ rẽ sang một hướng khác. Riêng mình, con đường đến với BrSE là một hành trình rất riêng, và chuỗi series này đơn giản là bản ghi chép lại những gì mình đã học, đã trải qua, đã vấp ngã và đang dần trưởng thành.
Nếu bạn cũng đang nuôi trong mình khát khao phát triển xa hơn trên con đường IT, nhưng lại không xuất phát từ kỹ thuật – thì mình hy vọng rằng những chia sẻ này có thể trở thành một chiếc la bàn nhỏ, giúp bạn định hình lại hướng đi, hoặc chí ít là góp thêm một góc nhìn thực tế, gần gũi và đáng để tham khảo.
👉 Không phải ai cũng cần trở thành BrSE. Nhưng nếu bạn đang ấp ủ ước mơ đó, thì biết đâu chính những dòng này sẽ là bước khởi đầu đầu tiên cho một hành trình mới.
 
#BrSEnontech #Taiyangsharing #ITcomtorToBrSE #hànhtrìnhtrởthànhBrSEnontech #ITstorytelling #ITtopic #SQLforlife