Quản lý dự án SEO: đưa kế hoạch đã duyệt thành việc được thực thi và nghiệm thu
Dịch vụ quản lý dự án SEO của RED: bản đồ luồng công việc, sổ phân quyền quyết định, bảng phụ thuộc, định nghĩa hoàn thành theo loại việc và nhật ký thay đổi.
Một chiến lược SEO đúng vẫn có thể không tạo ra kết quả nào trong mười hai tháng. Không phải vì phân tích sai, mà vì mười hai tháng đó trôi qua như sau: hạng mục kỹ thuật nằm trong hàng chờ của đội phát triển vì không ai đủ thẩm quyền đẩy ưu tiên; bài viết bị kẹt ba tuần ở khâu duyệt pháp chế mà không ai biết đang chờ ai; một lần phát hành làm mất thẻ canonical trên toàn bộ trang danh mục và ba tuần sau mới có người phát hiện; và mỗi cuộc họp hàng tháng đều dành bốn mươi phút để đọc lại bảng số liệu rồi kết thúc mà không ra quyết định nào.
Thảo luận trong ngành năm 2026 nhiều lần chỉ ra rằng phần lớn thất bại của các chương trình SEO ở quy mô lớn có nguồn gốc tổ chức chứ không phải kỹ thuật: quyền quyết định không rõ, quyền sở hữu không xác định, quy trình không có. Cùng dòng thảo luận đó nhấn mạnh nhu cầu duy trì nhật ký thay đổi cho các website lớn, vì nhiều nhóm khác nhau có thể đẩy thay đổi lên website mà không ai trong số họ biết tác động tới tìm kiếm.
Trang này mô tả phạm vi dịch vụ quản lý dự án SEO của RED. Đây không phải dịch vụ vận hành một bảng công việc — giá trị không nằm ở công cụ mà ở quyền quyết định được xác định rõ, phụ thuộc được nhìn thấy trước khi thành điểm nghẽn, thay đổi trên website được ghi lại, và mỗi việc chỉ được đóng khi có bằng chứng trên môi trường thật.
Ranh giới đặt trước: RED không nhận quyền quyết định mà RED không có, và không cam kết thời hạn cho những việc phụ thuộc vào các bên nằm ngoài phạm vi kiểm soát của RED.
Lập bản đồ luồng công việc trước khi mở bảng công việc
Câu hỏi đầu tiên: chương trình này gồm những luồng công việc nào, và chúng phụ thuộc nhau ra sao?
Việc mở một bảng công việc rồi bắt đầu đổ nhiệm vụ vào là cách khởi động nhanh nhất và cũng là cách tạo ra hỗn loạn nhanh nhất. Sau vài tuần, bảng có tám mươi nhiệm vụ không nhóm được, không thấy được cái nào chặn cái nào, và không trả lời được câu hỏi cơ bản: mỗi nhiệm vụ này phục vụ mục tiêu nào.
Cấu trúc đúng đi từ trên xuống: kế hoạch đã duyệt chia thành các luồng công việc, mỗi luồng có một người sở hữu, mỗi nhiệm vụ thuộc về một luồng và gắn với một kết quả cụ thể.
Bản đồ luồng công việc của chương trình SEO
| Luồng | Nội dung công việc | Chủ sở hữu điển hình | Phụ thuộc chính |
|---|---|---|---|
| Kỹ thuật | Cơ chế crawl, lập chỉ mục, canonical, cấu trúc URL, hiệu năng | Kỹ thuật SEO phối hợp đội phát triển | Lịch phát hành, năng lực đội phát triển |
| Nội dung | Sản xuất, cập nhật, gộp và loại bỏ nội dung | Trưởng nhóm nội dung | Chuyên gia lĩnh vực, duyệt pháp chế và thương hiệu |
| Offpage và truyền thông | Xây quan hệ, chiến dịch, xử lý hồ sơ liên kết | Phụ trách truyền thông | Dữ liệu và người phát ngôn từ doanh nghiệp |
| Địa phương | Thông tin doanh nghiệp, trang theo khu vực | Phụ trách marketing vùng | Dữ liệu chi nhánh, đội vận hành |
| Đo lường | Cấu hình theo dõi, định nghĩa chỉ số, hệ báo cáo | Đội dữ liệu | Quyền truy cập hệ thống, đội phát triển |
| Phát hành và vận hành | Đưa thay đổi lên môi trường thật, kiểm soát chất lượng | Đội phát triển | Toàn bộ các luồng trên |
Luồng cuối cùng có đặc điểm riêng: nó là nút cổ chai chung của mọi luồng khác. Gần như mọi thay đổi — kỹ thuật, nội dung, đo lường — cuối cùng đều phải đi qua một lần phát hành. Khi lập kế hoạch, việc bỏ qua năng lực thực tế của luồng này là nguyên nhân phổ biến nhất khiến lộ trình trượt tiến độ ngay từ quý đầu.
Nguyên tắc: mỗi nhiệm vụ phải thuộc về một luồng và gắn với một kết quả mà kế hoạch đã duyệt nêu ra. Nhiệm vụ không thỏa mãn điều kiện này thường là việc xuất hiện từ một ý tưởng ngẫu hứng hoặc từ một cảnh báo của công cụ, và nó cạnh tranh nguồn lực với những việc thực sự quan trọng.
Ranh giới phạm vi: việc chọn luồng nào được đầu tư bao nhiêu thuộc tư vấn chiến lược SEO. Quản lý dự án nhận danh mục đã được duyệt và vận hành nó, không tự thay đổi hướng đầu tư.
Quyền quyết định phải được xác định bằng tên người
Câu hỏi: ai duyệt việc đổi URL, ai duyệt nội dung, ai duyệt quy tắc chuyển hướng, ai duyệt dữ liệu có cấu trúc, ai duyệt phát hành?
Trong nhiều tổ chức, câu trả lời cho từng câu là "tùy trường hợp" — và chính sự mơ hồ đó tạo ra phần lớn độ trễ. Một thay đổi nhỏ về cấu trúc URL có thể nằm chờ hai tuần vì không ai chắc mình có quyền đồng ý, và không ai muốn là người quyết định sai.
Sổ phân quyền quyết định
| Loại quyết định | Người thực hiện | Người chịu trách nhiệm cuối | Cần tham vấn | Cần thông báo |
|---|---|---|---|---|
| Thay đổi cấu trúc URL | Đội phát triển | Chủ sở hữu sản phẩm hoặc website | Kỹ thuật SEO, đội nội dung | Toàn bộ các luồng |
| Quy tắc chuyển hướng | Đội phát triển | Kỹ thuật SEO | Đội phát triển | Đội đo lường |
| Xuất bản và sửa nội dung | Đội nội dung | Trưởng nhóm nội dung | Chuyên gia lĩnh vực, pháp chế nếu cần | Kỹ thuật SEO |
| Gỡ hoặc gộp nội dung | Đội nội dung | Chủ sở hữu chương trình | Kỹ thuật SEO, đội bán hàng | Ban lãnh đạo nếu quy mô lớn |
| Dữ liệu có cấu trúc | Đội phát triển | Kỹ thuật SEO | Pháp chế nếu liên quan tới tuyên bố | — |
| Thẻ robots và robots.txt | Đội phát triển | Kỹ thuật SEO | — | Toàn bộ các luồng |
| Lịch phát hành | Đội phát triển | Quản lý kỹ thuật | Quản lý dự án SEO | Toàn bộ các luồng |
| Nội dung truyền thông ra ngoài | Phụ trách truyền thông | Trưởng bộ phận marketing | Pháp chế, thương hiệu | Ban lãnh đạo |
| Cấu hình đo lường | Đội dữ liệu | Trưởng bộ phận marketing | Kỹ thuật SEO | Toàn bộ các luồng |
| Thay đổi ngân sách hoặc phạm vi | — | Người ký ngân sách | Quản lý dự án SEO | Toàn bộ các luồng |
Bảng này chỉ có giá trị khi mỗi ô chứa tên người cụ thể, không phải tên phòng ban. "Phòng marketing duyệt" là câu không dẫn tới hành động; "chị A duyệt, khi chị A vắng thì anh B" thì có.
Đường leo thang khi bế tắc
Cần định nghĩa trước, không ứng biến khi xảy ra. Nội dung tối thiểu: sau bao lâu một việc chờ duyệt được coi là bế tắc, ai là người tiếp theo trong chuỗi, và ai có quyền ra quyết định khi hai bên không đồng thuận.
Không có đường leo thang thì các bế tắc sẽ nằm im. Người quản lý dự án nhắc ba lần, không ai phản hồi, việc rơi xuống cuối bảng, và ba tháng sau không ai nhớ nó từng tồn tại.
Ranh giới của RED: RED không nhận quyền quyết định thay doanh nghiệp về những việc thuộc thẩm quyền doanh nghiệp — đổi cấu trúc URL, gỡ nội dung, thay đổi sản phẩm. RED đưa ra khuyến nghị kèm bằng chứng, làm rõ ai cần quyết định, và theo dõi để quyết định đó được đưa ra thay vì bị bỏ quên.
Bảng phụ thuộc ngăn việc bị chặn âm thầm
Câu hỏi: việc nào đang chờ việc khác, chờ ai, và đã chờ bao lâu?
Bị chặn không phải vấn đề. Bị chặn mà không ai biết mới là vấn đề. Trong các chương trình SEO, phần lớn độ trễ không đến từ việc thực thi chậm mà đến từ việc nằm chờ — chờ một bản thiết kế, chờ một trường dữ liệu, chờ một buổi duyệt, chờ một lần phát hành — và trạng thái chờ đó không hiển thị ở đâu cả.
Bảng phụ thuộc
| Trường | Nội dung | Nguyên tắc |
|---|---|---|
| Việc bị chặn | Tên việc và luồng của nó | Ghi cụ thể, không gộp nhóm |
| Đang chờ gì | Việc, tài liệu, quyết định hoặc dữ liệu cần có trước | Một dòng chờ một thứ |
| Người phụ trách phần chờ | Tên người ở phía cung cấp | Không ghi tên phòng ban |
| Ngày bắt đầu chờ | Ngày việc chuyển sang trạng thái chờ | Cơ sở để tính thời gian bế tắc |
| Mức tin cậy của thời điểm dự kiến | Cao, trung bình hay thấp | Không đưa ngày cụ thể khi mức tin cậy thấp |
| Tác động nếu tiếp tục chờ | Việc nào phía sau bị ảnh hưởng | Cho thấy chi phí thật của việc chờ |
| Phương án thay thế | Có thể làm gì khác trong lúc chờ | Tránh để nguồn lực rỗi |
Cột mức tin cậy của thời điểm dự kiến là thứ giữ cho báo cáo trung thực. Có sự khác biệt lớn giữa "đội phát triển đã lên lịch cho sprint sau, mức tin cậy cao" và "đội phát triển nói sẽ xem, mức tin cậy thấp". Ghi cả hai thành một ngày dự kiến như nhau là tạo ra kỳ vọng sai, và khi kỳ vọng đó không thành hiện thực thì độ tin cậy của toàn bộ báo cáo giảm theo.
Nguyên tắc RED áp dụng: không cam kết thời hạn cho việc phụ thuộc vào các bên nằm ngoài phạm vi kiểm soát của RED. Thay vào đó, RED báo cáo trạng thái phụ thuộc một cách minh bạch, nêu rõ ai cần làm gì để gỡ bế tắc, và leo thang khi thời gian chờ vượt ngưỡng đã thống nhất.
Về việc dùng thời gian chờ: khi một luồng bị chặn, việc cần làm là chuyển nguồn lực sang luồng khác chứ không phải chờ. Điều này chỉ khả thi khi bảng phụ thuộc được duy trì liên tục — nếu chỉ phát hiện bế tắc trong cuộc họp hàng tháng thì đã mất bốn tuần.
Định nghĩa hoàn thành phải riêng cho từng loại việc SEO
Câu hỏi: một việc SEO khi nào được coi là xong?
Không phải khi mã nguồn được gộp vào nhánh chính. Không phải khi bài viết được xuất bản. Không phải khi ai đó nói đã làm. Trong công việc SEO, khoảng cách giữa "đã thực hiện" và "đã có hiệu lực trên môi trường thật" đủ lớn để cần một bước xác minh riêng.
Đây là chỗ nhiều chương trình rò rỉ giá trị âm thầm. Bảng công việc hiển thị hai mươi việc đã hoàn thành trong quý, nhưng khi kiểm tra thực tế thì năm trong số đó chưa có hiệu lực trên môi trường thật, ba việc có hiệu lực nhưng sai, và hai việc đã bị một lần phát hành sau đó ghi đè.
Định nghĩa hoàn thành theo loại việc
| Loại việc | Điều kiện để đóng | Bằng chứng cần đính kèm |
|---|---|---|
| Quy tắc chuyển hướng | URL nguồn chuyển tới đúng đích, một bước, mã trạng thái đúng, trên môi trường thật | Kết quả kiểm tra danh sách URL kèm mã trạng thái |
| Sửa lỗi kỹ thuật | Trạng thái đã thay đổi trên môi trường thật, không phát sinh vấn đề mới | Ảnh chụp trước và sau, kết quả crawl |
| Thay đổi thẻ robots hoặc canonical | Giá trị đúng trên môi trường thật; canonical Google chọn khớp với canonical khai báo | Kết quả kiểm tra URL trong Search Console |
| Xuất bản nội dung | Trang truy cập được, không bị chặn lập chỉ mục, có liên kết nội bộ trỏ tới | Kết quả kiểm tra URL, danh sách liên kết nội bộ |
| Cập nhật nội dung | Nội dung mới hiển thị trên môi trường thật, các thẻ đúng | Ảnh chụp trang, kết quả crawl |
| Gỡ hoặc gộp nội dung | Mã trạng thái đúng theo quyết định, chuyển hướng đúng đích nếu có | Kết quả kiểm tra mã trạng thái |
| Dữ liệu có cấu trúc | Đánh dấu hợp lệ, phản ánh nội dung thật của trang | Kết quả công cụ kiểm tra |
| Thay đổi cấu hình đo lường | Sự kiện ghi nhận đúng, không nhân đôi, có mốc đánh dấu ngày thay đổi | Kết quả kiểm tra thời gian thực |
| Cải thiện hiệu năng | Chỉ số cải thiện trên dữ liệu người dùng thật của template bị ảnh hưởng | Dữ liệu thực địa theo nhóm trang |
Nguyên tắc chung cho mọi dòng: bằng chứng phải lấy từ môi trường thật, phải có ngày, và phải được lưu kèm việc. Ba yêu cầu này nghe nặng nề nhưng chi phí thực tế nhỏ — thường là một ảnh chụp màn hình và một dòng ghi chú — trong khi lợi ích là khả năng trả lời câu hỏi "việc này đã làm chưa và có còn hiệu lực không" ở bất kỳ thời điểm nào sau đó.
Trường hợp cần lưu ý: một số loại việc không thể xác minh ngay sau khi phát hành. Ví dụ với canonical, việc Google có chọn đúng URL hay không cần thời gian để thấy trong dữ liệu. Với các việc này, RED tách thành hai mốc: mốc thực hiện — đã triển khai đúng trên môi trường thật, và mốc xác nhận — dữ liệu phản ánh đúng, kiểm tra lại sau một khoảng thời gian. Việc chỉ đóng hẳn sau mốc thứ hai.
Nhật ký thay đổi là lớp quản trị bắt buộc
Câu hỏi: những gì đã thay đổi trên website, ai thay đổi, ảnh hưởng tới nhóm URL nào, và có quay lui được không?
Với website có nhiều nhóm cùng làm việc — đội sản phẩm, đội marketing, đội nội dung, đội phát triển, các đối tác bên ngoài — không ai có tầm nhìn đầy đủ về những gì đang thay đổi. Thảo luận trong ngành năm 2026 nêu rõ đây là lý do các website ở quy mô lớn cần một nhật ký thay đổi tập trung: nhiều nhóm có thể đẩy thay đổi ảnh hưởng tới tìm kiếm mà không nhóm nào trong số đó nhận ra tác động.
Giá trị của nhật ký thể hiện rõ nhất khi có sự cố. Không có nhật ký, việc chẩn đoán một cú giảm lưu lượng phải bắt đầu bằng việc dựng lại lịch sử từ trí nhớ nhiều người — mất nhiều ngày và kết quả không đáng tin. Có nhật ký, bước đầu tiên là mở ra xem trong cửa sổ thời gian đó có gì.
Nhật ký thay đổi SEO
| Trường | Nội dung | Vì sao cần |
|---|---|---|
| Ngày và giờ | Thời điểm thay đổi có hiệu lực trên môi trường thật | Đối chiếu với dữ liệu chuỗi thời gian |
| Loại thay đổi | Kỹ thuật, nội dung, cấu hình, hạ tầng, đo lường | Phân nhóm khi điều tra |
| Mô tả | Thay đổi cụ thể là gì | Đủ để người khác hiểu mà không cần hỏi |
| Người thực hiện | Tên người và nhóm | Biết hỏi ai |
| Phạm vi ảnh hưởng | Template nào, nhóm URL nào, ước lượng số trang | Khoanh vùng khi có sự cố |
| Đánh giá rủi ro trước khi thực hiện | Mức rủi ro và lý do | Cho biết thay đổi này có được cân nhắc không |
| Cách quay lui | Có quay lui được không, mất bao lâu | Điều kiện để ra quyết định nhanh khi có sự cố |
| Đã thông báo cho ai | Các nhóm được báo trước | Phát hiện các thay đổi không được thông báo |
Điểm khó nhất khi triển khai là làm cho các nhóm khác ghi vào nhật ký. Cách hiệu quả không phải là yêu cầu thêm một việc, mà là gắn nhật ký vào quy trình đã có: nếu đội phát triển đã có ghi chú phát hành, việc cần làm là bổ sung vài trường vào đó thay vì tạo một tài liệu riêng. Nếu đội nội dung đã có lịch xuất bản, tương tự.
Nguyên tắc: không chấp nhận các thay đổi vô hình. Một thay đổi ảnh hưởng tới nhóm URL quan trọng mà không xuất hiện trong nhật ký là một lỗ hổng quản trị, và cần được xử lý ở cấp quy trình chứ không phải bằng cách nhắc nhở từng lần. Việc đối chiếu nhật ký này với các đường trong báo cáo là điều làm cho báo cáo SEO có giá trị chẩn đoán thay vì chỉ mô tả.
Sổ rủi ro phải có điều kiện kích hoạt và phương án ứng phó
Câu hỏi: những rủi ro nào đang tồn tại, dấu hiệu nào cho biết chúng đang xảy ra, và làm gì khi đó?
Một sổ rủi ro liệt kê các rủi ro chung chung với mức "cao, trung bình, thấp" không dùng được. Cái làm cho sổ rủi ro có giá trị là hai cột thường bị bỏ: điều kiện kích hoạt — dấu hiệu quan sát được cho biết rủi ro đang thành hiện thực, và phương án ứng phó — việc cần làm khi đó.
Ma trận rủi ro và leo thang
| Rủi ro | Điều kiện kích hoạt | Biện pháp giảm thiểu trước | Phương án ứng phó khi xảy ra | Người phụ trách |
|---|---|---|---|---|
| Thẻ noindex của môi trường thử nghiệm lên môi trường thật | Kiểm tra sau phát hành phát hiện noindex diện rộng | Đưa kiểm tra thẻ robots vào cổng phát hành | Sửa ngay trong ngày, kiểm tra lại toàn bộ template | Đội phát triển |
| Chuyển website mất tín hiệu | Nhóm URL ưu tiên không chuyển hướng đúng sau launch | Chạy toàn bộ danh sách chuyển hướng trên môi trường thử nghiệm | Sửa quy tắc theo nhóm ưu tiên trước | Kỹ thuật SEO |
| Thay đổi template ảnh hưởng diện rộng | Một template được sửa mà không qua kiểm tra | Bắt buộc kiểm tra mẫu cho mọi thay đổi template | Đánh giá phạm vi, quyết định sửa hay quay lui | Đội phát triển |
| Nội dung tắc ở khâu duyệt | Thời gian chờ duyệt vượt ngưỡng đã thống nhất | Thống nhất thời gian duyệt tối đa từ đầu | Leo thang theo đường đã định | Trưởng nhóm nội dung |
| Năng lực đội phát triển bị rút | Hạng mục SEO bị đẩy khỏi sprint nhiều lần liên tiếp | Thỏa thuận tỷ lệ năng lực dành cho SEO từ đầu chu kỳ | Đưa ra ban lãnh đạo với dữ liệu về tác động | Quản lý dự án |
| Mất dữ liệu đo lường | Chênh lệch bất thường giữa các nguồn | Giám sát cấu hình theo dõi | Xử lý ngay, đánh dấu khoảng dữ liệu bị ảnh hưởng | Đội dữ liệu |
| Nội dung không đủ chiều sâu chuyên môn | Không tiếp cận được chuyên gia lĩnh vực | Xác nhận nguồn chuyên môn trước khi lên lịch sản xuất | Hoãn chủ đề, chuyển sang chủ đề có nguyên liệu | Trưởng nhóm nội dung |
Nguyên tắc quan trọng nhất: không giấu rủi ro để giữ tiến độ đẹp. Đây là cám dỗ thường trực trong các dự án có báo cáo định kỳ với ban lãnh đạo — một rủi ro được ghi nhận sẽ tạo câu hỏi, và câu hỏi tạo áp lực. Nhưng rủi ro không được nêu sẽ không biến mất; nó chỉ chuyển từ trạng thái quản lý được sang trạng thái sự cố.
Về việc chấm điểm rủi ro: RED không dùng thang điểm số nhân giữa xác suất và mức tác động. Cách đó tạo cảm giác chính xác không có thật, vì cả hai đầu vào đều là phán đoán. Cách dùng là mô tả cụ thể điều kiện kích hoạt và phương án ứng phó — thứ dùng được khi rủi ro thực sự xảy ra.
Với các rủi ro liên quan tới chuyển đổi cấu trúc website, quy trình kiểm soát chi tiết nằm trong phạm vi SEO Migration và được đưa vào chương trình như một luồng có cổng kiểm soát riêng.
Nhịp họp phải phục vụ quyết định
Câu hỏi: mỗi cuộc họp trong chương trình này tạo ra kết quả gì?
Nếu câu trả lời là "cập nhật tình hình" thì cuộc họp đó nên được thay bằng một tài liệu. Việc đọc lại bảng số liệu trước mặt nhau không phải cách sử dụng thời gian tốt, đặc biệt khi có nhiều người tham gia.
Nhịp quản trị chương trình SEO
| Loại họp | Tần suất | Người tham gia | Kết quả cần có |
|---|---|---|---|
| Họp ngắn theo luồng | Hàng tuần | Người trong luồng | Xác định các bế tắc mới, phân công gỡ |
| Rà soát chu kỳ triển khai | Theo sprint | Quản lý dự án, đội phát triển, kỹ thuật SEO | Xác nhận việc nào đã đóng có bằng chứng, việc nào vào chu kỳ sau |
| Họp điều hành chương trình | Hàng tháng | Chủ sở hữu các luồng, quản lý dự án, trưởng bộ phận | Ra các quyết định về ưu tiên và nguồn lực |
| Họp sự cố | Khi cần | Những người liên quan trực tiếp | Xác định phạm vi, phân công điều tra, quyết định có quay lui không |
| Rà soát với ban lãnh đạo | Hàng quý | Người ký ngân sách, trưởng bộ phận | Quyết định về hướng đi và ngân sách chu kỳ tiếp theo |
Nguyên tắc chung cho mọi cuộc họp: có chương trình gửi trước, có tài liệu số liệu gửi trước, và thời gian trong phòng dành cho việc quyết định chứ không phải trình bày. Nếu một cuộc họp không có quyết định nào cần ra, hủy nó.
Cuộc họp sự cố cần được định nghĩa trước về điều kiện triệu tập — không phải mọi biến động đều cần họp khẩn. Ngưỡng nên gắn với mức nghiêm trọng đã thống nhất trong sổ rủi ro, và người có quyền triệu tập phải được xác định rõ.
Bàn giao để chương trình không phụ thuộc vào một đơn vị
Câu hỏi: khi hợp đồng kết thúc hoặc khi đổi người phụ trách, doanh nghiệp nhận lại được gì?
Đây là câu hỏi mà một đơn vị cung cấp dịch vụ có động cơ né tránh. Việc để doanh nghiệp phụ thuộc — dữ liệu nằm trong hệ thống của đơn vị dịch vụ, tài liệu không được bàn giao, quyền truy cập không được chuyển giao — tạo ra sự ràng buộc nhưng phá hủy niềm tin.
RED làm ngược lại: toàn bộ tài sản của chương trình thuộc về doanh nghiệp và được bàn giao ở định dạng dùng được.
Gói bàn giao dự án
| Hạng mục | Nội dung | Yêu cầu về định dạng |
|---|---|---|
| Quyền truy cập | Toàn bộ tài khoản, quyền quản trị các công cụ | Doanh nghiệp là chủ sở hữu, không phải người được mời |
| Danh sách công việc | Việc đã xong, việc đang làm, việc chưa bắt đầu, kèm mô tả | Xuất được ra định dạng độc lập với công cụ |
| Nhật ký thay đổi | Toàn bộ lịch sử thay đổi trong thời gian hợp tác | Tệp dữ liệu bảng, không phải ảnh chụp |
| Bằng chứng nghiệm thu | Các bằng chứng đã lưu cho từng việc đã đóng | Có tổ chức theo việc |
| Tài liệu quy trình | Các quy trình đã thiết lập: cổng phát hành, định nghĩa hoàn thành, đường leo thang | Văn bản, không phụ thuộc công cụ |
| Sổ quyết định | Các quyết định đã ra và lý do | Bao gồm cả các phương án đã loại |
| Rủi ro còn mở | Những gì chưa xử lý xong, đang ở trạng thái nào | Kèm khuyến nghị bước tiếp theo |
| Tài liệu bàn giao vận hành | Ai cần làm gì để duy trì chương trình | Đủ để người mới tiếp nhận |
Về quyền truy cập: nguyên tắc là các tài khoản gốc thuộc về doanh nghiệp ngay từ đầu dự án, và RED được cấp quyền như một người dùng được mời. Cách này tránh tình huống phải chuyển giao quyền sở hữu khi kết thúc — vốn là lúc dễ phát sinh vướng mắc nhất.
Về công cụ: nếu chương trình dùng công cụ riêng của RED, dữ liệu trong đó phải xuất được ra định dạng chuẩn. RED không xây dựng sự phụ thuộc bằng cách giữ dữ liệu trong hệ thống đóng.
Câu hỏi thường gặp
Quản lý dự án SEO khác tư vấn chiến lược ở điểm nào?
Tư vấn chiến lược trả lời câu hỏi nên đầu tư vào đâu và không đầu tư vào đâu, kết thúc bằng một danh mục đã được duyệt. Quản lý dự án nhận danh mục đó và làm cho nó được thực thi: phân luồng công việc, xác định quyền quyết định, theo dõi phụ thuộc, kiểm soát chất lượng và ghi nhật ký thay đổi. Quản lý dự án không tự thay đổi hướng đầu tư đã được duyệt.
RED có quản lý đội phát triển và đội nội dung của doanh nghiệp không?
Không theo nghĩa quản lý nhân sự. RED điều phối công việc SEO qua các đội đó: đưa yêu cầu vào đúng quy trình, làm rõ tiêu chí nghiệm thu, theo dõi trạng thái, và leo thang khi có bế tắc. Quyền phân công và đánh giá nhân sự thuộc về người quản lý trực tiếp của từng đội trong doanh nghiệp.
Có dùng sổ phân quyền và nhật ký thay đổi không?
Có, và cả hai là điều kiện để chương trình vận hành được. Sổ phân quyền phải chứa tên người cụ thể cho từng loại quyết định, không phải tên phòng ban. Nhật ký thay đổi được gắn vào quy trình đã có của các đội thay vì tạo thêm một tài liệu riêng, và ghi nhận mọi thay đổi ảnh hưởng tới website — không chỉ các thay đổi do đội SEO thực hiện.
Một việc SEO khi nào được coi là hoàn thành?
Khi có bằng chứng trên môi trường thật cho thấy thay đổi đã có hiệu lực đúng như dự định, và bằng chứng đó được lưu kèm việc. Việc mã nguồn đã gộp hoặc bài đã xuất bản chưa đủ. Với một số loại việc cần thời gian để thấy trong dữ liệu — như canonical Google chọn — có hai mốc: mốc thực hiện và mốc xác nhận, và việc chỉ đóng sau mốc thứ hai.
Có quản lý các dự án chuyển website và phát hành lớn không?
Có, dưới dạng một luồng công việc có cổng kiểm soát riêng. Các dự án loại này có đặc điểm là rủi ro tập trung vào một thời điểm và một số lỗi không đảo ngược được, nên cần điều kiện đi tiếp được định nghĩa trước và kế hoạch quay lui viết sẵn thay vì ứng biến trong ngày phát hành.
Kết thúc dự án thì bàn giao những gì?
Quyền truy cập với doanh nghiệp là chủ sở hữu, danh sách công việc ở định dạng xuất được, toàn bộ nhật ký thay đổi, bằng chứng nghiệm thu của các việc đã đóng, tài liệu quy trình đã thiết lập, sổ quyết định kèm lý do, danh sách rủi ro còn mở và tài liệu bàn giao vận hành. Nguyên tắc là doanh nghiệp có thể tiếp tục chương trình mà không phụ thuộc vào RED.
Gửi bối cảnh để RED đánh giá phạm vi quản lý
Nếu doanh nghiệp đã có kế hoạch SEO nhưng việc không được thực thi tới nơi — hạng mục kỹ thuật nằm mãi trong hàng chờ, nội dung tắc ở khâu duyệt, thay đổi trên website không ai biết — hãy gửi cho RED:
- Kế hoạch hoặc danh mục công việc SEO đã được duyệt
- Cách tổ chức các đội liên quan: phát triển, nội dung, sản phẩm, dữ liệu
- Quy trình phát hành hiện tại và tần suất phát hành
- Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
- Các điểm nghẽn cụ thể đang gặp
RED sẽ đánh giá cấu trúc luồng công việc, các quyền quyết định cần xác định và cơ chế kiểm soát cần thiết lập, rồi phản hồi bằng bản mô tả phạm vi quản lý. RED không nhận quyền quyết định thuộc về doanh nghiệp và không cam kết thời hạn cho những việc phụ thuộc vào các bên nằm ngoài phạm vi kiểm soát của RED.