Phát Triển MVP: Phạm Vi, Chi Phí Và Tiến Độ

Việc phát triển MVP đi chệch hướng ngay tại buổi họp xác định phạm vi, chứ không phải trong lúc lập trình. Ai đó nói ra cụm từ „sản phẩm khả dụng tối thiểu", mọi người gật đầu, rồi danh sách tính năng xuất hiện với tài khoản người dùng, một trang quản trị, thanh toán, thông báo, một bảng điều khiển và một ứng dụng di động. Đó không phải là sản phẩm khả dụng tối thiểu. Đó là một sản phẩm hoàn chỉnh, và nó sẽ mất thời gian gấp ba lần con số bạn đang nghĩ trong đầu.

Chữ gây ra thiệt hại là „khả dụng". Phần lớn các đội đọc nó thành „đủ tốt để bán cho tất cả mọi người", trong khi ý nghĩa thật sự là „vừa đủ để biết có ai muốn thứ này hay không".

Bài kiểm tra phạm vi tiết kiệm nhiều tiền nhất: với mỗi tính năng, hãy hỏi bạn sẽ làm khác đi điều gì tùy theo câu trả lời nhận được. Nếu một tính năng không thể thay đổi bất kỳ quyết định nào, nó không thuộc về MVP. Trang quản trị không cho bạn biết liệu người ta có muốn sản phẩm hay không; nó chỉ cho biết sản phẩm sẽ dễ quản trị hơn khi họ đã muốn. Hãy xây nó ở lượt thứ hai.

Phát triển MVP thực sự phục vụ điều gì

MVP tồn tại để trả lời một câu hỏi duy nhất bằng người dùng thật thay vì bằng ý kiến chủ quan. Thường là câu này: có ai chịu trả tiền cho nó không, hoặc có ai dùng nó đủ thường xuyên để điều đó có ý nghĩa không?

Điều đó định hình lại những gì được phép nằm bên trong. Bạn cần đúng một lộ trình chứng minh giá trị, chạy thông suốt từ đầu đến cuối, hoàn chỉnh đến mức một người thật có thể tự đi hết mà không cần bạn ngồi bên cạnh. Mọi thứ còn lại đều là tùy chọn cho tới khi lộ trình đó chứng minh được điều cần chứng minh.

Điều đó cũng giải thích khác biệt so với bản mẫu. Một bản mẫu là thứ dùng xong bỏ đi và trả lời một câu hỏi thiết kế, thường không có backend hoạt động. Một MVP là mã nguồn chạy thật với người dùng thật và dữ liệu thật, được xây để mở rộng tiếp nếu câu trả lời là có. Nhầm lẫn hai thứ này tốn kém theo cả hai chiều: hoặc bạn vứt bỏ đoạn mã mà mình cần, hoặc bạn dày công thiết kế thứ sắp bị loại bỏ.

Cái gì được đưa vào và cái gì phải chờ

Đưa vào: lộ trình giá trị cốt lõi, mức xác thực tối thiểu mà lộ trình đó đòi hỏi, một cách thu tiền nếu câu hỏi là liệu người ta có trả tiền hay không, và đủ công cụ đo lường để thấy người dùng thực sự làm gì.

Phải chờ: các giao diện quản trị, hệ thống vai trò và phân quyền vượt quá một hoặc hai vai trò, tùy chọn thông báo, luồng hướng dẫn ban đầu, những tích hợp chưa ai yêu cầu, và mọi thứ được mở đầu bằng câu „tiện tay làm luôn".

Có hai thứ hay bị cắt mà lẽ ra không nên. Công cụ đo lường, vì một MVP lên sóng mà không có phân tích dữ liệu thì không trả lời được câu hỏi nào cả, và bạn đã tiêu tiền một cách vô ích. Và khả năng xóa hoặc sửa dữ liệu, vì người dùng thật mắc lỗi ngay từ ngày đầu tiên, còn việc can thiệp thủ công vào cơ sở dữ liệu thì rất nhanh trở nên mệt mỏi.

Kiểu phình phạm vi phổ biến nhất là trang quản trị, và gần như lúc nào cũng tránh được. Trong vài tuần đầu, chạy truy vấn bằng tay dựng nhanh hơn và hoàn toàn đủ dùng ở mức mười người dùng. Hãy xây trang quản trị khi việc hỗ trợ người dùng thủ công trở thành nút thắt cổ chai, và đó là một vấn đề đáng mừng.

Chi phí thực tế tại Anh

MVP được định giá theo số lượng việc khác nhau mà nó làm được, chứ không theo ý tưởng đứng sau nó. Các khoảng giá chúng tôi thấy khi triển khai tại Anh:

Triển khai offshore ở mức £100 hoặc £200 mỗi ngày làm thay đổi phép tính này và mang theo chi phí phối hợp mà chúng tôi trình bày trong bài thuê ngoài phát triển phần mềm . Bài phân tích chi phí phát triển phần mềm tùy chỉnh của chúng tôi giải thích điều gì đẩy từng mức giá lên.

Có hai khoản chi phí bị bỏ sót trong gần như mọi ngân sách MVP. Phải có người vận hành nó sau khi đã lên sóng, và đó là một con số hằng tháng có thật, không phải sai số làm tròn. Và phiên bản thứ hai, bởi nếu MVP trả lời tốt câu hỏi của nó thì bước tiếp theo ngay lập tức là xây thêm trên nền đó, còn một ngân sách kết thúc ở ngày ra mắt sẽ hết đúng vào lúc bạn vừa biết mình cần làm gì.

Sai lầm biến ba tháng thành chín tháng

Xây dựng cho một quy mô mà bạn chưa hề có.

