Bài 50 — Tracking Discovery Work (Spike, Research)

Mở đầu — vì sao bài này quan trọng

Có một loại công việc mà gần như mọi PM đều làm hằng ngày nhưng lại rất ít khi được ghi nhận đúng cách trong Jira: công việc khám phá (discovery work). Đó là những giờ ngồi phỏng vấn khách hàng, những buổi đội ngũ đau đầu chọn giữa hai thư viện kỹ thuật, những bản prototype vẽ tới vẽ lui trên Figma, những "spike" mà kỹ sư dành ra để thử nghiệm một hướng đi trước khi cam kết xây thật.

Vấn đề nằm ở chỗ: nếu bạn không theo dõi discovery work một cách tường minh, nó sẽ trở thành phần "vô hình" trong dữ liệu của đội. Sprint velocity của bạn tụt xuống mà không rõ lý do. Kỹ sư "bận cả tuần" nhưng board không có gì di chuyển. Sếp hỏi "tuần này team làm gì?" và bạn lúng túng vì phần lớn giá trị tạo ra lại không nằm trên bất kỳ tấm thẻ nào.

Ở nhiều đội Việt Nam mà tôi từng làm việc cùng, discovery thường bị "giấu" dưới dạng một dòng note trong Slack, hoặc tệ hơn — bị nhồi thẳng vào một Story delivery khiến story đó phình to gấp ba, không bao giờ đóng đúng hạn. Bài này sẽ dạy bạn cách phân biệt rạch ròi discovery với delivery, và cách dùng Jira để làm cho phần công việc "vô hình" đó trở nên hữu hình, đo được, và bảo vệ được trước áp lực deadline.

Khái niệm cốt lõi

Discovery vs Delivery — hai nửa của cùng một sản phẩm

Hãy nhớ một câu ngắn gọn: Discovery là "tìm ra thứ đáng để xây", Delivery là "xây thứ đó cho đúng và ship ra".

Discovery work trả lời câu hỏi "Chúng ta có nên làm cái này không, và làm thế nào?". Nó bao gồm nghiên cứu người dùng (user research), phân tích dữ liệu, phỏng vấn, dựng prototype, kiểm chứng giả định (assumption), và các "spike" kỹ thuật để đánh giá tính khả thi.
Delivery work trả lời câu hỏi "Làm thế nào để xây và giao thứ đã quyết định?". Đây là những Story, Task quen thuộc: viết code, test, deploy.

Điểm mấu chốt mà Marty Cagan (tác giả Inspired) nhấn mạnh là hai luồng này chạy song song và liên tục (continuous), không phải nối tiếp. Trong khi đội đang deliver các tính năng của sprint hiện tại, PM và designer đã phải discover cho những gì sắp tới. Nếu discovery dừng lại, backlog delivery của bạn sẽ cạn kiệt ý tưởng đã được kiểm chứng và đội buộc phải xây dựa trên phỏng đoán.

Spike là gì?

Spike là một thuật ngữ đến từ Extreme Programming (XP), chỉ một khối công việc có thời lượng cố định (time-boxed) nhằm trả lời một câu hỏi hoặc giảm một rủi ro cụ thể — chứ không nhằm tạo ra sản phẩm ship được.

Có hai loại spike phổ biến:

Technical spike: thử nghiệm kỹ thuật. Ví dụ: "Dành 2 ngày để đánh giá xem thư viện thanh toán VNPay hay MoMo SDK dễ tích hợp hơn cho luồng checkout."
Functional spike: khám phá về hành vi hoặc nhu cầu người dùng. Ví dụ: "Phỏng vấn 5 người bán hàng để hiểu vì sao họ bỏ ngang bước tạo đơn."

Đặc điểm bắt buộc của spike:

Time-boxed — luôn có giới hạn thời gian (thường 1–3 ngày). Hết thời gian là dừng, bất kể đã "xong" hay chưa.
Có câu hỏi rõ ràng — spike phải nhắm tới một quyết định cần đưa ra.
Đầu ra là kiến thức (learning), không phải code production. Kết quả thường là một tài liệu, một khuyến nghị, hoặc một quyết định "đi tiếp / dừng lại".

