Ребята, осмелюсь затронуть одну из самых непростых тем в IT сфере – взаимодействия SEO-специалистов и программистов. Я хочу поделиться с вами нашими лайфхаками как выстроить совместную работу, оптимизировать процесс сотрудничества с техническими специалистами и остаться друзьями.
Уверена, что каждый SEO-специалист или SEO команда сталкивались с тем, что ТЗ написанное “сеошным языком” явно не воспринимается программистами, а точнее вызывает у них почти физическую боль, мучение и раздражение. В этом случае мы не застрахованы от результата ХЗ, что зачастую и происходит. В итоге, отношения между IT отделом и SEO-специалистами становятся весьма натянутыми и не продуктивными.
Давайте разберёмся, почему так происходит и как правильно выстроить бизнес-процессы и составление ТЗ, чтобы каждый понимал, что от него требуется. И чтобы SEO-специалист не дёргался каждый раз из-за случайного noindex, а получал ожидаемый результат с первого раза. Ну что, погнали!
#1 Нечеткое ТЗ
В первую очередь, SEO-специалисту нужно понять и принять простой факт: что для нас является само собой разумеющимся, вовсе не является таковым для программистов.
Если хотите, чтобы ТЗ было выполнено так как вам надо, не поленитесь и потратьте время на детальное расписывание каждого пункта. Подкрепите важные пункты скриншотами и самое главное – объясните для чего это внедряется. Это во многом поможет разобраться, как и что нужно реализовать, и какую функцию тот или иной пункт должен выполнять на сайте.
+ обязательно гляньте это видео вряд ли где-либо еще, ситуация с нечеткостью ТЗ продемонстрирована более ярко и емко.
#2 Не достаточно информации и понимания как работает SEO
Программисты не обязаны знать все сеошные тонкости. НО, если вы с IT командой работаете постоянно, в ваших интересах донести до них минимальную информацию о SEO и дать базовое понимание того, как SEO работает.
#3 Нет понимания сеошных терминов
Первое с чего начинается недопонимание ТЗ — это не согласованная терминология, которая понятна всем. Подготовьте вокабулярий терминов, которые вы обычно используете в ТЗ (как сеошники, так и программисты), чтобы все понимали, о чем идёт речь.
#4 Нет глобальной информации в ТЗ
Давайте ребятам глобальную информацию, зачем вносятся такие изменения или зачем мы это пилим. Вы видите общую картину, а программисты нет. Хоть мы зачастую считаем, что это не очень-то и важно, на самом деле конечная цель может в корне поменять реализацию (а мы им просто этой информации не дали). Если вы ставите задачу программисту и знаете, что таких задач будет несколько – лучше об этом написать сразу.
У нас была аналогичная история, когда программисты не понимали зачем мы удаляем 500 страниц, которые вылили полгода назад. SEO-специалисты проводят много экспериментов, в том числе неудачных и безрезультатных. А можем вообще под фильтр попасть, следовательно, все ранее сделанные действия откатываются. Просто принять, что сегодня мы это пилим, через неделю сносим, а еще через месяц снова возвращаем, программистам сложно. С их стороны это все выглядит как наши спонтанные прихоти или ошибки. Избежать такого исхода можно просто объяснив, почему мы приняли то или иное решение.
#5 Нет инструментов для тестирования
Еще одна точка несостыковки проявляется в процессе тестирования со стороны IT-команды. Зачастую SEO-специалисты просто не понимают, как можно было не заметить каких-то очевидных вещей и вернуть задачу после теста в таком виде. На самом деле, половину пунктов, которые прописывают SEO-специалисты для исправления можно проверить только краулером, или какими-то веб-сервисами, которыми SEO-специалист постоянно пользуется, а тех отдел о них понятия не имеет.
Так что, если хотите качественное тестирование ваших задач, позаботьтесь о том, чтоб у IT команды был краулер (Netpeak Spider или Screaming Frog, желательно то, чем пользуетесь вы) и все необходимые ссылки на веб-ресурсы для проверки (например, page speed, микроразметки и т.д.), а также проведите инструктаж по использованию этих инструментов.
Мы у себя в компании постарались максимально закрыть боли обеих сторон. SEO-специалисты и программисты подготовили чеклист и лист правил по работе с задачами от SEO-отдела. Мы решали сложности, соответствующие нашим проектам. У вас могут быть другие камни преткновения, но как инструмент по выстраиванию процесса наша схема зарекомендовала себя очень круто:
- Брать задачи в том порядке, в котором они идут в спринте (работаем по системе спринтов, у нас он длится рабочую неделю) – приоритетность по задачам выставляется SEO-специалистом.
- Уточнять реализацию до постановки ТЗ (особенно если там и так ведро костылей)
- Задачу выливаем и тестируем за 1 день. Если это невозможно – согласовываем с SEO-специалистом приемлемые варианты реализации для обеих сторон.
- Обязательно закрываем страницы, над которыми работаем, гет параметром (например, domain.com/?test=seo) и noindex, nofollow. Не пилим сразу на проде (если задача позволяет) + ограничиваем себя от случайно попавших страниц в Google.
- После выливки в мир ОБЯЗАТЕЛЬНО удаляем мета тег noindex, nofollow (если нет запроса оставить его).
- Файл .htaccess копируем перед началом любой работы над сайтом (если он вдруг отвалится, у нас будет оригинальный файл)
- Названия любых новых картинок на сайте (даже если задача не от SEO-специалистов) свели к единому формату, что исключает возможность ошибки (если надо уточнения, пингуем PMов сайтов)
- Прописываем rel= “canonical” на каждой новой странице с ссылкой на саму себя (если заказчик не попросил другого).
- Каждую новую страницу добавляем в sitemap (если в задаче не просили не добавлять).
- Перед редактированием файла robots.txt всегда подгружаем в задачу старый файл.
В общем, программистам надо принять, что SEO — это живой организм. Именно поэтому у SEO-специалистов бывают как спонтанные решения, так и кардинально противоположные задачи (а не просто потому, что нам (сеошникам) так захотелось).
А SEO-специалистам надо понять, что нужно обязательно описывать причины и предысторию задачи, указывать почему внедряются те или иные изменения и ставить четкие и понятные ТЗ.
И вообще, чем больше будет понимания в специфике работы сеошников и программистов, тем более продуктивными и адекватными будут и отношения, и результаты совместной работы.
That’s all, folks!
Да будет мир!
Автор: Татьяна Скачко, Head of SEO Team TRIONIKA
Друзі, насмілюсь торкнутися однієї з найскладніших тем в IT-сфері – взаємодії SEO-фахівців і програмістів. Я хочу поділитися з вами нашими лайфхаками як побудувати спільну роботу, оптимізувати процес співпраці з технічними спеціалістами і залишитись друзями.
Впевнена, що кожен SEO-фахівець чи SEO команда стикалися з тим, що ТЗ написане “сеошною мовою” явно не сприймається програмістами, а точніше викликає в них майже фізичний біль, муки та роздратування. В цьому випадку ми не застраховані від поганого результату, що найчастіше і відбувається. В результаті відносини між IT відділом і SEO-фахівцями стають дуже натягнутими та непродуктивними.
Давайте розберемося, чому так відбувається і як правильно вибудувати бізнес-процеси та складання ТЗ, щоб кожен розумів, що від нього вимагається. І щоб SEO-фахівець не смикався щоразу через випадковий noindex, а отримував очікуваний результат з першого разу. Ну що, вперед!
#1 Нечітке ТЗ
Насамперед, SEO-фахівцеві потрібно зрозуміти і прийняти простий факт: що для нас є само собою зрозумілим, зовсім не є таким для програмістів.
Якщо хочете, щоб ТЗ було виконано так, як вам треба, не полінуйтеся витратити час на детальне розписування кожного пункту. Підкріпіть важливі пункти скріншотами і найголовніше – поясніть для чого це впроваджується. Це багато в чому допоможе розібратися, як і що потрібно реалізувати, і яку функцію той чи інший пункт має виконувати на сайті.
+ обов’язково подивіться це відео (навряд чи деінде, ситуація з нечіткістю ТЗ продемонстрована яскравіше).
#2 Недостатність інформації та розуміння як працює SEO
Програмісти не повинні знати всі сеошні тонкощі. АЛЕ, якщо ви з IT командою працюєте постійно, у ваших інтересах донести до них мінімальну інформацію про SEO і дати базове розуміння того, як SEO працює.
#3 Немає розуміння сеошних термінів
Перше, з чого починається нерозуміння ТЗ, — це неузгоджена термінологія, яка зрозуміла всім. Підготуйте вокабулярій термінів, які ви використовуєте в ТЗ (як сеошніки, так і програмісти), щоб всі розуміли, про що йдеться.
#4 Немає глобальної інформації в ТЗ
Давайте програмістам глобальну інформацію – навіщо вносяться такі зміни або навіщо ми це реалізуємо. Ви бачите загальну картину, а програмісти – ні. Хоча ми часто вважаємо, що це не дуже важливо, насправді кінцева мета може докорінно змінити реалізацію (а ми їм просто цієї інформації не дали). Якщо ви ставите завдання програмісту і знаєте, що таких завдань буде декілька — краще написати це відразу.
У нас була аналогічна історія, коли програмісти не розуміли, навіщо ми видаляємо 500 сторінок, які залили півроку тому. SEO-фахівці проводять багато експериментів, в тому числі невдалих і безрезультатних. А можемо взагалі під фільтр потрапити, отже всі раніше зроблені дії відміняються. Потрібно просто прийняти той факт, що сьогодні ми це додаємо, за тиждень зносимо, а ще за місяць знову повертаємо. З боку ж програмістів це все виглядає як наші спонтанні забаганки або помилки. Уникнути такого результату можна просто пояснивши, чому ми ухвалили те чи інше рішення.
#5 Немає інструментів для тестування
Ще одне нестикування проявляється в процесі тестування з боку IT-команди. Найчастіше SEO-фахівці просто не розуміють, як можна було не помітити якихось очевидних речей і повернути завдання після тесту в такому вигляді. Насправді, половину пунктів, які прописують SEO-фахівці для виправлення, можна перевірити лише краулером або якимись веб-сервісами, якими SEO-фахівець постійно користується, а технічний відділ про них уявлення не має.
Отже, якщо хочете якісне тестування ваших завдань, подбайте про те, щоб у IT команди був краулер (Netpeak Spider або Screaming Frog, бажано те, чим ви користуєтеся) і всі необхідні посилання на веб-ресурси для перевірки (наприклад, page speed, мікророзмітки і т.д.), а також проведіть інструктаж щодо використання цих інструментів.
Ми у себе в компанії постаралися максимально закрити біль обох сторін. SEO-фахівці і програмісти підготували чеклист та список правил щодо роботи з завданнями від SEO-відділу. Ми вирішували труднощі, які відповідають нашим проектам. У вас можуть бути інші камені спотикання, але як інструмент з вибудовування процесу наша схема зарекомендувала себе дуже круто:
- Брати завдання в тому ж порядку, в якому вони йдуть у спринті (працюємо за системою спринтів, у нас він триває робочий тиждень) – пріоритетність із завдань виставляється SEO-фахівцем.
- Уточнювати реалізацію до постановки ТЗ
- Завдання реалізуємо і тестуємо 1 день. Якщо це неможливо – погоджуємо із SEO-фахівцем прийнятні варіанти реалізації для обох сторін.
- Обов’язково закриваємо сторінки, над якими працюємо, цей параметр (наприклад, domain.com/?test=seo) і noindex, nofollow. Не пиляємо відразу на проді (якщо завдання дозволяє) + обмежуємо себе від сторінок, що випадково потрапили в Google.
- Після фінальної реалізації ОБОВ’ЯЗКОВО видаляємо мета тег noindex, nofollow (якщо немає запиту залишити його).
- Файл .htaccess копіюємо перед початком будь-якої роботи над сайтом (якщо він раптом відвалиться, у нас буде оригінальний файл)
- Назви будь-яких нових картинок на сайті (навіть якщо завдання не від SEO-фахівців) звели до єдиного формату, що виключає можливість помилки (якщо треба уточнення, пінгуємо PMів сайтів)
- Прописуємо rel = “canonical” на кожній новій сторінці з посиланням на саму себе (якщо замовник не попросив іншого).
- Кожну нову сторінку додаємо в sitemap (якщо немає інших вказівок у завданні).
- Перед редагуванням файлу robots.txt завжди підвантажуємо в завдання старий файл.
Загалом програмістам треба прийняти, що SEO – це живий організм. Саме тому у SEO-фахівців бувають як спонтанні рішення, так і кардинально протилежні завдання (а не просто тому, що нам (сеошнікам) так закортіло).
А ось SEO-фахівцям треба зрозуміти, що потрібно обов’язково описувати причини і передісторію завдання, вказувати чому впроваджуються ті чи інші зміни і ставити чіткі та зрозумілі ТЗ.
І взагалі, чим більше буде розуміння у специфіці роботи сеошників і програмістів, тим більш продуктивними та адекватними будуть і відносини, і результати спільної роботи.
That’s all, folks!
Хай буде мир!
Автор: Тетяна Скачко, Head of SEO Team TRIONIKA
