Пять человек, три проекта, один общий чат. Пока заказов немного, план держится в голове руководителя и в переписке, и этого хватает. Потом добавляется четвёртый проект, дизайнер уходит в отпуск, подрядчик задерживает макеты, и внезапно выясняется, что сроки двух работ упираются в одного человека в одну и ту же неделю. Список задач такое не показывает: там всё выглядит спокойно, у каждой строки есть исполнитель и дедлайн.
Диаграмма Ганта в Битрикс24 закрывает ровно этот разрыв. Задачи выкладываются на календарную шкалу, где видно длительность каждой работы, их наложения и стрелки зависимостей между ними. Для команды из пяти-десяти человек это часто единственный инструмент планирования, который реально приживается: не нужны ни отдельная программа, ни отдельный человек, который будет вести план вместо всех остальных.
Ниже устройство режима Ганта в облачном Битрикс24 на уровне механики и то, как небольшой команде выстроить на нём рабочий процесс вместо красивой картинки для собственника.
Чем режим Ганта отличается от других представлений задач
В проектах Битрикс24 одни и те же задачи можно смотреть в нескольких режимах: Список, Канбан, Сроки, Мой план, Календарь и диаграмма Ганта. Переключение между ними не меняет сами задачи, меняется только угол зрения.
Список отвечает на вопрос «что вообще есть». Он показывает максимум полей (активность, статус, сроки, исполнителя) и хорош, когда нужно найти конкретную задачу или отсортировать всё по крайнему сроку. Канбан отвечает на вопрос «на каком этапе». Он отлично работает у команд с повторяющимся конвейером, где каждая задача проходит одни и те же стадии. Календарь и Сроки отвечают на вопрос «что горит на этой неделе».
Ганта отвечает на другой вопрос: «в каком порядке это физически можно сделать». Это единственное представление, в котором задача занимает не точку на шкале, а отрезок. У отрезка есть ширина, и она сразу выдаёт то, что скрывает список. Две трёхнедельные работы, поставленные на одного человека, в списке выглядят как две строки, а на диаграмме как два параллельных прямоугольника, которые одним сотрудником не закрыть.
Второе отличие в стрелках. Между задачами можно установить зависимости, и они отображаются линиями со стрелками. План перестаёт быть набором дат и становится последовательностью, у которой есть логика.
Как читать шкалу, чтобы она была полезной
Первое, на что стоит смотреть, это общая длина проекта. Диаграмма показывает, когда начинается первая работа и когда заканчивается последняя. Если клиенту обещали месяц, а последний прямоугольник упирается в середину следующего, вопрос закрыт ещё до старта: срок нереален, и это видно за секунды.
Дальше идёт цепочка самых длинных связанных отрезков. В классическом проектном управлении её называют критическим путём. В небольшой команде её редко считают формально, но глазами она читается легко: это последовательность задач, где каждая следующая не может начаться, пока не закончилась предыдущая. Любая просрочка внутри цепочки сдвигает финал всего проекта. У задач вне цепочки такого эффекта нет, у них есть запас.
Третье, что стоит смотреть, это вертикальные срезы. Возьмите любую неделю и посмотрите, сколько отрезков её пересекает и чьи они. Если четыре из шести приходятся на одного разработчика, план придётся переделывать независимо от того, насколько красиво он выглядит целиком.
Есть и обратная ситуация, которую замечают реже: длинные пустые участки у отдельных людей. Для небольшой команды это прямые деньги. Если у копирайтера в середине проекта две свободные недели, туда можно поставить работу по другому клиенту, и Ганта покажет, влезет она туда или нет.
Четыре типа связей и что они делают на самом деле
Зависимости это то, ради чего диаграмма Ганта вообще существует. Связь ставится мышью: наведите курсор на край блока задачи, нажмите на появившийся кружок и перетяните его к старту или финишу другой задачи. Битрикс24 поддерживает четыре типа связей.
- «Финиш-Старт». Изменение финиша задачи А сдвигает старт задачи Б. Самый частый вариант: пока не согласован макет, вёрстка не начинается.
- «Старт-Старт». Изменение старта задачи А сдвигает старт задачи Б. Подходит для работ, которые запускаются вместе: например, наполнение контентом и настройка аналитики стартуют в один день.
- «Финиш-Финиш». Изменение финиша задачи А сдвигает финиш задачи Б. Полезно, когда две работы должны быть готовы к одной дате, но длятся по-разному.
- «Старт-Финиш». Изменение старта задачи А сдвигает финиш задачи Б. Встречается редко, обычно когда старая работа должна продолжаться ровно до запуска новой.
Важная деталь, которая экономит много недоумения: влияние идёт только в одну сторону. Если вы поменяли даты у зависимой задачи Б, на сроках основной задачи А это никак не отразится. Направление задаёт сама связь, порядок задач на экране тут ни при чём.
Система следит за логикой и не даст замкнуть цепочку саму на себя: при попытке появится ошибка «Нельзя создавать циклические связи». Это раздражает в момент, когда торопишься, но спасает от планов, в которых задача формально зависит сама от себя через три шага.
Ненужную связь удаляют так же просто: клик по стрелке зависимости и выбор удаления. Здесь стоит держать себя в руках. Соблазн связать всё со всем возникает у каждого, кто впервые дорвался до инструмента, а потом любой сдвиг на два дня превращает план в лавину. Ставьте связь только там, где зависимость настоящая и техническая, а не там, где вам просто удобнее такой порядок.
Как собрать план проекта: порядок действий
План собирается за один вечер, если идти сверху вниз и не пытаться сразу описать каждую мелочь.
- Создайте проект и задайте его сроки. Это не формальность: сроки задач не должны выходить за сроки проекта, и рамка сразу дисциплинирует. Если проект заканчивается 30 ноября, поставить задачу на декабрь уже не выйдет.
- Набросайте крупные блоки. Пять-восемь задач верхнего уровня, каждая длиной от недели. Для сайта это обычно аналитика и структура, дизайн, вёрстка, программирование, наполнение, тестирование, запуск. Вглубь пока не уходите, сначала должен встать каркас.
- Расставьте зависимости между блоками. На этом этапе почти все связи будут типа «Финиш-Старт». Как только вы их проставите, диаграмма сама выстроит лесенку и покажет реальную длину проекта. Часто именно здесь выясняется, что обещанный клиенту срок расходится с расчётным на две недели.
- Назначьте ответственных и посмотрите на перегрузы. Один человек не может вести три отрезка одновременно, каким бы героем он ни был. Двигайте задачи по шкале мышью: перетаскивание блока целиком меняет обе даты, левый край отвечает за старт, правый за финиш. Зависимые задачи при этом сдвигаются автоматически.
- Заложите запас на согласование с клиентом, правки и ожидание контента от заказчика. Эти интервалы имеет смысл вносить отдельными задачами и не растворять внутри рабочих: тогда при срыве видно, кто именно задержал проект.
- Только теперь дробите блоки на подзадачи. Детализация нужна исполнителям, но она не должна ломать верхнеуровневую картину, по которой руководитель принимает решения.
Пример: студия из шести человек и три параллельных проекта
Возьмём иллюстративный случай, типичный для алматинского рынка. Веб-студия: руководитель, два разработчика, дизайнер, контент-менеджер, менеджер по продажам. В работе три сайта с датами сдачи в пределах полутора месяцев.
До перехода на планирование в CRM ситуация выглядела так: задачи стояли, дедлайны были, но два проекта регулярно уезжали на одну-две недели. Причину каждый раз называли разную, то клиент долго согласовывал, то дизайнер не успел.
После сборки трёх диаграмм и выстраивания зависимостей картина изменилась за один вечер. Дизайнер оказался узким горлом сразу в трёх проектах: во всех трёх его отрезок стоял в первой трети, и во всех трёх от него шла стрелка «Финиш-Старт» к вёрстке. Пока он вёл один проект, два других физически стояли, хотя в списке задач у разработчиков всё это время висели активные задачи.
Решение оказалось организационным. Даты старта двух проектов сдвинули на неделю относительно друг друга, чтобы дизайн шёл последовательно и не внахлёст. Согласование с клиентом вынесли в отдельные задачи с явным сроком, и стало видно, что один заказчик стабильно съедает пять рабочих дней там, где команда закладывала два. Этот срок просто внесли в план как факт.
Ни один процесс не поменялся, ни одного сотрудника не наняли. Изменилось то, что руководитель начал видеть загрузку до старта, а не постфактум.
Где план разваливается у небольших команд
Самая частая проблема: план собрали один раз и больше не открывали. Диаграмма Ганта живёт только тогда, когда даты в задачах поддерживаются в актуальном состоянии. Если исполнители не переносят сроки при задержках, через две недели диаграмма показывает вымышленный проект. Лечится это привычкой, а не уговорами: пятнадцать минут раз в неделю руководитель проходит по шкале вместе с командой и двигает то, что реально сдвинулось.
Вторая проблема в избыточной детализации. Пятьдесят задач по два часа каждая превращают диаграмму в нечитаемую полосу. Для команды до десяти человек комфортный масштаб это двадцать-тридцать блоков на проект, остальное уходит в подзадачи и чек-листы.
Третья проблема в связях, поставленных для красоты. Если между задачами нет настоящей технической зависимости, стрелка только вредит: любой сдвиг тащит за собой работы, которые могли идти параллельно.
Четвёртая связана с отпусками и выходными. Диаграмма честно покажет отрезок с 25 декабря по 5 января, и формально всё будет корректно. Отпуска сотрудников имеет смысл заводить как отдельные задачи или события, чтобы они физически занимали место на шкале.
Пятая проблема в том, что план видит только руководитель. Права доступа в проектах Битрикс24 настраиваются отдельно, и по умолчанию имеет смысл открыть диаграмму всей команде. Исполнитель, который видит, что от его задачи зависят ещё три, ведёт себя со сроками иначе, чем исполнитель, у которого просто стоит дедлайн.
Что делать, когда объём меняется посреди проекта
Клиент, который посреди работы просит добавить ещё один раздел, это норма, а не форс-мажор. Проблема возникает из-за того, что правку тихо вставляют в текущие сроки и никому об этом не говорят.
Диаграмма делает этот разговор предметным. Новая работа заводится отдельной задачей и ставится на шкалу, со своей длительностью и своими зависимостями. Дальше видно два числа: на сколько сдвинулся финал проекта и чья неделя оказалась занята. С этими двумя числами можно идти к клиенту и обсуждать конкретную дату вместо общих слов про загрузку.
Здесь же выясняется, входит ли правка в договор. Если новый раздел добавляет к проекту десять рабочих дней, это отдельная работа, и её стоит оформить как таковую. Команды, которые ведут план формально, обычно этого не замечают: правки растворяются в старых задачах, и по итогам месяца непонятно, почему проект вышел за бюджет.
Практическое правило простое. Любое изменение объёма отражается на шкале в тот же день, когда его озвучили. Если менять план задним числом, через месяц никто уже не восстановит, где именно потерялось время.
Как выглядит еженедельный разбор плана
Диаграмма приносит пользу ровно в той мере, в какой вокруг неё выстроен ритуал. У небольших команд хорошо приживается короткая планёрка раз в неделю, на которой открывают диаграмму каждого активного проекта.
Порядок разбора обычно такой. Сначала смотрят на задачи, которые должны были закончиться на прошлой неделе и не закончились: их даты двигают прямо в момент обсуждения, чтобы шкала не расходилась с реальностью. Затем оценивают ближайшие две недели и проверяют, нет ли у кого-то из команды трёх параллельных отрезков. В конце смотрят на дату сдачи: сдвинулась ли она за неделю и на сколько.
На три-четыре проекта такая планёрка занимает около двадцати минут. Её главный эффект в том, что срыв срока перестаёт быть новостью. Дата уезжает постепенно, по дню-два, и на шкале это видно за три недели до того, как станет проблемой для клиента.
Шаблоны и регулярные задачи: план, который не нужно собирать заново
Если проекты у вас однотипные, собирать структуру с нуля каждый раз бессмысленно. В Битрикс24 для этого есть шаблоны задач: раздел «Задачи и проекты», меню «Ещё», пункт «Шаблоны». Шаблон заполняется как обычная задача, с описанием, исполнителями, наблюдателями, важностью и сроками, и потом разворачивается в новую задачу за пару кликов.
На основе шаблона настраиваются и регулярные задачи. В карточке шаблона включается параметр «Регулярная задача», после чего появляется блок настроек периодичности: ежедневно, еженедельно, раз в месяц или раз в год. Битрикс24 создаёт новые задачи сам по заданному правилу. Для агентства это закрывает ежемесячные отчёты и плановые проверки, которые иначе живут в чьей-то памяти.
Связка работает так: типовой проект собирается из шаблонных задач, диаграмма Ганта задаёт для них порядок и даты, регулярные задачи закрывают сопровождение после сдачи. Настроить её под конкретный набор услуг это обычная часть работы при внедрении и настройке Битрикс24, и уходит на неё меньше времени, чем на попытки приучить команду к внешнему таск-трекеру.
Как планирование проектов связано с продажами
Планирование проектов в CRM даёт эффект, которого нет у отдельного проектного инструмента: план и сделка живут в одной системе. Менеджер, который обсуждает с клиентом срок запуска, может посмотреть текущую загрузку производства до того, как назовёт дату.
Для небольшой компании это напрямую влияет на деньги. Обещанный и сорванный срок обходится дороже, чем срок на две недели дальше, но выполненный. Когда продажи и производство смотрят в один портал, разговор о сроках перестаёт быть внутренними переговорами.
Второй эффект связан с повторными продажами. Проект с зафиксированным планом легко превращается в отчёт для клиента: что уже сделано и что впереди. Такой отчёт занимает у менеджера несколько минут и заметно снижает количество тревожных звонков вида «а как там у нас дела».
Частые вопросы
Нужно ли выделять отдельного человека под ведение диаграммы Ганта?
Для команды до десяти человек нет. План собирает руководитель проекта или собственник, дальше диаграмма поддерживается за счёт того, что исполнители честно двигают даты в своих задачах. Отдельная роль появляется, когда проектов становится больше десяти одновременно.
Что будет с планом, если одна задача сорвана на неделю?
Если между задачами проставлены зависимости, сдвиг основной задачи автоматически сдвинет связанные с ней. Обратного эффекта нет: изменение дат в зависимой задаче не потянет за собой основную. Поэтому реальный сдвиг проекта видно сразу, а не в конце месяца.
Можно ли связать задачи из разных проектов?
Логика зависимостей рассчитана на задачи внутри одного проекта, и общая рекомендация состоит в том, чтобы планировать в границах проекта. Если работы действительно связаны через несколько проектов, практичнее развести их по датам вручную или объединить в один проект с этапами.
Диаграмма Ганта заменяет канбан?
Нет, они решают разные задачи. Ганта отвечает за сроки и порядок, канбан за текущее состояние работы. В небольших командах обычно используют оба режима: руководитель смотрит шкалу, исполнители работают в канбане.
Что делать, если сроки задачи выходят за сроки проекта?
Битрикс24 такое не пропустит: сроки задач не должны выходить за сроки проекта. Значит, надо честно решить, что двигать. Либо работа сокращается, либо часть её выносится за периметр проекта отдельной задачей, либо сдвигается дата окончания самого проекта, и об этом сразу узнаёт клиент. Молча уместить лишние две недели внутрь старой рамки не получится, и это скорее плюс.
С чего начать, если проектов уже много, а плана нет ни у одного?
Начните с одного проекта, того, где сроки горят чаще всего. Соберите по нему диаграмму крупными блоками, поставьте зависимости и проживите с ней две недели. Переносить подход на остальные проекты имеет смысл только после того, как команда привыкла обновлять даты.