Quy trình Thực tế: Quản lý Vòng đời Yêu cầu

Các bài trước đã đi qua từng client riêng lẻ (Claude Code, OpenCode, Gemini CLI, Cursor) kết nối với Airtable MCP. Bài này ghép mọi thứ lại thành một workflow đầu-cuối hoàn chỉnh: từ lúc một requirement được ghi nhận (intake) — dù từ note họp, email khách hàng, hay ticket support — cho tới khi feature được deliver và status tự động phản ánh đúng thực tế trong code/issue tracker. Đây là dạng workflow bạn có thể áp dụng thật cho một team product/engineering vừa và nhỏ, không cần đầu tư hệ thống requirement management riêng đắt đỏ.

Tổng Quan Workflow: Từ Intake Đến Feature Đã Delivered Trong Airtable

Trước khi đi vào từng bước kỹ thuật, cần hình dung rõ toàn cảnh vòng đời một requirement đi qua bao nhiêu trạng thái và ai/cái gì chịu trách nhiệm chuyển trạng thái đó.

Sơ đồ trạng thái (Status field trong table Requirements):

New → Triaged → In Review → In Progress → In Review (code) → Done → Archived
                    ↓                              ↓
                 Blocked ←──────────────────────────┘

Vai trò của từng bên trong vòng đời này:

• Con người (PM/BA) quyết định: requirement có hợp lý không, priority là gì, có nên archive không.
• AI agent đảm nhận: parse input thô thành record có cấu trúc (bước 1), làm giàu record với effort/dependency estimate dựa trên phân tích code (bước 2), và đồng bộ ngược status dựa trên tín hiệu thật từ Git/issue tracker (bước 3).
• Airtable đóng vai trò "nguồn sự thật" (source of truth) duy nhất mà cả người và agent đều đọc/ghi vào, thay cho việc rải rác thông tin qua nhiều tool (Slack thread, email, note cá nhân) như nhiều team vẫn làm.

Schema table Requirements dùng xuyên suốt bài này:

Toàn bộ workflow 3 bước dưới đây được thiết kế để con người luôn review ở các điểm quyết định quan trọng (chuyển Priority, chuyển Status sang Done), còn agent xử lý phần "lao động nặng" là parse, tổng hợp, và match dữ liệu — đúng tinh thần agent hỗ trợ con người ra quyết định nhanh hơn, không phải agent tự quyết định thay con người.

Mẹo: Vẽ sơ đồ trạng thái này ra và dán ngay trong description của table Requirements trên Airtable (Airtable cho phép ghi mô tả table) — mọi thành viên mới vào team, kể cả khi họ chưa đọc tài liệu này, cũng hiểu ngay quy ước Status đang dùng.

Bước 1: Thu Thập Và Chuẩn Hóa Requirement Đầu Vào Thành Record

Input thực tế của một requirement thường rất "bẩn" — note họp viết vội, email dài dòng, ticket support lẫn nhiều thông tin không liên quan. Bước này để agent làm việc parse và chuẩn hóa.

Ví dụ input thô (note họp với khách hàng):

Note họp với khách hàng Acme Corp, 2026-08-20:
- Họ than phiền checkout bị timeout khi có > 20 item trong cart
- Muốn có export invoice ra PDF, hiện chỉ export CSV
- Hỏi có SSO qua Okta không (họ dùng Okta nội bộ)
- Một câu hỏi không liên quan về billing cycle, không phải requirement

Prompt chuẩn hóa và tạo record:

