Phát triển web app và ứng dụng di động từ phạm vi sản phẩm đã xác định

Những đầu vào sản phẩm nào định hình phạm vi xây dựng đầu tiên?

Brief sản phẩm là tạo tác đầu tiên chúng tôi xem xét. Nó cho thấy người dùng mục tiêu, tác vụ chính của họ và các nền tảng mà bản build phải hỗ trợ. Một bản xem xét phạm vi bằng văn bản sau đó sẽ tách biệt các yêu cầu đã xác nhận khỏi các quyết định còn bỏ ngỏ. Điều này giữ cho các lựa chọn tính năng được kết nối với quy trình làm việc thực tế của người dùng.

Bản ghi phạm vi mặc định của chúng tôi nắm bắt 5 trường: tác vụ người dùng, nền tảng, tính năng, phụ thuộc và điểm chấp nhận. Chúng tôi kiểm tra nó tại 3 điểm kiểm tra: xem xét brief, xem xét thiết kế và bàn giao.

Mang những tài liệu này đến buổi thảo luận đầu tiên:

• Tóm tắt sản phẩm: dịch vụ làm gì và phục vụ ai.
• Tác vụ người dùng: hành động mà khách truy cập hoặc khách hàng nên hoàn thành.
• Danh sách nền tảng: trang web, ứng dụng di động hoặc cả hai.
• Tài liệu hiện có: nhận diện, thiết kế, nội dung hoặc ghi chú kỹ thuật.
• Phụ thuộc: tích hợp, loại tài khoản và bất kỳ tính năng AI nào đang được xem xét.

Chúng tôi ghi lại những gì đã biết và xác định các quyết định cần thiết trước khi triển khai. Một sản phẩm đang hình thành có thể tiếp tục với các câu hỏi mở được đánh dấu rõ ràng để phê duyệt. Một trang tập trung và một sản phẩm nhiều màn hình cần các phạm vi khác nhau. Xem xét dịch vụ thiết kế landing page nếu một hành trình duyệt web là yêu cầu chính. Để có sự kết hợp rộng hơn giữa công việc sáng tạo và phát triển, hãy xem tổng quan studio.

Điều gì khác biệt giữa một trang web, ứng dụng và tính năng AI?

Hành trình người dùng và mô hình truy cập xác định những sản phẩm bàn giao nào thuộc về bản build ban đầu. Một trang web có thể trình bày thông tin sản phẩm hoặc hỗ trợ quy trình làm việc dựa trên trình duyệt. Một ứng dụng di động yêu cầu phạm vi màn hình và tính năng riêng. Một tính năng AI cần một tác vụ xác định trước khi nó trở thành một phần của kế hoạch sản phẩm.

Đây là các danh mục phạm vi, không phải package cố định. Một trang web doanh nghiệp có thể bao gồm nhận diện thị giác, logic chức năng, bảng quản trị hoặc trang quản lý và thiết lập SEO. Một phạm vi di động có thể bao gồm thiết kế màn hình và phát triển tính năng. Ba loại màn hình—máy tính để bàn, di động và máy tính bảng—có thể được giải quyết thông qua thích ứng đáp ứng nơi dự án yêu cầu.

Nếu dự án bao gồm nhiều định dạng, hãy đánh dấu hành trình người dùng thiết yếu trước. Sau đó liệt kê các tính năng có thể theo sau trong một phạm vi sau. Để có một hệ thống thị giác nhất quán trên các màn hình sản phẩm và tài liệu hỗ trợ, hãy xem xét phát triển brand book.

Bằng chứng nào làm cho một tính năng AI sẵn sàng cho thiết kế sản phẩm?

Một trường hợp sử dụng bằng văn bản mang lại cho tính năng AI một vai trò có thể kiểm tra trong sản phẩm. Nó nêu tên tác vụ người dùng, thông tin được cung cấp và phản hồi mà người dùng sẽ nhận được. Nếu không có những chi tiết đó, tính năng không thể được xác định phạm vi rõ ràng cùng với phần còn lại của logic ứng dụng.

Trước khi thêm tích hợp AI vào một brief, hãy ghi lại:

• Vấn đề người dùng mà tính năng nên giải quyết.
• Đầu vào mà tính năng sẽ nhận.
• Đầu ra dự kiến và cách người dùng có thể sửa nó.
• Bất kỳ yêu cầu xử lý dữ liệu nào đã biết.
• Sản phẩm nên làm gì khi tính năng không thể hoàn thành tác vụ.

Những ghi chú này giúp phân biệt một tính năng AI với một khát vọng sản phẩm chung chung. Chúng cũng cung cấp cho thiết kế và phát triển một tham chiếu chung cho các điều khiển, phản hồi và hành vi dự phòng. Tính năng sau đó có thể được xem xét như một phần của phạm vi sản phẩm, thay vì được coi như một lời hứa riêng biệt về toàn bộ ứng dụng.

