Tư duy (Mindset) khi làm Leader Bài 3: Nhìn bức tranh lớn - Hiểu Business và quy trình (Process).

Nhiều lập trình viên có thói quen nhìn công việc qua một cái "ống hút" – tức là chỉ thấy đúng ticket mình đang làm, file code mình đang sửa. Leader thì khác, họ phải đứng trên cao để nhìn thấy toàn bộ hệ thống bánh răng đang vận hành ra sao.

Dưới đây là 3 lăng kính bạn cần trang bị để nhìn được "bức tranh lớn":

1. Lăng kính Kinh doanh (Business): Công ty sống bằng gì?

Code dù hay đến mấy mà không tạo ra tiền hoặc giá trị cho người dùng thì cũng chỉ là những dòng text vô nghĩa. Bạn cần hiểu sản phẩm của mình đang giải quyết bài toán gì cho thị trường.

• Hiểu dòng chảy giá trị (Value Stream): Người dùng vào app của bạn làm gì? Tính năng nào mang lại doanh thu chính? Tính năng nào giúp giữ chân khách hàng (retention)?
• Hiểu các chỉ số (Metrics): Thay vì chỉ quan tâm đến Response Time (thời gian phản hồi của server) hay Test Coverage (độ bao phủ test), hãy bắt đầu làm quen với những khái niệm của Product như: DAU/MAU (Lượng user active hàng ngày/tháng), Conversion Rate (Tỉ lệ chuyển đổi), Churn Rate (Tỉ lệ rời bỏ của user).
• Thay đổi cách đánh giá tính năng: Khi có một yêu cầu làm tính năng mới, khoan nghĩ đến kiến trúc hệ thống. Hãy tự hỏi: "Làm cái này thì user có dùng nhiều hơn không? Có mang lại thêm doanh thu hay lợi thế cạnh tranh gì cho công ty không?"

2. Lăng kính Hệ thống (Systems Thinking): Hiệu ứng Domino

Một sự thay đổi nhỏ ở backend có thể làm chậm frontend, gây lỗi cho ứng dụng mobile cũ chưa cập nhật, hoặc làm sai lệch dữ liệu của team Data Analyst.

Người có tư duy Leader luôn đánh giá tác động dây chuyền trước khi hành động:

• Nếu thay đổi cấu trúc Database này, những API nào bị ảnh hưởng?
• Việc deploy tính năng này có cần downtime (dừng hệ thống) không? Nếu có thì thời điểm nào ít ảnh hưởng tới user nhất?
• Team Customer Service (CS) đã được báo trước về sự thay đổi giao diện này chưa để họ còn hướng dẫn khách hàng?

3. Lăng kính Quy trình (Process): Bôi trơn các bánh răng

Quy trình phát triển phần mềm (SDLC) không chỉ có code. Nó bao gồm: Lên yêu cầu (BA/PO) $\rightarrow$ Thiết kế (UI/UX) $\rightarrow$ Code (Dev) $\rightarrow$ Kiểm thử (QA) $\rightarrow$ Triển khai (DevOps/Dev).

Thay vì phàn nàn "QA test chậm quá" hay "BA viết requirement không rõ ràng", Leader sẽ tìm cách tối ưu hóa quy trình (optimize the bottleneck):

• Nếu requirement thường xuyên không rõ ràng: Đề xuất có một buổi "Pre-planning" ngắn giữa Dev và BA để chốt kỹ thuật trước khi đưa vào Sprint.
• Nếu môi trường test thường xuyên chết: Chủ động làm việc với DevOps để thiết lập lại môi trường ổn định hơn, hoặc viết script tự động hóa để giảm tải.

Nguyên tắc: Đừng chỉ giải quyết hậu quả, hãy tìm ra lỗ hổng trong quy trình đã tạo ra cái hậu quả đó và vá nó lại.

📝 Bài tập thực hành cho Bài 3 (Trong tuần này)

1. Vẽ luồng kinh doanh (Business Flow): Không vẽ biểu đồ luồng dữ liệu (Data Flow) hay kiến trúc (Architecture). Hãy thử lấy giấy bút vẽ lại luồng người dùng (User Journey) đối với tính năng bạn đang làm. Họ click vào đâu, điều gì khiến họ hài lòng, điều gì có thể làm họ bực mình thoát app?
2. Trở thành "Thám tử quy trình": Quan sát team trong tuần này và tìm ra 1 công đoạn đang làm lãng phí thời gian nhất của mọi người (ví dụ: họp Daily quá dài, đợi chờ merge code quá lâu...). Nghĩ ra 1 giải pháp nhỏ (không tốn chi phí) để cải thiện nó và đề xuất trong buổi Retrospective (Cải tiến quy trình) của team.