Mở đầu — vì sao bài này quan trọng
Hãy hình dung tình huống quen thuộc: bạn là Product Manager, viết một PRD rất chỉn chu cho tính năng "đăng nhập bằng số điện thoại". Đội kỹ thuật báo "xong rồi", bạn vào test thử thấy chạy được, nhấn nút release. Hai tuần sau, đội bảo mật phát hiện rằng bản ghi log đang lưu cả mã OTP dưới dạng văn bản thuần. Tính năng "chạy được" trên màn hình, nhưng phần code phía sau làm sai hoàn toàn so với tinh thần của spec. Câu hỏi đặt ra: lẽ ra bạn có thể phát hiện sớm không?
Phần lớn PM trả lời "không, tôi đâu biết đọc code". Đó chính xác là rào cản mà bài học này muốn gỡ bỏ. Bạn không cần — và không nên — trở thành kỹ sư. Nhưng trong kỷ nguyên mà AI có thể "dịch" code sang ngôn ngữ con người chỉ trong vài giây, việc một PM ngó qua một Pull Request (PR — đề xuất thay đổi code mà kỹ sư gửi lên để review trước khi gộp vào sản phẩm) đã trở thành một kỹ năng khả thi và cực kỳ giá trị.
Mục tiêu của bài này rất cụ thể: dùng AI làm "người phiên dịch" để PM có thể đọc PR ở mức độ vừa đủ, nhằm (1) xác minh tính năng được build đúng như spec, (2) phát hiện scope creep — code làm thêm những thứ không nằm trong yêu cầu, hoặc code chết (dead code) không ai dùng, và (3) theo dõi tiến độ thực sự của một feature thay vì chỉ tin vào lời báo cáo. Đây không phải để bạn "soi" kỹ sư hay can thiệp vào quyết định kỹ thuật — đó là việc của tech lead. Đây là để bạn đóng vai trò người gác cổng sản phẩm tốt hơn.
Khái niệm cốt lõi
PM không phải engineer — và điều đó hoàn toàn ổn
Trước hết phải nói thẳng ranh giới. PM đọc PR KHÔNG nhằm đánh giá chất lượng kỹ thuật: thuật toán có tối ưu không, kiến trúc có sạch không, có bug ẩn không — đó là trách nhiệm của reviewer kỹ thuật. PM đọc PR để trả lời những câu hỏi thuộc về sản phẩm:
- Thay đổi này có khớp với hành vi mà spec mô tả không?
- Có ràng buộc nghiệp vụ nào (business rule) bị hiểu sai không?
- Có gì được thêm vào ngoài phạm vi đã thống nhất không?
- Feature đã hoàn thành thực sự hay mới chỉ là một phần?
Một PR thực sự gồm những gì
Một PR điển hình trên GitHub/GitLab có vài thành phần PM cần nhận diện:
- Tiêu đề và mô tả (description): kỹ sư tóm tắt họ làm gì. Đây là phần dễ đọc nhất.
- Danh sách file thay đổi: cho biết PR "đụng" vào đâu. Một PR cho tính năng đăng nhập mà lại sửa file liên quan đến thanh toán là một tín hiệu đáng hỏi.
- Diff: phần code được thêm (dòng xanh, dấu +) và xóa (dòng đỏ, dấu -). Đây là phần "đáng sợ" với PM, và cũng là phần AI giúp được nhiều nhất.
- Tests: code kiểm thử. Nếu một PR thêm tính năng lớn mà không có test nào, đó là điều đáng lưu ý.
AI là lớp phiên dịch giữa code và ngôn ngữ sản phẩm
Điểm mấu chốt của bài này: AI (Claude, ChatGPT, Gemini, hay tính năng AI ngay trong GitHub Copilot) có thể đọc một diff và giải thích bằng tiếng Việt rằng "thay đổi này khiến hệ thống, khi người dùng nhập sai mật khẩu quá 5 lần, sẽ khóa tài khoản trong 15 phút". Từ một đoạn diff khô khan, bạn nhận lại một câu mô tả hành vi mà bạn — người viết spec — đủ sức đối chiếu.
Sức mạnh nằm ở chỗ bạn không cần đọc cú pháp. Bạn cần đọc ý nghĩa, và AI chuyển cú pháp thành ý nghĩa. Tuy nhiên — và đây là điểm sẽ nhắc lại — AI có thể hiểu sai hoặc "đoán" khi thiếu ngữ cảnh, nên kết quả của AI là điểm khởi đầu cho một cuộc hỏi, không phải kết luận cuối cùng.
Ba việc PM nên làm khi đọc PR
- Verify against spec (đối chiếu với spec): lấy từng tiêu chí chấp nhận (acceptance criteria) trong PRD, hỏi xem PR có hiện thực đúng không.
- Spot scope creep & dead code: tìm những thay đổi không phục vụ mục tiêu của PR. Scope creep làm chậm tiến độ và phình rủi ro; dead code làm sản phẩm khó bảo trì.
- Track progress: đọc nhiều PR liên tiếp để biết một feature lớn đã đi được bao xa, thay vì chờ một báo cáo "90% xong" mơ hồ.
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "chạy được nhưng sai business rule"
Giả định một PM tại Tiki phụ trách tính năng "Freeship Extra cho đơn từ 200.000đ". Spec ghi rõ: ngưỡng tính trên giá trị sản phẩm sau khi trừ voucher giảm giá, không tính phí vận chuyển. Kỹ sư gửi PR, demo cho thấy đơn 250.000đ được freeship — đúng như mong đợi, ai cũng gật đầu.
PM dán phần diff vào Claude và hỏi: "Đoạn này tính ngưỡng freeship dựa trên giá trị nào — trước hay sau khi áp voucher?". AI trả lời rằng biến được dùng để so sánh là order.subtotal, và chỉ ra rằng trong codebase này subtotal được tính trước khi trừ voucher. Nghĩa là một đơn 250.000đ dùng voucher giảm 80.000đ (còn 170.000đ thực trả) vẫn được freeship — sai với spec.
Demo "chạy được" vì người demo dùng đơn không có voucher. Bài học: PM không tự đọc ra dòng order.subtotal, nhưng PM biết spec, biết câu hỏi cần hỏi, và dùng AI để soi đúng chỗ. Một câu hỏi đặt đúng chỗ đã chặn được một lỗi tốn tiền thật khi nhân lên hàng chục nghìn đơn mỗi ngày.
Ví dụ 2 — Startup fintech và scope creep âm thầm
Một startup ví điện tử ở TP.HCM (gọi là PayMoon) đang chạy nước rút cho tính năng "chuyển tiền theo lịch". PM theo dõi sát vì sắp đến deadline gọi vốn. Một PR được gửi lên với tiêu đề "Add scheduled transfer", nhưng PM để ý danh sách file thay đổi có cả file liên quan đến notification_settings và referral_bonus.
PM hỏi AI: "PR này khai báo là làm tính năng chuyển tiền theo lịch. Hãy liệt kê những thay đổi KHÔNG trực tiếp phục vụ mục tiêu đó." AI tóm tắt: ngoài phần lịch chuyển tiền, PR còn thêm một logic cộng điểm thưởng giới thiệu khi giao dịch thành công, và một thay đổi mặc định bật thông báo marketing.
Hai phần "thêm" đó không nằm trong spec. Khi PM hỏi lại, kỹ sư thừa nhận "tiện tay làm luôn vì thấy liên quan". Vấn đề: phần referral chưa được pháp chế duyệt, còn việc bật mặc định thông báo marketing có thể vi phạm nguyên tắc consent. PM yêu cầu tách hai phần đó ra khỏi PR. Bài học: scope creep hiếm khi xuất hiện với ý đồ xấu — nó đến từ thiện chí "tiện tay". Nhưng nó làm PR khó review, trộn lẫn rủi ro, và che mờ tiến độ thật. PM đọc danh sách file + một câu hỏi AI là đủ để phát hiện.
Ví dụ 3 — Theo dõi tiến độ thật của một feature lớn
Một PM tại công ty SaaS ở Singapore phụ trách tính năng "xuất báo cáo PDF có thương hiệu riêng" — một feature lớn, chia thành nhiều PR. Tech lead báo cáo hàng tuần "đang đúng tiến độ", nhưng PM muốn có cơ sở khách quan hơn để cập nhật cho khách hàng doanh nghiệp đang chờ.
Thay vì hỏi đi hỏi lại đội kỹ thuật, PM lập một danh sách 6 acceptance criteria, rồi với mỗi PR mới được merge, dán mô tả + diff vào AI và hỏi: "Trong 6 tiêu chí sau, PR này hoàn thành tiêu chí nào, một phần tiêu chí nào, và chưa đụng tới tiêu chí nào?" Sau 3 tuần, PM có một bảng theo dõi cho thấy 4/6 tiêu chí đã xong, tiêu chí "tùy chỉnh logo theo từng khách hàng" mới làm một nửa, và tiêu chí "hỗ trợ font tiếng Việt có dấu trong PDF" chưa được động đến.
Hóa ra phần font tiếng Việt bị bỏ quên — một rủi ro lớn vì nhiều khách hàng là doanh nghiệp Việt. PM nêu ra trong buổi sync, đội bổ sung kịp thời. Bài học: "đúng tiến độ" là một câu nói; đối chiếu PR với acceptance criteria là một dữ kiện. AI biến việc đọc code rải rác thành một bảng theo dõi tiến độ có thể tin được.
Hướng dẫn từng bước
Bước 1 — Chuẩn bị "thước đo" trước khi đọc. Mở PRD hoặc danh sách acceptance criteria của feature. Đừng đọc PR trong trạng thái không có gì để đối chiếu, vì khi đó bạn chỉ "ngắm" code chứ không "kiểm tra" nó. Hãy viết ra 3–6 câu hỏi cụ thể mà PR này phải trả lời.
Bước 2 — Đọc tiêu đề, mô tả và danh sách file trước. Đây là phần không cần AI. Tự hỏi: PR này tuyên bố làm gì? Nó đụng vào những vùng nào của sản phẩm? Có vùng nào bất ngờ không (ví dụ feature đăng nhập lại sửa file thanh toán)?
Bước 3 — Dùng AI để tóm tắt toàn cảnh. Dán mô tả PR và phần diff (hoặc dùng tính năng tóm tắt PR sẵn có trong GitHub Copilot) và hỏi một prompt kiểu: "Tôi là PM, không phải kỹ sư. Hãy giải thích bằng tiếng Việt, theo góc nhìn hành vi sản phẩm: thay đổi này làm người dùng hoặc hệ thống cư xử khác đi như thế nào? Tránh thuật ngữ kỹ thuật khi có thể."
Bước 4 — Đối chiếu từng acceptance criterion. Với mỗi tiêu chí trong "thước đo" ở Bước 1, hỏi AI: "PR này có hiện thực đúng yêu cầu sau không, và dựa vào dòng code nào? [dán tiêu chí]". Yêu cầu AI chỉ ra bằng chứng cụ thể (tên biến, tên hàm) để bạn dễ hỏi lại kỹ sư.
Bước 5 — Săn scope creep và dead code. Hỏi: "Liệt kê những thay đổi trong PR này KHÔNG trực tiếp phục vụ mục tiêu [tên feature]" và "Có đoạn code nào được thêm vào nhưng có vẻ không được gọi/sử dụng ở đâu không?". Lưu ý: AI chỉ "gợi ý nghi vấn", bạn dùng nó để đặt câu hỏi, không để kết tội.
Bước 6 — Chốt bằng đối thoại, không bằng comment phán xét. Mang phát hiện ra hỏi kỹ sư với tinh thần làm rõ: "Mình thấy ngưỡng freeship đang tính trên subtotal trước voucher, spec mình ghi là sau voucher — mình hiểu đúng không?" Cách hỏi này giữ được sự tôn trọng chuyên môn và biến việc đọc PR thành cộng tác, không phải giám sát.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin AI tuyệt đối. AI đọc một diff tách rời khỏi toàn bộ codebase nên dễ "đoán" sai về ngữ cảnh (ví dụ một biến tên subtotal ở dự án khác lại đã trừ voucher). Mẹo: luôn coi câu trả lời của AI là "giả thuyết cần xác nhận", và khi có thể, cung cấp thêm ngữ cảnh — file định nghĩa hàm, mô tả business rule — để AI bớt đoán mò. Đây cũng là lý do kỹ năng phát hiện AI bịa (sẽ học sâu hơn ở các bài về hallucination) rất quan trọng.
Lỗi 2 — Sa đà vào đánh giá kỹ thuật. PM bắt đầu bình luận về cách viết vòng lặp hay đặt tên biến. Đây là vượt vai trò và làm kỹ sư khó chịu. Mẹo: giữ mọi câu hỏi của bạn ở tầng "hành vi sản phẩm và business rule".
Lỗi 3 — Dán code nhạy cảm vào AI công cộng. Codebase có thể chứa khóa bí mật (API key), thông tin khách hàng, hoặc logic độc quyền. Mẹo: chỉ dùng công cụ AI được công ty phê duyệt, ưu tiên bản doanh nghiệp không dùng dữ liệu để huấn luyện; chủ động xóa/ẩn các giá trị nhạy cảm trước khi dán. (Chủ đề guardrails cho dữ liệu nhạy cảm có bài riêng.)
Lỗi 4 — Đọc PR quá trễ. Đợi đến lúc "xong hết" mới đọc thì scope creep đã ăn sâu, sửa lại tốn kém. Mẹo: đọc các PR sớm và nhỏ ngay khi chúng xuất hiện; PR nhỏ dễ hiểu hơn và rẻ hơn để điều chỉnh.
Mẹo cộng tác: thống nhất trước với đội kỹ thuật rằng bạn sẽ đọc PR ở góc độ sản phẩm. Khi đội hiểu mục đích là tránh build sai spec chứ không phải soi mói, họ thường chủ động viết mô tả PR rõ ràng hơn — lợi cho cả hai bên.
Bài tập thực hành
- Tìm một PR thật. Nếu công ty bạn dùng GitHub/GitLab, xin quyền xem một PR đã merge của một feature bạn từng viết spec. Nếu không có, dùng một PR công khai trên một dự án open-source bất kỳ.
- Viết thước đo trước. Liệt kê 3 acceptance criteria mà PR đó (theo bạn) phải thỏa mãn — viết ra trước khi đọc diff.
- Phiên dịch bằng AI. Dán mô tả + diff vào công cụ AI và yêu cầu giải thích bằng ngôn ngữ hành vi sản phẩm, không dùng thuật ngữ kỹ thuật. Ghi lại bản tóm tắt bằng lời của chính bạn.
- Đối chiếu và săn scope creep. Với từng tiêu chí, hỏi AI PR có đáp ứng không và dựa vào đâu. Sau đó hỏi AI liệt kê các thay đổi không phục vụ mục tiêu chính. Ghi lại ít nhất một câu hỏi bạn sẽ mang đi hỏi kỹ sư.
- Tự kiểm chứng. Chọn một khẳng định của AI và tự kiểm tra lại (đọc kỹ đoạn code đó, hoặc hỏi một kỹ sư). Mục tiêu là cảm nhận được khi nào AI đáng tin và khi nào nó đang đoán.
Tóm tắt
PM không phải kỹ sư, nhưng PM hoàn toàn có thể — và nên — đọc Pull Request ở tầng sản phẩm. Việc đọc PR giúp bạn xác minh feature được build đúng spec, phát hiện scope creep và dead code, và theo dõi tiến độ thật thay vì tin vào báo cáo mơ hồ. AI đóng vai trò lớp phiên dịch, biến những đoạn diff khô khan thành mô tả hành vi mà bạn đủ sức đối chiếu với PRD. Quy trình gọn: chuẩn bị thước đo (acceptance criteria) trước, dùng AI tóm tắt và đối chiếu, săn những thay đổi ngoài phạm vi, rồi chốt bằng đối thoại tôn trọng với kỹ sư. Hãy nhớ ba nguyên tắc an toàn: coi câu trả lời AI là giả thuyết cần xác nhận, giữ mình ở tầng hành vi sản phẩm chứ không lấn sân kỹ thuật, và tuyệt đối cẩn trọng với dữ liệu nhạy cảm. Làm được vậy, bạn biến một kỹ năng từng "chỉ dành cho kỹ sư" thành một lợi thế thật sự của một PM trong thời đại AI.