Mục lục bài viết7 mục
Khi một yêu cầu bị làm sai, phản xạ thường là nghĩ bên kia không hiểu chuyên môn. Thực tế phần lớn trường hợp là bản mô tả thiếu một thông tin mà người viết tưởng ai cũng biết. Bài này liệt kê sáu sai lầm theo tần suất thật, cách sửa từng cái, và một quy tắc chung áp được cho mọi yêu cầu.
Vì sao khoảng cách này tồn tại
Người làm SEO và developer nhìn cùng một website bằng hai bản đồ khác nhau. Một bên nghĩ theo mẫu trang và loại nội dung, bên kia nghĩ theo thành phần giao diện và tầng dữ liệu.
Cùng một câu nói vì vậy chỉ về hai thứ khác nhau. Khi bạn nói trang sản phẩm, bạn hình dung một nhóm URL có chung mục đích. Developer hình dung một tệp mẫu trong mã nguồn, và tệp đó có thể đang phục vụ cả những trang bạn không nghĩ tới.
Khoảng cách thứ hai là về mức độ chắc chắn. Nghề SEO quen sống với các kết luận dạng thường thì và tùy trường hợp. Nghề phát triển phần mềm cần điều kiện rõ ràng để viết mã. Khi bạn nói nên có, developer không biết đó là bắt buộc hay tùy chọn.
Khoảng cách thứ ba là về thời gian. Bạn biết kết quả của thay đổi này sẽ thấy sau vài tuần. Nếu không nói ra, developer mặc định làm xong là xong, và không ai theo dõi phần sau đó.
Sáu sai lầm dưới đây đều bắt nguồn từ ba khoảng cách này.
Mô tả bằng thuật ngữ mà developer không dùng
Các cụm như phân bổ sức mạnh trang, ngân sách thu thập, tín hiệu chủ đề, ăn thịt từ khóa không có nghĩa rõ với người ngoài nghề. Tệ hơn, chúng nghe như có nghĩa nên không ai hỏi lại.
Cách sửa là dịch mỗi thuật ngữ thành một hành vi quan sát được. Thay vì nói cần dồn sức mạnh về trang danh mục, nói cần mọi trang sản phẩm có một liên kết trỏ về trang danh mục cha, đặt trong phần đường dẫn phân cấp.
Phép thử nhanh: đọc lại yêu cầu và tự hỏi câu này có kiểm được bằng một thao tác cụ thể không. Không kiểm được nghĩa là nó chưa nói gì với người sẽ làm.
Sai lầm hai: không nêu phạm vi
Yêu cầu thêm thẻ canonical nghe rõ ràng cho tới khi developer hỏi thêm cho trang nào. Trang sản phẩm có, trang danh mục có không, trang lọc theo màu thì sao, trang phân trang thứ hai trở đi thì sao.
Mỗi câu hỏi không được trả lời trước là một chỗ để developer tự quyết, và họ sẽ quyết theo cách hợp lý với kiến trúc mã chứ không theo mục đích của bạn.
Cách sửa là luôn viết hai danh sách: mẫu trang trong phạm vi và mẫu trang cố ý để ngoài. Danh sách thứ hai quan trọng ngang danh sách thứ nhất, vì nó ngăn việc mở rộng ngoài ý muốn và cũng cho developer biết bạn đã nghĩ tới chúng.
Sai lầm ba: nói việc cần làm thay vì kết quả cần đạt
Khi bạn chỉ định cách làm, bạn loại bỏ các phương án tốt hơn mà developer biết còn bạn thì không. Bạn cũng nhận về mình trách nhiệm cho một quyết định kỹ thuật mà bạn không đủ thông tin để ra.
Cách sửa là mô tả trạng thái đúng sau khi làm xong, để bên kia chọn đường. Thay vì nói thêm một đoạn mã vào tệp mẫu để sinh thẻ, nói mỗi trang thuộc mẫu này xuất đúng một thẻ với giá trị là địa chỉ của chính nó.
Có một nhóm ngoại lệ: các lựa chọn kỹ thuật mà bản thân lựa chọn đó đã là kết quả, chẳng hạn loại chuyển hướng hay mã trạng thái trả về. Với nhóm này, hãy nêu chúng như một điều kiện phải thỏa mãn, đừng nêu như một chỉ dẫn cách viết mã.
Không nói lý do nên developer không phát hiện xung đột
Đây là sai lầm gây thiệt hại âm thầm nhất. Khi developer không biết vấn đề gốc, họ làm đúng chữ mà không phát hiện được các trường hợp yêu cầu của bạn xung đột với kiến trúc hiện có.
Ví dụ điển hình: bạn yêu cầu thẻ canonical trỏ về chính trang đó. Developer làm đúng. Nhưng hệ thống đang sinh ba địa chỉ khác nhau cho cùng một sản phẩm tùy đường vào, nên mỗi địa chỉ giờ trỏ về chính nó, và bạn vẫn có ba trang cạnh tranh nhau. Nếu biết lý do, developer đã hỏi lại ngay.
Cách sửa là thêm hai tới ba câu nêu vấn đề đang gặp và hậu quả nếu không sửa. Phần này ngắn nhưng nó biến người thực hiện thành người cùng giải bài toán.
Sai lầm năm và sáu
Sai lầm thứ năm là không thống nhất cách kiểm trước khi bắt đầu. Bạn kiểm bằng xem mã nguồn gốc, developer kiểm bằng công cụ dành cho nhà phát triển vốn hiển thị bản đã render. Hai bên nhìn hai thứ khác nhau và cùng tin mình đúng.
Cách sửa là ghi rõ trong yêu cầu bạn sẽ kiểm bằng công cụ nào, thao tác gì, trên bao nhiêu trang mẫu. Việc này còn giúp developer tự kiểm trước khi bàn giao, cắt được một vòng qua lại.
Sai lầm thứ sáu là gộp nhiều yêu cầu độc lập vào một. Khi một phần bị chặn vì lý do kỹ thuật, cả gói dừng lại. Khi số liệu biến động sau đó, bạn không biết thay đổi nào gây ra điều gì.
Cách sửa là tách theo nguyên tắc mỗi yêu cầu một mục tiêu kiểm được. Nếu bạn không viết được điều kiện nghiệm thu trong bốn dòng, đó là dấu hiệu cần tách.
Quy tắc chung áp cho mọi yêu cầu
Trước khi gửi, đọc lại bản mô tả và trả lời ba câu. Nếu có câu nào không trả lời được, yêu cầu chưa sẵn sàng.
Câu thứ nhất: một người không làm nghề SEO đọc xong có biết kết quả đúng trông như thế nào không.
Câu thứ hai: có thao tác cụ thể nào để kiểm đúng hoặc sai, và cả hai bên có cùng làm được thao tác đó không.
Câu thứ ba: nếu developer đề xuất một cách làm khác, bạn có đủ thông tin trong bản mô tả để đánh giá cách đó có đạt mục tiêu không.
Ba câu này mất khoảng hai phút và chúng bắt được phần lớn sáu sai lầm ở trên.
Một việc nữa nên làm ở cấp quy trình: sau mỗi lần nghiệm thu, ghi lại chỗ nào bị hiểu khác đi và vì sao. Sau vài tháng, danh sách đó cho bạn biết khoảng cách giữa hai bên nằm ở đâu, và nó thường tập trung vào hai hoặc ba loại thuật ngữ chứ không rải đều.
=== FAQ === Q: Nên viết yêu cầu bằng ngôn ngữ kỹ thuật đến mức nào? A: Đủ để kiểm được là đủ, không cần chỉ định cách triển khai, và nếu bạn không chắc về thuật ngữ kỹ thuật thì mô tả bằng hành vi quan sát được sẽ an toàn hơn là dùng sai từ. Q: Có nên ngồi cùng developer khi họ làm không? A: Không cần ngồi cùng, nhưng một cuộc trao đổi mười lăm phút trước khi bắt đầu thường lộ ra vài chỗ xung đột với kiến trúc hiện tại, và sửa lúc đó rẻ hơn nhiều so với sửa sau. Q: Làm sao thuyết phục ưu tiên khi hàng đợi phát triển đã đầy? A: Nêu hậu quả bằng đơn vị mà người xếp ưu tiên quan tâm, ví dụ số trang đang không được ghi nhận hoặc số khách hàng tiềm năng bị ảnh hưởng, thay vì nêu bằng thuật ngữ chuyên môn.
Phần lớn khoảng cách giữa hai bên đóng lại được bằng cách viết rõ kết quả cần đạt và cách kiểm, chứ không cần bên kia học thêm chuyên môn. Nên áp ba câu hỏi ở phần cuối cho yêu cầu gần nhất bạn sắp gửi, vì chúng mất hai phút và thường lộ ra ngay chỗ mà chính bạn cũng chưa nói rõ.
