Постановка и контроль задач команде: какую систему выбрать

Постановка и контроль задач команде - это не выбор между двумя похожими приложениями, а выбор между таск-трекером, который просто фиксирует "кто что написал", и системой, которая физически не даёт задаче потеряться и показывает, во сколько живого ФОТ обходится каждый шаг работы. Если ты селлер на Wildberries, Ozon или Я.Маркете и уже упёрся в потолок ручного контроля - выбирать систему нужно не по красоте интерфейса и не по количеству шаблонов досок, а по тому, встроен ли в неё контроль выполнения шага и видно ли, где реально теряется время команды.

Типичная картина у растущего продавца маркетплейса: задачи ставятся в личных чатах, голосовых сообщениях и общих таблицах. Байер должен заказать партию, контент-менеджер - сдать фото и инфографику, менеджер по маркетплейсу - обновить карточку и запустить рекламу, бухгалтер - свести отчёт по площадке. Каждый шаг зависит от предыдущего, но никто не видит цепочку целиком. Задача "потерялась в чате" - это не редкость, а системная дыра: как только команда вырастает больше трёх-четырёх человек, ручной контроль перестаёт работать физически, вне зависимости от того, насколько дисциплинированы сотрудники.

В статье разберём, чем принципиально отличаются типы систем для постановки и контроля задач, по каким критериям их сравнивать именно для команды маркетплейс-селлера, и на модельном примере покажем, как выбор системы влияет на то, видишь ты реальную нагрузку на фонд оплаты труда или нет.

Чем система контроля задач отличается от простого списка дел

Список задач отвечает на вопрос "что нужно сделать". Система контроля отвечает на другой вопрос - "на каком шаге сейчас стоит работа и кто её держит". Разница критична именно для маркетплейс-команды, потому что почти любая рабочая цепочка здесь многошаговая и проходит через нескольких людей.

Пример: запуск новой карточки товара обычно проходит так - байер согласовывает закупку, контент-менеджер готовит фото и описание, менеджер по маркетплейсу публикует карточку и настраивает рекламу, бухгалтер фиксирует себестоимость для расчёта юнит-экономики. Если это просто список задач в таблице, каждый видит только свою строку. Если это процесс в системе, следующий шаг открывается только после того, как закрыт предыдущий, и руководитель в любой момент видит, на ком именно сейчас стоит цепочка.

Какие типы систем существуют для постановки задач команде

Условно все варианты, которые встречаются у продавцов маркетплейсов, делятся на три группы.

Чаты и таблицы. Мессенджер плюс Google Таблица или Excel. Бесплатно и знакомо всем, но задача существует только до тех пор, пока о ней кто-то помнит. Нет истории, нет автоматического напоминания, нет способа быстро понять, сколько задач висит просроченными.

Классические таск-трекеры. Trello, Asana, Bitrix24-задачи, Яндекс Трекер и похожие сервисы. Здесь уже есть карточки, статусы, дедлайны, ответственные. Это шаг вперёд по сравнению с чатом, но задачи в таких системах, как правило, независимы друг от друга: ничто не мешает менеджеру закрыть свою карточку "публикация карточки товара", даже если байер ещё не подтвердил остатки на складе. Контроль держится на человеке, который вручную проверяет связки между задачами.

Системы с бизнес-процессами. Здесь задача - это не отдельная карточка, а шаг заранее выстроенного процесса. Следующий этап физически не открывается, пока не закрыт предыдущий, и руководитель видит не разрозненные задачи, а весь маршрут - от заказа партии до продажи - вместе с тем, сколько времени и оплаченных часов ушло на каждый шаг.

Хотите навести порядок в задачах и процессах команды? Посмотреть →

По каким критериям выбирать систему

Чтобы не выбирать систему "на глаз", стоит проверить её по нескольким конкретным пунктам:

1. Задача привязана к процессу, а не существует сама по себе - можно построить цепочку "заказ товара -> приёмка -> публикация карточки -> запуск рекламы -> продажа" и увидеть её целиком.
2. Следующий шаг нельзя начать, пока не закрыт предыдущий - это снимает человеческий фактор, а не полагается на память сотрудника.
3. Видно, на ком сейчас стоит задача и сколько времени она уже висит без движения.
4. Есть роли под реальную структуру команды маркетплейс-продавца: байер, контент-менеджер, менеджер по рекламе, менеджер маркетплейса, бухгалтер.
5. Можно посмотреть, во что обходится каждый этап процесса в пересчёте на ФОТ, а не только "сделано / не сделано".
6. Есть история изменений - кто, когда и что сделал, без необходимости спрашивать у сотрудника лично.

