— Содержание +
Проблема была не в задачах
Мы действительно хороши в асинхронной работе — и долго этим гордились. Наши менеджеры умеют вести проект в задачах; проект-менеджеры агентства двигают сборку одними комментариями и пометками. Примерно первый год так и шло всё партнёрство: наши разработчики и разработчики агентства ни разу не поговорили напрямую — всё шло через слой менеджеров с обеих сторон.
И слой работал отлично. Решения он передавал точно: задача говорит, что собрать, комментарий — что поправить, менеджер переносит и то, и другое через стык между командами, не теряя по дороге ни запятой. Всё, кроме одного. И это одно в итоге перевесило всё, что он переносил безупречно.
Что асинхрон не довозит
То, что не проходило через стык, — не решение. Решения как раз долетали без потерь. Не проходил общий стандарт под ними: то, как должна быть устроена сборка, чтобы потом, когда придёт контент-команда агентства и начнёт укладывать тексты, всё легло без единого спора.
Такое в задачу не уместишь. Это то, что один разработчик на пальцах объясняет другому: где идёт контент, как собраны секции, что остаётся одинаковым от сайта к сайту — чтобы тому, кто потом кладёт текст, не приходилось гадать. Итог такого разговора менеджер передать может. Сам разговор — нет: он слишком технический, для него у языка управления проектами просто нет слов.
Поэтому разговора и не было. Почти год каждая сторона собирала по своему представлению о «правильной» структуре — и договорённость, которая сделала бы работу контент-команды гладкой, не появлялась. Ей было негде появиться: не существовало места, где обе команды разработчиков сидели бы за одним столом.
Решение менеджер перенесёт. Стандарт под решением — нет: о нём разработчики договариваются напрямую.
— Рабочая заметка · 2025
Решение: дать разработчикам поговорить
Решение оказалось до обидного простым: дать нашим разработчикам и разработчикам агентства поговорить напрямую. Не статусная встреча — она и так была, и не созвон по расписанию. Просто разговор по необходимости: на практике раз в месяц, иногда — раз в два, когда впереди была сборка и обе стороны нужно было свести ещё до старта.
Повестка всегда одна — сам стандарт. Как устроить сборку, чтобы контент-команда укладывала тексты сразу, без хождения по кругу: какие секции, какие компоненты, что не меняется от сайта к сайту.
Первый созвон вышел неловким. Обе стороны так привыкли к буферу из менеджеров, что прямой разговор ощущался почти нарушением протокола. Но уже ко второму-третьему это были просто две команды разработчиков, которые спокойно договаривались, как собрать следующий сайт. В этом и был весь смысл — и именно этого ни один менеджер за нас сделать не мог.
Что изменилось
Перемена была негромкой, и дело было совсем не в скорости. Просто сборки начали приходить в той форме, о которой обе стороны действительно договорились, — а не в той, которую каждая додумала за другую.
Сильнее всего это чувствовалось дальше по цепочке, у контент-команды агентства. Когда структура согласована заранее — понятно, где идёт текст и что одинаково между сайтами, — укладка контента перестаёт быть переговорами и становится механикой. В этом и вся отдача: люди, которые кладут текст, больше не воюют со структурой, которую с ними никто не обсуждал.
Был и второй эффект, тише первого. После того как разработчики один раз поговорили напрямую, у партнёрства появился канал для технического «как» — того самого, который менеджеры перенести не могли. Пользовались им редко, так и было задумано. Но он существовал — и одно его наличие меняло то, с чем обе стороны входили в сборку ещё до её старта.
Что из этого следует
Это не выпад против асинхронной работы. Мы по-прежнему ведём проекты в основном через задачи и ветки в рабочих таблицах: асинхрон удобно искать по истории, он сам собой ведёт летопись, он работает через любые часовые пояса. Ничего из этого мы менять не собираемся.
Вывод точнее. Асинхрон с менеджерами посередине великолепно переносит решения — и плохо переносит договорённость под ними. Общий стандарт две команды разработчиков должны согласовать сами, напрямую, потому что он технический настолько, что менеджеры его не переведут. И это не накладной расход: для white-label-сборки именно от него зависит, занимается контент-команда агентства укладкой текста — или спором со структурой.
Если вы маркетинговое агентство и ведёте WordPress-разработку через подрядчика целиком асинхронно — стоит спросить себя не о том, работают ли задачи. Скорее всего, работают. Вопрос в другом: договаривались ли хоть раз ваши разработчики с разработчиками подрядчика, как должна быть устроена сборка для тех, кто придёт следом, — или каждый просто молча это додумывал.
Как проверить у себя
Проверить это ничего не стоит: посадите обе команды на один созвон и попросите проговорить этот стандарт вслух. Получится — договорённость есть. Не получится — вы только что нашли пробел, который иначе не дал бы о себе знать, пока не стало бы поздно.
Нам стоило завести этот созвон раньше. Не завели, потому что казалось — он и не должен быть нужен: хорошая документация, выстроенный процесс, опытные менеджеры закроют всё. Обычно и закрывают. Но ровно на том единственном, что они перенести не могут, — не закрывают; и пока люди, которые делают работу, не окажутся в одной комнате, ничто вам об этом не скажет.