Khả năng hiển thị tìm kiếm hỗ trợ AI là một dịch vụ riêng. Xem khả năng hiển thị tìm kiếm AI cho công việc đó.

Những sản phẩm bàn giao nào nên được ghi trong hồ sơ dự án?

Tài liệu phạm vi nên nêu tên từng sản phẩm bàn giao và cách khách hàng sẽ xem xét nó. Một nhãn như “thiết kế” là không đủ. Hãy chỉ rõ các trang hoặc màn hình, các hành vi cần triển khai và các thích ứng cần thiết trên các định dạng đã chọn.

Tùy thuộc vào brief, hồ sơ có thể bao gồm:

• Thiết kế giao diện và bố cục đáp ứng cho máy tính để bàn, di động và máy tính bảng.
• Trang web hoặc màn hình ứng dụng với logic kinh doanh đã thống nhất.
• Phát triển tính năng và một tích hợp AI cụ thể.
• Thiết lập SEO, cộng với bảng quản trị hoặc trang quản lý cho công việc trang web khi cần.
• Ghi chú bàn giao và bất kỳ hỗ trợ bảo trì hoặc quản lý nào đã thống nhất.

Đối với mỗi mục, hãy nêu điểm chấp nhận của nó. Thiết kế màn hình có thể được xem xét dựa trên hành trình người dùng đã thống nhất. Công việc tính năng có thể được kiểm tra dựa trên hành vi trong brief. Bảo trì nên nêu rõ hỗ trợ liên tục nào được mong đợi, thay vì dựa trên giả định rằng nó đi kèm với mọi bản build.

Cũng ghi lại ai cung cấp nội dung, tài sản thị giác, quyết định sản phẩm và quyền truy cập vào các hệ thống cần thiết. Những đầu vào này làm cho việc xem xét dễ tổ chức hơn. Chúng giúp đánh dấu tài liệu còn thiếu trước khi nó chặn một tác vụ đã lên kế hoạch. Tổng quan studio cho thấy cách phát triển có thể song hành cùng các công việc sáng tạo khác.

Làm thế nào một brief sản phẩm di chuyển qua thiết kế và phát triển?

Trình tự xem xét bắt đầu với các yêu cầu và kết thúc với một bàn giao được ghi lại. Mỗi giai đoạn cung cấp cho khách hàng một tạo tác để kiểm tra trước khi nhóm quyết định tiếp theo được đưa ra. Bản xem xét phạm vi bằng văn bản là điểm kiểm soát đầu tiên: nó nắm bắt các tác vụ người dùng, lựa chọn nền tảng, tính năng và các câu hỏi chưa được giải quyết.

Quy trình xem xét mặc định của chúng tôi sử dụng 2 tạo tác: phạm vi đã thống nhất và một bản build đang hoạt động. Chúng tôi kiểm tra chúng tại 3 điểm kiểm tra: phạm vi, thiết kế và bàn giao. Mỗi điểm kiểm tra ghi lại 1 chủ sở hữu và một hành động tiếp theo. Chúng tôi ghi nhật ký 4 trạng thái vấn đề: mở, bị chặn, sẵn sàng xem xét và đã giải quyết.

Dự án sau đó di chuyển qua các hoạt động này:

• Xem xét yêu cầu: xác nhận vai trò, tác vụ cốt lõi và nhu cầu chức năng.
• Xem xét thiết kế: kiểm tra cấu trúc trang hoặc màn hình và hành vi đáp ứng.
• Xem xét phát triển: so sánh các tính năng đang hoạt động với các yêu cầu đã thống nhất.
• Xem xét bàn giao: ghi lại công việc đã bàn giao và thảo luận nhu cầu hỗ trợ.

Phản hồi hữu ích nhất khi một người thu thập ý kiến và kết nối mỗi điểm với một tác vụ người dùng. Đối với một trang web, hãy xác nhận ai sẽ cập nhật nội dung và liệu có cần bảng quản trị hoặc trang quản lý hay không. Đối với một ứng dụng, hãy kiểm tra các trạng thái màn hình quan trọng, bao gồm các điều kiện tải, trống và lỗi nếu có liên quan. Chỉ kiểm tra trực quan sẽ không cho thấy liệu tác vụ chính có hoạt động từ đầu đến cuối hay không.

Thời gian được thiết lập sau khi phạm vi và các điểm xem xét được thống nhất. Độ sâu tính năng, tích hợp và các quyết định sản phẩm chưa được giải quyết có thể thay đổi trình tự. Kế hoạch dự án nên làm cho những phụ thuộc đó hiển thị trước khi phát triển bắt đầu.

Những phụ thuộc phát hành nào nằm ngoài phạm vi phát triển?

