Mục lục bài viết6 mục
Hai mô hình này thường được trình bày như một lựa chọn về triết lý, trong khi nó là một lựa chọn về chi phí và về nút thắt. Bài này so sánh theo bốn tiêu chí đo được, chỉ ra ba điều kiện đảo chiều, và đưa mô hình lai mà phần lớn đội nên dùng.
Hai mô hình bố trí SEO review và khác biệt thật
Mô hình thứ nhất là chèn một bước SEO review vào quy trình phát triển, thường đặt ở giai đoạn thiết kế và một lần nữa trước khi phát hành. Ai đó phải xem và duyệt trước khi tính năng đi tiếp.
Mô hình thứ hai là để đội phát triển làm theo cách của họ, rồi đội marketing rà và đề xuất sửa sau khi tính năng đã ra mắt.
Khác biệt thật không nằm ở chỗ mô hình nào đúng hơn, mà nằm ở hai thứ: chi phí sửa và ai là nút thắt.
Mô hình một bắt lỗi khi sửa còn rẻ, nhưng nó tạo ra một người phải duyệt, và người đó thành nút thắt khi số tính năng tăng lên.
Mô hình hai không có nút thắt, nhưng mọi thứ bắt được đều đã ở giai đoạn sửa đắt, và phần lớn trong số đó sẽ không bao giờ được xếp vào hàng đợi vì luôn có việc mới quan trọng hơn.
So theo bốn tiêu chí
Tiêu chí một là tỷ lệ vấn đề được sửa thật, và mô hình có SEO review thắng rõ. Khi bước SEO review nằm trong quy trình, vấn đề được xử lý ngay trong cùng đợt phát triển. Trong mô hình hai, các đề xuất sau khi ra mắt cạnh tranh với tính năng mới trong hàng đợi, và phần lớn thua.
Tiêu chí hai là chi phí trên mỗi vấn đề. Mô hình một thắng, vì sửa ở giai đoạn thiết kế tốn một dòng trong tài liệu còn sửa sau khi ra mắt tốn cả một chu kỳ gồm viết mã, chuyển hướng, kiểm và theo dõi.
Tiêu chí ba là tốc độ phát hành. Mô hình hai thắng. Không có bước duyệt nào nghĩa là không có gì làm chậm.
Tiêu chí bốn là khả năng mở rộng. Mô hình hai thắng ở quy mô lớn, vì mô hình một cần một người có chuyên môn đọc mọi thứ, và người đó không nhân bản được.
Cộng bốn tiêu chí, không mô hình nào thắng hẳn, và đó chính là lý do mô hình lai ở phần sau tồn tại.
Ba điều kiện đảo chiều kết luận
Điều kiện thứ nhất là tần suất phát hành. Đội phát hành mỗi quý một lần chịu được một bước SEO review đầy đủ. Đội phát hành mỗi ngày thì không, và ép mô hình một lên họ sẽ dẫn tới việc bước duyệt bị bỏ qua trong thực tế dù vẫn tồn tại trên giấy.
Điều kiện thứ hai là tỷ trọng lưu lượng tự nhiên trong tổng lưu lượng. Với website mà phần lớn khách đến từ tìm kiếm, chi phí của một lỗi lọt ra rất cao và mô hình một đáng giá. Với sản phẩm mà người dùng vào thẳng qua ứng dụng, chi phí đó thấp hơn nhiều.
Điều kiện thứ ba là mức độ ổn định của kiến trúc. Nếu đội đang dựng nền tảng mới và cấu trúc đường dẫn còn thay đổi liên tục, một bước SEO review sớm có giá trị cao. Nếu kiến trúc đã ổn định nhiều năm và tính năng mới chỉ thêm màn hình vào khuôn có sẵn, phần lớn quyết định rủi ro đã được chốt từ lâu.
Ba điều kiện này nên được trả lời trước khi chọn mô hình, vì chúng đổi kết luận hoàn toàn.
Mô hình lai, phân tầng SEO review theo rủi ro
Mô hình lai giữ ưu điểm của cả hai bằng cách phân tầng theo rủi ro thay vì áp một cách cho mọi tính năng.
Tầng một là tự kiểm bằng danh sách. Mọi tính năng đều đi qua tầng này. Người viết tài liệu trả lời bốn câu hỏi ngắn về việc tính năng có sinh trang công khai không, đường dẫn theo cấu trúc nào, nội dung có trong mã nguồn từ máy chủ không, và có đường vào từ liên kết nội bộ không. Không cần chuyên môn tìm kiếm để trả lời, và nó mất khoảng mười phút.
Tầng hai là SEO review đầy đủ, chỉ áp cho nhóm tính năng có câu trả lời đầu tiên là có. Với phần lớn đội, nhóm này chiếm khoảng một phần ba số tính năng, nên khối lượng đọc giảm đáng kể.
Tầng ba là rà sau khi ra mắt, chạy theo lịch cố định mỗi quý cho toàn bộ những gì đã phát hành, không phải cho từng tính năng. Tầng này bắt các thứ lọt qua hai tầng trên.
Điểm mấu chốt của mô hình lai là tầng một do chính đội sản phẩm làm, không do người làm SEO làm. Nếu tầng một cũng cần người có chuyên môn thì nút thắt quay lại và mô hình lai mất ưu điểm.
Cách triển khai mà không tạo đối kháng
Bước một là bắt đầu bằng đọc và góp ý, không bằng quyền chặn. Trong ba tháng đầu, người làm SEO đọc tài liệu và để lại nhận xét, nhưng không ai bị chặn phát hành vì chưa duyệt. Cách này cho bạn dữ liệu về việc bước SEO review bắt được những gì mà không tạo ra kháng cự.
Bước hai là sau ba tháng, tổng hợp lại: đã bắt được bao nhiêu vấn đề, và nếu chúng lọt ra thì chi phí sửa ước tính bao nhiêu ngày công. Đây là con số để đề xuất siết chặt hơn.
Bước ba là chỉ siết ở đúng nhóm rủi ro cao. Đừng đòi quyền chặn cho mọi tính năng, hãy đòi cho nhóm sinh trang công khai mới hoặc nhóm đổi cấu trúc đường dẫn.
Bước bốn là đo chính bước duyệt. Ghi thời gian trung bình một tài liệu nằm chờ. Nếu con số này vượt hai ngày, bước SEO review đang là nút thắt và cần chuyển bớt việc xuống tầng tự kiểm.
Sai lầm hay gặp ở cả hai mô hình
Sai lầm thứ nhất là đòi quyền chặn ngay từ đầu. Việc này tạo đối kháng và thường dẫn tới việc bước duyệt bị lách bằng cách phát hành gấp.
Sai lầm thứ hai là áp SEO review cho mọi tính năng bất kể mức rủi ro. Đọc tài liệu của một tính năng nằm hoàn toàn sau đăng nhập là lãng phí thời gian của cả hai bên, và nó làm giảm mức độ nghiêm túc với các lần thật sự cần.
Sai lầm thứ ba là ở mô hình hai, gửi một danh sách dài đề xuất sau khi ra mắt. Danh sách dài không được xếp ưu tiên. Gửi một hoặc hai việc kèm ước tính tác động thì có cơ hội được làm.
Sai lầm thứ tư là không đo gì cả. Không có số liệu về việc bước duyệt bắt được gì thì mọi cuộc thảo luận về quy trình đều dựa trên cảm giác, và bên có tiếng nói to hơn sẽ thắng.
=== FAQ === Q: Đội nhỏ dưới mười người thì nên chọn mô hình nào? A: Mô hình lai với tầng một thật nhẹ là hợp lý, vì ở quy mô đó người viết tài liệu và người phát triển thường ngồi cạnh nhau nên bốn câu hỏi giải quyết được phần lớn vấn đề. Q: Nếu không có ai chuyên trách SEO trong công ty thì sao? A: Vẫn áp được tầng một vì nó không đòi chuyên môn, còn tầng hai thì thuê ngoài theo đợt, tập trung vào các tính năng lớn thay vì mọi tính năng. Q: Bước duyệt nên nằm ở giai đoạn nào của quy trình? A: Giai đoạn thiết kế là nơi có giá trị cao nhất vì các quyết định về đường dẫn và cách dựng trang được chốt ở đó, còn kiểm trước khi phát hành chỉ bắt được lỗi triển khai.
Chọn đúng mô hình phụ thuộc vào tần suất phát hành và tỷ trọng lưu lượng tự nhiên, không phụ thuộc vào việc mô hình nào nghe bài bản hơn. Nên chạy ba tháng ở chế độ đọc và góp ý trước khi đề xuất bất kỳ quyền chặn nào, vì dữ liệu thu được trong ba tháng đó là lập luận thuyết phục nhất bạn có.
