Mở đầu — vì sao bài này quan trọng
Hãy hình dung tình huống này: bạn là PM của một fintech tại TP.HCM, vừa hoàn thành một bản PRD rất đẹp cho tính năng "chuyển tiền theo lịch định kỳ". Tài liệu mô tả rõ người dùng cần gì, vì sao tính năng quan trọng, KPI ra sao. Bạn đẩy sang cho team kỹ thuật, yên tâm chờ đợi. Hai tuần sau, lúc demo, bạn phát hiện engineer đã hiểu sai một chi tiết then chốt: hệ thống chỉ retry chuyển tiền một lần khi thất bại, trong khi nghiệp vụ thật cần retry ba lần với khoảng cách tăng dần. Lý do? Phần "HOW" — cách hệ thống thực sự xử lý — chưa bao giờ được viết ra và review một cách nghiêm túc.
Đó chính là khoảng trống mà Technical Spec Document (TSD) lấp đầy. Nếu PRD trả lời câu hỏi "chúng ta xây cái gì và tại sao", thì TSD trả lời "chúng ta sẽ xây nó như thế nào". Là một Technical PM, bạn thường không phải người viết TSD — engineer hoặc tech lead viết — nhưng bạn là người review TSD một cách có chiều sâu. Khả năng đọc, đặt câu hỏi và phản biện một TSD là ranh giới phân biệt một PM "biết kỹ thuật" với một PM chỉ chuyển tiếp yêu cầu. Bài học này sẽ giúp bạn hiểu TSD là gì, đọc nó ra sao, và đóng góp vào nó như thế nào để dự án bớt rủi ro ngay từ giai đoạn thiết kế — khi việc sửa sai còn rẻ.
Khái niệm cốt lõi
TSD khác PRD ở đâu
Đây là sự phân biệt quan trọng nhất bạn cần nắm vững. Nhiều PM trẻ nhầm lẫn hai tài liệu này, dẫn đến việc viết PRD lan sang phần kỹ thuật, hoặc ngược lại không hiểu được giá trị của TSD.
| Tiêu chí | PRD (Product Requirements Document) | TSD (Technical Spec Document) |
|---|---|---|
| Trả lời câu hỏi | WHAT — xây cái gì; WHY — vì sao; FOR WHOM — cho ai | HOW — xây như thế nào |
| Người viết chính | PM | Engineer / Tech Lead |
| Người review | Engineer, Design, Business | PM, các Engineer khác, Security, SRE |
| Ngôn ngữ | Nghiệp vụ, user-centric | Kỹ thuật: API, schema, data flow, sequence diagram |
| Mục tiêu | Thống nhất về vấn đề và giá trị | Thống nhất về giải pháp triển khai |
Vì sao TSD tồn tại
TSD không phải thủ tục hành chính để "có tài liệu". Nó phục vụ ba mục đích thực tế:
Thứ nhất — buộc suy nghĩ trước khi gõ phím. Việc viết ra cách hệ thống hoạt động ép engineer phải đối mặt với các tình huống biên (edge case) ngay từ đầu: Điều gì xảy ra khi mạng rớt giữa chừng? Khi hai người dùng cùng thao tác một lúc? Khi dữ liệu cũ không khớp định dạng mới? Sửa một đoạn văn trong TSD tốn 5 phút; sửa kiến trúc đã code xong tốn 5 tuần.
Thứ hai — đồng bộ hiểu biết trong team. Khi một tính năng cần ba engineer phối hợp, TSD là điểm tham chiếu chung để mọi người hiểu phần ghép nối (interface) giữa các module của họ.
Thứ ba — lưu lại lý do của quyết định. Sáu tháng sau, khi ai đó hỏi "vì sao mình chọn Redis chứ không phải Postgres cho cái này?", TSD chính là câu trả lời được lưu lại — tránh việc tranh luận lại từ đầu.
Cấu trúc một TSD điển hình
Mỗi công ty có template riêng, nhưng một TSD chất lượng thường có các phần sau. Là PM review, bạn nên kiểm tra xem TSD có đủ những phần này không:
- Context & Goals — Tóm tắt bài toán (thường trích từ PRD) và mục tiêu kỹ thuật cần đạt. Cũng nêu rõ Non-goals — những gì cố tình KHÔNG làm trong phạm vi này.
- Current State — Hệ thống hiện tại đang hoạt động ra sao. Giúp người đọc hiểu điểm xuất phát.
- Proposed Solution — Trái tim của tài liệu. Mô tả kiến trúc, luồng dữ liệu, các thành phần. Thường kèm sơ đồ (architecture diagram, sequence diagram).
- API & Data Model — Các endpoint mới/thay đổi, schema cơ sở dữ liệu, định dạng dữ liệu.
- Alternatives Considered — Các phương án khác đã cân nhắc và lý do không chọn. Phần này cực kỳ giá trị cho PM, vì nó phơi bày trade-off.
- Risks & Edge Cases — Rủi ro, tình huống biên, kế hoạch xử lý lỗi.
- Rollout Plan — Triển khai theo giai đoạn ra sao, có dùng feature flag không, kế hoạch rollback nếu hỏng.
- Open Questions — Những điểm chưa chốt, cần thảo luận thêm.
Vai trò của PM khi review TSD
Bạn không review code, cũng không phán xét lựa chọn công nghệ thuần túy. Bạn review TSD ở ba góc độ mà engineer dễ bỏ sót:
- Khớp với nghiệp vụ — Giải pháp kỹ thuật có thực sự giải quyết đúng vấn đề trong PRD không? Có hiểu sai yêu cầu nào không?
- Edge case nghiệp vụ — Những tình huống biên về mặt người dùng/nghiệp vụ đã được tính đến chưa? (Ví dụ: người dùng huỷ giao dịch đúng lúc hệ thống đang retry.)
- Trade-off và rollout — Phương án này hy sinh điều gì (tốc độ, chi phí, độ phức tạp)? Kế hoạch triển khai có an toàn với người dùng thật không?
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT và tính năng "đặt trước hàng" (pre-order)
Một sàn thương mại điện tử giả định tên ChợViệt muốn ra mắt tính năng pre-order cho các đợt mở bán điện thoại số lượng giới hạn. PM viết PRD: cho phép tối đa 5.000 đơn pre-order, mỗi người chỉ được 1 máy, hiển thị số lượng còn lại theo thời gian thực.
Tech lead viết TSD và đề xuất: dùng một cột available_count trong bảng MySQL, mỗi đơn hàng giảm cột này đi 1. Khi PM đọc phần Edge Cases, cô ấy không thấy đề cập đến tình huống flash sale có hàng nghìn người bấm "Đặt" cùng một giây. Cô đặt câu hỏi trong phần comment: "Nếu 3.000 người cùng bấm trong 2 giây, làm sao đảm bảo không bán quá 5.000 (overselling)?"
Câu hỏi này buộc team nhìn lại. Hoá ra cách cập nhật đơn giản đó có thể gây race condition. Tech lead bổ sung giải pháp dùng atomic decrement với điều kiện (UPDATE ... WHERE available_count > 0) và một hàng đợi để xử lý tuần tự. Bài học: PM không cần biết viết câu SQL đó, nhưng việc đặt câu hỏi nghiệp vụ "điều gì xảy ra khi nhiều người cùng thao tác?" đã cứu công ty khỏi một sự cố bán vượt hàng — vốn rất tai tiếng với khách hàng Việt Nam vào ngày sale lớn.
Ví dụ 2 — Grab và phần "Alternatives Considered"
Giả định một team tại Grab cần xây tính năng thông báo cho tài xế khi có cuốc xe gần đó. Engineer viết TSD với phương án chính là dùng WebSocket giữ kết nối liên tục với app tài xế. Trong phần Alternatives Considered, họ ghi rõ đã cân nhắc hai phương án khác: (a) polling mỗi 3 giây, và (b) push notification qua Firebase.
PM review và đọc kỹ phần này. Anh nhận ra trade-off quan trọng: WebSocket cho độ trễ thấp nhất (quan trọng vì cuốc xe phải đến tay tài xế trước đối thủ), nhưng tốn pin và dữ liệu của tài xế — một vấn đề thật ở thị trường có nhiều tài xế dùng máy Android tầm thấp và gói data hạn chế. PM đề xuất một thoả hiệp được ghi vào TSD: dùng WebSocket khi app đang mở foreground, fallback sang push notification khi app ở background.
Bài học: Phần "Alternatives Considered" chính là nơi PM tạo ra nhiều giá trị nhất. Bằng cách hiểu vì sao engineer loại bỏ các phương án, PM có thể đem góc nhìn người dùng (pin, data, chi phí) vào quyết định mà engineer thuần kỹ thuật dễ bỏ qua.
Ví dụ 3 — Fintech và rollout plan thiếu kế hoạch rollback
Một ví bán điện tử ở Việt Nam triển khai lại module tính phí giao dịch. TSD mô tả giải pháp rất gọn gàng, nhưng phần Rollout Plan chỉ ghi đúng một dòng: "Deploy lên production sau khi test xong." PM — vốn đã được học về triển khai an toàn — dừng lại và phản biện: "Module này động đến tiền của hàng trăm nghìn người dùng. Nếu công thức tính phí mới sai, chúng ta phát hiện và quay lại trạng thái cũ bằng cách nào? Mất bao lâu?"
Câu hỏi này buộc team viết lại Rollout Plan: bật tính năng cho 1% người dùng qua feature flag trước, theo dõi số liệu chênh lệch phí trong 48 giờ, có nút tắt khẩn cấp (kill switch) để quay về công thức cũ trong vòng dưới 1 phút mà không cần deploy lại. Bài học: Với hệ thống động đến tiền hoặc dữ liệu nhạy cảm, một TSD chưa có kế hoạch rollback rõ ràng là một TSD chưa hoàn chỉnh. PM là tiếng nói nhắc team rằng "ra mắt được" và "ra mắt an toàn" là hai chuyện khác nhau.
Hướng dẫn từng bước
Đây là quy trình để bạn — với vai trò PM — đồng hành cùng một TSD từ đầu đến cuối:
Bước 1 — Đảm bảo PRD đã đủ rõ trước khi TSD bắt đầu. TSD chỉ tốt khi đầu vào tốt. Trước khi engineer viết TSD, hãy chắc chắn PRD đã trả lời rõ ràng các tình huống nghiệp vụ. Nếu PRD mơ hồ, TSD sẽ phải đoán, và đoán sai là gốc rễ của lãng phí.
Bước 2 — Cung cấp context nghiệp vụ cho người viết TSD. Ngồi cùng tech lead 30 phút giải thích các ràng buộc nghiệp vụ ẩn: quy định pháp lý, hành vi người dùng đặc thù, cam kết với đối tác. Những điều này thường không nằm trong PRD nhưng ảnh hưởng đến thiết kế.
Bước 3 — Đọc TSD theo lớp. Lần đọc đầu, đọc tổng quan để nắm ý chính (Context, Proposed Solution). Lần đọc thứ hai, soi kỹ từng phần Edge Cases, Alternatives, Rollout. Đừng cố hiểu từng dòng kỹ thuật — hãy tập trung vào logic và trade-off.
Bước 4 — Đặt câu hỏi thay vì ra lệnh. Dùng câu hỏi mở: "Điều gì xảy ra nếu...", "Mình đã cân nhắc trường hợp... chưa?", "Phương án này đánh đổi gì so với...". Câu hỏi giữ cho engineer làm chủ giải pháp, đồng thời lộ ra điểm mù.
Bước 5 — Kiểm tra ánh xạ TSD ngược về PRD. Với mỗi yêu cầu quan trọng trong PRD, hãy chỉ ra phần TSD nào giải quyết nó. Nếu có yêu cầu không tìm thấy chỗ tương ứng, đó là cờ đỏ.
Bước 6 — Chốt Open Questions trước khi ký duyệt. Một TSD còn câu hỏi mở quan trọng chưa được trả lời thì chưa nên bắt đầu code. Giúp team đưa các câu hỏi đó đến đúng người ra quyết định.
Bước 7 — Coi TSD là tài liệu sống. Khi triển khai thực tế lộ ra điều mới, hãy cập nhật TSD. Tài liệu lỗi thời còn nguy hiểm hơn không có tài liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — PM viết lẫn HOW vào PRD. Khi PM viết "dùng bảng X, gọi API Y" trong PRD, bạn vô tình tước đi không gian thiết kế của engineer và thường đề xuất giải pháp dưới tối ưu. Hãy mô tả vấn đề và ràng buộc, để engineer chọn cách giải.
Lỗi 2 — Duyệt TSD mà không thực sự đọc. "LGTM" (looks good to me) cho một tài liệu bạn chưa hiểu là cách nhanh nhất đánh mất uy tín kỹ thuật. Nếu không hiểu một phần, hãy hỏi — sự thiếu hiểu của bạn thường trùng với chỗ tài liệu viết chưa rõ.
Lỗi 3 — Bỏ qua phần Non-goals và Alternatives. Nhiều PM chỉ đọc Proposed Solution. Nhưng giá trị review lớn nhất nằm ở ranh giới (Non-goals) và đánh đổi (Alternatives).
Lỗi 4 — Quên hỏi về rollback và monitoring. "Nếu hỏng thì sao?" và "Làm sao biết nó đang hỏng?" là hai câu hỏi PM phải luôn đặt ra.
Mẹo: Giữ một checklist cá nhân khi review TSD: (1) Khớp PRD? (2) Edge case nghiệp vụ đủ chưa? (3) Trade-off rõ chưa? (4) Rollback & monitoring có chưa? (5) Open questions đã chốt chưa? Chỉ năm câu này đã đủ làm bạn nổi bật so với một PM thông thường.
Mẹo: Khen ngợi phần được viết tốt, không chỉ chỉ ra lỗi. Review TSD là cộng tác, không phải kiểm tra.
Bài tập thực hành
- Phân biệt PRD/TSD: Lấy một tính năng quen thuộc (ví dụ: "đăng nhập bằng số điện thoại + OTP"). Viết 3 gạch đầu dòng thuộc về PRD và 3 gạch đầu dòng thuộc về TSD. Tự kiểm tra: phần PRD của bạn có vô tình mô tả HOW không?
- Soạn câu hỏi review: Tưởng tượng bạn nhận TSD cho tính năng "giỏ hàng giữ trong 30 phút rồi tự xoá". Viết ra 5 câu hỏi review tập trung vào edge case nghiệp vụ và rollout (ví dụ: "Điều gì xảy ra với giỏ hàng nếu người dùng đăng nhập từ thiết bị khác?").
- Đánh giá rollout: Cho một Rollout Plan chỉ ghi "deploy sau khi QA pass", hãy viết lại thành một kế hoạch an toàn hơn với feature flag, phần trăm rollout tăng dần, chỉ số cần theo dõi, và cơ chế rollback.
Tóm tắt
TSD là tài liệu trả lời câu hỏi "xây như thế nào", bổ sung cho PRD vốn trả lời "xây cái gì và tại sao". Engineer hoặc tech lead thường là người viết TSD, còn PM là người review với chiều sâu kỹ thuật. Một TSD tốt có đủ các phần: Context & Goals, Current State, Proposed Solution, API & Data Model, Alternatives Considered, Risks & Edge Cases, Rollout Plan và Open Questions. Vai trò giá trị nhất của PM là đảm bảo giải pháp khớp với nghiệp vụ trong PRD, phơi bày các edge case người dùng, làm rõ trade-off, và buộc team có kế hoạch rollback an toàn. Hãy review bằng câu hỏi mở thay vì mệnh lệnh, đừng bao giờ duyệt một tài liệu mình chưa hiểu, và luôn nhớ: sửa sai trong một đoạn văn TSD rẻ hơn rất nhiều so với sửa sai trong code đã chạy production. Khi bạn thành thạo kỹ năng này, bạn không còn là người "chuyển tiếp yêu cầu" — bạn trở thành một đối tác kỹ thuật thực thụ của đội ngũ engineering.