Sai lầm một: mô tả đích đến bằng sai đơn vị
Phần lớn các vòng bị lãng phí trong cuộc trò chuyện build đến từ việc nhắm sai "độ cao", và điều này xảy ra theo hai hướng ngược nhau. Một số người yêu cầu ít hơn ý họ muốn — "cải thiện thiết kế", "làm cho nó tốt hơn", "cái này chưa ổn". Mỗi câu như vậy là một chẩn đoán không có mục tiêu, nên phiên bản tiếp theo chỉ là một phỏng đoán: có thể làm tối phần đầu trang, có thể đổi font chữ, có thể sắp xếp lại thanh điều hướng, và bạn sẽ không biết lý do cho đến khi nhìn kết quả và tự hỏi chuyện gì đã xảy ra. Những người khác lại làm quá và yêu cầu nhiều hơn mức cần thiết — họ nêu tên cookie phiên, hay CSS grid, hay một component skeleton loading, vì họ biết chút ít và muốn giúp ích. Sai lầm đó âm thầm hơn nhưng tốn kém không kém. Ngay khi bạn chỉ định cách triển khai, thường là bạn đã chỉ định sai, hoặc tốt nhất cũng chỉ thu hẹp không gian giải pháp xuống còn những gì cá nhân bạn đã biết — điều mà, trừ khi bạn là một lập trình viên chuyên nghiệp, hẹp hơn nhiều so với những gì công cụ build có thể tự thử. Và nếu thư viện hay mẫu bạn nêu tên hóa ra là lựa chọn sai, thì đó giờ trở thành lỗi do bạn tạo ra, một lỗi mà công cụ build sẽ không bao giờ mắc phải nếu làm việc dựa trên kết quả mong muốn thay vì cách triển khai.
Cách khắc phục nằm giữa hai kiểu sai lầm đó: hãy nêu tên thứ bạn đang nhìn vào và sự thay đổi bạn muốn thấy, chứ không phải cơ chế tạo ra nó. "Khách truy cập nên có thể đặt chỗ mà không cần tạo tài khoản" tốt hơn nhiều so với một đoạn văn về cookie phiên, vì điều bạn thực sự muốn là loại bỏ sự vướng víu, và có lẽ có ba cách để đạt được điều đó mà bạn chưa từng nghĩ tới. "Bảng giá gây khó hiểu" vẫn còn quá mơ hồ — khó hiểu ở chỗ nào? — nhưng "mọi người không thấy được gói năm tiết kiệm tiền, hãy đặt phần giảm giá cạnh giá thay vì giấu trong phần chữ nhỏ" cho công cụ build một thứ cụ thể để làm việc. Nếu bạn không biết bản sửa nên trông như thế nào, cũng không sao — hãy nói cái gì sai và để nó đề xuất hình dạng. Điều không hiệu quả là sự không hài lòng mơ hồ không có điểm neo, vì điều đó biến mỗi phiên bản tiếp theo thành một trò đoán mò.
| Thay vì… | Hãy nói… |
|---|---|
| "Cải thiện nó" | "Chữ ở phần hero khó đọc trên ảnh nền — hãy tăng độ tương phản" |
| "Sửa cảm giác chơi game" | "Cú nhảy lơ lửng quá lâu; hãy làm nó gọn gàng hơn" |
| "Thêm xác thực kiểu nào đó" | "Người chơi cần tài khoản để điểm số được lưu lại" |
| "Làm cho nhanh hơn" | "Trang thư viện ảnh mất một lúc để tải ảnh — hiển thị placeholder thay vì màn hình trắng" |
| "Phần này tệ" | "Phần đánh giá của khách hàng trông như một ý tưởng thêm vào sau — hãy cho nó tầm quan trọng ngang với phần bảng giá" |
Sai lầm hai: phản ứng với một phiên bản thay vì nhìn vào nó
Cách thứ hai khiến người dùng tự làm khó mình là trả lời phần tóm tắt thay đổi của cuộc trò chuyện thay vì bản thân sự thay đổi. Ai đó đọc "đã chuyển lịch trình sang trang riêng và làm tối phần đầu trang", hình dung ra một bức tranh trong đầu, rồi viết phản hồi dựa trên bức tranh đó thay vì trang web thực tế. Hầu hết các phàn nàn kiểu "cái này làm sai rồi" hóa ra là "tôi chưa mở bản xem trước" — kết quả thực ra ổn, hoặc gần ổn, và sự phản đối thực chất là về một giả định. Chỉ mất khoảng ba mươi giây để nhấp qua xem trước rồi mới gõ phản hồi, và bỏ qua bước đó là nguồn lãng phí vòng lặp lớn nhất lẽ ra không nên tồn tại. Kể cả khi đang xem lại từ điện thoại trong một cuộc họp, hãy liếc qua bản xem trước trước tiên — phản hồi dựa trên mô tả của một mô tả sẽ khiến sai số cộng dồn rất nhanh.
Sai lầm liên quan là gộp các yêu cầu không liên quan vào một tin nhắn và mất khả năng xác định điều gì gây ra điều gì. Bạn hoàn toàn có thể gộp nhiều yêu cầu và nhận tất cả trong một phiên bản mới — một bản build sửa phần đầu trang, di chuyển lịch trình và thu gọn thanh điều hướng trên di động trong một lượt sẽ dễ xem lại hơn ba bản khác biệt riêng lẻ, vì bạn đang đánh giá một trạng thái nhất quán của trang web thay vì ba thay đổi so với một mục tiêu đang di chuyển. Vấn đề bắt đầu khi các yêu cầu không liên quan với nhau. Gộp việc đại tu trang lịch trình với thay đổi màu sắc toàn cục, và nếu có gì đó về kết quả cảm thấy không ổn, bạn thực sự không thể biết thay đổi nào gây ra nó — trang khó đọc là do bố cục mới hay do bảng màu mới? Gỡ rối điều đó tốn thêm một tin nhắn theo dõi và cả một vòng nữa chỉ để cô lập biến số. Hãy giữ "mọi thứ về trang lịch trình" trong một tin nhắn và "hướng màu sắc" trong tin nhắn tiếp theo, dù không có gì cấm bạn kết hợp chúng; mỗi phiên bản vẫn giữ được sự so sánh rõ ràng, và bạn có thể hoàn tác hoặc điều chỉnh đúng một thứ cần sửa thay vì bỏ đi một phiên bản vốn tốt chỉ vì một phần bị lệch.
Sai lầm ba: coi mỗi phiên bản là dùng một lần rồi bỏ
Sai lầm thứ ba là quên rằng một thẻ phiên bản không phải là biên lai, mà là một đối tượng làm việc, và bỏ qua những gì nó thực sự mang lại. Mỗi vòng hoàn thành tạo ra một thẻ với Xem trước trực tiếp — một phiên bản đang chạy thật sự, không phải ảnh chụp màn hình, nên nhấp vào một nút trong đó sẽ hoạt động đúng như khi nhấp vào nó ở môi trường thực tế. Có một tab Mã nguồn để duyệt mọi tệp đã thay đổi, điều này quan trọng nếu bạn đủ am hiểu kỹ thuật để kiểm tra nhanh một điều cụ thể nào đó (biểu mẫu này có thực sự gửi đến đúng endpoint không?) mà không cần chờ phản hồi trò chuyện để xác nhận. Tải xuống cho bạn các tệp gốc. Và menu hành động là nơi một phiên bản không còn là bản nháp nữa: xuất bản trực tiếp, tạo trình cài đặt gốc nếu đó là một ứng dụng, gửi lên cửa hàng ứng dụng, lưu toàn bộ thành mẫu cho các bản build sau này, hoặc triển khai độc lập.
Những người bỏ qua tất cả những điều này rốt cuộc phải cố nhớ xem nút có màu xanh trong phiên bản cũ hay không, thay vì chỉ cần mở phiên bản cũ ra và nhìn — vì hậu quả của việc coi thẻ phiên bản là dùng một lần rồi bỏ chính là như vậy: dựa vào trí nhớ cho một thứ vẫn nằm cách một cú nhấp chuột. Phiên bản 4 không bị lưu trữ hay đóng băng khi phiên bản 7 ra mắt. Bản xem trước của nó vẫn chạy, tab mã nguồn của nó vẫn duyệt được, menu hành động của nó vẫn hoạt động, mãi mãi. So sánh hai phiên bản không phải là việc đọc bản khác biệt, mà là mở cả hai bản xem trước cạnh nhau và nhấp thử từng cái. Thẻ cũng mang theo hồ sơ xác minh của bản build — vòng kiểm tra tự động xác nhận nó thực sự hoạt động trước khi được bàn giao cho bạn dưới dạng hoàn tất — gắn liền với phiên bản cụ thể đó, đây cũng là lý do tại sao việc giữ các thẻ cũ hoạt động lại quan trọng: nếu phiên bản 6 xác minh sạch và phiên bản 7 thì không, bạn có cả hai để so sánh thay vì một tin nhắn trò chuyện nói "đã sửa xong" mà bạn phải tin tưởng suông.
Cùng một xu hướng — coi quy trình làm việc là thứ để lướt qua thay vì sử dụng — cũng thể hiện ở việc bỏ qua các đề xuất tiếp theo mà cuộc trò chuyện đưa ra sau mỗi bản build. Chúng không phải nội dung lấp chỗ trống chung chung; chúng được rút ra từ chính bản build, nên chúng có xu hướng bắt được những thứ bạn sẽ bỏ lỡ khi tự kiểm tra: một trạng thái trống không ai thiết kế, một biểu mẫu không xác nhận việc gửi, một trang ổn trên desktop nhưng chật chội trên di động. Việc áp dụng chúng không bắt buộc, nhưng lướt qua chúng không tốn gì cả, và chúng là một sự thay thế hợp lý cho một vòng kiểm tra chất lượng (QA) nếu bạn không có thời gian tự nhấp qua từng trang.
