Смотри, я сейчас скажу страшную вещь.
В 80% случаев проблема не в “плохих разработчиках”.
Проблема в том, как им ставят задачи.
Картина типичная:
Маркетолог:
«Сделайте нормальную форму, она плохо конвертит»
Разработчик:
«Что значит “нормальную”? Что именно поменять?»
Маркетолог (мысленно):
«Ты же программист, сам должен знать…»
В итоге:
— задачи висят неделями,
— сроки плавают,
— доработки живут своей жизнью,
— все друг друга тихо ненавидят.
А сайт на 1С-Битрикс как был кривоватым, так и остаётся.
Давай разберёмся, как маркетологу разговаривать с разработчиком так, чтобы задачи делались, а не растворялись в переписке.
1. Забудь фразу «сделай красиво»
Если в постановке задачи есть слова:
- «красивее»,
- «по-человечески»,
- «как у нормальных ребят»,
- «чтобы конвертило» —
это не задача. Это эмоция.
Разработчик работает с:
- конкретными экранами,
- конкретными блоками,
- конкретными кнопками и формами.
Плохо:
«Сделайте лендинг более продающим, а то не работает реклама».
Нормально:
«На странице /uslugi/dorabotka-bitrix/ нужно:
– поднять форму заявки выше, сразу под первым экраном;
– убрать из формы поле “Компания” и “Как вы о нас узнали”;
– сделать кнопку “Получить аудит” вместо “Отправить”;
– после отправки показывать текст: “Заявка принята, вернёмся в течение 30 минут в рабочее время”».
Фокус — не на «красоте», а на поведении пользователя и действиях интерфейса.
2. Переводи свои хотелки в гипотезы, а не в приказы
Маркетологу кажется: «Надо так».
Разработчику кажется: «Опять придумывают фигню».
Нейтральная территория — гипотеза.
Не:
«Переделайте корзину, так неудобно»
А:
«Есть гипотеза: если убрать из шага оформления заказа лишние поля и разделить процесс на 2 простых шага — конверсия в заказ вырастет.
Предлагаю:
- Убрать поля “Отчество” и “Как вы о нас узнали”;
- Разнести доставку и оплату на разные шаги;
- Измерять: конверсию “Перешёл к оформлению → Успешный заказ” 2 недели до и 2 недели после».
Разработчик понимает:
- зачем он вообще что-то трогает;
- что будет считаться успехом;
- что потом можно будет показать цифрами.
3. Описывай задачу так, будто ты объясняешь её новому человеку
Частая ошибка маркетолога — писать задачи в стиле «для своих»:
«Как обсуждали, поправьте там кнопку у формы и фильтр каталога, чтобы нормально работал. Сейчас не то».
Разработчик зашёл в задачу через неделю.
Что такое «там»? Что именно «не то»? На каком экране? На какой странице?
Как надо:
- Где:
– «Страница: /catalog/svet/ (каталог светильников)» - Что сейчас:
– «При выборе фильтра “Бренд” и “Тип” одновременно, страница перезагружается 3–4 секунды, иногда выдаёт пустой список» - Что хотим получить:
– «Фильтр работает без ошибок, время отклика не более 1,5–2 секунд» - Зачем:
– «До 40% пользователей пользуются фильтром, сейчас часть из них видит пустой результат и уходит. После правки замерим: сколько людей применяют фильтр и переходят в карточку товара».
Это уже понятная техническая задача, а не «сделайте нормально, а то я психую».
4. Уважай очередность задач, а не “вот это срочно, реально срочно”
Маркетологу всё горит.
Новости, баннер, лендинг, попап, ещё вот тут чуть-чуть текст поправить…
Если всё «срочно», то нифига не срочно.
У разработчика нет суперсилы делать 15 задач одновременно.
Ему нужен список по приоритету, а не свалка в чате.
Простой формат:
- P1 — критично для денег/заявок прямо сейчас
(формы не работают, заказ не оформляется, реклама льётся на 404, отвалилась оплата) - P2 — влияет на конверсию в ближайший месяц
(улучшить корзину, поправить воронку, сделать нормальные формы на ключевых страницах) - P3 — “хотелки” и улучшения
(красивее иконки, ещё одна анимация, переставить блок местами без влияния на деньги)
Если вы как маркетолог не готовы честно сказать:
«Да, вот это можно сделать позже», — вы сами ломаете процесс.
5. Заранее думай, что ты будешь смотреть в аналитике
Самая тупая постановка задачи:
«Сделайте так, чтобы было больше заявок».
Больше — это сколько? Из чего? За счёт чего?
Любая задача маркетолога к разработчику должна цепляться за метрику:
- заявки;
- заказы;
- клик по кнопке;
- переход до конкретного шага.
Пример нормальной постановки:
«Сейчас с лендинга /bitrix-audit/ клики по кнопке “Заказать аудит” → 2,3% (по данным за последние 2 недели).
Считаю, что проблема в том, что форма спрятана внизу и слишком много полей.
Задача:
– поднять форму выше, сразу под первым экраном;
– убрать поле “Компания”;
– сделать кнопку “Получить расчёт” вместо “Отправить”.
Цель: довести клик по кнопке до 3,5–4% + дальше смотреть по конверсии формы».
Разработчик видит:
- исходную точку;
- конкретные действия;
- цель в цифрах.
Это уже похоже на работу, а не на магию.
6. Перестань писать ТЗ в виде переписки в чате
Ещё одно зло:
всё обсуждается голосом или в чатике по 100 сообщений.
Через неделю:
- никто не помнит, что решили;
- разработчик сделал так, как понял;
- маркетолог говорит: «я не это имел в виду».
Решение простое:
- в чате можно обсуждать,
- но итог всегда должен быть в задаче: один текст, одно место.
Формат:
- Кратко — суть задачи (1–2 предложения).
- Подробно — что где меняем.
- Зачем — гипотеза и метрика.
- Готово, когда — критерии приёмки:
«Форма отправляется, письмо приходит, лид в CRM, пробовали X/Y/Z».
5. Прикреплённые скрины/макеты/тексты.
Пока ТЗ живёт в формате «листай переписку неделю назад» — ругаться будете вечно.
7. Не проси “волшебную кнопку”, если сам не знаешь, что потом будешь с ней делать
Часто вижу такое:
«Сделайте попап с “оставьте телефон, перезвоним за 5 минут”».
Спрашиваю маркетолога:
— А кто будет перезванивать?
— Ну… отдел продаж.
— Они готовы перехватывать эти заявки в течение 5 минут?
— Ну, вообще-то нет…
Тут проблема не к разработчику, а к тебе.
Не надо просить реализовать то, чего бизнес не тянет.
Пока ты не понимаешь:
- кто берёт эти лиды;
- как быстро с ними работают;
- как будешь измерять эффективность -
любой новый попап останется просто декоративной штукой.
8. Не стесняйся спрашивать “а как проще/дешевле сделать то же самое”
Маркетолог часто приходит уже с решением в голове:
«Сделайте сложный калькулятор на 10 шагов, вот схема».
Иногда разработчик молча реализует.
Иногда честно говорит: «Дорого и долго».
Но правильный вопрос с твоей стороны:
«Слушай, мне нужно собирать вот такие данные от пользователя и доводить его до заявки. Как это сделать проще, чтобы и вам было адекватно по срокам, и пользователю не больно?»
Хороший разработчик предложит альтернативу:
- вместо калькулятора — условно 3 шага + форма;
- вместо кастомной адской интеграции — использовать уже готовые механизмы;
- вместо полного передела страницы — локальные изменения.
Если ты не спрашиваешь, а просто требуешь «как придумал», ты сам загоняешь проект в дорогие и долгие разработки.
9. Встречайтесь регулярно, а не только когда всё горит
Самое продуктивное, что можно сделать маркетологу и разработчику — раз в неделю созвон на 20–30 минут.
Формат:
- Что сделали за прошлую неделю (и что это дало по факту).
- Что в работе сейчас.
- Что планируем на следующую.
- Что мешает (нет текстов, нет решений по офферам, нет макетов и т.п.).
Это сильно лучше, чем:
- молчать месяцами,
- потом скинуть список на 20 задач и фразу «это всё срочно, давайте к понедельнику».
10. Ты не “просто маркетолог”, ты интерфейс между бизнесом и разработкой
Важная мысль:
Разработчик не обязан понимать маркетинг.
Но и ты не обязан читать код.
Твоя зона ответственности:
- чётко знать, чего хочет бизнес (заявки, продажи, рост конверсии, повторные покупки);
- переводить это в понятные задачи: что на каком экране меняется, как это измерять;
- не перекладывать всё на «ну вы же специалисты».
Чем лучше ты умеешь говорить на языке задач и метрик,
тем меньше ты будешь слышать «подумаем», «посмотрим», «Битрикс сложный», и тем больше у тебя будет реальных доработок, которые двигают цифры, а не суету.