Что даёт модуль задач и зачем он команде

Начнём с простого вопроса: где сейчас хранятся дела вашей команды? Часть в голове у руководителя, часть в переписке, часть в устных «сделай, пожалуйста». Пока людей трое, это работает. На пятом-шестом сотруднике начинается течь: кто-то не расслышал, кто-то забыл, кто-то был уверен, что задачу делает коллега. Классика — «я думал, ты этим занимаешься».

Модуль задач в Битрикс24 закрывает эту дыру. Он делает три вещи. Фиксирует договорённость: кто, что и к какому числу. Показывает статус в реальном времени — сделано, в работе, просрочено. И хранит историю: кто поставил, кто менял срок, что писали в комментариях. Уволился сотрудник — его задачи не ушли вместе с ним, они в системе, с перепиской и файлами.

Отдельно ценный эффект — задача перестаёт быть «просьбой», которую легко проигнорировать, и становится обязательством с именем и датой. Руководителю не нужно каждое утро обходить всех и спрашивать «ну как там». Он открывает доску и видит картину за минуту. По нашим проектам именно это — переход от ручного контроля к обзору — и есть главная причина, по которой команды остаются в задачах, а не бросают их через месяц.

Задача без ответственного и срока — это не задача, а пожелание. Пожелания не выполняются. Вся ценность модуля начинается там, где у каждого дела есть имя и число, к которому оно должно быть готово. — практика ooobs

Карточка задачи: постановщик, ответственный, сроки, чек-лист

Карточка задачи — это сердце всего модуля. Разберём её по полям, потому что от того, как вы их заполняете, зависит, будет система помогать или мешать.

  • Постановщик — тот, кто задачу создал и кому важен результат. Он получает уведомление, когда работа завершена, и принимает её. Часто это руководитель, но не всегда: менеджер может поставить задачу бухгалтеру и остаться постановщиком.
  • Ответственный — один человек, который делает. Именно один. Это железное правило: у задачи ровно один ответственный, иначе не с кого спросить. Если работа коллективная, есть соисполнители — но отвечает всё равно один.
  • Соисполнители — те, кто помогает ответственному. Видят задачу, участвуют, но результат не на них.
  • Наблюдатели — те, кому нужно быть в курсе: смежный отдел, руководитель уровнем выше. Получают уведомления, но ничего не делают и ни за что не отвечают.
  • Крайний срок (дедлайн) — дата и время, к которому задача должна быть готова. Без него просрочку не поймать, поэтому мы ставим срок почти всегда.
  • Чек-лист — разбивка задачи на пункты внутри карточки. Удобно, когда дело состоит из шагов: «согласовать текст», «сверстать», «отправить на вычитку». Каждый пункт отмечается галочкой, виден прогресс.

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

Ещё одно поле, которое стоит приучить команду заполнять, — описание. Одна строка «сделай лендинг» порождает три уточняющих вопроса в комментариях и потерянный день. Нормальная постановка занимает минуту: что нужно, зачем, какой результат считается готовым. На практике команды, где принято ставить задачи подробно, тратят на переписку внутри карточек в разы меньше времени.

Представления: список, канбан, Гант и «Мои дела»

Один и тот же набор задач Битрикс24 умеет показывать по-разному — и это не украшательство. Разным ролям нужен разный взгляд на одни и те же данные. Исполнителю важно «что делать сегодня», руководителю проекта — «где мы по срокам», а тимлиду — «у кого затык».

Переключаются представления одной кнопкой над списком задач. Ниже — когда какое включать.

Представление Что показывает Кому и когда удобно
Список Таблица задач: название, ответственный, срок, статус. Сортировка и фильтры по любому полю. Быстро найти конкретную задачу, отфильтровать просроченные, массово поменять сроки.
Канбан (доска) Карточки по колонкам-стадиям: «Сделать — В работе — На проверке — Готово». Задачи тянутся мышкой. Команде для наглядного потока работы, дейли-планёрок, когда важен статус, а не даты.
Диаграмма Гант Задачи как полосы на шкале времени, со связями и зависимостями между ними. Руководителю проекта: видеть сроки, накладки и что от чего зависит по датам.
Мои дела Личный список: только задачи, где вы ответственный, сгруппированные по срочности. Исполнителю — план на день: что горит, что на сегодня, что можно отложить.
Календарь / Крайний срок Задачи по датам дедлайнов, распределённые по дням недели или месяца. Планировать загрузку, видеть, на какой день навалилось слишком много.

На практике команда обычно живёт в двух режимах. Исполнители сидят в «Моих делах» и на канбане своего проекта. Руководитель заглядывает в Гант раз в неделю, чтобы свести сроки, и в список — когда надо что-то быстро найти. Навязывать всем одно представление не нужно: пусть каждый работает в удобном ему, данные-то одни и те же.

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

Канбан против Ганта: когда что

Частый вопрос — что выбрать основным. Ответ зависит от того, чем измеряется ваша работа. Если задачи короткие и важен поток («взяли — сделали — отдали»), основа — канбан. Если проект длинный, с этапами, которые зависят друг от друга («нельзя запускать рекламу, пока не готов сайт»), нужен Гант: он покажет, что сдвиг одного срока тянет за собой остальные. В длинных проектах мы обычно ведём оба: команда работает на канбане, руководитель контролирует сроки на Ганте.

Проекты и группы: где живут связанные задачи

Пока задач мало, они спокойно лежат общим списком. Но как только направлений становится несколько — клиенты, внутренние дела, отдельные запуски — список превращается в свалку. Здесь и нужны проекты, они же рабочие группы.

