Business & Product Thinking: Tư duy ngoài Mã nguồn

Trả lời: Để biết được tính năng nào thực sự quan trọng mang lại tiền/giá trị cho công ty, từ đó ưu tiên nguồn lực và thiết kế giải pháp phù hợp.

Trả lời: Sản phẩm khả thi tối thiểu. Là phiên bản sản phẩm có đủ các tính năng cơ bản nhất để tung ra thị trường lấy phản hồi từ người dùng, tránh lãng phí thời gian vào các tính năng thừa.

Trả lời: Là thời gian từ lúc có ý tưởng đến khi sản phẩm đến tay người dùng. Trong kinh doanh, ra mắt sớm để chiếm lĩnh thị trường thường quan trọng hơn việc có một hệ thống hoàn hảo 100%.

Trả lời: Họ là người trả tiền và sử dụng sản phẩm. Mọi dòng code viết ra cuối cùng đều phải phục vụ nhu cầu của họ. Code sạch mà user không dùng được thì vẫn là sản phẩm thất bại.

Trả lời:

• Feature: Tính năng kỹ thuật (ví dụ: Tốc độ xử lý 1ms).
• Benefit: Lợi ích mang lại (ví dụ: Giúp khách hàng không phải chờ đợi khi thanh toán). Kinh doanh tập trung vào Benefit.

Trả lời: Vì cách bạn viết code và thiết kế kiến trúc trực tiếp quyết định số tiền công ty phải trả hàng tháng. Code không tối ưu có thể làm “đốt” hàng ngàn USD tiền server.

Trả lời: Giúp nhận ra các lỗi logic hoặc các tính năng gây khó chịu mà lập trình viên không tự thấy được trong quá trình phát triển.

Trả lời: Là việc mượn thời gian của tương lai để tiêu cho hiện tại. Nếu nợ quá nhiều, khả năng cạnh tranh của công ty sẽ giảm do không thể ra mắt tính năng mới nhanh được nữa.

Trả lời:

• B2B (Doanh nghiệp): Ưu tiên tính ổn định, bảo mật và khả năng tích hợp.
• B2C (Cá nhân): Ưu tiên trải nghiệm người dùng (UX), giao diện (UI) và tốc độ.

Trả lời: Để đảm bảo các bên (Dev, Design, Product, Client) hiểu đúng yêu cầu, tránh việc xây dựng sai thứ người dùng cần.

Trả lời: Trong kỹ thuật không có giải pháp hoàn hảo, chỉ có giải pháp phù hợp nhất. Ví dụ: Đánh đổi giữa Tốc độ phát triển nhanh vs Hiệu năng hệ thống tối đa.

Trả lời:

• SLI: Chỉ số thực tế (Uptime 99.5%).
• SLO: Mục tiêu nội bộ (Hướng tới 99.9%).
• SLA: Cam kết hợp đồng với khách hàng (Nếu dưới 99% sẽ bồi thường).

Trả lời: Chia nhỏ task. Dùng phương pháp so sánh (Story Points). Luôn cộng thêm thời gian dự phòng cho rủi ro (Buffer). Học hỏi từ các lần ước lượng sai trước đó.

Trả lời:

• Buy (SaaS): Nhanh, tốn phí hàng tháng, không tốn công bảo trì (ví dụ: dùng Stripe cho thanh toán).
• Build: Tùy biến cao, tốn thời gian và nhân sự phát triển. Quyết định dựa trên việc tính năng đó có phải là “Core Value” của công ty không.

Trả lời: Sử dụng dữ liệu thực tế (Analytics, A/B Testing) để quyết định hướng đi tiếp theo thay vì dựa vào cảm tính cá nhân.

Trả lời: Luôn cập nhật tiến độ thường xuyên. Báo cáo rủi ro sớm nhất có thể. Đừng hứa những gì không chắc chắn làm được (Under-promise and over-deliver).

Trả lời: Khi bạn dành 1 tháng để refactor code sạch sẽ, bạn đã mất đi cơ hội ra mắt một tính năng mới có thể mang lại 1000 khách hàng trong tháng đó.