Vì sao phải tách discovery ra khỏi delivery trong Jira?

Nếu bạn trộn discovery vào Story delivery, ba vấn đề xảy ra:

Velocity bị nhiễu: Story delivery bị kéo dài vì "chờ nghiên cứu xong", làm sai lệch số liệu tốc độ đội.
Không thấy được rủi ro: bạn không nhìn ra được đội đang phải khám phá nhiều đến mức nào, tức là mức độ chưa chắc chắn của sản phẩm.
Khó bảo vệ thời gian nghiên cứu: khi discovery không có thẻ riêng, nó là thứ đầu tiên bị cắt khi deadline siết lại.

Mô hình hoá discovery trong Jira

Có vài cách tổ chức tùy quy mô đội:

Issue Type riêng "Spike" (hoặc dùng Task/Research với label). Đây là cách nhẹ nhàng, phổ biến nhất.
Label discovery / spike / research để lọc và báo cáo bằng JQL.
Component "Discovery" nếu đội muốn phân tách rõ ràng theo mảng công việc.
Với đội trưởng thành hơn, tạo một Discovery Board / Kanban riêng chạy song song với board delivery, hoặc dùng một dự án Jira riêng cho luồng khám phá.

Tình huống thực tế

Ví dụ 1 — Tiki: spike đánh giá cổng thanh toán trước khi cam kết

Một đội sản phẩm giả định ở Tiki cần thêm phương thức "trả góp qua ví điện tử". Trước khi hứa với stakeholder về ngày ra mắt, PM tạo một Spike trong Jira:

Tiêu đề: [Spike] Đánh giá khả năng tích hợp trả góp: MoMo vs ZaloPay
Time-box: 3 ngày (ước lượng 3 story points, nhưng team quy ước spike không tính vào velocity delivery).
Câu hỏi cần trả lời: SDK nào có sandbox ổn định? Chi phí giao dịch? Thời gian tích hợp ước tính?
Definition of Done của spike: một trang Confluence tóm tắt so sánh + khuyến nghị chọn 1 nhà cung cấp.

Sau 3 ngày, kỹ sư phát hiện MoMo có tài liệu sandbox tốt hơn nhưng phí cao hơn 0,4%, còn ZaloPay rẻ hơn nhưng webhook thiếu ổn định. Đội quyết định chọn MoMo và tạo các Story delivery sau khi đã có kết luận.

Bài học: Spike đã ngăn đội cam kết mù quáng một hướng đi và phải làm lại. 3 ngày discovery tiết kiệm được có thể là 2 tuần delivery sai hướng.

Ví dụ 2 — Startup fintech ở TP.HCM: discovery bị "nuốt" vào delivery

Một startup fintech 25 người tôi từng tư vấn có thói quen nhồi nghiên cứu vào Story. Ví dụ Story "Xây màn hình onboarding KYC" được estimate 5 điểm, nhưng thực tế bên trong ẩn cả việc phỏng vấn người dùng để hiểu vì sao tỷ lệ bỏ dở KYC lên tới 60%.

Kết quả: Story này kéo dài qua 2 sprint. Velocity đội tụt từ 32 xuống 19 điểm trong sprint đó. Trong buổi retrospective, CEO chất vấn "team chậm lại à?". Thực tế đội không chậm — họ đã dành 4 ngày làm discovery quý giá, nhưng dữ liệu Jira không phản ánh điều đó.

Sau khi tách riêng, họ tạo issue type Research với label discovery, để việc phỏng vấn KYC thành một thẻ riêng. Sprint kế tiếp, velocity delivery trở lại 30 điểm và ai cũng nhìn thấy rõ 4 ngày discovery trên board.

Bài học: Discovery phải hữu hình. Khi nó ẩn bên trong delivery, nó vừa làm nhiễu số liệu vừa khiến giá trị của nghiên cứu bị vô hình hoá trước mắt lãnh đạo.

Ví dụ 3 — Grab: dual-track với discovery board song song