Đọc note họp dưới đây. Tách ra các requirement THẬT (bỏ qua câu hỏi
không phải yêu cầu tính năng). Với mỗi requirement, tạo record trong
table "Requirements" của base "Product Roadmap":
- Title: ngắn gọn, dạng hành động (ví dụ "Fix checkout timeout with
  large cart")
- Description: diễn giải đầy đủ từ note gốc
- Source: "Customer call"
- Status: "New"
- Priority: để trống, chờ PM đánh giá

Trước khi tạo, liệt kê danh sách requirement đã tách ra để tôi xác
nhận, chưa tạo record ngay.

Note: [paste nội dung note họp]

Agent sẽ trả về danh sách để xác nhận trước, ví dụ:

Tôi tách được 3 requirement từ note:
1. Fix checkout timeout with large cart (Source: Customer call)
2. Add PDF export for invoices (Source: Customer call)
3. Support SSO via Okta (Source: Customer call)

Câu hỏi về billing cycle không được tính là requirement, đã bỏ qua.
Xác nhận để tôi tạo 3 record này?

Sau khi bạn xác nhận, agent mới thực hiện create_records. Bước "liệt kê trước, tạo sau" này chính là pattern an toàn đã nhắc ở các bài trước, áp dụng ngay từ bước đầu vòng đời — sai từ bước intake sẽ kéo theo sai suốt các bước tiếp theo.

Chuẩn hóa để tránh trùng lặp — trước khi tạo record mới, luôn kiểm tra requirement tương tự đã tồn tại chưa:

Trước khi tạo 3 record trên, tìm trong table "Requirements" các record
có Title tương tự (ví dụ chứa từ khóa "checkout timeout",
"PDF export", "SSO", "Okta"). Nếu tìm thấy record đã tồn tại và
chưa Done, báo cho tôi biết để cân nhắc gộp thay vì tạo trùng.

Mẹo: Luôn yêu cầu bước kiểm tra trùng lặp trước khi tạo record mới từ nguồn input không có cấu trúc — requirement trùng lặp rải rác từ nhiều nguồn (customer call, support ticket, sales feedback) cho cùng một vấn đề là tình trạng rất phổ biến, và dọn dẹp sau khi đã tạo trùng tốn công hơn nhiều so với việc chặn ngay từ đầu.

Bước 2: Làm Giàu Record Với Effort, Dependency Và Priority Nhờ AI

Sau khi record đã tồn tại ở Status "New" hoặc "Triaged", bước tiếp theo là làm giàu (enrichment) — agent phân tích codebase thật để đưa ra ước lượng effort, phát hiện dependency giữa các requirement, và gợi ý priority dựa trên dữ liệu, còn quyết định cuối cùng vẫn là của PM.

Ước lượng effort dựa trên phân tích code thật, không chỉ đoán theo mô tả:

Với record "Fix checkout timeout with large cart" trong table
"Requirements", đọc code hiện tại trong module src/checkout/.
Ước lượng effort (story points, thang 1-2-3-5-8-13) dựa trên:
- Số file/module liên quan cần sửa
- Có cần thay đổi schema database không
- Có cần viết test mới không
Cập nhật field Effort, và ghi lý do ước lượng vào một field mới
"Effort Notes" (tạo field text nếu chưa có, hỏi tôi trước khi tạo field).

Lưu ý quan trọng: tạo field mới đòi hỏi scope schema.bases:write — như đã nhấn mạnh ở bài tổng quan, đây là hành động rủi ro cao nên luôn để agent hỏi xác nhận trước khi tự tạo field mới, không auto-run.

Phát hiện dependency giữa các requirement:

Đọc toàn bộ record đang Status = "New" hoặc "Triaged" trong table
"Requirements". Với record "Support SSO via Okta", kiểm tra xem có
requirement nào khác mà nó phụ thuộc vào không (ví dụ cần refactor
module auth trước). Nếu có, cập nhật field Dependencies (linked
record) để trỏ tới đúng record đó.

Gợi ý priority dựa trên dữ liệu khách hàng, không chỉ cảm tính:

Với 3 record mới tạo từ note họp Acme Corp, tính điểm priority gợi ý
dựa trên: số lần requirement tương tự xuất hiện từ các Source khác
nhau trong 90 ngày qua (đọc toàn bộ record cũ có Description tương
tự), độ nghiêm trọng nếu là bug (timeout > feature mới), và có khách
hàng Enterprise yêu cầu không (giả định Acme Corp là Enterprise).
Đề xuất Priority cho mỗi record kèm lý do, KHÔNG tự cập nhật field
Priority — chỉ đề xuất, tôi sẽ quyết định.

Đây là ranh giới rất quan trọng cần giữ vững trong toàn bộ workflow: agent được giao quyền đề xuất dựa trên dữ liệu, nhưng quyết định Priority cuối cùng — vốn phản ánh chiến lược kinh doanh, quan hệ khách hàng, không chỉ dữ liệu định lượng — nên do con người quyết, không giao hẳn cho agent tự set.

Mẹo: Tách rõ trong prompt giữa "đề xuất" và "quyết định cuối" cho mọi field mang tính chiến lược (Priority, có nên archive requirement không) — agent làm tốt phần tổng hợp dữ liệu để hỗ trợ quyết định, nhưng đừng giao luôn quyền quyết định cho agent chỉ vì nó có thể làm được về mặt kỹ thuật.

Bước 3: Đồng Bộ Ngược Delivery Status Từ Code Và Issue Tracker

Đây là bước khép vòng đời: khi requirement đã thành code thật và merge/deploy, status trong Airtable phải tự động phản ánh đúng thực tế, không phải chờ ai đó nhớ vào Airtable sửa tay.

Đồng bộ khi PR merge (chạy thủ công sau khi merge, hoặc gọi từ một script/hook CI với agent chạy ở chế độ headless nếu client hỗ trợ):

PR #491 "Fix checkout timeout with large cart" vừa merge vào main.
Tìm record trong table "Requirements" có Title khớp hoặc Linked PR
chứa "491". Cập nhật:
- Status = "In Review" nếu đang ở "In Progress" (chưa Done ngay,
  vì còn chờ deploy)
- Linked PR = "491"
- Effort Notes: ghi thêm "Merged 2026-08-22, actual changes: <tóm tắt
  diff>" để so sánh với effort ước lượng ban đầu

Việc ghi lại "actual changes" so với ước lượng ban đầu ở bước 2 là chi tiết dễ bị bỏ qua nhưng rất giá trị: qua vài tháng, bạn có dữ liệu thật để đánh giá agent (hoặc team) đang ước lượng effort chính xác đến đâu, và điều chỉnh cách ước lượng cho các requirement tương lai.

Đồng bộ khi deploy lên production (bước cuối, chuyển Done thật):

Danh sách PR đã deploy lên production hôm nay: #491, #488, #495.
Với mỗi PR, tìm record tương ứng trong table "Requirements" qua
Linked PR, cập nhật Status = "Done", Merged Date = 2026-08-22.
Sau đó tổng hợp: bao nhiêu requirement đã Done trong tuần này,
so với tuần trước.

Đồng bộ ngược từ issue tracker (nếu team dùng Jira/Linear song song, Requirement trong Airtable là tầng cao hơn issue kỹ thuật):

Đọc field Linked Issue của các record đang Status = "In Progress".
Với mỗi Linked Issue ID, kiểm tra trạng thái thật trên Linear qua
Linear MCP (nếu đã kết nối). Nếu issue trên Linear đã "Done" nhưng
record Airtable vẫn "In Progress", báo cho tôi danh sách các record
lệch trạng thái này — KHÔNG tự cập nhật, chỉ báo cáo lệch để tôi
kiểm tra lý do (có thể do quên cập nhật, hoặc do PR merge nhưng
chưa deploy thật).

Ví dụ cuối này cho thấy giá trị thật của việc kết hợp nhiều MCP server trong cùng một agent (Airtable + Linear/Jira + Git) — agent trở thành "người đối chiếu" phát hiện lệch trạng thái giữa các hệ thống mà bình thường phải có người ngồi so sánh tay giữa nhiều tab, một việc rất dễ bị bỏ quên trong lịch làm việc bận rộn.

Mẹo: Ưu tiên thiết kế bước đồng bộ cuối (issue tracker → Airtable) ở dạng "phát hiện và báo cáo lệch trạng thái" hơn là "tự động ghi đè" — vì lệch trạng thái giữa hai hệ thống thường là dấu hiệu của một vấn đề thật (quên cập nhật, deploy dở dang) mà con người nên biết và xử lý gốc, không nên để agent "che" đi bằng cách tự đồng bộ âm thầm.

Mẹo Thực Chiến

• Duy trì đúng một Airtable base làm "nguồn sự thật" duy nhất cho vòng đời requirement, mọi tool khác (Git, issue tracker) chỉ là nguồn tín hiệu để đồng bộ vào, không tạo thêm một nguồn sự thật thứ hai gây lệch dữ liệu.
• Ở bước intake, luôn kiểm tra trùng lặp trước khi tạo record mới — chi phí kiểm tra rẻ hơn nhiều so với dọn dẹp dữ liệu trùng về sau.
• Ở bước enrichment, tách rõ ràng "agent đề xuất" và "người quyết định cuối" cho mọi field mang tính chiến lược như Priority.
• Ở bước đồng bộ ngược, ưu tiên convention rõ ràng (Linked PR, Linked Issue) để match record chính xác bằng ID, không match mờ theo tên.
• Khi phát hiện lệch trạng thái giữa các hệ thống, để agent báo cáo thay vì tự động ghi đè — lệch trạng thái thường là tín hiệu của vấn đề thật cần con người xử lý.

Mẹo: Sau khi workflow 3 bước này chạy ổn định vài sprint, dùng chính dữ liệu đã tích lũy trong Airtable (Effort Notes ghi actual vs. estimate, risk score theo tuần từ các báo cáo trước) để agent tự đề xuất cải thiện quy trình ước lượng — đây là lúc bạn thu được giá trị compound thật của việc để AI tham gia toàn bộ vòng đời requirement, không chỉ ở một bước rời rạc.