— Содержание +
9 месяцев, 50 сайтов, ноль созвонов
К весне-лету 2025 года мы шли с маркетинговым агентством из США уже 9 месяцев. За это время сдали около 50 сайтов на WordPress — по локальному бизнесу: стоматологии, юристы, ветеринары, оптометристы. Все собирались по одному и тому же шаблонному стеку: Astra Pro плюс Elementor Pro, агентский набор пресетов.
Между нашей командой разработчиков и разработчиками агентства за эти 9 месяцев не прошло ни одного прямого разговора. Всё шло через слой менеджеров: задача в Redmine — комментарий в Google Docs — пометка в шаблонной таблице — другая задача. Решения долетали точно. Менеджеры с обеих сторон знали свою работу. Ничего не терялось.
Кроме одного. И это одно копилось тихо.
Что копилось
Мелкие ошибки. Поодиночке — пустяк: где-то отступ на мобильных разошёлся с соседним блоком; иногда CTA-кнопка наследовала цвет из чужого пресета; на одном из сайтов заголовок секции вышел в body-типографии. Ни одна из них не была блокером сдачи. Каждую агентство ловило при своей проверке, заводило отдельной задачей, мы её закрывали за 10 минут. Цикл шёл.
Только одна и та же ошибка повторялась в каждой третьей-четвёртой сборке. Тот отступ под мобильным — снова. Цвет CTA-кнопки, унаследованный из чужого пресета. И заголовок секции в той же body-типографии, четвёртый раз за месяц. Менеджер передавал её как новый дефект — для него и был новый: новая сборка, новая задача, новое исправление. Что эту самую ошибку мы починили на сайте 3 недели назад, в системе задач не помечено.
Это и есть то, что асинхронный канал переносит хуже всего. Он переносит факт ошибки. Источник ошибки в нём не помещается: чтобы его увидеть, нужно держать в голове 20 предыдущих сборок и сказать «погоди, это уже был раз четвёртый — где-то в нашей сборочной заготовке оно зашито». Этого менеджер сделать не может. Этого вообще никто кроме разработчика, который сидит в этих сборках каждый день, сделать не может.
Первый созвон
Случился он не как итог большого решения, а как раз потому, что один из наших разработчиков как-то в чате обронил: «знакомый отступ снова». Мы сели — наши 2 и 2 с агентской стороны. Без аккаунт-менеджеров. На 40 минут.
Повестка была одна: пройти по последним 10 сайтам и для каждой повторяющейся мелкой ошибки найти, откуда она берётся. Не «как мы её правим в этой конкретной задаче» — это мы уже знали. Где в процессе она появляется в первый раз, и что нужно поменять, чтобы она не появлялась ни на следующем сайте, ни через сайт, ни через десять.
К концу 40 минут у нас был список из 7 источников. 6 из них — наши: базовый пресет Astra, который мы не заметили что чуть отличается от агентского; одна шаблонная PHP-вставка, копированная из старой сборки и тащащая старый CSS-namespace; способ заводить мобильные точки адаптации, который у нас и у агентства разъезжался на одну точку адаптации. 7-й — общий: ни у нас, ни у них не было одного описания того, какие именно блоки в типовой странице обязательны, а какие опциональны.
7 источников за 40 минут. До этого мы их вылавливали по одной задаче в неделю, 9 месяцев подряд.
Что изменилось
Не скорость сборки. Скорость не сильно поменялась — мы и до этого собирали быстро. Поменялось количество новых задач из-за повторяющихся мелочей: оно упало почти в ноль через 2 следующие сборки. Не потому что мы стали внимательнее, а потому что закрытые источники физически перестали порождать ту ошибку.
Поменялось и второе — у партнёрства появился канал, через который разработчики могли проговорить «как», когда оно техническое настолько, что менеджер его не переведёт. Пользовались им редко, как и было задумано: примерно раз в месяц-полтора, перед следующей крупной сборкой. Но он был — и это меняло то, с чем обе стороны входили в работу ещё до её старта.
Решение менеджер перенесёт. Источник ошибки — нет: он не помещается в формат задачи. О нём разработчики говорят напрямую, или он копится месяцами.
— Рабочая заметка · 2025
Что из этого следует
Это не выпад против асинхронной работы. Мы по-прежнему ведём проекты в основном через задачи и комментарии — асинхрон ищется по истории, ведёт летопись, работает через любые часовые пояса. Менять это мы не собираемся.
Вывод точнее. Асинхронный канал с менеджерами посередине отлично переносит решения и плохо переносит источники повторяющихся ошибок. Их видит только тот, кто сидит в коде каждый день — и видит он их, когда говорит с другим таким же. Менеджер этого разговора провести не может, потому что для этого разговора у языка управления проектами просто нет слов.
Если вы маркетинговое агентство, ведущее WordPress-разработку через подрядчика целиком асинхронно, и за последние полгода у вас в трекере появлялась дважды одна и та же мелкая ошибка от разных задач — стоит спросить себя не о том, работают ли задачи. Скорее всего, работают. Вопрос в другом: говорили ли хоть раз ваши разработчики с разработчиками подрядчика про то, откуда эта ошибка приходит — или вы по 20-му разу её правите и закрываете задачу.
Как проверить у себя
Откройте трекер за последние 6 месяцев. Сгруппируйте закрытые задачи не по сайту, а по характеру ошибки. Если одна и та же мелочь встречается в 3+ сборках — вы только что нашли источник, который иначе будет жить в системе ещё 9 месяцев.
Нам стоило завести этот созвон раньше. Не завели, потому что казалось — он не должен быть нужен: хорошая документация, выстроенный процесс, опытные менеджеры закроют всё. Обычно и закрывают. Но ровно на повторяющихся мелочах — не закрывают; и пока люди, которые делают работу, не окажутся в одной комнате на 40 минут, ничто вам об этом не скажет.