Ở quy mô lớn hơn, một đội tại Grab (giả định bối cảnh) áp dụng Dual-Track Agile. Họ duy trì hai luồng:

Discovery track: một Kanban board với các cột Cần nghiên cứu → Đang phỏng vấn/Prototyping → Đang tổng hợp → Sẵn sàng cho Delivery. Mỗi thẻ là một cơ hội (opportunity) cần kiểm chứng.
Delivery track: Scrum board bình thường, chỉ nhận vào những item đã "tốt nghiệp" từ discovery track (đã có bằng chứng người dùng thật cần).

Quy tắc của họ: một Story chỉ được kéo vào backlog delivery khi thẻ discovery tương ứng đã đạt trạng thái Sẵn sàng cho Delivery, kèm link tới tài liệu bằng chứng. Điều này tạo ra một "cửa chất lượng" — không tính năng nào được xây nếu chưa qua khám phá.

Bài học: Ở quy mô lớn, discovery và delivery cần board riêng để không giẫm chân nhau, nhưng phải có liên kết (issue link) rõ ràng giữa thẻ discovery và các Story delivery sinh ra từ nó, để truy vết được "vì sao chúng ta xây cái này".

Hướng dẫn từng bước

Đây là cách thiết lập theo dõi discovery work trong Jira cho một đội cỡ vừa.

Bước 1 — Thống nhất định nghĩa với đội. Trong một buổi họp ngắn, chốt: cái gì tính là discovery (research, spike, prototype, phỏng vấn) và cái gì là delivery. Viết ra để tránh tranh cãi sau này.

Bước 2 — Chọn cách mô hình hoá. Đội nhỏ: dùng Issue Type Task + label spike. Đội vừa trở lên: tạo Issue Type riêng tên Spike hoặc Research (nhờ Jira admin thêm vào issue type scheme — xem lại Bài 6). Nhất quán là quan trọng nhất.

Bước 3 — Viết spike đúng chuẩn. Mỗi thẻ discovery phải có:

Câu hỏi cần trả lời ghi rõ trong phần mô tả.
Time-box cụ thể ghi trong tiêu đề hoặc một custom field (ví dụ: "3 ngày").
Definition of Done dạng đầu ra kiến thức: "Sản phẩm cuối là tài liệu X + khuyến nghị Y".

Bước 4 — Quyết định cách tính điểm. Có hai trường phái, chọn một và giữ nhất quán:

Spike không tính vào velocity delivery (khuyến nghị): để velocity phản ánh đúng năng lực ship. Nhưng vẫn ước lượng thời gian để lập kế hoạch capacity.
Hoặc gán điểm cho spike nhưng báo cáo tách riêng bằng label.

Bước 5 — Đặt spike vào sprint có kiểm soát. Giới hạn tổng dung lượng discovery mỗi sprint (ví dụ: tối đa 20% capacity của đội) để discovery không "ăn" hết thời gian delivery, và ngược lại delivery không bóp chết discovery.

Bước 6 — Liên kết discovery với delivery. Khi một spike đẻ ra các Story, dùng issue link kiểu "is discovered by" hoặc "relates to" để nối thẻ spike với các Story kết quả. Điều này giữ lại "dấu vết quyết định".

Bước 7 — Lưu kết quả ở nơi tìm lại được. Đính kèm hoặc link tài liệu Confluence (xem Bài 22) vào thẻ spike. Kiến thức discovery mất giá trị rất nhanh nếu không ai tìm lại được.

Bước 8 — Theo dõi bằng JQL. Tạo bộ lọc và gadget dashboard để nhìn discovery riêng, ví dụ:

project = "MOBILE" AND labels = "spike" AND sprint in openSprints()

hoặc để xem tất cả discovery còn dang dở:

labels in ("spike", "discovery", "research") AND statusCategory != Done
ORDER BY created DESC

Lỗi thường gặp & mẹo

Lỗi 1 — Spike không có time-box. Đây là lỗi phổ biến nhất. Một spike không giới hạn thời gian sẽ trở thành "nghiên cứu vô tận". Mẹo: luôn ghi rõ số ngày trong tiêu đề và tôn trọng nó tuyệt đối. Hết giờ thì dừng và trình bày những gì đã học được, kể cả kết luận là "chưa đủ dữ liệu".