Trả lời: Giúp kỹ sư hiểu được bối cảnh sử dụng: User là ai? Họ dùng app lúc nào? Trên thiết bị gì? Từ đó đưa ra các quyết định kỹ thuật phù hợp (ví dụ: ưu tiên offline mode nếu user ở vùng mạng yếu).

Trả lời: Giúp giảm thiểu “Bus Factor” (nếu 1 người nghỉ việc hệ thống không bị sập). Giúp onboard nhân sự mới nhanh chóng, giảm chi phí vận hành lâu dài.

Trả lời: Khả năng hệ thống tăng trưởng để phục vụ lượng khách hàng lớn hơn mà không cần tăng chi phí nhân sự/hạ tầng một cách tuyến tính.

Trả lời: Sử dụng Spot Instances cho worker. Tự động tắt server dev vào ban đêm. Chuyển dữ liệu ít dùng sang Cold Storage. Tối ưu query để giảm dung lượng data transfer.

Trả lời: Monolith rẻ và nhanh lúc đầu. Microservices đắt đỏ, phức tạp về hạ tầng nhưng giúp team lớn làm việc song song hiệu quả hơn. Chỉ chuyển đổi khi Monolith trở thành nút thắt cổ chai cho sự phát triển của công ty.

Trả lời: Xây dựng văn hóa “Pragmatic Engineering”. Ưu tiên các giải pháp kỹ thuật có giá trị kinh doanh rõ ràng. Sử dụng các số liệu kỹ thuật để chứng minh tác động đến doanh thu/chi phí.

Trả lời: Đánh đổi giữa Chi phí (Shared rẻ hơn) vs Bảo mật/Performance (Isolated tốt hơn). Architect cần chọn mô hình phù hợp với túi tiền và yêu cầu bảo mật của khách hàng mục tiêu.

Trả lời: Phần mềm không bao giờ thực sự “xong”. Nó là vòng lặp liên tục: Launch -> Measure -> Learn -> Iterate. Kỹ sư cần thiết kế kiến trúc sao cho việc “Iterate” (thay đổi) là dễ dàng nhất.

Trả lời: Kiểm tra: 1. Cộng đồng hỗ trợ. 2. Khả năng tuyển dụng nhân sự biết công nghệ đó. 3. Độ ổn định lâu dài. 4. Chi phí chuyển đổi nếu công nghệ đó bị khai tử.

Trả lời:

• RTO (Recovery Time Objective): Hệ thống sập bao lâu thì phải sống lại?
• RPO (Recovery Point Objective): Chấp nhận mất dữ liệu trong bao nhiêu phút/giờ? Kinh doanh càng nhạy cảm (như ngân hàng) thì RTO/RPO càng phải tiến về 0, nhưng chi phí sẽ tăng cực cao.

Trả lời: Dự báo các rào cản kỹ thuật trong 1-2 năm tới dựa trên định hướng kinh doanh. Chuẩn bị sẵn hạ tầng và kiến trúc trước khi nhu cầu kinh doanh ập đến.

Trả lời: Kỹ sư chủ động đề xuất các giải pháp công nghệ tạo ra dòng tiền mới hoặc tiết kiệm chi phí vận hành khổng lồ, thay vì chỉ ngồi đợi nhận task từ Product Manager.

Xử lý: 1. Đề xuất phương án MVP (cắt giảm các yêu cầu không quan trọng). 2. Chấp nhận nợ kỹ thuật có kế hoạch (viết code chạy được trước, refactor sau). 3. Giải thích rõ rủi ro cho sếp nếu ép deadline quá mức.

Xử lý: 1. Audit lại toàn bộ tài nguyên (xóa các server rác, ổ cứng không dùng). 2. Kiểm tra log traffic để tìm các endpoint bị call vô tội vạ. 3. Áp dụng Caching và CDN để giảm tải server chính. 4. Xem xét Reserved Instances cho các server chạy 24/7.