Discovery Sprint: Lập kế hoạch trước khi xây dựng

Đây là gì

Sprint tập hợp những thông tin cần thiết để định hình một quyết định sản phẩm. Nó có thể xem xét mục tiêu kinh doanh, quy trình hiện tại, các nhóm người dùng, dữ liệu sẵn có, hệ thống hiện có, các hành trình ưu tiên và những câu hỏi ban đầu về tính khả thi. Phạm vi cụ thể được thống nhất bằng văn bản và phản ánh tài liệu cũng như nhân sự có thể tham gia hợp đồng. Thay vì tạo ra một tài liệu dài chỉ để có tài liệu, discovery tập trung vào các quyết định: điều gì nên được khám phá ngay bây giờ, điều gì cần xác thực, những giả định nào đang làm nền cho kế hoạch, và điều gì chưa nên được coi là cam kết. Một discovery sprint có thể tạo ra một tuyên bố vấn đề được sắp xếp ưu tiên, phác thảo luồng người dùng, hồ sơ quyết định, bản đồ phụ thuộc và phạm vi đề xuất cho giai đoạn tiếp theo. Phát triển production, thiết kế UI cuối cùng và xây dựng kiến trúc hoàn chỉnh có thể tiếp nối như những đầu ra được thống nhất riêng.

Dành cho ai

Discovery Sprint phù hợp với các đội ngũ:

• Có một ý tưởng sản phẩm hoặc vấn đề vận hành nhưng cần một bản yêu cầu rõ ràng hơn trước khi đề nghị ước tính chi phí xây dựng
• Đang phải lựa chọn giữa nhiều hành trình người dùng, tính năng hoặc ưu tiên thị trường khả thi
• Cần nhà sáng lập, người phụ trách sản phẩm và những người đóng góp kỹ thuật làm việc dựa trên cùng một tập hợp giả định
• Muốn xác định các phụ thuộc và khoảng trống quyết định trước khi cam kết ngân sách, nỗ lực của nhà cung cấp hoặc tiến độ triển khai

Giúp làm rõ điều gì

Discovery giúp làm rõ:

• Vấn đề, người dùng mục tiêu và hành trình ưu tiên nào nên làm trọng tâm cho giai đoạn tiếp theo
• Những gì đã biết về tình trạng hiện tại và những câu hỏi nào vẫn cần bằng chứng, nghiên cứu, quyền truy cập hoặc quyết định
• Những giả định, tích hợp, nội dung, phê duyệt và phụ thuộc bên thứ ba nào có thể ảnh hưởng đến việc triển khai
• Liệu bước tiếp theo hợp lý là một blueprint, định hướng UX/UI, phạm vi MVP, đánh giá kỹ thuật hay một hợp đồng khác

Những gì được bao gồm

• Xác nhận bằng văn bản về câu hỏi discovery, tài liệu sẵn có, người tham gia và ranh giới ra quyết định
• Rà soát có cấu trúc về tình trạng hiện tại, người dùng mục tiêu, hành trình ưu tiên, ràng buộc đã biết và các câu hỏi ban đầu về tính khả thi
• Hồ sơ ghi lại các giả định, phụ thuộc, câu hỏi chưa được giải quyết và các quyết định cần một người phụ trách được chỉ định
• Sắp xếp ưu tiên thực tế cho vấn đề và các luồng người dùng liên quan nhất đến giai đoạn tiếp theo
• Khuyến nghị bằng ngôn ngữ dễ hiểu về một phạm vi tiếp theo thực tế và tập trung
• Buổi trao đổi bàn giao giải thích các phát hiện, ranh giới và các hành động tiếp theo hợp lý

Những gì không được bao gồm

• Phát triển production, thiết kế UI cuối cùng, hệ thống thiết kế hoàn chỉnh hoặc xây dựng kiến trúc đầy đủ, trừ khi có phạm vi riêng
• Bảo đảm về thành công thương mại, tính khả thi kỹ thuật, ngân sách cuối cùng, khả năng sẵn sàng của nhà cung cấp hoặc ngày bàn giao
• Nghiên cứu, workshop, ý tưởng, phỏng vấn hoặc chỉnh sửa không giới hạn vượt quá hợp đồng đã thống nhất
• Tư vấn chính thức về pháp lý, tuân thủ, đầu tư hoặc nghiên cứu thị trường
• Tự động triển khai mọi ý tưởng được xác định trong quá trình discovery

Khi nào nên chọn

Hãy chọn Discovery Sprint khi câu hỏi quan trọng nhất vẫn là xây dựng cái gì, cho ai và vì sao. Hình thức này hữu ích trước một MVP, một đợt xây dựng lại lớn hơn, một công cụ nội bộ mới hoặc một thay đổi đối với hành trình khách hàng. Nó cũng có thể giúp ích khi đội ngũ đã nhận được các bản ước tính có vẻ không nhất quán vì phạm vi nền tảng chưa rõ ràng. Discovery ít hữu ích hơn khi ranh giới sản phẩm đã được xác định và đội ngũ chỉ cần bàn giao một tính năng cụ thể; khi đó, một phạm vi xây dựng tập trung có thể phù hợp hơn. Sprint hiệu quả nhất khi những người ra quyết định liên quan có thể tham gia, tài liệu hiện có có thể được chia sẻ, và đội ngũ sẵn sàng coi một số ý tưởng là khả năng trong tương lai thay vì cam kết trước mắt.

Phương pháp của chúng tôi

Chúng tôi bắt đầu bằng việc thống nhất quyết định mà sprint cần hỗ trợ. Sau đó công việc đi từ tình trạng hiện tại đến tình trạng mục tiêu: người dùng đang cố gắng làm gì, trải nghiệm hoặc quy trình hiện tại gặp trục trặc ở đâu, và một hành trình tiếp theo hữu ích có thể trông như thế nào. Chúng tôi làm cho các giả định trở nên rõ ràng thay vì cài chúng vào một kế hoạch xây dựng tương lai. Các phụ thuộc như dữ liệu, nội dung, nhà cung cấp, quyền truy cập, phê duyệt nội bộ và hệ thống hiện có được ghi nhận cùng các câu hỏi mà chúng đặt ra. Các khuyến nghị ban đầu được trình bày cùng bằng chứng và các câu hỏi còn mở, để thấy rõ mức độ chắc chắn của chúng. Tài liệu bàn giao cuối cùng tách biệt thông tin đã quan sát, giả định làm việc, ràng buộc và các quyết định tiếp theo. Điều này giúp đội ngũ có cơ sở để chọn một blueprint, định hướng thiết kế, MVP hoặc đánh giá kỹ thuật tập trung hơn, với phạm vi, chi phí và thời gian sau này được tinh chỉnh khi có thêm bằng chứng.

Câu hỏi thường gặp

Bài viết liên quan