Vì sao Discovery vs delivery quan trọng
Trong nhiều team sản phẩm Việt Nam, mọi năng lượng đổ vào delivery: sprint, ticket, release. Discovery bị coi là "việc phụ", làm khi rảnh, hoặc gộp chung vào một tuần "research" trước dự án lớn rồi thôi. Hậu quả là team giao hàng rất nhanh nhưng giao nhầm thứ. Bạn hoàn thành 12 story point mỗi sprint, biểu đồ burndown đẹp, nhưng chỉ số kinh doanh không nhúc nhích.
Discovery và delivery là hai loại công việc khác nhau về bản chất. Delivery trả lời câu hỏi "xây thứ này thế nào cho đúng và bền". Discovery trả lời câu hỏi "có nên xây thứ này không, và thứ gì đáng xây nhất". Nếu bạn chỉ giỏi delivery, bạn trở thành một feature factory: một nhà máy sản xuất tính năng, đo bằng sản lượng chứ không đo bằng kết quả.
Cái giá của việc thiếu kỹ năng discovery rất cụ thể. Một team fintech ở TP.HCM từng dồn ba tháng xây tính năng chia sẻ hoá đơn nhóm, vì sếp "cảm thấy" người dùng cần. Ra mắt xong, tỷ lệ dùng dưới 2%. Ba tháng lương kỹ sư, cơ hội bị lỡ, và niềm tin nội bộ bị bào mòn. Nếu team dành hai tuần discovery đúng cách trước đó, họ đã phát hiện nhu cầu thật nằm ở chỗ khác: nhắc nợ tự động.
Bức tranh lớn
Discovery và delivery không phải hai giai đoạn nối tiếp mà là hai luồng chạy song song, liên tục. Team giỏi làm cả hai trong cùng một tuần: một phần công suất dành để học (discovery), phần còn lại để xây (delivery). Kết quả discovery nuôi backlog delivery; dữ liệu từ delivery nuôi câu hỏi discovery.
graph LR A[Cau hoi kinh doanh] --> B[Discovery lien tuc] B --> C[Cơ hoi da kiem chung] C --> D[Delivery xay dung] D --> E[Do luong ket qua] E --> B
Điểm mấu chốt: discovery không kết thúc khi delivery bắt đầu. Bạn vừa xây một tính năng vừa tiếp tục phỏng vấn khách hàng để chuẩn bị cho tính năng kế tiếp. Đây là ý nghĩa của chữ "continuous" trong Continuous Discovery: một nhịp đều đặn hàng tuần, không phải một đợt bùng nổ rồi im lặng.
Ví dụ chi tiết
Một startup giao đồ ăn tại Đà Nẵng đối mặt tỷ lệ huỷ đơn cao ở giờ cao điểm. Cách cũ: PM viết ngay một spec "cho phép tài xế nhận nhiều đơn cùng lúc" và đẩy vào sprint.
Cách mới, tách discovery khỏi delivery:
Bước 1, đặt câu hỏi discovery: "Vì sao đơn bị huỷ ở giờ cao điểm?" thay vì lao vào giải pháp.
Bước 2, một tuần discovery nhẹ: PM và một designer phỏng vấn 5 khách vừa huỷ đơn và 3 tài xế. Phát hiện: khách huỷ không phải vì thiếu tài xế, mà vì thời gian dự kiến hiển thị sai lệch, chờ 40 phút trong khi app báo 20.
Bước 3, tách bạch hai loại việc. Discovery đã cho biết vấn đề thật là "kỳ vọng thời gian". Delivery giờ tập trung xây tính năng ước tính thời gian động thay vì tính năng gộp đơn ban đầu.
Bước 4, chạy song song. Trong lúc kỹ sư xây bản ước tính động, PM tiếp tục phỏng vấn để chuẩn bị cho vấn đề kế tiếp là tính minh bạch phí. Kết quả: tỷ lệ huỷ giảm 31% sau một tháng, và team không lãng phí sprint vào tính năng gộp đơn vốn không giải quyết gốc rễ.
Lộ trình từng bước để làm chủ
graph TD A[Tach hai loai cong viec tren giay] --> B[Danh mot phan cong suat cho discovery] B --> C[Dat lich phong van hang tuan] C --> D[Chay discovery va delivery song song] D --> E[Dua ket qua discovery vao backlog] E --> F[Do ket qua va lap lai]
Bắt đầu bằng việc vẽ rõ trên bảng: cột Discovery và cột Delivery. Mỗi việc phải nằm đúng một cột. Sau đó cam kết một phần công suất cố định cho discovery, dù chỉ là hai giờ mỗi tuần cho PM và designer. Đặt lịch phỏng vấn định kỳ để discovery không bao giờ bị bỏ. Cuối cùng, đảm bảo mọi thứ vào backlog delivery đều xuất phát từ một learning discovery, không phải một ý thích.
Thói quen & kỷ luật
| Nhịp | Thói quen |
|---|---|
| Hàng ngày | Ghi lại một câu hỏi discovery mới nảy ra |
| Hàng tuần | Phỏng vấn ít nhất một khách hàng |
| Mỗi sprint | Review: việc nào là discovery, việc nào là delivery |
| Hàng tháng | Kiểm tra tỷ lệ backlog xuất phát từ learning thật |
Cần luyện tập gì (drills)
Drill 1: Lấy backlog hiện tại của bạn, gắn nhãn từng mục là Discovery hay Delivery. Đếm tỷ lệ. Nếu 100% là delivery, đó là dấu hiệu báo động.
Drill 2: Với ba tính năng gần nhất team đã giao, truy ngược: learning discovery nào dẫn tới nó? Nếu không có, đó là quyết định dựa trên cảm tính.
Drill 3: Viết lại một "yêu cầu giải pháp" từ sếp thành một "câu hỏi discovery". Ví dụ đổi "làm tính năng chat" thành "khách gặp khó khăn gì khi cần hỗ trợ nhanh".
Checklist hành động tuần này
- [ ] Vẽ bảng hai cột Discovery và Delivery cho team
- [ ] Gắn nhãn mọi mục trong backlog hiện tại
- [ ] Đặt lịch cố định một buổi phỏng vấn khách trong tuần
- [ ] Viết lại một yêu cầu giải pháp thành câu hỏi discovery
- [ ] Chia sẻ với team ranh giới giữa hai loại công việc
Chỉ số & North Star
North Star ở đây là tỷ lệ quyết định sản phẩm được nuôi bởi evidence discovery thay vì ý kiến.
| Chỉ số | Tốt | Xấu |
|---|---|---|
| Số khách phỏng vấn mỗi tuần | Từ 1 trở lên đều đặn | Nhiều tuần liền bằng 0 |
| Tỷ lệ backlog có learning | Trên 70% | Dưới 30% |
| Thời gian từ ý tưởng tới xây | Có bước discovery ở giữa | Nhảy thẳng vào code |
Dấu hiệu bạn đã thành thạo
Bạn tự động phân biệt hai loại việc mà không cần nghĩ. Khi sếp yêu cầu một giải pháp, phản xạ của bạn là hỏi vấn đề gốc chứ không mở ngay tài liệu spec. Team của bạn có một nhịp discovery đều đặn tồn tại song song với sprint, và không ai coi đó là việc phụ nữa.
Cạm bẫy thường gặp
| Cạm bẫy | Thay bằng |
|---|---|
| Discovery chỉ làm một đợt đầu dự án | Discovery liên tục hàng tuần |
| Coi mọi việc là delivery | Phân loại rõ hai luồng |
| Đo bằng số tính năng | Đo bằng kết quả và learning |
| Discovery làm khi rảnh | Discovery có lịch cố định |
Chốt lại
- Discovery và delivery là hai loại công việc song song, không nối tiếp.
- Thiếu discovery biến team thành feature factory, giao nhanh nhưng giao nhầm.
- Mọi mục delivery nên xuất phát từ một learning discovery thật.
- North Star là tỷ lệ quyết định dựa trên evidence chứ không phải cảm tính.