Если система не закрывает хотя бы пункты 1 и 2, она остаётся продвинутым списком дел, а не инструментом контроля.

Почему не регламент, а процесс в системе

На этом месте логично посоветовать "пропиши регламент" или "заведи должностную инструкцию". Но регламент - это документ, который можно не прочитать, забыть или прочитать один раз и больше не открывать. Он держится на дисциплине сотрудника, а не на устройстве работы.

Бизнес-процесс, встроенный в систему, устроен иначе: шаг физически нельзя пропустить или закрыть раньше срока, потому что следующий этап просто не откроется, пока не выполнен предыдущий. Разница не в строгости формулировок, а в том, что один вариант зависит от человека, а другой - нет. Поэтому при выборе системы для контроля задач команде смотри не на то, есть ли в ней раздел для регламентов и инструкций, а на то, можно ли в ней собрать реальный процесс с обязательной последовательностью шагов.

Во что реально обходится задержка на шаге

Здесь важно не путать причины. Если задача менеджера по маркетплейсу два дня простояла в очереди, это само по себе не сжигает бюджет - зарплата фиксированная, компания платит её одинаково, и в эти два дня человек занимался другими оплаченными задачами. Расходы возникают в двух реальных местах, и хорошая система показывает именно их.

Первый - упущенная скорость по цепочке. Пример: карточку товара не обновили вовремя, запуск рекламной кампании сдвинулся на неделю, а вместе с ним - и продажи, которые могли пойти раньше. Это не прямые сгоревшие рубли, а потерянная выручка во времени.

Второй - реально потраченное оплаченное время на переделку. Пример: контент-менеджер вернулся к задаче через три дня после того, как о ней забыли, и потратил час, чтобы заново вникнуть в бриф и сверить остатки. Вот этот час можно честно умножить на ставку сотрудника, потому что в этот час он не делал никакой другой оплаченной работы. Система, которая показывает "рентген ФОТ", разделяет эти два вида потерь вместо того, чтобы валить всё в одну кучу с формулой "часы простоя умножить на ставку".

Модельный пример выбора системы для команды продавца

Пример: команда из семи человек - байер, два контент-менеджера, менеджер по маркетплейсу, менеджер по рекламе, бухгалтер и руководитель - ведёт три бренда на Wildberries и Ozon. До этого задачи жили в общем чате и таблице с остатками.

При переходе на классический таск-трекер команда получает удобные карточки и дедлайны по каждой задаче, но руководитель по-прежнему вручную сверяет, не забыл ли байер согласовать закупку до того, как менеджер по рекламе запустил кампанию под ещё не поступивший товар. Контроль связок остаётся на человеке.

При переходе на систему с процессами руководитель один раз собирает маршрут "закупка - приёмка - контент - публикация - реклама - учёт себестоимости", и дальше система сама не даёт открыть следующий шаг раньше времени. Плюс становится видно, на каком именно этапе и у кого чаще всего скапливаются задержки - это уже вопрос не дисциплины, а перегрузки конкретной роли, будь то контент-менеджер или бухгалтер, который параллельно считает ДРР и маржинальность по каждому SKU.

Как внедрить систему без сопротивления команды

Резкий переход "с понедельника все работаем только в новой системе" почти всегда проваливается. Рабочий порядок такой:

• выбери один процесс, который сейчас болит сильнее всего - например, запуск карточки товара или обработка возврата;
• собери его как цепочку шагов с понятными ответственными, а не как абстрактную схему;
• запусти этот один процесс в системе и дай команде две-три недели привыкнуть именно к нему;
• только после этого добавляй следующий процесс - приёмку товара, согласование цены, работу с отзывами.

Такой поэтапный запуск снимает главное возражение команды - "нас заставляют учить сложную систему ради галочки". Люди видят, что конкретный процесс перестал теряться и рваться, и охотнее соглашаются перенести туда следующий кусок работы.