Quy trình phát triển phần mềm theo yêu cầu từ Discovery đến MVP

Giai đoạn 0: xác nhận đây là bài toán đáng giải quyết

Trước discovery, doanh nghiệp cần một problem brief ngắn: ai gặp vấn đề, việc gì đang xảy ra, hậu quả được đo thế nào và ai sở hữu kết quả. Đừng bắt đầu bằng danh sách màn hình hoặc công nghệ. Nếu một công cụ có sẵn đáp ứng phần lớn nhu cầu và workflow không tạo khác biệt, mua hoặc cấu hình có thể là quyết định tốt hơn xây mới.

Cổng quyết định đầu tiên là có nên đầu tư để hiểu sâu hơn hay không. Dữ liệu ban đầu có thể là thời gian xử lý, số lỗi, số bước bàn giao, chi phí thao tác hoặc phản hồi người dùng. Nếu không có baseline, dự án sẽ khó chứng minh phần mềm tạo ra thay đổi thật.

• ✓Một nhóm người dùng và một workflow ưu tiên.
• ✓Baseline hiện tại và kết quả mong muốn.
• ✓Người sở hữu quyết định, dữ liệu và ngân sách.
• ✓Lý do mua, xây hoặc kết hợp cần được kiểm tra.

Quy trình tốt không bảo đảm mọi giả thuyết đều đúng. Nó giúp doanh nghiệp phát hiện giả thuyết sai khi chi phí thay đổi còn thấp.

Giai đoạn 1: Discovery để giảm bất định

Discovery thu thập bằng chứng về người dùng, quy trình, dữ liệu, chính sách, hệ thống liên quan và ràng buộc kỹ thuật. Hoạt động có thể gồm phỏng vấn, quan sát công việc, mapping workflow, audit dữ liệu và thử kết nối API. GOV.UK Service Manual nhấn mạnh không bắt đầu xây service trong discovery; mục tiêu là hiểu vấn đề và quyết định có đáng chuyển sang thử giải pháp hay không.

Đầu ra cần ngắn nhưng dùng được: problem statement, nhóm người dùng, bản đồ quy trình, giả thuyết giá trị, rủi ro, phạm vi loại trừ và kế hoạch kiểm chứng. Friday Works thường lập kế hoạch discovery 1–3 tuần khi bài toán và người tham gia sẵn sàng; độ dài thực tế phụ thuộc độ phân tán của dữ liệu và số bên liên quan.

• ✓Bằng chứng từ công việc thật, không chỉ ý kiến trong phòng họp.
• ✓Rủi ro lớn nhất về giá trị, khả dụng, dữ liệu, tích hợp và an toàn.
• ✓Các giả định phải được kiểm tra trước khi ước tính sâu.
• ✓Cổng quyết định: dừng, mua, prototype hoặc đi tiếp với phạm vi hẹp.

Giai đoạn 2: Prototype và Alpha để thử hướng giải pháp

Prototype có thể là luồng giao diện, mô hình dữ liệu, API spike hoặc bản mô phỏng dịch vụ. Nó được chọn theo rủi ro cần giảm: nếu chưa biết người dùng hiểu quy trình mới hay không, thử giao diện; nếu rủi ro nằm ở tích hợp, hãy gọi API thật trên dữ liệu giả; nếu rủi ro ở quyền truy cập, hãy mô hình hóa vai trò trước.

Trong cách gọi của GOV.UK, alpha là nơi thử nhiều giải pháp cho vấn đề đã hiểu trong discovery. Không cần giữ mọi đoạn code thử nghiệm. Kết quả quan trọng là bằng chứng: giải pháp có khả dụng không, tích hợp có hoạt động không, giả định kiến trúc nào sai và phạm vi beta hoặc MVP nên là gì.

• ✓Prototype đúng loại rủi ro thay vì làm bản demo đẹp cho mọi thứ.
• ✓Dữ liệu thử có cấu trúc và tiêu chí đánh giá trước khi thử.
• ✓Decision log cho lựa chọn kiến trúc và phần bị loại.
• ✓Cổng quyết định: có một hướng đủ khả thi để xây end-to-end hay chưa.

Giai đoạn 3: MVP là một lát cắt vận hành, không phải sản phẩm làm ẩu

MVP nên hoàn thành một hành trình quan trọng từ đầu đến cuối cho một nhóm người dùng đủ hẹp. Nó có đăng nhập, phân quyền, dữ liệu, xử lý lỗi, đo lường và hỗ trợ ở mức tương xứng với rủi ro. Cắt phạm vi bằng cách giảm số vai trò, số workflow hoặc số tích hợp; không cắt bằng cách bỏ tiêu chí nghiệm thu, kiểm thử hay bảo vệ dữ liệu.

NIST SSDF xem yêu cầu an toàn, bảo vệ thành phần, tạo phần mềm an toàn và phản hồi lỗ hổng là hoạt động xuyên suốt. Vì vậy bảo mật không phải một gói được thêm sau MVP. Một phiên bản đầu có thể có phạm vi nhỏ, nhưng xác thực, phân quyền, bí mật, logging và cập nhật dependency vẫn phải được thiết kế theo dữ liệu và tác động thực tế.

• ✓Một outcome và một nhóm người dùng ưu tiên.
• ✓Luồng end-to-end có thể sử dụng và đo lường.
• ✓Tiêu chí chấp nhận, observability và đường lui an toàn.
• ✓Cổng quyết định dựa trên sử dụng, chất lượng, chi phí và rủi ro.

Giai đoạn 4: Production, vận hành và vòng cải tiến

Trước production, đội ngũ cần hoàn tất migration, cấu hình môi trường, backup và khôi phục, monitoring, runbook, quyền truy cập, tài liệu và kế hoạch hỗ trợ. Beta hoặc phát hành giới hạn giúp kiểm tra hệ thống với người dùng thật và lưu lượng có kiểm soát trước khi mở rộng. GOV.UK mô tả live không phải điểm kết thúc; service tiếp tục được phát triển dựa trên nhu cầu đã xác định và dữ liệu vận hành.

Sau ra mắt, roadmap nên ưu tiên theo bằng chứng: tính năng nào được dùng, điểm nào gây lỗi, workflow nào vẫn cần thao tác ngoài hệ thống và chi phí trên một đơn vị kết quả ra sao. Một review định kỳ cũng kiểm tra dependency, quyền truy cập, chi phí hạ tầng và các giả định kiến trúc đã thay đổi.

• ✓Release checklist, migration plan và rollback.
• ✓Dashboard cho lỗi, hiệu năng, sử dụng và chi phí.
• ✓Runbook, đầu mối hỗ trợ và quy trình phản hồi lỗ hổng.
• ✓Roadmap dựa trên dữ liệu thay vì danh sách mong muốn cũ.