Bạn nói “làm cho em tính năng đặt hàng giống bên sàn X”. Đội lập trình gật đầu. Ba tháng sau, bản bàn giao cũng “giống” — chỉ là giống theo cách hiểu của họ.
Giữa câu nói của bạn và dòng code đầu tiên phải có một chặng mà nhiều dự án nhảy qua: bản đặc tả — nơi yêu cầu được viết thành màn hình, trường dữ liệu, trạng thái, quyền và tiêu chí nghiệm thu mà cả hai bên cùng nhìn. Lập trình website theo yêu cầu làm tốt hay không, phần lớn được quyết định ở chặng đó, trước khi bất kỳ ai viết code.
Một yêu cầu càng đặc thù, khoảng trống cho cách hiểu riêng càng lớn. Người đặt hàng hình dung theo trải nghiệm họ từng dùng; người lập trình hình dung theo cách họ từng làm. Cả hai đều hợp lý — và cả hai cùng tin rằng bên kia đang hình dung giống mình, cho đến ngày nghiệm thu.
Công cụ để hai phiên bản đó gặp nhau không phải thêm nhiều cuộc họp hơn. Nó là một văn bản đủ cụ thể để bất kỳ ai đọc cũng dựng ra cùng một thứ. Trang này đi dọc hành trình của một yêu cầu để thấy văn bản đó xuất hiện ở đâu và gồm những gì.
Hành trình của một yêu cầu qua bốn chặng — và điểm rơi ở từng chặng
Chặng 1 — Câu nói ban đầu
Ngắn, cảm tính, đầy tham chiếu (“giống bên X”, “đơn giản thôi”, “như app Y nhưng nhẹ hơn”). Điểm rơi: các tham chiếu này mỗi bên hiểu một khác ngay từ giây đầu tiên.
Chặng 2 — Buổi hỏi lại
Đội làm việc hỏi về người dùng, tình huống dùng, dữ kiện liên quan, các trường hợp ngoại lệ. Điểm rơi: chặng này bị cắt ngắn vì cả hai bên đều nóng lòng “làm luôn cho kịp”.
Chặng 3 — Bản đặc tả
Yêu cầu được viết thành văn bản có cấu trúc (mục tiếp theo cho thấy một mẫu đầy đủ). Điểm rơi kinh điển: chặng này bị nhảy qua hoàn toàn — từ câu nói đi thẳng vào code.
Chặng 4 — Bản dựng và nghiệm thu
Hai bên đối chiếu sản phẩm với… trí nhớ của mình về chặng 1. Nếu chặng 3 tồn tại, nghiệm thu là việc kiểm tra theo danh sách. Nếu không, nghiệm thu là một cuộc tranh luận về gu.
Mẫu đặc tả một tính năng: “đặt hàng” viết đến mức lập trình được
Đặt một tính năng quen thuộc lên bàn mổ để thấy độ chi tiết cần thiết:
Mỗi mục trong mẫu này tồn tại để chặn một kiểu hiểu lầm đã từng làm hỏng dự án thật. Yêu cầu của bạn phức tạp hơn hay đơn giản hơn đều đi qua cùng một khung như vậy.
- Mục đích: khách hoàn tất đặt hàng mà không cần tài khoản; nhân viên nhận đơn đủ dữ kiện để xử lý ngay.
- Người dùng & quyền: khách lạ (đặt), nhân viên bán hàng (xem, cập nhật trạng thái), quản lý (xem tổng hợp).
- Màn hình/luồng: giỏ hàng → thông tin nhận hàng → xác nhận → thông báo đã đặt + mã đơn.
- Trường dữ liệu: họ tên, điện thoại (bắt buộc, kiểm tra định dạng), địa chỉ, ghi chú; mỗi sản phẩm: mã, số lượng, giá tại thời điểm đặt.
- Trạng thái của đơn: mới → đã xác nhận → đang giao → hoàn thành / đã hủy kèm lý do.
- Ngoại lệ phải xử lý: sản phẩm vừa hết hàng giữa chừng; khách nhập sai điện thoại; đơn trùng do bấm gửi hai lần; hủy đơn sau khi đã xác nhận thì ai được hủy.
- Thông báo: khách nhận xác nhận qua kênh nào; nhân viên được báo đơn mới ở đâu.
- Tiêu chí nghiệm thu: liệt kê các tình huống kiểm tra cụ thể tương ứng từng mục trên — đạt/không đạt rõ ràng.
Thay đổi giữa chừng là bình thường — thay đổi không qua sổ mới là thảm họa
Làm theo yêu cầu mà không có thay đổi nào mới là bất thường: dùng thử bản dựng, ý tưởng sẽ rõ hơn lúc ban đầu. Vấn đề không nằm ở việc đổi, mà ở cách đổi:
Cơ chế này bảo vệ cả hai bên: bạn không bị “phát sinh” bất ngờ ở cuối dự án; đội làm việc không bị yêu cầu một đằng, nghiệm thu một nẻo.
- Mỗi thay đổi được ghi vào một sổ chung: nội dung đổi, lý do, ảnh hưởng tới phạm vi/thời gian, ai chốt.
- Thay đổi được phân loại: đổi trong phạm vi đã đặc tả (hiệu chỉnh nhỏ) và đổi mở rộng phạm vi (tính như một hạng mục riêng, báo trước khi làm).
- Không có thay đổi nào chỉ tồn tại trong một tin nhắn thoại — vì ba tuần sau, không ai còn nhớ nó từng được nói.
Phần nào của yêu cầu không nên làm riêng
Đặc tả tử tế cũng chỉ ra phần yêu cầu nào đang đòi làm riêng một thứ đã có sẵn và đủ tốt:
Tỷ lệ riêng/chuẩn này được chỉ rõ trong đề xuất để bạn biết tiền của mình đang đi vào phần khác biệt thật hay vào việc phát minh lại bánh xe.
- Các luồng phổ thông (đăng nhập, quên mật khẩu, gửi email xác nhận…) nên dựa trên nền tảng/framework chuẩn thay vì viết lại từ đầu.
- Tính năng “riêng” chỉ vì thói quen nhìn ở nơi khác, không gắn với quy tắc kinh doanh nào của bạn, nên được cân nhắc bỏ hoặc dùng mẫu có sẵn.
- Ngược lại, quy tắc nghiệp vụ là lõi khác biệt của doanh nghiệp bạn thì phải được đặc tả đến nơi đến chốn — đó là nơi đáng tiền nhất của dự án theo yêu cầu.
Quy trình triển khai
Gửi yêu cầu bằng ngôn ngữ của bạn
Mô tả tự do, gửi kèm trang/app mẫu bạn muốn tham chiếu nếu có. Chưa cần bất kỳ định dạng nào.
Nhận đặc tả mẫu và đề xuất trong 24–48 giờ làm việc
Đặc tả cho phần yêu cầu cốt lõi, phân định riêng/chuẩn, thứ tự triển khai và thời gian theo phạm vi.
Chốt đặc tả đầy đủ cho phạm vi đã chọn
Từng tính năng được viết theo khung đặc tả; đây là văn bản gốc cho triển khai và nghiệm thu.
Triển khai theo mốc, thay đổi qua sổ, nghiệm thu theo đặc tả
Mỗi mốc đối chiếu trực tiếp với các mục của đặc tả; thay đổi phát sinh đi qua sổ thay đổi kèm đánh giá ảnh hưởng trước khi làm.
Câu hỏi thường gặp
Yêu cầu của tôi khó diễn đạt thành lời — có làm việc được không?
Được. Buổi hỏi lại được thiết kế để moi yêu cầu ra bằng câu hỏi về tình huống dùng thật (“khách của bạn bấm vào đâu trước”, “sai trường hợp nào thì sao”), không đòi bạn phải biết thuật ngữ. Đầu ra là đặc tả do Dũng Virgo viết và bạn duyệt bằng ngôn ngữ thường.
Tôi muốn vừa làm vừa nghĩ thêm tính năng — có sao không?
Không sao nếu đi qua cơ chế sổ thay đổi: mọi bổ sung được đánh giá ảnh hưởng đến thời gian/phạm vi và chốt bằng văn bản trước khi làm. Điều gây hại cho dự án là thay đổi ngầm, không phải thay đổi nhiều.
Ước lượng thời gian cho yêu cầu riêng kiểu gì?
Theo từng mục của đặc tả: tính năng được tách thành các phần có độ phức tạp ước lượng được thay vì một con số tổng cho “cả website”. Khi đặc tả thay đổi, ước lượng được cập nhật tương ứng — đó là lý do đặc tả đi trước báo giá chi tiết.
Nghiệm thu dựa vào đâu để khỏi cãi nhau?
Dựa vào tiêu chí nghiệm thu viết sẵn trong đặc tả của từng tính năng: các tình huống kiểm tra cụ thể, đạt/không đạt. Phần cảm tính (đẹp/chưa đẹp) được xử lý ở mốc duyệt giao diện riêng trước khi vào lập trình.
Đặc tả có phải là tài sản của tôi không?
Có. Bản đặc tả và tài liệu dự án là đầu ra bạn nhận và giữ — chúng là căn cứ để bất kỳ đội nào sau này tiếp tục phát triển đúng ý đồ ban đầu.
Nếu yêu cầu của tôi hóa ra làm bằng nền có sẵn là đủ thì sao?
Đề xuất sẽ nói thẳng điều đó ở khâu phân định riêng/chuẩn, kèm hướng làm bằng nền có sẵn cho phần đó. Mục tiêu của buổi tư vấn là phân định đúng, không phải kéo mọi yêu cầu về hướng làm riêng.
Khoảng cách giữa “ý của bạn” và “cái được bàn giao” chỉ thu hẹp được bằng một văn bản — hãy nhận văn bản đó trước khi quyết định
Bạn không cần diễn đạt yêu cầu của mình thật hoàn hảo mới được bắt đầu — diễn đạt hoàn hảo là việc của bản đặc tả, và bản đặc tả là thứ bạn sẽ nhận ở bước đầu. Hãy gửi yêu cầu bằng đúng ngôn ngữ bạn đang dùng để kể nó với người khác. Phần còn lại — hỏi lại, viết thành màn hình/trạng thái/tiêu chí — là việc của buổi tư vấn. Đặc tả mẫu và đề xuất phạm vi đượ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.