Проект в Битрикс24 — это отдельное пространство под одно направление. Внутри — свои задачи, свой канбан и Гант, общий чат, файлы, календарь и лента. Зашёл в группу «Клиент Ромашка» — видишь только то, что относится к этому клиенту, ничего лишнего. Это резко снижает шум: сотрудник не тонет в тысяче чужих задач.

Когда заводить отдельный проект? Мы отталкиваемся от простого признака — есть ли у направления своя команда и свой набор дел, который живёт дольше одной недели. Примеры из наших внедрений:

  1. Проект под клиента. Всё по одному заказчику в одном месте: задачи, переписка, макеты, договорённости. Удобно, когда над клиентом работает несколько человек.
  2. Проект под отдел. «Маркетинг», «Бухгалтерия», «Разработка» — внутренние группы, где копятся регулярные дела подразделения.
  3. Проект под запуск. Разовое событие с началом и концом: «Переезд офиса», «Запуск нового сайта». Закончили — группу можно закрыть в архив.

Роли в группе разграничены: есть владелец и модераторы (управляют составом и настройками) и участники (работают с задачами). Это удобно, когда над проектом трудится и своя команда, и подрядчик, — доступ выдаётся ровно тем, кому нужно. И ещё: задачи проекта можно связать с CRM и бизнес-процессами, чтобы часть работы ставилась автоматически, — об этом ниже.

Учёт времени и дедлайны: как держать сроки

Дедлайн — это то, ради чего половина команд вообще заводит задачи. Разберём, как заставить сроки работать, а не висеть мёртвым полем.

Первое правило простое до банальности: у задачи должен быть крайний срок. Как только он есть, Битрикс24 начинает работать за вас. Просроченные задачи подсвечиваются красным и попадают в счётчик у сотрудника — их не спрячешь. Напоминания прилетают за день и за час до дедлайна. А руководитель одним фильтром «просроченные» видит весь провал по срокам сразу.

Второе — учёт времени. В карточке задачи есть таймер: сотрудник запускает его, когда садится за дело, и останавливает, когда закончил. Плюс можно указать плановое время («на это уйдёт 3 часа») и потом сравнить с фактом. Зачем это нужно:

  • Понять реальную загрузку. Когда видно, что у человека фактически 50 часов работы на неделю, разговор «почему не успел» становится предметным.
  • Считать себестоимость. Для проектных команд время = деньги. Учёт по задачам показывает, сколько часов реально ушло на клиента.
  • Планировать точнее. Через месяц накапливается статистика, и оценки сроков перестают быть пальцем в небо.

Оговоримся честно: учёт времени приживается не везде. Если команда воспринимает таймер как надзор, он будет саботироваться. Мы советуем вводить его там, где время правда важно для денег (агентства, студии, сервис), и не навязывать там, где важнее сам результат. И объяснять команде, зачем это — не для наказаний, а чтобы не перегружать людей. Насильно внедрённый учёт времени умирает первым.

Шаблоны и регулярные задачи: убираем рутину

Много дел повторяется слово в слово. Каждый месяц — сдать отчётность. Каждую пятницу — сделать бэкап. Каждый раз при новом клиенте — один и тот же список из восьми задач на онбординг. Ставить это руками — терять время и рано или поздно что-то забыть.

Битрикс24 закрывает это двумя инструментами.

  • Шаблоны задач. Один раз описываете задачу целиком — с чек-листом, ответственным, плановым временем — и сохраняете как шаблон. Дальше создаёте похожую задачу в два клика, не набивая всё заново. Для типовых процессов (запуск клиента, подготовка мероприятия) шаблон экономит по полчаса на каждой постановке.
  • Регулярные задачи. Задача создаётся сама по расписанию: каждый понедельник, первого числа месяца, раз в квартал. Сотрудник просто получает готовое дело в срок и не держит в голове «не забыть завести отчёт».

Следующий уровень — когда задачи ставятся не по расписанию, а по событию. Пришла заявка определённого типа — робот сам создаёт задачу нужному человеку. Оплатили счёт — задача бухгалтеру закрыть документы. Это уже территория автоматизации бизнеса: связка задач с CRM и роботами убирает ручную постановку однотипных дел совсем. По опыту именно здесь команды получают самый заметный выигрыш времени — рутинные задачи перестают требовать участия человека на этапе «создать и назначить».

Частые ошибки: чего не делать

Собрали то, из-за чего внедрение задач чаще всего буксует. Все ошибки — из живых проектов, не выдуманные.

  1. Задачи без сроков. Самая частая. Задача без дедлайна не просрочивается никогда, а значит висит вечно и не давит. Команда быстро понимает, что «бессрочное» = «необязательное». Правило простое: нет срока — нет задачи.
  2. Всё на одного. Руководитель ставит все задачи на себя или на одного «безотказного» сотрудника. Через месяц у человека 80 открытых задач, он в них тонет и перестаёт открывать Битрикс24 вообще. Нагрузку надо распределять и видеть на канбане, у кого перекос.
  3. Десять человек в одной задаче. Когда в задаче толпа ответственных и наблюдателей, ответственность размывается. Один ответственный — железно. Остальные — соисполнители и наблюдатели.
  4. Задачи вместо чек-листа. Крупное дело дробят на десяток микрозадач, которые делает один человек подряд. Список раздувается, обзор теряется. Один заход одного человека — это чек-лист внутри карточки, а не отдельные задачи.
  5. Постановка одной строкой. «Сделай сайт» без описания порождает переписку на полдня. Минута на нормальную постановку экономит команде часы уточнений.
  6. Внедрили и бросили. Настроили доски, показали команде — и ушли. Первые две-три недели нужен человек, который следит, чтобы задачи реально заводили, а не откатывались в чат. Без этого система тихо умирает.

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