Giải thích Product Blueprint & Scope

Đây là gì

Công việc vạch ra ranh giới sản phẩm đã thống nhất với mức chi tiết đủ để hỗ trợ một quyết định thực tế cho giai đoạn tiếp theo. Nó có thể bao gồm vai trò người dùng, các luồng cốt lõi, ưu tiên tính năng, nhu cầu dữ liệu và tích hợp, lựa chọn nền tảng, giả định, loại trừ, các giai đoạn triển khai và tác động đến kiểm soát thay đổi. Mức độ chi tiết được điều chỉnh theo quyết định cần đưa ra, tập trung vào những tính năng quan trọng cho giai đoạn tiếp theo. Blueprint mô tả những gì được bao gồm ngay bây giờ và những gì được cố ý để ngoài giai đoạn đầu tiên. Nó cũng ghi lại các câu hỏi phụ thuộc vào quyền truy cập của khách hàng, hệ thống bên thứ ba, ý kiến của nhà cung cấp hoặc điều tra kỹ thuật thêm. Phát triển và triển khai đầy đủ sẽ tiếp nối trong một phạm vi triển khai riêng. Mục đích của nó là giảm sự mơ hồ, không phải tạo ra sự chắc chắn giả tạo.

Dành cho ai

Product Blueprint & Scope phù hợp với các đội ngũ:

• Đã hoàn thành discovery ban đầu và cần một cầu nối rõ ràng hơn giữa tư duy sản phẩm và lập kế hoạch triển khai
• Cần nhiều bên liên quan thống nhất về vai trò người dùng, ưu tiên tính năng, các giai đoạn triển khai và các loại trừ
• Đang chuẩn bị làm việc với nhà phát triển nội bộ hoặc nhà cung cấp bên ngoài và muốn có một hồ sơ quyết định hữu ích hơn
• Cần hiểu tác động của các tích hợp, giả định và yêu cầu thay đổi trong tương lai trước khi cam kết xây dựng

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

Một blueprint giúp làm rõ:

• Những vai trò người dùng và luồng cốt lõi nào là thiết yếu cho giai đoạn đầu tiên đã thống nhất
• Những tính năng, tích hợp, nội dung và phụ thuộc vận hành nào thuộc bên trong hoặc bên ngoài ranh giới hiện tại
• Các giả định, loại trừ và giai đoạn triển khai ảnh hưởng thế nào đến ước tính, trách nhiệm và việc kiểm soát thay đổi sau này
• Những câu hỏi nào cần thêm quyền truy cập, ý kiến nhà cung cấp, xác thực kỹ thuật hoặc một phạm vi chuyên sâu riêng

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

• Xác nhận bằng văn bản về quyết định sản phẩm, vai trò người dùng, giai đoạn dự kiến và các đầu vào sẵn có
• Phác thảo có cấu trúc về các luồng cốt lõi, ranh giới tính năng, ưu tiên, tích hợp, giả định và loại trừ, kèm khuyến nghị về kiến trúc kỹ thuật và technology stack
• Kế hoạch các giai đoạn triển khai kèm ước tính tiến độ và khoảng chi phí dự trù (là ước tính phục vụ lập kế hoạch), tách biệt phạm vi trước mắt với các ý tưởng và phụ thuộc sau này
• Hồ sơ quyết định giải thích những yêu cầu nào vẫn còn mở hoặc phụ thuộc vào quyền truy cập và hệ thống bên ngoài
• Hướng dẫn thực tế về kiểm soát thay đổi để xử lý các yêu cầu mới mà không âm thầm mở rộng ranh giới đã thống nhất
• Buổi trao đổi bàn giao phù hợp với nhà sáng lập, người phụ trách sản phẩm, đội ngũ kỹ thuật và đối tác triển khai

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

• Phát triển đầy đủ, triển khai, đưa lên production hoặc quản lý sản phẩm liên tục, trừ khi có phạm vi riêng
• Bảo đảm rằng phạm vi, chi phí, thời gian hoặc cách tiếp cận kỹ thuật sẽ không bao giờ cần thay đổi
• Định nghĩa tính năng, tạo màn hình, đàm phán với nhà cung cấp hoặc chỉnh sửa không giới hạn vượt quá công việc đã thống nhất
• Tư vấn chính thức về pháp lý, tuân thủ, khả năng tiếp cận, chứng nhận bảo mật hoặc mua sắm
• Xác nhận hành vi, khả năng sẵn sàng hoặc giá của hệ thống bên thứ ba khi không có quyền truy cập và bằng chứng cần thiết

Khi nào nên chọn

Hãy chọn Product Blueprint & Scope khi định hướng sản phẩm đã đủ rõ để lập kế hoạch, nhưng đội ngũ cần sự đồng thuận chặt chẽ hơn về người dùng, luồng, tính năng, phụ thuộc và ranh giới trước khi bắt đầu triển khai. Hình thức này hữu ích sau discovery, trước một sprint MVP, trước một đợt xây dựng lại, hoặc khi một cuộc trao đổi với nhà cung cấp cần một cơ sở rõ ràng hơn một danh sách tính năng mong muốn. Nó có thể giảm những bất đồng có thể tránh được bằng cách ghi lại giai đoạn hiện tại nhằm đạt được điều gì và không nhằm giải quyết điều gì. Nó ít phù hợp hơn khi đội ngũ vẫn chưa chắc chắn về vấn đề cơ bản hoặc người dùng mục tiêu; discovery có thể là bước đầu tiên tốt hơn. Blueprint hiệu quả nhất khi người ra quyết định sẵn sàng chấp nhận đánh đổi và nêu rõ các loại trừ thay vì để mọi thứ đều có khả năng được bao gồm.

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

Chúng tôi bắt đầu bằng việc xác nhận giai đoạn dự kiến và các quyết định mà blueprint phải hỗ trợ. Sau đó chúng tôi lần lượt làm việc với vai trò người dùng, các hành trình cốt lõi, tính năng, tích hợp, nội dung, yêu cầu vận hành và ràng buộc. Cuộc thảo luận phân biệt một yêu cầu với một giả định, và một cam kết cho giai đoạn đầu với một ý tưởng tương lai. Chúng tôi ghi nhận các loại trừ cẩn thận như các hạng mục được bao gồm, vì chính ranh giới là điều giúp ước tính và kế hoạch triển khai sau này đáng tin cậy hơn. Khi một yêu cầu phụ thuộc vào quyền truy cập, hệ thống bên thứ ba, sự hợp tác của nhà cung cấp hoặc công việc kỹ thuật thêm, phụ thuộc đó luôn được thể hiện rõ. Chi phí và thời gian trong blueprint được trình bày dưới dạng ước tính phục vụ lập kế hoạch. Khi bàn giao, đội ngũ có một cái nhìn sẵn sàng cho việc ra quyết định về ranh giới sản phẩm, các giai đoạn, tác động đến kiểm soát thay đổi, và những thông tin vẫn còn cần trước khi việc triển khai có thể được xác nhận một cách có trách nhiệm.

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

Bài viết liên quan