Một câu yêu cầu nghe rất gọn — "làm cho em tính năng đặt hàng giống bên sàn X" — phía sau có thể là mười đầu việc. Giá của website theo yêu cầu nằm ở chỗ đó.
"Theo yêu cầu" không phải một loại website. Nó là một thang nhiều cấp độ: có yêu cầu chỉ cần đổi cách trình bày, có yêu cầu cần cấu hình lại tính năng có sẵn, và có yêu cầu phải viết riêng vì nó chính là cách doanh nghiệp của bạn vận hành. Trang này giúp bạn nhìn rõ yêu cầu của mình đang ở cấp nào trước khi hỏi giá.
Cùng một câu "em muốn làm web theo yêu cầu", người bán có thể hiểu là thay giao diện theo bộ nhận diện, còn người mua đang nghĩ đến một luồng duyệt đơn hai cấp mà chỉ công ty họ mới có. Hai bên nói chuyện rất lâu mới phát hiện đang nói về hai thứ khác nhau — và báo giá ban đầu trở nên vô nghĩa.
Muốn hỏi đúng giá của website theo yêu cầu, trước hết phải trả lời được: yêu cầu của bạn khác với cách làm phổ biến ở điểm nào, và điểm khác đó chạm vào trình bày, vào tính năng hay vào dữ liệu phía sau?
Ba cấp độ của "theo yêu cầu" — và giá thay đổi theo cấp, không theo tên gọi
Cấp 1 — Theo yêu cầu về trình bày
Cấu trúc trang và tính năng giữ theo cách làm phổ biến; phần thay đổi nằm ở giao diện, bố cục, màu sắc, cách sắp xếp nội dung theo nhận diện của doanh nghiệp. Đây là cấp nhẹ nhất: phù hợp khi quy trình bán hàng của bạn không khác số đông, chỉ cần website "trông là của mình".
Cấp 2 — Cấu hình lại tính năng có sẵn theo cách dùng của bạn
Tính năng vẫn là loại phổ biến (form liên hệ, đặt lịch, quản lý sản phẩm, gửi yêu cầu báo giá) nhưng trường thông tin, bước thao tác và người nhận thông báo được chỉnh theo vận hành thật: ví dụ form phải thu thêm mã đơn vị, thông báo phải về hai đầu mối khác nhau theo khu vực. Giá tăng so với cấp 1 vì phải khảo sát cách bạn đang làm và kiểm thử các trường hợp lệch chuẩn.
Cấp 3 — Viết riêng theo quy trình chỉ doanh nghiệp bạn có
Luồng xử lý, trạng thái dữ liệu hoặc cách phân quyền không tồn tại sẵn: duyệt nhiều cấp, tính giá theo công thức riêng, đồng bộ dữ liệu hai chiều với hệ thống đang dùng. Đây là cấp tốn công khảo sát và kiểm thử nhất, và cũng là cấp duy nhất thực sự cần ngân sách "theo yêu cầu" theo đúng nghĩa.
Một website hoàn chỉnh thường trộn cả ba cấp: đa số trang ở cấp 1, vài tính năng ở cấp 2, và chỉ một–hai điểm khác biệt cốt lõi ở cấp 3. Báo giá hợp lý là báo giá chỉ ra được tỷ lệ trộn đó.
Giải phẫu một yêu cầu nghe rất đơn giản
Lấy yêu cầu mẫu: "Khách đặt hàng xong, cho khách tự tra cứu tình trạng đơn trên website."
Để câu này chạy được thật, phía sau cần ít nhất các đầu việc sau:
Không đầu việc nào trong số này là "trang trí". Khi bạn nghe một yêu cầu được báo giá cao hơn dự tính, hãy hỏi lại theo đúng cách này: nó gồm những đầu việc phía sau nào? Nhà cung cấp trả lời được rõ ràng từng đầu việc thì con số mới đáng tin.
- Một cách để khách xác thực mình là chủ đơn (mã đơn, số điện thoại, hoặc tài khoản) — mỗi cách kéo theo mức bảo mật khác nhau.
- Các trạng thái đơn phải được định nghĩa rõ: đã nhận, đang chuẩn bị, đã giao vận chuyển, hoàn thành, hủy — và ai là người cập nhật từng trạng thái.
- Nhân viên kho/kế toán phải có màn hình cập nhật trạng thái; nếu họ không cập nhật, trang tra cứu sẽ hiển thị sai và khách còn mất niềm tin hơn không có.
- Thông báo khi trạng thái đổi: hiện trên web, gửi tin nhắn, hay cả hai?
- Trường hợp lệch: đơn bị tách làm hai lần giao, đơn đổi địa chỉ sau khi đặt — hiển thị thế nào?
Yêu cầu nào đáng viết riêng, yêu cầu nào nên dùng đồ có sẵn
Một cách tự kiểm tra nhanh, áp dụng cho từng yêu cầu của bạn:
- Yêu cầu này có phải là điểm khiến khách chọn bạn thay vì đối thủ không? Nếu có, nó đáng ở cấp 3. Nếu không, hãy cân nhắc cấp 1–2.
- Quy trình phía sau yêu cầu có người vận hành thật không? Tính năng viết riêng mà không ai cập nhật dữ liệu sẽ chết sau vài tuần — vấn đề nằm ở vận hành, không nằm ở code.
- Cách làm phổ biến đang làm bạn mất gì cụ thể? Nếu trả lời được bằng một tình huống mất đơn, mất thời gian hoặc sai dữ liệu, yêu cầu đó có cơ sở để tùy biến. Nếu chỉ là "thấy bên kia có nên muốn có", hãy để nó ở giai đoạn sau.
- Yêu cầu có đổi theo mùa/theo chiến dịch không? Thứ thay đổi thường xuyên nên được làm thành phần cấu hình được (cấp 2), không viết cứng ở cấp 3.
Mô tả yêu cầu theo tình huống sử dụng, đừng mô tả theo tên tính năng
Báo giá sai thường bắt đầu từ cách mô tả. So sánh hai cách nói về cùng một nhu cầu:
Khi gửi yêu cầu, hãy viết theo mẫu ba ý: ai đang làm việc này — hiện họ làm bằng cách nào — chỗ nào đang kẹt. Ba ý đó đủ để nhà cung cấp phân loại cấp độ và hỏi lại đúng chỗ còn thiếu, thay vì báo một con số đoán.
- Cách theo tên tính năng: "Em cần tính năng quản lý khách hàng." — người nghe không biết quản lý để làm gì, gồm những gì.
- Cách theo tình huống: "Nhân viên kinh doanh của em đang giữ danh sách khách trong file riêng. Em cần một chỗ chung để xem khách nào đã được báo giá, khách nào chưa ai gọi lại." — người nghe đã hình dung được dữ liệu, người dùng và kết quả cần đạt.
Quy trình triển khai
Gửi yêu cầu theo tình huống sử dụng
Bạn gửi danh sách yêu cầu theo mẫu ba ý ở trên. Chưa có danh sách cũng được: kể lại ngày làm việc điển hình của đội bạn, Dũng Virgo sẽ trích ra các yêu cầu ngầm trong đó.
Nhận phân loại cấp độ trong 24–48 giờ làm việc
Mỗi yêu cầu được xếp vào cấp 1, 2 hoặc 3 kèm lý do. Bạn thấy ngay phần nào đang bị "đội giá" bởi một yêu cầu cấp 3 chưa thật cần, và có thể hạ cấp hoặc để sang giai đoạn sau trước khi chốt.
Chốt phạm vi và triển khai theo milestone
Phần viết riêng được duyệt bằng tình huống sử dụng thật (dữ liệu mẫu gần với dữ liệu của bạn), không duyệt bằng mô tả miệng. Landing vẫn 1–3 ngày, website bán hàng thường 3–7 ngày; phần viết riêng có mốc thời gian riêng ghi trong đề xuất.
Bàn giao kèm tài liệu vận hành phần riêng
Phần tùy biến được bàn giao kèm mô tả cách dùng và các tình huống lệch đã kiểm thử, để người vận hành phía bạn — và cả đội kỹ thuật khác sau này — hiểu được nó chạy thế nào.
Câu hỏi thường gặp
Làm theo yêu cầu có phải lúc nào cũng đắt hơn làm theo mẫu không?
Không nhất thiết theo cách bạn nghĩ. Nếu phần lớn yêu cầu của bạn ở cấp 1–2, chênh lệch nằm ở công khảo sát và cấu hình, không phải viết lại cả website. Chỉ những yêu cầu cấp 3 mới làm ngân sách thay đổi rõ rệt — và đề xuất phải chỉ ra được chúng là những yêu cầu nào.
Làm riêng thì sau này đổi đội làm web khác có sửa tiếp được không?
Được, nếu phần lõi dùng nền tảng phổ biến và phần viết riêng có tài liệu vận hành. Đây là điểm bạn nên hỏi thẳng mọi nhà cung cấp trước khi ký: phần nào là nền phổ biến, phần nào là code riêng, tài liệu bàn giao gồm những gì.
Tôi chưa biết rõ mình cần gì thì có hỏi giá được không?
Được, và đó là lúc nên hỏi. Hãy bắt đầu bằng việc kể tình huống sử dụng và chỗ đang kẹt; khâu phân loại cấp độ trong đề xuất sẽ giúp bạn nhìn rõ nhu cầu của chính mình trước khi quyết định mức đầu tư.
Giữa chừng tôi đổi yêu cầu thì sao?
Yêu cầu mới hoặc thay đổi sẽ được phân loại cấp độ và báo phạm vi riêng trước khi làm, giống cách xử lý phát sinh minh bạch. Vì vậy lúc chốt phạm vi ban đầu, hãy ưu tiên đưa những yêu cầu "chắc chắn phải có" vào trước.
Viết riêng có làm website chậm hơn không?
Phần viết riêng tốn thêm thời gian khảo sát và kiểm thử, nên mốc bàn giao được chốt theo phạm vi trong đề xuất thay vì áp mốc của website thông thường. Đổi lại, bạn duyệt phần riêng bằng tình huống thật ở từng milestone nên ít phải sửa vòng lại ở cuối.
Yêu cầu của tôi liên quan đến hệ thống nội bộ đang dùng thì sao?
Đó là yêu cầu cấp 3 điển hình: cần biết hệ thống hiện tại có cho phép trao đổi dữ liệu hay không. Hãy nêu tên hệ thống và việc bạn muốn hai bên trao đổi dữ kiện gì ngay trong brief; khả thi hay không sẽ được trả lời trong đề xuất, không phỏng đoán.
Đừng để câu "theo yêu cầu" là một cái giá mở — hãy để nó được phân loại thành từng cấp độ rõ ràng
Bạn không cần viết đặc tả kỹ thuật. Chỉ cần gửi những yêu cầu đang làm bạn phân vân theo cách kể tình huống: ai đang làm, làm bằng gì, kẹt ở đâu. Đề xuất sẽ trả lại cho bạn bản phân loại từng yêu cầu — phần dùng sẵn, phần cấu hình lại, phần đáng viết riêng — để bạn quyết định mức đầu tư bằng con mắt của người hiểu rõ mình đang mua gì. Phần không khác biệt sẽ không bị tính tiền như phần khác biệt. Đề xuất được phản hồi trong 24–48 giờ làm việc. Văn phòng Hà Nội: 144 Trần Vỹ · Văn phòng Phú Thọ: Số 2 Chùa Cấm, Phúc Yên. Liên hệ nhanh qua các nút Điện thoại/Zalo trên trang.
