03 thg 2, 2026·8 phút
Gói MVP AI phạm vi cố định để agency duy trì lợi nhuận
Tìm hiểu cách agency bán gói MVP AI phạm vi cố định với bước khám phá rõ ràng, giới hạn sửa đổi, giá cả và bước bàn giao giúp bảo vệ biên lợi.
Tìm hiểu cách agency bán gói MVP AI phạm vi cố định với bước khám phá rõ ràng, giới hạn sửa đổi, giá cả và bước bàn giao giúp bảo vệ biên lợi.
AI có thể rút ngắn thời gian xây dựng nhanh chóng. Nó không làm giảm sự do dự của khách hàng, thay đổi ưu tiên, hay phản hồi mơ hồ. Khe hở đó là lý do các dự án nhanh vẫn biến thành công việc chậm, biên lợi thấp.
Một ý tưởng rõ ràng có thể trở thành MVP hoạt động nhanh hơn nhiều so với quy trình truyền thống. Vấn đề là tốc độ làm thay đổi kỳ vọng của khách hàng. Khi họ thấy thay đổi xảy ra nhanh, họ cho rằng thay đổi phải là không giới hạn. Thường đó là nơi lợi nhuận bắt đầu rò rỉ.
Một brief lỏng lẻo biến một MVP nhỏ thành phần mềm tùy chỉnh mà không ai nói rõ điều đó. Khách hàng bắt đầu với "một portal đơn giản" rồi yêu cầu vai trò, báo cáo, thanh toán, giao diện di động và công cụ admin. Mỗi yêu cầu nghe có vẻ nhỏ. Cộng lại, chúng trở thành năm dự án trong một khoản phí.
Sửa đổi là một kẻ âm thầm giết biên lợi nữa. Vòng đầu thường sửa lỗi thực tế. Đến vòng ba hoặc bốn, phản hồi thường là về sở thích, không phải chức năng. Nếu đội bạn tiếp tục xây lại màn hình, luồng và logic mà không có giới hạn rõ ràng, thời gian tiết kiệm được nhờ AI sẽ bị nuốt bởi việc làm lại.
Hầu hết các gói cố định hỏng ở cùng vài chỗ. Ghi chú khám phá vẫn chung chung thay vì cụ thể. Tiêu chí thành công không được viết ra. Phản hồi được xử lý như mở. Các mục bàn giao chỉ được ngụ ý thay vì liệt kê.
Bàn giao là nơi phạm vi mơ hồ trở nên đắt đỏ. Nếu bạn không ghi rõ khách hàng nhận được gì, họ có thể mong đợi tài liệu hoàn thiện, đào tạo, hỗ trợ triển khai, dọn dẹp mã và hỗ trợ sau ra mắt nằm trong cùng một công việc. Phần xây có thể đã xong, nhưng dự án vẫn cảm thấy chưa hoàn tất.
Một ví dụ thường gặp: agency giao một MVP portal khách hàng trong một tuần. Ứng dụng hoạt động, nhưng khách hàng mong đợi quy tắc admin, email theo thương hiệu, và một buổi hướng dẫn cho đội của họ. Những thứ đó không nằm trong phạm vi. Agency hoặc phải nói không và gây ma sát, hoặc nói có và đánh đổi biên lợi.
Giao nhanh chỉ hiệu quả khi ranh giới rõ. Phạm vi càng chặt, càng dễ giữ tốc độ có lãi.
Các MVP tốt nhất cho gói cố định giải quyết một vấn đề nhỏ với một luồng người dùng rõ ràng. Một bài kiểm tra đơn giản: liệu khách hàng có thể giải thích sản phẩm trong một câu không? Nếu họ có thể nói, "Người dùng gửi yêu cầu, đội duyệt, và cả hai bên theo dõi trạng thái," thì thường phù hợp. Nếu ý tưởng cần nhiều vai trò, nhiều ngoại lệ, hoặc quy tắc kinh doanh mơ hồ, có lẽ quá rộng.
Các MVP an toàn nhất có một hành động chính và một kết quả rõ ràng. Portal khách hàng, công cụ thu nhận, luồng đặt lịch, app phê duyệt nội bộ hoặc dashboard đơn giản thường phù hợp vì mọi người biết như thế nào là "hoàn thành". Điều đó giúp dễ ước lượng và dễ được phê duyệt.
Mục tiêu của phiên bản đầu không phải là xây mọi thứ khách hàng có thể muốn sau này, mà là kiểm tra nhanh một ý tưởng kinh doanh. Người dùng có hoàn thành form không? Nhân viên có tiết kiệm thời gian không? Khách hàng có ngừng gửi email cho hỗ trợ và dùng self-service không?
Một gói cố định thường phù hợp khi dự án có:
Tích hợp sâu là nơi lợi nhuận thường biến mất. Nếu MVP phụ thuộc vào CRM cũ, ERP, logic thanh toán tùy chỉnh hay nhiều API bên ngoài, những bất ngờ nhỏ nhanh chóng biến thành công việc thêm. Trong gói cố định, thường an toàn hơn khi chỉ cung cấp form, thông báo, upload tệp và có thể một tích hợp nhẹ.
Đặt tiêu chuẩn thiết kế nữa. Hứa một giao diện sạch, dễ dùng với các thành phần nhất quán và màn hình thân thiện di động, không phải thiết kế tùy chỉnh cho mọi trang. Cấu trúc lặp lại kiểu đó là thứ làm cho giao hàng nhanh trở nên thực tế.
Một quy trình khám phá lặp lại giữ cho các bản dựng nhanh không biến thành dự án dài, lộn xộn. Nếu mỗi lead trả lời cùng các câu cốt lõi, bạn có thể phát hiện ý tưởng yếu sớm, viết phạm vi chặt hơn và bảo vệ biên lợi.
Bắt đầu với một form tiếp nhận cho mọi khách hàng tiềm năng. Giữ nó ngắn để họ hoàn thành, nhưng đủ nghiêm để cung cấp dữ kiện sử dụng được. Bạn không cố thu thập mọi ý tưởng; bạn đang tìm phiên bản nhỏ nhất đáng để xây.
Yêu cầu khách hàng định nghĩa ba thứ:
Bộ lọc đơn giản này loại bỏ nhiều nhiễu. "Một portal cho khách hàng của chúng tôi" là mơ hồ. "Khách hàng đăng nhập, tải lên một tài liệu và kiểm tra trạng thái phê duyệt" là thứ bạn có thể định phạm vi.
Sau đó phân loại tính năng thành hai nhóm: bắt buộc và muốn có. Cương quyết. Nếu một tính năng không giúp người dùng đầu tiên giải quyết vấn đề chính, có lẽ thuộc pha hai. Một quy tắc hữu ích: nếu sản phẩm vẫn hoạt động mà không có nó ngày đầu, thì không phải là bắt buộc.
Trước khi khởi động, ghi ra những gì khách hàng phải cung cấp. Thường bao gồm tài sản thương hiệu, nội dung, dữ liệu mẫu, văn bản pháp lý, quyền truy cập domain và người có thẩm quyền phê duyệt. Thiếu đầu vào trì hoãn dự án thường hơn thời gian xây thực tế.
Nếu bạn dùng Koder.ai, những ghi chú khám phá đó có thể chuyển thẳng vào chế độ lập kế hoạch và trở thành điểm bắt đầu cho việc xây. Điều đó làm cho bàn giao từ sales sang production sạch hơn.
Một đầu ra khám phá tốt nên vừa trên một trang. Nếu cần một cuộc gọi dài và một tài liệu lớn để giải thích MVP, phạm vi vẫn quá lỏng.
Phạm vi tốt đọc như một bức tranh của sản phẩm hoàn thành, không phải lời hứa mơ hồ. Khách hàng nên có thể nói, "Đúng, đó chính xác là thứ tôi đang mua," trước khi công việc bắt đầu.
Cách dễ nhất là mô tả MVP bằng ngôn ngữ đơn giản: bao gồm những màn hình nào, người dùng có thể làm gì trên mỗi màn hình, điều gì không bao gồm, và khách hàng nhận được gì khi kết thúc.
Bắt đầu bằng việc đặt tên các màn hình được bao gồm và hành động chính trên mỗi màn hình. Giữ cụ thể.
Thay vì nói "portal khách hàng cơ bản", hãy nói:
Điều đó cho khách hàng thứ họ có thể hình dung. Nó cũng bảo vệ đội bạn khỏi các giả định ẩn về chat, thanh toán, quyền nâng cao hay app native.
Sau đó thêm một ghi chú ngắn về ngoài phạm vi. Điều này quan trọng không kém công việc được bao gồm. Một dòng như "không bao gồm xử lý thanh toán, tích hợp tùy chỉnh, hỗ trợ đa ngôn ngữ hoặc app native" có thể cứu hàng giờ tranh luận.
Định nghĩa thế nào là "hoàn thành" nữa. Tập trung vào chức năng, không phải khẩu vị. Một màn hình được coi là xong khi luồng đã thỏa thuận hoạt động, dữ liệu lưu đúng, và bố cục khớp đủ gần với hướng đã phê duyệt để ra mắt.
Khách hàng cũng cần biết họ nhận được gì cuối cùng. Giữ ngắn gọn và cụ thể. Một bàn giao tốt có thể bao gồm MVP chạy, xuất mã nguồn, một buổi gọi walkthrough, thông tin đăng nhập và ghi chú ngắn về cách chỉnh sửa nội dung cơ bản.
Nếu bạn xây trên Koder.ai, hãy rõ ràng về việc triển khai, hosting, cài domain tùy chỉnh, snapshot, hoặc rollback có nằm trong gói không. Nền tảng hỗ trợ những tùy chọn đó, nhưng khách hàng nên biết những gì được bao gồm trong đề nghị của bạn.
Nếu khách hàng có thể đọc phạm vi trong hai phút và lặp lại trong một câu, có lẽ đủ rõ.
Các bản dựng nhanh mất tiền khi phản hồi mở không giới hạn. Nếu muốn gói cố định có lợi, quy tắc sửa đổi cần được đặt trước khi bước prompt, mockup hay bước xây nào bắt đầu.
Một quy tắc đơn giản hoạt động tốt: cho phép một hoặc hai vòng đánh giá cho mỗi pha, không phải phản hồi vô hạn cho toàn bộ dự án. Ví dụ, bạn có thể cho phép một vòng cho wireframe, một cho MVP hoạt động, và một vòng cuối trước bàn giao. Điều đó giữ quyết định tiến và ngăn các cuộc thảo luận cũ mở lại muộn.
Gắn mọi sửa đổi với phạm vi đã phê duyệt. Nếu khách hàng đã phê duyệt portal với đăng nhập, view tài khoản và quyền admin đơn giản, thì thay đổi văn bản nút hoặc di chuyển một trường form là sửa đổi. Yêu cầu quyền cho team, thanh toán hoặc phiên bản app di động là công việc mới.
Làm sự khác biệt hiển nhiên bằng văn bản:
Đặt giá cho vòng bổ sung trước khi dự án bắt đầu. Có thể là phí cố định, theo giờ, hoặc add-on cố định cho các thay đổi phổ biến. Quan trọng là không ai bị bất ngờ.
Một ví dụ ngắn giúp thực thi dễ hơn. Nếu đội bạn xây MVP trên Koder.ai và khách hàng muốn cập nhật nội dung sau review, đó nằm trong giới hạn sửa đổi. Nếu họ yêu cầu loại người dùng thứ hai và luồng phê duyệt mới, đó là thay đổi cần change order.
Giới hạn rõ bảo vệ cả hai bên. Khách hàng biết cách phản hồi hoạt động, và đội bạn có thể di chuyển nhanh mà không biến MVP nhỏ thành bản viết lại vô tận.
Một dự án nhanh cần con đường rõ ràng từ cuộc gọi đầu đến bàn giao. Lợi nhuận thường đến từ ít trễ hơn, ít bất ngờ hơn và ít lần làm lại hơn.
Bắt đầu với khám phá, nhưng giữ hẹp. Bạn không đi bản đồ toàn bộ doanh nghiệp khách hàng. Bạn trả lời một câu hỏi: vấn đề này có thể giải quyết bằng một MVP nhỏ với một luồng người dùng rõ ràng, một đối tượng và danh sách tính năng bắt buộc ngắn không?
Sau đó, gửi phạm vi ngắn và một mức giá cố định. Giữ rõ: bạn sẽ xây gì, không xây gì, thế nào là xong, và bao nhiêu vòng review được bao gồm. Nếu khách hàng không thể đồng ý bằng văn bản, dự án chưa sẵn sàng.
Rồi xây luồng cốt lõi trước. Nếu MVP là portal khách hàng, thường là đăng nhập, dashboard và một hành động chính như gửi yêu cầu hoặc xem bản ghi. Ý tưởng muốn có có thể để sau.
Khi luồng cốt lõi hoạt động, chuyển sang review. Yêu cầu khách hàng kiểm thử dựa trên phạm vi ban đầu, không phải mọi ý tưởng mới nảy ra trong tuần. Giữ thời hạn review ngắn và cụ thể. Sửa những gì hỏng, cải thiện những gì không rõ, rồi khoá phát hành.
Bàn giao nên cảm thấy đầy đủ, không gấp gáp. Đưa cho khách hàng những thứ thiết yếu trong một gói:
Bước cuối cùng đó bảo vệ biên lợi ngay bây giờ và làm giai đoạn trả phí tiếp theo dễ bán hơn.
Thời gian xây nhanh nên tăng biên lợi, không ép bạn phải giảm giá. Giá của một MVP cần bao gồm hơn thời gian sản xuất. Nó còn phải bù cho trễ từ khách hàng, phản hồi mơ hồ, kiểm thử, sửa lỗi nhỏ, và rủi ro một số hạng mục tốn thời gian hơn dự kiến.
Một quy tắc tốt là định giá theo rủi ro, không chỉ theo giờ. Nếu bạn nghĩ một dự án tốn 12 giờ, đừng chỉ tính 12 giờ đó. Thêm chỗ cho QA, quản lý dự án và một vòng dọn dẹp thông thường. Tốc độ là một phần giá trị mà khách hàng mua.
Một đệm nhỏ giữ dự án khỏi biến thành công việc không trả phí. Nhiều agency cộng thêm 15–30% cho kiểm thử và làm lại, đặc biệt khi app bao gồm đăng nhập, form, thanh toán hoặc công cụ bên ngoài. Đệm đó thường là khác biệt giữa một công việc suôn sẻ và một công việc căng thẳng.
Một cấu trúc giá đơn giản thường tốt nhất:
Điều này giữ đề nghị dễ hiểu trong khi cho bạn không gian tăng giá trị đơn mà không mở rộng phạm vi ban đầu.
Ví dụ, một agency có thể bán một portal khách hàng MVP với giá cố định bao gồm đăng nhập, dashboard và một workflow. Nếu sau đó khách hàng muốn kết nối Stripe, thiết kế thương hiệu tùy chỉnh hoặc báo cáo admin, đó sẽ là add-on có phí thay vì nhiệm vụ bất ngờ.
Ngay cả khi bạn xây bằng nền tảng nhanh như Koder.ai, kỷ luật tương tự vẫn áp dụng. Sản xuất nhanh không loại bỏ thời gian review, kiểm thử hay giao tiếp với khách hàng.
Sau mỗi dự án, so sánh ước tính với giờ thực tế đã dùng. Theo dõi thời gian đi đâu: khám phá, xây, sửa đổi, sửa lỗi và bàn giao. Sau vài dự án, lỗi định giá sẽ hiện rõ.
Một agency nhỏ có thể bán MVP portal khách hàng 2 tuần cho một công ty luật, kế toán hoặc tư vấn cần một nơi gọn để cập nhật khách hàng. Lời hứa đơn giản: một phiên bản hữu dụng được giao nhanh, với giới hạn rõ ràng về những gì được bao gồm.
Đó là lý do gói cố định dễ bán hơn. Khách hàng không mua "cái gì vừa vặn trong hai tuần." Họ mua một kết quả đã định nghĩa.
Trong khám phá, agency giữ brief chặt. Thay vì gom mọi ý tưởng, họ thu hẹp xây vào ba thiết yếu: đăng nhập, dashboard và một tập form nhỏ. Điều đó cho khách hàng một portal hoạt động mà không biến dự án thành kế hoạch phần mềm tùy chỉnh.
Một phạm vi điển hình có thể bao gồm:
Mọi thứ khác được để cho sau. Bao gồm thanh toán, quyền truy cập phức tạp, chat, báo cáo sâu và tích hợp bên thứ ba. Những yêu cầu đó vẫn được ghi nhận, nhưng được gắn nhãn là ý tưởng pha hai để phát hành đầu tiên giữ đúng tiến độ.
Sau demo, gói có thể bao gồm hai vòng sửa đổi. Agency định nghĩa rõ ràng. Vòng một bao gồm chỉnh nội dung, thay đổi bố cục nhỏ và cập nhật trường form. Vòng hai là mài giũa cuối cùng. Tính năng mới không tính là sửa đổi.
Bàn giao cũng rõ ràng. Khách hàng nhận file nguồn, ghi chú ra mắt ngắn và danh sách đề xuất cho pha tiếp theo dựa trên những gì xuất hiện trong quá trình xây. Nếu MVP được xây trong Koder.ai, bàn giao có thể bao gồm mã xuất và snapshot của phiên bản đã được duyệt.
Cấu trúc đó giữ dự án nhanh cho khách hàng và có lợi cho agency.
Cách nhanh nhất để mất tiền trên dự án phạm vi cố định là coi mọi yêu cầu nhỏ từ khách hàng là vô hại. Một trường thêm, một vai trò người dùng nữa, một thẻ dashboard mới — mỗi thứ nghe nhỏ. Cộng lại, chúng biến một MVP gọn thành công việc tùy chỉnh bạn chưa tính giá.
Gói cố định chỉ hoạt động khi đội có thể nói chắc chắn điều gì được bao gồm và điều gì không. Việc đó trở nên khó hơn khi agency bắt đầu xây trước khi khách hàng phê duyệt phạm vi bằng văn bản. Nếu ghi chú khám phá vẫn mơ hồ, giai đoạn xây trở thành đoán mò tốn kém.
Một vài vấn đề lặp lại:
Vấn đề sửa lỗi đặc biệt tốn kém. Nếu nút đăng nhập không hoạt động, đó là sửa lỗi. Nếu khách hàng muốn social login, đó là tính năng mới. Khi đội mơ hồ ranh giới đó, vòng sửa đổi mở rộng và biên lợi biến mất.
Tích hợp là một cái bẫy khác. Khách hàng có thể yêu cầu kết nối CRM, công cụ thanh toán hoặc cơ sở dữ liệu nội bộ và nghĩ đó là bổ sung nhỏ. Thực tế, tích hợp thường cần mapping thêm, xử lý lỗi, phân quyền và hỗ trợ sau ra mắt. Hiếm khi là lựa chọn phù hợp cho gói cố định trừ khi nó đã được chuẩn hóa.
Bước bàn giao là nơi nhiều agency trả lại lợi nhuận. Một checklist ngắn bằng văn bản giúp: đã giao gì, thông tin đăng nhập nào đã chia sẻ, hỗ trợ được tính thế nào, và gì cần báo giá mới. Tốc độ xây quan trọng, nhưng ranh giới rõ ràng còn quan trọng hơn.
Gói cố định chỉ hoạt động khi các điều cơ bản đã được xác định trước khi đề xuất đi ra. Nếu khách hàng vẫn mơ hồ về vấn đề, người dùng hay kết quả họ muốn, dự án biến thành đoán mò trả tiền.
Viết ba điểm đó bằng ngôn ngữ đơn giản: ai là đối tượng, giải quyết nỗi đau gì, và thành công trông như thế nào trong phiên bản đầu. Nếu khách hàng không thể đồng ý với bản tóm tắt đó, phạm vi chưa sẵn sàng.
Trước khi chào gói, kiểm tra vài thứ:
Điểm cuối quan trọng hơn nhiều agency thừa nhận. Công cụ xây nhanh có thể rút thời gian giao, nhưng không loại bỏ các chu kỳ review, trễ từ khách hàng hay sửa lỗi bất ngờ. Nếu lợi nhuận biến mất ngay khi một bước bị trễ, gói được định giá quá chặt.
Một bài stress-test đơn giản: tưởng tượng khách hàng yêu cầu thêm một cuộc gọi review, nội dung đến muộn hai ngày, và QA cuối cùng mất nửa ngày lâu hơn dự kiến. Nếu dự án vẫn có lợi, gói có lẽ lành mạnh.
Bắt đầu với một MVP bạn đã giao trước đây. Chọn dự án có mục tiêu rõ, ít bất ngờ và kết quả bạn có thể giải thích trong một câu. Đó thường là cách dễ nhất biến công việc tùy chỉnh thành gói cố định lặp lại được.
Đừng cố đóng gói mọi thứ cùng lúc. Chọn một loại khách hàng trước, ví dụ doanh nghiệp dịch vụ địa phương, coach, nhóm SaaS nhỏ hoặc công cụ vận hành nội bộ. Đối tượng hẹp giúp khám phá nhanh hơn, phạm vi dễ giải thích và định giá ít rủi ro.
Gói đầu tiên của bạn chỉ cần trả lời bốn câu hỏi:
Rồi lưu các phần bạn lặp lại. Giữ một form khám phá ngắn, mẫu phạm vi, chính sách sửa đổi và checklist bàn giao ở một chỗ. Mục tiêu không phải làm quy trình cầu kỳ, mà là ngừng viết lại cùng tài liệu mỗi lần.
Pilot nhỏ là cách an toàn nhất để thử. Bán gói cho một khách hàng, giao nó, và ghi lại nơi thời gian trượt. Có thể nội dung đến muộn, phê duyệt lâu, hoặc khách hàng cần nhiều trợ giúp hơn lúc bàn giao. Những khoảng hở đó chỉ ra chỗ bạn cần thắt chặt trước khi bán lại gói tương tự.
Nếu bạn dùng Koder.ai, vài tính năng có sẵn giúp giữ kỷ luật: chế độ lập kế hoạch trước khi bắt đầu, snapshot trước các thay đổi lớn và xuất mã nguồn làm bàn giao sạch hơn nếu khách hàng sau đó muốn đội của họ tiếp quản.
Sau pilot đầu tiên, cập nhật mẫu ngay. Một gói lặp lại, rõ ràng có giá trị hơn năm gói mơ hồ. Giữ nó hẹp, làm cho vạch đích rõ ràng và chỉ cải thiện gói sau khi có giao hàng thật sự.
Một lựa chọn phù hợp là sản phẩm nhỏ có một người dùng chính, một luồng rõ ràng và kết quả dễ nhận biết. Những thứ như portal cho khách hàng, app thu thập thông tin, luồng đặt lịch hoặc dashboard đơn giản thường dễ ước lượng và phê duyệt hơn so với sản phẩm có nhiều vai trò, nhiều ngoại lệ hoặc quy tắc phức tạp.
Đặt ranh giới trước khi bắt đầu, không đợi đến lúc review. Ghi rõ các màn hình được bao gồm, hành động chính, giới hạn sửa đổi và những mục ngoài phạm vi bằng ngôn ngữ đơn giản; sau đó xử lý các yêu cầu mới như thay đổi có tính phí thay vì ghép vào phí ban đầu.
Một hoặc hai lần đánh giá cho mỗi giai đoạn thường là đủ. Điều này cho khách hàng cơ hội sửa lỗi thực sự trong khi ngăn dự án biến thành chuỗi thay đổi theo sở thích không hồi kết.
Mô tả sản phẩm hoàn chỉnh sao cho khách hàng có thể hình dung được. Đặt tên các màn hình, giải thích mỗi màn hình làm gì, định nghĩa thế nào là “hoàn thành”, và liệt kê những gì không được bao gồm để các giả định ẩn không trở thành công việc miễn phí sau này.
Hãy thận trọng khi MVP phụ thuộc vào CRM cũ, ERP, luồng thanh toán tùy chỉnh hoặc nhiều API bên ngoài. Các tích hợp thường kéo theo việc mapping, xử lý lỗi, phân quyền và hỗ trợ sau ra mắt — những việc khó dự đoán trong giá cố định trừ khi đã chuẩn hóa trước.
Bàn giao nên ngắn gọn và cụ thể. Phần lớn khách hàng cần MVP đang chạy, thông tin truy cập, mã nguồn hoặc quyền xuất (nếu bao gồm), và hướng dẫn ngắn về cách quản lý nội dung cơ bản hoặc các thao tác admin.
Giá theo rủi ro, không chỉ theo giờ làm. Thêm phần để kiểm thử, quản lý dự án, việc dọn dẹp thông thường và những trễ nhỏ — vì giao nhanh không loại bỏ bước QA hay giao tiếp với khách hàng.
Có, nếu bạn dùng nó cùng quy trình rõ ràng. Koder.ai có thể biến ghi chú khám phá thành chế độ lập kế hoạch, cho phép lưu snapshot trước các thay đổi lớn, và làm bàn giao sạch hơn bằng cách xuất mã nguồn hay tùy chọn triển khai khi đó nằm trong gói.
Sửa lỗi là khi tính năng đã thỏa thuận không hoạt động như định nghĩa. Tính năng mới là khi có thêm thứ không nằm trong thỏa thuận ban đầu, như vai trò mới, logic thanh toán hoặc luồng duyệt mới.
Bắt đầu từ một MVP bạn đã triển khai thành công. Đóng gói nó cho một loại khách hàng rõ ràng, giữ phạm vi hẹp, thử với một khách hàng pilot, rồi điều chỉnh phạm vi, chính sách sửa đổi và ghi chú bàn giao dựa trên các điểm thực tế làm chậm dự án.