Bản năng ấy là dễ hiểu. Không ai thích viết đoạn mã mà mình sẽ phải thay thế. Thế là MVP được gắn thêm hàng đợi tin nhắn, một tầng bộ nhớ đệm, khả năng mở rộng theo chiều ngang và ranh giới microservice, không thứ nào trong số đó chịu tải thật ở mức năm mươi người dùng, mà tất cả đều phải được xây, kiểm thử và vận hành trước khi người đầu tiên nhìn thấy sản phẩm.

Quan điểm trung thực là một MVP hoàn toàn được phép nhàm chán về mặt kiến trúc. Một cơ sở dữ liệu, một ứng dụng, triển khai đơn giản. Nếu nó thành công, bạn sẽ viết lại vài phần với hiểu biết thật sự về nơi tải trọng nằm ở đâu, và lần viết lại đó sẽ rẻ hơn cùng nhắm trúng đích hơn nhiều so với phỏng đoán trước khi ra mắt.

Ngoại lệ là mọi thứ đắt đỏ khi phải thay đổi về sau: mô hình dữ liệu, cách tiếp cận xác thực, và bất kỳ quyết định nào chạm tới dữ liệu cá nhân. Làm cho những phần đó tương đối đúng ngay từ đầu là xứng đáng với một tuần bỏ thêm ra, vì đây chính là những thứ tốn kém nhất khi phải gỡ rối.

Cách xác định phạm vi chỉ trong một buổi chiều

Hãy viết ra đúng một câu mô tả điều mà người dùng đạt được. Sau đó liệt kê những màn hình mà câu đó đòi hỏi, và không thêm gì khác. Với từng tính năng còn lại, hãy áp dụng bài kiểm tra quyết định ở đầu bài viết này.

Rồi vẫn cứ cắt bớt một phần ba danh sách. Đội nào cũng phóng đại phạm vi ở lượt đầu tiên, và một phần ba mà bạn loại bỏ bây giờ gần như luôn đúng bằng một phần ba mà bạn sẽ loại bỏ sau khi ra mắt.

Hãy ấn định một ngày thay vì một danh sách tính năng. Một MVP ba tháng đã lên sóng có giá trị hơn một MVP năm tháng mà tới tháng thứ bảy vẫn còn cách ngày phát hành hai tuần, và một ngày cố định buộc các cuộc thảo luận về phạm vi phải diễn ra sớm, khi chúng còn rẻ.

Mecanik xác định phạm vi và xây dựng MVP thông qua đội phát triển phần mềm của chúng tôi, bao gồm cả phần có người thuyết phục bạn bỏ trang quản trị đi. Nếu bạn có một danh sách tính năng mà không có ngày, đó chính là chỗ nên bắt đầu.

Bài viết liên quan: Phat trien phan mem tuy chinh tai Vuong quoc Anh , Phát triển phần mềm fintech tại Anh: FCA, rails và chi phí , Cách Xây Dựng Ứng Dụng Web Năm 2026 - Hướng Dẫn UK , Phát triển web nhãn trắng cho agency .

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

Một MVP nên có những gì? Lộ trình giá trị cốt lõi chạy thông suốt từ đầu đến cuối, mức xác thực tối thiểu mà lộ trình đó cần, thanh toán nếu câu hỏi là liệu người ta có trả tiền hay không, và đủ công cụ đo lường để thấy người dùng thực sự làm gì. Trang quản trị, hệ thống vai trò, tùy chọn thông báo và những tích hợp chưa ai yêu cầu đều phải chờ cho tới khi MVP đã trả lời được câu hỏi của nó.

Phát triển MVP tại Anh tốn bao nhiêu tiền? Một ứng dụng web một lộ trình với một loại người dùng thường rơi vào khoảng £15.000 đến £35.000 trong sáu đến mười tuần. Hai loại người dùng kèm thanh toán và quản trị cơ bản rơi vào khoảng £35.000 đến £75.000 trong ba đến năm tháng. Sản phẩm nhiều bên có tích hợp hoặc yêu cầu tuân thủ bắt đầu từ khoảng £75.000 và mất năm tháng hoặc lâu hơn.

Bản mẫu và MVP khác nhau ở điểm nào? Bản mẫu là thứ dùng xong bỏ đi và trả lời một câu hỏi thiết kế, thường không có backend hoạt động. MVP là mã nguồn chạy thật với người dùng thật và dữ liệu thật, được xây để mở rộng tiếp nếu câu trả lời là có. Nhầm lẫn hai thứ này tốn kém theo cả hai chiều: vứt bỏ đoạn mã bạn cần, hoặc thiết kế quá mức cho thứ sắp bị bỏ đi.

Xây một MVP nên mất bao lâu? Sáu đến mười tuần cho ứng dụng một lộ trình, ba đến năm tháng ngay khi bạn thêm loại người dùng thứ hai và thanh toán. Nếu ước tính của bạn dài hơn năm tháng, phạm vi gần như chắc chắn lớn hơn một MVP và nên được cắt bớt trước khi có thứ gì được xây, thay vì cắt sau đó.

Sai lầm phổ biến nhất khi làm MVP là gì? Xây dựng cho một quy mô còn chưa tồn tại. Hàng đợi tin nhắn, tầng bộ nhớ đệm và ranh giới microservice không chịu tải thật ở mức năm mươi người dùng nhưng đều phải được xây, kiểm thử và vận hành trước khi ra mắt. Một MVP được phép nhàm chán về mặt kiến trúc. Ngoại lệ là mô hình dữ liệu, xác thực và mọi thứ chạm tới dữ liệu cá nhân, vốn đắt đỏ khi phải thay đổi về sau.