Lỗi 2 — Nhồi discovery vào Story delivery. Như ví dụ startup fintech ở trên. Mẹo: nếu bạn thấy một Story đang "chờ nghiên cứu", hãy tách phần nghiên cứu ra thành một spike độc lập.

Lỗi 3 — Đo velocity gộp cả spike. Điều này làm velocity dao động thất thường và mất khả năng dự báo. Mẹo: quy ước rõ spike có tính điểm hay không, và giữ nguyên tắc đó qua các sprint.

Lỗi 4 — Spike không có đầu ra rõ ràng. Kỹ sư "nghiên cứu xong" nhưng không ai biết kết luận là gì. Mẹo: bắt buộc mọi spike phải có Definition of Done dạng tài liệu/khuyến nghị, và review nó trong sprint review hoặc một buổi chia sẻ ngắn.

Lỗi 5 — Discovery bị cắt đầu tiên khi deadline gấp. Khi discovery không hiển thị trên board, nó dễ bị hy sinh. Mẹo: dành một hạn mức cố định (ví dụ 15–20% capacity) cho discovery mỗi sprint và bảo vệ nó như bảo vệ một cam kết delivery.

Mẹo nâng cao — dùng resolution riêng. Với Jira, bạn có thể cấu hình các resolution như "Kết luận: Đi tiếp", "Kết luận: Dừng lại", "Kết luận: Cần thêm dữ liệu" cho spike, giúp báo cáo discovery outcome trực quan.

Bài tập thực hành

Nhận diện discovery ẩn. Lấy sprint gần nhất của đội bạn (hoặc một sprint mẫu). Rà soát từng Story và đánh dấu những phần thực chất là discovery đang bị "giấu" bên trong. Ước tính bao nhiêu % thời gian sprint thực ra là discovery.

Viết một spike hoàn chỉnh. Chọn một câu hỏi thực tế đội bạn đang phải trả lời (ví dụ: "Nên dùng thư viện biểu đồ nào?"). Viết một thẻ spike đầy đủ gồm: câu hỏi cần trả lời, time-box, và Definition of Done dạng đầu ra kiến thức.

Thiết lập trong Jira. Tạo (hoặc phác thảo) một label spike, thêm 2–3 thẻ discovery, rồi viết một truy vấn JQL lọc riêng chúng ra khỏi công việc delivery. Tạo một saved filter đặt tên "Discovery — Sprint hiện tại".

Thiết kế cửa chất lượng. Viết ra quy tắc của riêng đội bạn: một item cần thoả điều kiện gì (bằng chứng nào) để được phép chuyển từ discovery sang backlog delivery? Diễn đạt bằng 2–3 câu.

Tóm tắt

Discovery work — nghiên cứu, phỏng vấn, prototype, spike — là nửa quyết định "xây cái gì cho đúng", chạy song song và liên tục với delivery. Nếu không theo dõi tường minh trong Jira, nó trở thành phần vô hình làm nhiễu velocity, che giấu rủi ro và dễ bị cắt bỏ khi áp lực deadline tăng.

Cốt lõi cần nhớ:

Tách discovery khỏi delivery bằng Issue Type Spike/Research hoặc label riêng.
Spike luôn time-boxed, có câu hỏi rõ ràng, và đầu ra là kiến thức chứ không phải code production.
Quyết định nhất quán việc spike có tính vào velocity hay không, và giới hạn dung lượng discovery mỗi sprint.
Liên kết thẻ discovery với Story delivery sinh ra từ nó, và lưu kết quả ở nơi tìm lại được (Confluence).
Theo dõi bằng JQL và dashboard để discovery luôn hữu hình trước cả đội và lãnh đạo.

Khi discovery trở nên hữu hình, bạn không chỉ có số liệu sạch hơn — bạn còn bảo vệ được thời gian nghiên cứu, thứ đảm bảo đội của bạn xây đúng thứ khách hàng thật sự cần.