TỪ CODER ĐẾN PROBLEM SOLVER: NGHỆ THUẬT NHẬN TASK VÀ TƯ DUY LÀM SẢN PHẨM

Sai lầm phổ biến nhất của một lập trình viên khi nhận task là gì? Đó là đọc lướt mô tả (spec), mở IDE lên và cắm cúi gõ code ngay lập tức.

Thực tế, code chỉ là công cụ. Cốt lõi của việc phát triển phần mềm không nằm ở việc bạn viết ra bao nhiêu dòng code, mà nằm ở việc bạn giải quyết được vấn đề gì. Dưới đây là bộ tư duy "nhận task" giúp bạn chuyển mình từ một Coder thuần túy thành một Problem Solver (người giải quyết vấn đề) – bước đệm tiên quyết để trở thành một Tech Lead xuất sắc.

1. Bức Tranh Tổng Thể: Đừng Vội Hỏi "How", Hãy Bắt Đầu Bằng "Why" Và "What"

Khi một yêu cầu (feature) được đưa xuống, trước khi suy nghĩ về thuật toán hay kiến trúc hệ thống, bạn cần làm rõ ba lăng kính sau:

• Giá trị người dùng (User Value): Tính năng này sinh ra để giải quyết "nỗi đau" (pain point) nào của người dùng? Nó giúp họ thao tác nhanh hơn, tiện lợi hơn, hay giảm thiểu sai sót?
  • Ví dụ: Nếu PO yêu cầu làm chức năng "Export Excel", đừng vội làm ngay. Hãy hỏi: "Người dùng cần file Excel này để làm gì?". Nếu họ chỉ cần xem báo cáo tổng quan, có thể một Dashboard biểu đồ trực quan mới là thứ họ thực sự cần.
• Giá trị kinh doanh (Business Value): Nếu không trực tiếp phục vụ người dùng cuối, feature này mang lại lợi ích gì cho tổ chức? Nó giúp tăng tỷ lệ chuyển đổi (conversion rate), tối ưu quy trình vận hành của đội Back-office, hay tiết kiệm chi phí hạ tầng server? Mọi dòng code viết ra đều phải có ý nghĩa về mặt kinh doanh.
• Giải pháp thay thế (Alternative Solutions): Dòng code tốt nhất là dòng code không bao giờ được viết ra. Liệu có cách nào đơn giản hơn để đạt được mục tiêu mà không cần đắp thêm logic phức tạp vào hệ thống không? Có thể tận dụng third-party services, hoặc chỉ cần thay đổi một chút trong quy trình vận hành (operations) thay vì dùng tech để xử lý hay không?

2. Tư Duy Chủ Động (Solution-Oriented): Lường Trước Tương Lai

Business Analyst (BA) hay Product Owner (PO) thường tập trung vào "Happy Path" (luồng lý tưởng). Trách nhiệm của một kỹ sư là phải nhìn thấy những cạm bẫy tiềm ẩn:

• Bài toán mở rộng (Scalability): Đừng chỉ test với 10 users. "Nếu sau một chiến dịch marketing, lượng truy cập tính năng này tăng gấp 10, gấp 100 lần trong cùng một thời điểm (concurrent requests) thì hệ thống, database có gánh nổi không? Có cần cache lại không?"
• Góc khuất hệ thống (Edge Cases): Có kịch bản lỗi nào PO chưa nghĩ tới không? Điều gì xảy ra nếu mạng lag, user click đúp 2 lần? Data đồng bộ bị gián đoạn giữa chừng thì xử lý rollback ra sao?
• Nguyên tắc "Đừng bao giờ báo cáo tay không": Khi gặp "đá tảng" (blocker) trong lúc làm task, đừng bao giờ nhắn cho Manager hay PO một câu cụt lủn: "Task này bị vướng, không làm được". Hãy phân tích nguyên nhân và chủ động mang đến 1-2 phương án xử lý (Options), kèm theo phân tích Ưu/Nhược điểm (ví dụ: Phương án A làm nhanh nhưng tốn tài nguyên server; Phương án B tối ưu nhưng trễ deadline 2 ngày). Quyết định cuối cùng có thể không phải của bạn, nhưng giải pháp phải xuất phát từ bạn.

3. Phá Vỡ Ranh Giới (Cross-Boundary) & Tinh Thần Làm Chủ (Ownership)

Một sản phẩm thành công không đến từ những cá nhân làm việc trong các ốc đảo (silo). Hãy nhìn rộng ra ngoài phạm vi mã nguồn của riêng mình:

• Sự thấu cảm với đồng đội (Cross-functional Empathy): Feature này ảnh hưởng thế nào đến Frontend, Mobile hay QA? Bạn đã chuẩn bị tài liệu API (Swagger/Postman) rõ ràng chưa? Dữ liệu trả về đã được tối ưu để client dễ dàng parse chưa? Bạn có chủ động gợi ý các kịch bản test (Test Cases) khó nhằn để QA dễ dàng kiểm chứng không?
• Vòng đời sau triển khai (Post-Deployment): Nhiệm vụ không kết thúc khi code được merge vào nhánh master. Sau khi deploy, làm sao để biết tính năng hoạt động ổn định? Cần gắn những metrics giám sát (Prometheus, Grafana) nào? Cần ghi log (Elasticsearch) ra sao để trace lỗi khi có sự cố? Và quan trọng nhất: Làm sao để đo lường xem user có thực sự bấm vào dùng tính năng đó hay không?

💡 Lời Kết

Việc đặt ra những câu hỏi sắc sảo không làm chậm tiến độ dự án, mà ngược lại, nó giúp tiết kiệm hàng tuần lễ đập đi xây lại vì hiểu sai yêu cầu ban đầu. Khi bạn bắt đầu trăn trở về giá trị cốt lõi, về người dùng và hệ sinh thái xung quanh đoạn code của mình, đó là lúc bạn chính thức lột xác từ một Coder trở thành một Problem Solver.