Danh sách kiểm tra phát hành xác định ai sở hữu từng phụ thuộc bên ngoài. Nó nên nêu tên các tài khoản dịch vụ cần thiết, phê duyệt truy cập, người xem xét nội dung và người tổng hợp phản hồi. Hồ sơ này cung cấp cho nhóm một cách thực tế để đánh dấu công việc bị chặn và thảo luận hành động tiếp theo.

Hãy kiểm tra những mục này trước khi bản build đạt đến đánh giá cuối cùng:

• Các dịch vụ bên ngoài mà sản phẩm phải kết nối và chủ sở hữu tài khoản của chúng.
• Quyền truy cập hoặc phê duyệt cần thiết để kiểm tra từng tích hợp.
• Người chịu trách nhiệm về nội dung và quyết định sản phẩm.
• Cách các vấn đề xem xét sẽ được ghi lại và phân công.
• Các tác vụ bảo trì dự kiến sau bàn giao.

Quyền truy cập dịch vụ bên thứ ba, các yêu cầu tích hợp thay đổi và đánh giá cửa hàng ứng dụng nằm ngoài tầm kiểm soát của nhóm build. Chúng tôi có thể bàn giao công việc đã thống nhất và báo cáo các vấn đề tìm thấy trong quá trình xem xét, nhưng không thể hứa hẹn phê duyệt bên ngoài hoặc phản hồi từ nền tảng.

Cung cấp quyền truy cập làm việc sớm giúp nhóm đánh giá các phụ thuộc trong quá trình lập kế hoạch. Giữ cho mỗi tích hợp được nêu rõ trong phạm vi. Ghi lại quyền truy cập thử nghiệm có sẵn và công việc dự kiến từ mỗi bên. Điều đó cung cấp cho cả hai bên một cơ sở cụ thể để đánh giá mức độ sẵn sàng phát hành mà không coi một quyết định bên ngoài như một sản phẩm bàn giao của phát triển.

Bàn giao nên ghi lại điều gì cho các thay đổi sản phẩm trong tương lai?

Hồ sơ bàn giao nên xác định những gì đã được bàn giao và cách các yêu cầu trong tương lai sẽ được đánh giá. Sau khi phát hành, hãy thu thập câu hỏi của người dùng, vấn đề hỗ trợ và yêu cầu tính năng. Tách biệt các bản sửa lỗi khẩn cấp khỏi các thay đổi cần một quyết định phạm vi mới.

Đối với mỗi thay đổi được đề xuất, hãy mô tả vấn đề người dùng, hành vi dự kiến và bất kỳ tích hợp nào liên quan. Điều này giúp xác định liệu tác vụ tiếp theo có cần cập nhật thiết kế, thay đổi logic hay phát triển tính năng mới hay không. Đối với một trang web, cũng giải quyết ai có thể chỉnh sửa nội dung và cách các yêu cầu đến được nhóm bảo trì. Đối với một tính năng AI, hãy lưu ý liệu người dùng có cần điều khiển hoặc hướng dẫn rõ ràng hơn hay không.

Hỗ trợ bảo trì và quản lý có thể được thống nhất cùng với dự án ban đầu hoặc thảo luận riêng. Một cuộc trò chuyện bàn giao hữu ích ghi lại ai sở hữu từng tác vụ tiếp theo và tài liệu nào khách hàng có thể cập nhật trực tiếp. Nếu nhận diện thị giác cũng cần phối hợp, dịch vụ brand book có thể hỗ trợ một hướng đi nhất quán trên các tài liệu sản phẩm.

Để bắt đầu, hãy gửi tóm tắt sản phẩm, nền tảng mục tiêu, tích hợp đã biết và các quyết định còn bỏ ngỏ qua liên hệ. Chúng tôi sẽ xem xét brief, làm rõ phạm vi và xác định các quyết định dự án tiếp theo.

Cách hoạt động

1. 1. Chia sẻ brief sản phẩmGửi mục đích sản phẩm, người dùng mục tiêu, nền tảng mục tiêu và các tài liệu thiết kế hoặc kỹ thuật hiện có.
2. 2. Xem xét yêu cầuChúng tôi xác định các tác vụ người dùng cốt lõi, tính năng cần thiết, phụ thuộc và các câu hỏi cần quyết định từ khách hàng.
3. 3. Thống nhất thiết kế và phạm viXác nhận sản phẩm bàn giao, điểm xem xét, thích ứng nền tảng và bất kỳ công việc AI hoặc tích hợp nào trước khi phát triển.
4. 4. Xây dựng và xem xétNhóm triển khai công việc đã thống nhất và chia sẻ để xem xét dựa trên các yêu cầu và hành trình người dùng.
5. 5. Ghi lại bàn giao và hỗ trợChúng tôi ghi lại phạm vi đã bàn giao và thảo luận về hỗ trợ bảo trì hoặc quản lý khi cần.