Tôi đã chứng kiến ba người khác nhau xử lý sai cùng một màn hình ba mươi giây — thẻ kế hoạch xuất hiện giữa lời nhắc của bạn và bản dựng — và mỗi người phải trả giá theo một cách khác nhau. Một người phải xây lại từ đầu. Một người lãng phí công gõ chữ. Một người có được sản phẩm không làm được điều họ thực sự cần. Thẻ kế hoạch là thời điểm rẻ nhất trong toàn bộ quy trình để đổi ý, và chính điều đó lại khiến người ta dễ dàng lướt qua nó.
Sai lầm một: phê duyệt qua loa
Đây là lỗi phổ biến nhất. Bố cục tổng thể trông ổn, nhấn phê duyệt, rồi chuyển tiếp — tôi đã làm vậy suốt nhiều tuần trước khi nó gây hậu quả. Bản dựng cuối cùng khiến tôi bỏ thói quen đó trả về với một luồng thanh toán Stripe được nối vào một trang tĩnh không có nơi lưu trạng thái tài khoản mà Stripe cần. Kế hoạch đã ghi rõ loại sản phẩm: trang tĩnh bằng chữ rõ ràng, ngay trên thẻ, và tôi đã lướt qua vì danh sách trang trông ổn và tôi đang vội.
Hậu quả từ sai lầm này luôn có cùng một hình dạng: mọi thứ theo sau kế hoạch đều đúng xét theo kế hoạch đó, nên lỗi không xuất hiện dưới dạng một thông báo lỗi, mà xuất hiện dưới dạng một bản dựng chạy được nhưng sai về cấu trúc. Không ai gắn cờ vì không có gì bị hỏng — một trang tĩnh có nút thanh toán chỉ đơn giản là làm sai âm thầm, hoặc thất bại đúng vào khoảnh khắc một người dùng thật nhấn "thanh toán". Bạn phát hiện ra điều này trong lúc xem xét, tức là nơi tốn kém nhất để phát hiện.
Sai lầm hai: nêu chi tiết quá mức để tránh vòng thứ hai
Sai lầm ngược lại trông có vẻ có trách nhiệm hơn nhưng không phải vậy. Một số người, sau khi bị sai lầm một cho một bài học, lại phản ứng thái quá bằng cách viết cả một đoạn yêu cầu chi tiết ngay ở bước lập kế hoạch — nội dung câu chữ chính xác, sở thích căn chỉnh, những tính năng nào chắc chắn nên có và không nên có, viết như một tài liệu đặc tả kỹ thuật. Tôi cũng từng làm vậy, vì một nỗi lo mơ hồ rằng bỏ qua chi tiết bây giờ đồng nghĩa với việc "lãng phí" một vòng dựng sau này.
Điều đó ngược đời, và đây là lý do: kế hoạch sẽ được sửa lại một lần nữa khi bạn thấy các trang thực tế, bất kể bạn đã cẩn thận đến đâu ở lần đầu. Và khi được sửa lại, bạn không nhận được bản so sánh những gì đã thay đổi — bạn nhận được một thẻ hoàn toàn mới đã tích hợp sẵn chỉnh sửa của bạn, chấm hết, không có ghi chú thay đổi. Vì vậy độ chính xác bạn gõ ở vòng một cũng không tồn tại nguyên vẹn sang vòng hai; dù sao bạn cũng phải đọc lại toàn bộ. Hai hoặc ba vòng "không, phải như thế này" mang lại kết quả tốt hơn, nhanh hơn về thời gian thực tế, so với một bản tóm tắt đầy đủ chi tiết ngay từ đầu — dù việc viết bản tóm tắt đó có cảm giác hiệu quả hơn trong lúc làm.
Những chỉnh sửa bằng ngôn ngữ thông thường thực sự hiệu quả thường ngắn gọn:
- "Bỏ blog, thêm trang giá" — hoán đổi danh sách trang một cách gọn gàng.
- "Đổi thành hai người chơi thay vì một người chơi" — lớn hơn nhiều so với vẻ ngoài của nó. Điều này có thể tác động đến mô hình dữ liệu, giờ theo dõi hai người tham gia thay vì một, và kế hoạch sửa đổi sẽ thể hiện tác động dây chuyền đó thay vì che giấu nó.
- "Cái này cần tài khoản người dùng" — nếu kế hoạch hiện tại là trang tĩnh, đây là câu buộc phải đối mặt trực tiếp với câu hỏi về loại sản phẩm.
Sai lầm ba: coi loại sản phẩm là một trường mềm
Đây là sai lầm tốn kém nhất, và nó tốn kém vì mọi thứ khác trên thẻ đều thực sự có thể khắc phục được. Trang, tính năng được suy luận, hầu hết các nhánh câu hỏi — tất cả đều có thể sửa bằng một lần cập nhật phiên bản sau khi bản dựng hoàn tất. Loại sản phẩm thì không. Có bốn nhóm:
| Loại sản phẩm | Nghĩa là gì |
|---|---|
| Trang tĩnh | Đơn giản, không có logic phía máy chủ. |
| Ứng dụng có thể cài đặt | Kiểu PWA — hoạt động ngoại tuyến, có thể thêm vào màn hình chính, vẫn không có logic phía máy chủ. |
| Bản build theo framework | Kiểu React/Next, tương tác phía client nặng hơn, vẫn không có backend lưu trữ liên tục. |
| Ứng dụng có backend | Loại duy nhất trong bốn loại có cơ sở dữ liệu thực sự và hệ thống tài khoản đứng sau. |
Phê duyệt một kế hoạch trang tĩnh, rồi ba phiên bản sau quyết định muốn có đăng nhập, đó không phải là nâng cấp phiên bản — đó là xây lại từ một loại sản phẩm khác, và bạn mất đi tính liên tục mà lịch sử phiên bản mang lại cho mọi thứ khác.
Mọi người thường sai theo hai cách. Thứ nhất, họ không đối chiếu prompt của mình với thực tế — nếu prompt của bạn có "tài khoản," "đăng nhập," "lưu," "bảng điều khiển cập nhật liên tục," "thanh toán," hoặc "nhiều người dùng cùng chỉnh sửa một thứ," mà thẻ lại không ghi là server-backed, thì đó chính là điểm đáng sửa duy nhất trước khi bạn phê duyệt, không có ngoại lệ. Thứ hai, họ nhầm lẫn giữa ứng dụng có thể cài đặt với bản dựng framework, vì cả hai đều giống như "một ứng dụng" trong cách nói thông thường. Chúng không thể thay thế cho nhau: ứng dụng có thể cài đặt phù hợp với công cụ mà toàn bộ trạng thái nằm trên thiết bị người dùng — máy tính tính tiền boa, đồng hồ bấm giờ tập luyện. Bản dựng framework nghĩa là tương tác và cấu trúc component nhiều hơn nhưng vẫn không có gì lưu trữ phía server xuyên suốt các phiên hoặc thiết bị. Không cái nào là "một ứng dụng" theo nghĩa có tài khoản và dữ liệu đi theo bạn trên mọi thiết bị — chỉ server-backed mới đúng nghĩa đó. Và việc chọn dư thừa lên server-backed "cho chắc" đối với một trang portfolio hay trang tài liệu cũng không phải lựa chọn an toàn — hạ cấp sau này cũng tốn công dựng lại chẳng khác gì nâng cấp.
Còn lại gì sau khi bạn ngừng làm ba điều đó
Một khi bạn không còn lướt qua dòng loại sản phẩm, không còn viết đặc tả ở bước lập kế hoạch, và không còn coi ngôn ngữ về tài khoản/dữ liệu/thanh toán trong lời nhắc của chính mình là có thể thương lượng, những gì còn lại là một kiểm tra nhanh, gọn:
- Đọc loại sản phẩm.
- Đối chiếu với lời nhắc của bạn.
- Lướt qua danh sách tính năng được suy luận để xem có gì bạn sẽ loại bỏ ngay lập tức không.
Danh sách này tồn tại chính xác vì một lời nhắc như "công cụ đặt lịch cho tiệm làm tóc" sẽ kéo theo những thứ bạn không hề gõ ra — lịch dạng calendar và nhắc nhở qua SMS và danh sách khách hàng, một số bạn có ý muốn và một số là hiện tượng phình phạm vi mà mô hình thêm vào vì các tính năng đó thường đi kèm nhau về mặt thống kê. Hãy cắt bỏ những gì không thuộc về ở đây, bằng một câu, thay vì sau khi đã xây xong.
Mọi thứ khác — nội dung câu chữ, khoảng cách, sắc độ màu nhấn, nút ghi "Bắt đầu ngay" hay "Dùng thử miễn phí" — hoàn toàn không có trên thẻ, một cách có chủ đích. Những thứ đó rẻ để xem và sửa trên một bản dựng đang chạy, nên thẻ không lãng phí sự chú ý của bạn vào chúng, và bạn cũng không nên. Đó có lẽ là mười lăm giây phán đoán thực sự trong ba mươi giây cần để đọc nó.
