Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một câu hỏi mà tôi thường đặt ra cho các Product Owner (PO) mới vào nghề: "Bạn có cần biết viết code không?" Câu trả lời của tôi luôn là: "Không, nhưng bạn cần hiểu code đủ để không bị qua mặt và không vô tình ra những quyết định đắt giá."
Trong thực tế làm việc tại các công ty công nghệ ở Việt Nam, tôi đã chứng kiến không ít PO rơi vào hai thái cực nguy hiểm. Một số PO né tránh hoàn toàn phần kỹ thuật, coi đó là "việc của dev", và kết quả là họ ưu tiên backlog dựa trên cảm tính kinh doanh thuần túy, bỏ qua những rủi ro kỹ thuật khổng lồ đang âm thầm tích tụ. Thái cực còn lại là những PO cố gắng can thiệp quá sâu vào cách dev viết code, làm mất quyền tự chủ của đội ngũ và phá vỡ tinh thần Scrum.
Bài học hôm nay nằm ở chỗ chính giữa: một PO giỏi không cần là kỹ sư, nhưng cần đủ "literacy kỹ thuật" — khả năng đọc hiểu ngôn ngữ của đội phát triển — để đưa ra quyết định thông minh về thứ tự ưu tiên, đánh đổi (trade-off), và đầu tư dài hạn. Khi bạn hiểu được vì sao một tính năng "trông đơn giản" lại tốn ba sprint, vì sao đội kỹ thuật cứ nài nỉ "cho tụi em một sprint dọn nợ kỹ thuật", hay vì sao việc chọn nền tảng hôm nay quyết định tốc độ ra mắt sản phẩm trong hai năm tới — lúc đó bạn mới thực sự là người cầm lái sản phẩm, chứ không phải người ngồi ghế sau.
Trong bài này, chúng ta sẽ đi qua những khái niệm kỹ thuật cốt lõi mà mọi PO cần nắm: cách một ứng dụng được cấu trúc (kiến trúc cơ bản), API và sự phụ thuộc giữa các thành phần, và đặc biệt là nợ kỹ thuật (technical debt) — kẻ thù vô hình nhưng tốn kém nhất của mọi sản phẩm.
Khái niệm cốt lõi
Kiến trúc cơ bản: một ứng dụng được lắp ráp như thế nào
Hãy hình dung một ứng dụng phần mềm giống như một nhà hàng. Khách hàng ngồi ở bàn (giao diện người dùng — frontend), gọi món qua người phục vụ (lời gọi API), bếp chế biến (xử lý logic — backend), và kho nguyên liệu lưu trữ đồ ăn (cơ sở dữ liệu — database). Người phục vụ không tự nấu, kho không tự phục vụ khách — mỗi bộ phận có vai trò riêng và giao tiếp với nhau qua những "giao thức" rõ ràng.
Cụ thể hơn, một sản phẩm web/mobile điển hình gồm các tầng:
- Frontend (Client): phần người dùng nhìn thấy và tương tác — chạy trên trình duyệt hoặc app điện thoại. Đây là nơi xử lý hiển thị, không phải nơi lưu dữ liệu quan trọng.
- Backend (Server): "bộ não" xử lý logic nghiệp vụ — kiểm tra đăng nhập, tính toán giá, áp dụng quy tắc kinh doanh.
- Database: nơi lưu trữ dữ liệu lâu dài — thông tin người dùng, đơn hàng, sản phẩm.
- API (Application Programming Interface): "hợp đồng giao tiếp" giữa các tầng. Khi frontend cần dữ liệu, nó gọi API của backend. API quy định: gọi cái gì, gửi gì lên, nhận lại gì.
API và sự phụ thuộc (dependencies)
Một sản phẩm hiện đại hiếm khi tự làm mọi thứ. Nó dựa vào các dịch vụ bên thứ ba: cổng thanh toán (như MoMo, VNPay, ZaloPay ở Việt Nam), dịch vụ gửi SMS/email, bản đồ, lưu trữ đám mây. Mỗi dịch vụ này được tích hợp qua API.
Điều PO cần nhận thức: mỗi phụ thuộc bên ngoài là một điểm rủi ro và một điểm chậm trễ tiềm tàng. Nếu tính năng của bạn phụ thuộc vào việc đối tác cấp quyền truy cập API, thì lịch ra mắt của bạn không còn nằm hoàn toàn trong tay đội ngũ nữa. Tôi sẽ minh họa điều này bằng một tình huống cụ thể ở phần sau.
Nợ kỹ thuật (Technical Debt) — khái niệm quan trọng nhất bài này
Đây là khái niệm mà mọi PO phải hiểu thấu. Thuật ngữ "nợ kỹ thuật" được Ward Cunningham đưa ra với một phép ẩn dụ tài chính rất hay: khi đội ngũ chọn giải pháp nhanh-nhưng-không-tối-ưu để kịp deadline, họ đang "vay nợ". Giải pháp đó giúp ship nhanh hôm nay, nhưng về sau bạn phải trả "lãi" — dưới dạng code khó sửa, bug nhiều hơn, và mỗi tính năng mới càng ngày càng tốn thời gian.
Có nhiều loại nợ kỹ thuật:
- Nợ cố ý, có chiến lược: "Chúng ta biết cách làm này chưa tối ưu, nhưng cần ra mắt kịp Tết để bắt mùa mua sắm. Sẽ refactor sau." — Đây là khoản vay hợp lý nếu được ghi nhận và trả đúng hạn.
- Nợ cố ý, liều lĩnh: "Không có thời gian viết test, cứ đẩy lên đi." — Vay mà không có kế hoạch trả.
- Nợ vô tình: Đội ngũ học hỏi và nhận ra giải pháp cũ không còn phù hợp khi sản phẩm lớn lên. Loại này không tránh được.
Vai trò của PO không phải là loại bỏ hoàn toàn nợ kỹ thuật — điều đó bất khả thi và cũng không khôn ngoan. Vai trò của bạn là quản lý nó như quản lý một danh mục đầu tư: biết mình đang nợ bao nhiêu, lãi suất ra sao, và chủ động dành một phần "ngân sách" của mỗi sprint (thông thường 15–20% năng lực) để trả nợ, thay vì để nó tích tụ đến mức sản phẩm "vỡ nợ" — tức là đến lúc thêm bất kỳ tính năng nào cũng gần như bất khả thi.
Đọc hiểu ước lượng và độ phức tạp
PO không tự ước lượng, nhưng cần hiểu vì sao một con số được đưa ra. Khi đội ngũ nói "việc này 8 story point, không phải 2", thường vì một trong các lý do: cần chạm nhiều tầng kiến trúc, phụ thuộc bên thứ ba, hoặc phải đụng vào vùng code có nhiều nợ kỹ thuật. Hiểu được điều này giúp bạn đặt câu hỏi đúng — "Có cách nào làm phiên bản nhỏ hơn (MVP) trước không?" — thay vì gây áp lực mù quáng.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán nợ kỹ thuật khi tăng trưởng nóng
Hãy tưởng tượng một sàn thương mại điện tử như Tiki trong giai đoạn tăng trưởng nóng. Để giành thị phần, đội sản phẩm liên tục ép tiến độ: tính năng flash sale, voucher, ví điện tử... tất cả được ship trong vòng vài tháng. Mỗi tính năng đều "vay" một ít nợ kỹ thuật để kịp deadline.
Sau khoảng một năm, một PO mới tiếp quản module thanh toán nhận ra điều bất thường: một thay đổi nhỏ — thêm một phương thức trả góp — được dev ước lượng tới 13 story point, tương đương gần cả sprint. Khi hỏi kỹ, cô phát hiện logic thanh toán đã được "vá" quá nhiều lần đến mức không ai dám sửa vì sợ vỡ những phần khác. Tỷ lệ lỗi thanh toán đã âm thầm tăng từ 0,3% lên 1,1% giao dịch — với hàng trăm nghìn giao dịch mỗi ngày, đó là con số khủng khiếp.
Bài học: PO này không đổ lỗi cho dev. Cô lập một "biểu đồ nợ kỹ thuật" đơn giản, đưa nó vào backlog như những item có giá trị kinh doanh rõ ràng (giảm tỷ lệ lỗi giao dịch trực tiếp cứu doanh thu), và thuyết phục ban lãnh đạo dành 2 sprint refactor module thanh toán. Sau đó, velocity cho các tính năng thanh toán mới tăng gần gấp đôi. Đây là minh chứng: trả nợ kỹ thuật không phải chi phí, mà là khoản đầu tư có ROI đo được.
Tình huống 2 — Một startup fintech và cái bẫy phụ thuộc API
Một startup fintech tại TP.HCM xây dựng ứng dụng cho vay tiêu dùng, cần tích hợp eKYC (xác thực danh tính điện tử) qua API của một nhà cung cấp bên ngoài. PO cam kết với nhà đầu tư sẽ ra mắt trong 8 tuần và lên kế hoạch sprint dày đặc.
Vấn đề: đội ngũ chỉ bắt đầu xử lý phần tích hợp eKYC ở sprint thứ ba. Đến lúc đó mới phát hiện nhà cung cấp API yêu cầu quy trình phê duyệt pháp lý kéo dài 3 tuần và môi trường sandbox của họ thường xuyên lỗi. Lịch ra mắt đổ vỡ, trễ gần một tháng.
Bài học: Nếu PO hiểu rằng "phụ thuộc bên thứ ba là rủi ro nằm ngoài tầm kiểm soát của đội", cô đã ưu tiên việc xác minh và tích hợp API rủi ro cao này ngay từ sprint đầu (nguyên tắc "đối mặt rủi ro lớn nhất sớm nhất"). Literacy kỹ thuật ở đây không phải biết code eKYC, mà là biết đặt câu hỏi: "Tính năng nào của chúng ta phụ thuộc vào bên ngoài? Điều gì xảy ra nếu họ chậm?"
Tình huống 3 — Quyết định kiến trúc "tưởng nhỏ mà lớn" tại một công ty SaaS
Một công ty SaaS B2B ở Đông Nam Á phục vụ khách hàng doanh nghiệp. Một khách hàng lớn ở Singapore yêu cầu dữ liệu phải được lưu trong khu vực của họ vì quy định pháp lý. PO ban đầu coi đây là "một yêu cầu cấu hình nhỏ".
Khi trao đổi với kiến trúc sư hệ thống, anh mới vỡ lẽ: hệ thống được thiết kế với một database tập trung duy nhất (single-tenant database tập trung). Việc tách dữ liệu theo vùng địa lý đòi hỏi thay đổi kiến trúc nền tảng — công việc nhiều tháng, không phải vài ngày.
Bài học: PO hiểu kiến trúc đủ để dịch yêu cầu kinh doanh thành tác động kỹ thuật, và ngược lại. Thay vì hứa hẹn mù quáng với khách hàng, anh thương lượng được một lộ trình hợp lý, đồng thời đưa "khả năng phân vùng dữ liệu" thành một quyết định chiến lược cho roadmap — vì anh dự đoán nhiều khách hàng doanh nghiệp khác cũng sẽ cần. Quyết định kiến trúc hôm nay định hình khả năng bán hàng của ngày mai.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn nâng cao literacy kỹ thuật và áp dụng nó vào công việc PO hằng ngày:
- Vẽ sơ đồ kiến trúc sản phẩm của bạn. Ngồi với tech lead 30 phút, nhờ họ vẽ một sơ đồ đơn giản: frontend, backend, database, và các dịch vụ bên thứ ba. Bạn không cần hiểu chi tiết bên trong, chỉ cần biết các "khối" và cách chúng nối với nhau. Dán nó lên tường.
- Lập danh sách các phụ thuộc bên ngoài. Với mỗi dịch vụ bên thứ ba (thanh toán, SMS, bản đồ...), ghi rõ: ai cung cấp, mức độ quan trọng, và điều gì xảy ra nếu nó gặp sự cố. Đây là bản đồ rủi ro của bạn.
- Thiết lập "ngân sách nợ kỹ thuật" cho mỗi sprint. Thống nhất với đội ngũ một tỷ lệ năng lực cố định (ví dụ 15–20%) dành cho việc trả nợ kỹ thuật và cải thiện chất lượng. Đưa các item này vào backlog với mô tả giá trị kinh doanh rõ ràng, không để chúng là "việc ẩn".
- Học cách đặt câu hỏi đúng thay vì ra lệnh. Khi nhận ước lượng cao bất ngờ, hỏi: "Điều gì khiến việc này phức tạp? Có phần nào ta làm nhỏ hơn trước được không? Đây là độ phức tạp thực sự hay vì code cũ?" Câu hỏi tốt còn giá trị hơn kiến thức kỹ thuật.
- Tham gia (im lặng) các buổi technical discussion. Ngồi nghe đội ngũ thảo luận giải pháp, ghi lại những thuật ngữ bạn chưa hiểu rồi tra cứu sau. Sau vài tháng, vốn từ kỹ thuật của bạn sẽ tăng đáng kể.
- Đưa rủi ro kỹ thuật cao lên sớm trong roadmap. Áp dụng nguyên tắc "đối mặt với điều bất định lớn nhất trước". Việc tích hợp khó, công nghệ mới, phụ thuộc bên ngoài — hãy ưu tiên xử lý sớm để lộ rủi ro ra ánh sáng khi vẫn còn thời gian xoay xở.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi nợ kỹ thuật là "việc của dev, không liên quan đến mình." Đây là sai lầm tốn kém nhất. Nợ kỹ thuật trực tiếp ảnh hưởng đến tốc độ ra mắt tính năng — tức là ảnh hưởng đến chính KPI của PO. Mẹo: hãy quy đổi nợ kỹ thuật ra ngôn ngữ kinh doanh (chậm tiến độ, tăng lỗi, mất khách) khi trình bày với lãnh đạo.
Lỗi 2 — Học kỹ thuật rồi can thiệp vào cách dev viết code. Literacy kỹ thuật là để bạn ra quyết định what và why, không phải how. Việc chọn giải pháp kỹ thuật là quyền tự chủ của đội ngũ. Mẹo: nói "tôi cần kết quả X và ràng buộc Y", đừng nói "hãy dùng công nghệ Z".
Lỗi 3 — Hứa với khách hàng/sếp trước khi hiểu tác động kỹ thuật. Như tình huống công ty SaaS, một yêu cầu "nhỏ" có thể chạm vào nền tảng. Mẹo: luôn nói "để tôi xác nhận với đội kỹ thuật" trước khi cam kết deadline cho bất kỳ thay đổi nào động đến dữ liệu, bảo mật, hay tích hợp.
Lỗi 4 — Để nợ kỹ thuật vô hình trong backlog. Nếu các item kỹ thuật không xuất hiện trên backlog, chúng sẽ không bao giờ được ưu tiên. Mẹo: làm cho nợ kỹ thuật "hữu hình" — đặt tên, ước lượng, và gắn giá trị kinh doanh cho nó như mọi item khác.
Mẹo vàng: Hãy xây dựng mối quan hệ tin cậy với tech lead. Một PO có literacy kỹ thuật tốt cộng với một tech lead sẵn sàng "dịch" những vấn đề phức tạp sẽ tạo thành một cặp đôi quyền lực ra quyết định nhanh và chính xác.
Bài tập thực hành
- Sơ đồ kiến trúc: Hẹn tech lead (hoặc một developer) trong sản phẩm bạn đang làm, nhờ họ vẽ sơ đồ kiến trúc cơ bản. Tự viết lại bằng ngôn ngữ của bạn: dữ liệu đi từ đâu đến đâu khi người dùng thực hiện một hành động cốt lõi (ví dụ: đặt một đơn hàng).
- Bản đồ phụ thuộc: Liệt kê tất cả các dịch vụ bên thứ ba mà sản phẩm của bạn phụ thuộc. Với mỗi cái, viết một câu: "Nếu dịch vụ này ngừng hoạt động 1 giờ, điều gì xảy ra với người dùng?"
- Phỏng vấn nợ kỹ thuật: Hỏi đội ngũ của bạn: "Nếu được dành 2 sprint chỉ để cải thiện chất lượng kỹ thuật, các bạn sẽ làm gì và tại sao?" Ghi lại 3 vấn đề lớn nhất, rồi thử quy đổi mỗi vấn đề thành tác động kinh doanh.
- Tái ưu tiên rủi ro: Lấy roadmap hiện tại của bạn, đánh dấu những tính năng có phụ thuộc bên ngoài hoặc công nghệ mới. Thử sắp xếp lại để các rủi ro kỹ thuật lớn nhất được xử lý sớm hơn. Giải thích lựa chọn của bạn trong 3–4 câu.
Tóm tắt
Product Owner không cần trở thành kỹ sư, nhưng cần đủ literacy kỹ thuật để ra quyết định thông minh. Trong bài này, chúng ta đã đi qua ba trụ cột:
- Kiến trúc cơ bản: hiểu một sản phẩm gồm frontend, backend, database và API giúp bạn biết một thay đổi sẽ chạm vào đâu và vì sao ước lượng thay đổi.
- Phụ thuộc và rủi ro: mỗi tích hợp bên thứ ba là một điểm rủi ro nằm ngoài tầm kiểm soát — hãy lập bản đồ và đối mặt với rủi ro lớn nhất sớm nhất.
- Nợ kỹ thuật: kẻ thù vô hình nhưng tốn kém nhất. PO giỏi quản lý nó như một danh mục đầu tư — làm nó hữu hình, dành ngân sách trả nợ đều đặn, và quy đổi nó ra ngôn ngữ kinh doanh.