Постановка и контроль задач команде без программиста и внедренцев

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

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

Дальше - как устроена постановка и контроль задач без привлечения ИТ-специалистов: что настраивать, куда смотреть руководителю и почему бизнес-процесс в системе работает надёжнее, чем список поручений в мессенджере.

Что значит "без программиста и внедренцев"

Раньше внедрение системы управления задачами означало техническое задание, месяцы разработки и штат интеграторов, которые донастраивают систему под бизнес. Для команды из 5-15 человек это неподъёмно ни по деньгам, ни по срокам.

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

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

Как ставить задачи, чтобы их не теряли

Задача, поставленная в личном чате или голосом на созвоне, живёт ровно столько, сколько её помнит человек. Чтобы задача не потерялась, у неё должно быть:

1. конкретный исполнитель - не "кто-нибудь свободный", а один человек;
2. понятный срок - не "побыстрее", а дата и время;
3. критерий "сделано" - что именно нужно приложить, заполнить или отметить, чтобы задача закрылась;
4. привязка к процессу - видно, из какого шага она выросла и что откроется дальше.

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

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

Контроль без летучек и напоминаний "ну как там дела"

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

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

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

Бизнес-процесс вместо регламента: в чём разница

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

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

Что видит руководитель: рентген ФОТ по задачам

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

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

А вот что действительно стоит денег и видно в системе:

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

Именно это руководитель и должен видеть по каждой задаче, а не абстрактный "простой" в часах.

Частые ошибки при постановке задач команде селлера

1. Задача ставится конкретному человеку в обход процесса - как только сотрудник уволился или заболел, задача теряется вместе с ним, потому что нигде не зафиксировано, что делать дальше.
2. Нет единого критерия "готово" - для приёмки товара один менеджер считает достаточным пересчёт коробок, другой требует ещё и сверку по качеству, и это выясняется только после ошибки.
3. Смежные роли не видят задач друг друга - байер не знает, что кладовщик уже принял товар и пора платить поставщику, бухгалтер не видит связи между приёмкой и оплатой.
4. Контроль держится на памяти руководителя - вместо того чтобы система сама показывала просроченные шаги, руководитель пытается всё удержать в голове или в заметках.
5. Задачи не связаны с метриками - маржинальность, ДРР и оборачиваемость смотрят отдельно от того, кто и что делает, и не видно, как задержка на одном шаге бьёт по цифрам в другом месте.

Как запустить постановку и контроль задач за один день

1. Выбрать 2-3 процесса, которые чаще всего рвутся - обычно это запуск нового товара, обработка возврата, изменение цены.
2. Расписать шаги процесса как последовательность задач с ответственными - не как список должностных обязанностей, а как маршрут, по которому проходит работа.
3. Настроить процесс в системе самостоятельно, без технического задания и разработчика - конструктор бизнес-процессов сам подсказывает логику шагов.
4. Запустить процесс на реальных задачах и посмотреть, где он спотыкается - какой шаг регулярно задерживается и почему.
5. Донастроить сроки и ответственных по факту работы, а не по теории на бумаге.

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