[Series: Tư duy bứt phá] Phần 4: "Kỹ năng mềm" của một hệ thống "Cứng" - Thấu hiểu Domain Business

Ở Phần 3, chúng ta đã say sưa nói về Microservices, về Kafka, về Redis. Cảm giác thiết kế ra một hệ thống chịu tải hàng vạn request mỗi giây thật sự rất "phê".

Nhưng hôm nay, tôi dội một gáo nước lạnh vào bạn: Kiến trúc hệ thống của bạn có hoàn hảo đến mấy, vác những công nghệ tối tân nhất vào, mà giải quyết sai bài toán kinh doanh (Business Problem) thì tất cả đều là rác.

Ranh giới sinh tử giữa Kỹ sư và Thợ gõ không chỉ nằm ở việc hiểu máy tính, mà còn nằm ở việc hiểu con người và hiểu ngành nghề (Domain Business).

1. Code chỉ là công cụ, Giải quyết nỗi đau mới là đích đến

Thợ gõ nhìn mọi thứ dưới lăng kính của dữ liệu: Table này có mấy cột, API kia nhận payload gì.

Kỹ sư nhìn hệ thống dưới lăng kính của luồng nghiệp vụ (Business Flow).

Hãy lấy một bài toán rất "khoai" nhưng thực tế: Hệ thống Thu phí Tự động (Automatic Fare Collection - AFC) cho xe buýt hoặc tàu điện.

• Ticket từ BA viết: "Khi khách quẹt thẻ/mã QR tại cổng (gate), gọi API kiểm tra số dư. Nếu đủ tiền -> trừ tiền -> mở cổng."
• Tư duy Thợ gõ: Dễ ợt! Viết một cái API /api/v1/scan-ticket. Chọc vào database check balance. Đủ thì update lại balance, gọi HTTP request xuống thiết bị cứng để mở cổng. Test local chạy dưới 100ms. Done task!

Nhưng khi đem cái "logic hoàn hảo" đó ra thực tế nhà ga vào giờ cao điểm lúc 7h sáng, mọi thứ sụp đổ. Tại sao? Vì Thợ gõ không hiểu Domain Business của ngành giao thông công cộng. Mục tiêu tối thượng của nhà ga vào giờ cao điểm là Giải phóng đám đông cực nhanh, không phải là chờ API check số dư cầu kỳ. Mạng 4G/Wifi chập chờn, API gọi lên server trung tâm mất 2 giây mới phản hồi. 2 giây chờ đợi ở cổng x 1.000 người = Ách tắc kinh hoàng.

• Tư duy Kỹ sư (Hiểu Business): Kỹ sư biết rằng không thể phụ thuộc 100% vào mạng (Online). Họ thiết kế kiến trúc Offline-First. Thông tin số dư hoặc gói vé tháng được mã hóa và lưu trực tiếp trên thẻ cứng (Mifare/NFC). Khi quẹt, thiết bị đọc thẳng từ thẻ, tự tính toán và mở cổng trong 0.2 giây. Cuối ngày hoặc khi rảnh rỗi rớt mạng, thiết bị mới đồng bộ (sync) đống log giao dịch đó lên Server trung tâm (Kafka lao vào xử lý chỗ này).

Nếu có sai lệch, business chấp nhận rủi ro thất thoát một số tiền nhỏ (vài nghìn đồng cho 1 chuyến lậu), đổi lấy việc hệ thống thông suốt. Kỹ sư dùng giải pháp kỹ thuật để phục vụ cho sự đánh đổi của kinh doanh.

2. Nghệ thuật "Cãi" BA/PO (Push-back requirement)

Thợ gõ coi Requirement là Thánh chỉ. Giao sao làm vậy, lỡ có vô lý thì "do BA nó yêu cầu thế, em chỉ biết code".

Kỹ sư coi Requirement là Điểm bắt đầu của một cuộc thương lượng.

Sẽ có những ngày đẹp trời, PO yêu cầu bạn: "Anh cần một tính năng xuất Excel toàn bộ lịch sử giao dịch 5 năm qua của hệ thống ra một file real-time, user bấm cái phải có ngay". Thợ gõ sẽ đâm đầu vào nghiên cứu các luồng streaming data, tối ưu memory limit của PHP/NodeJS rớt nước mắt để không bị crash server.

Kỹ sư sẽ dừng lại và hỏi: "Tại sao anh lại cần file Excel này? Anh định dùng nó để làm gì?" Và câu trả lời của PO có thể là: "À, anh muốn xem tổng doanh thu của tháng 12 năm ngoái so với năm nay". Bùm! Bài toán thay đổi hoàn toàn. Thay vì làm tính năng export hàng chục triệu record (cực kỳ tốn resource và rủi ro), Kỹ sư đề xuất: "Thế em làm cho anh một cái Dashboard thống kê theo tháng đã được pre-calculate (tính toán sẵn) vào ban đêm nhé. Nhanh gấp 10 lần, server không chết, anh xem được ngay".

Giải pháp kỹ thuật tốt nhất đôi khi là không cần viết dòng code nào, mà thay đổi cách tiếp cận vấn đề của Business.

3. Ownership - Trách nhiệm với "Đứa con tinh thần"

Một đặc điểm chết người của hội chứng Thợ gõ là tư duy "Code xong là rũ bỏ trách nhiệm". Pull Request được merge, QA test pass, tính năng lên Production là họ phủi tay sang làm ticket khác.

Với Kỹ sư, Production không phải là điểm kết thúc, mà là Bắt đầu vòng đời của sản phẩm.

• Hệ thống trả về mã lỗi 500 vào ban đêm lúc user thanh toán ZaloPay/VNPay? Kỹ sư không đợi Customer Service gọi dậy. Họ đã chủ động cài alert bắn về Telegram/Slack và là người đầu tiên vào soi log tra mã lỗi (Status Code) từ Gateway bên thứ 3.
• Tính năng mới lên, Kỹ sư không chỉ check xem code có lỗi không, mà còn soi xem các chỉ số Business có thay đổi không (Tỉ lệ rớt đơn hàng có giảm không? Thời gian user ở lại trang có tăng không?).

Tạm kết

Đừng mãi giam mình trong cái "hang" của IDE và Terminal. Hãy bước ra ngoài, nói chuyện với đội Sales, đội Vận hành, ngồi với BA để hiểu xem dòng code của mình đang kiếm tiền cho công ty bằng cách nào.

Chỉ khi bạn hiểu được Business, bạn mới biết đâu là Core System (Hệ thống lõi) cần đổ 200% công lực để làm cho chuẩn, và đâu là những feature râu ria có thể "làm bẩn" một chút để tiết kiệm thời gian ra thị trường.

Phần cứng (Kiến trúc) bạn đã có. Phần mềm (Business) bạn đã thấu hiểu. Giờ là lúc đối mặt với "Trùm cuối". Nếu ngày mai một con AI có thể làm được 80% những gì bạn vừa tự hào, bạn sẽ làm gì? Đón xem phần kết: Kỷ nguyên AI - Trở thành "Nhạc trưởng" thay vì "Nhạc công".