Диаграмма Ганта не работает. Показываем на примере правительства США, Airbus и Amazon
Мы в Minervasoft думали, что диаграмма Ганта — нормальный способ планирования. А потом кое-что поняли.
Его используют везде: преподаватели — для расписания занятий и экзаменов, логисты — для поставок товаров и графиков инвентаризации, учёные — для клинических испытаний и тестирования препаратов.
Но почему с Гантом нужно быть осторожным? Давайте разбираться.
Гант добрался и до таск-трекеров: Asana, YouGile и ClickUp.
Дисклеймер: Мы считаем, что диаграмма Ганта — не очень хороший инструмент планирования. Вы можете думать иначе, и мы это уважаем.
Как работает Гант
Гант — это инструмент, который показывает, как выполняются запланированные действия с течением времени.
Чтобы было нагляднее, вот Гант на основе учебного расписания.
Было:
1 пара (8:30–10:05) — Менеджмент в рекламе
2 пара (10:15–11:50) — Производство видеорекламы
3 пара (12:00–13:35) — Реклама и PR в соцсетях
Стало:
Пары какого-то студента-рекламщика. Длина блоков — это длительность занятий, а в списке слева — что за предметы идут в это время.
Пример с парами многим знаком, но чаще Гант используется как инструмент планирования в компаниях. И это приводит к плохим последствиям.
Проблемы Ганта
Гант не показывает ресурсы, риски и сложность задач
Это просто графическое изображение длительности этапов работы.
Это красиво, но непрактично: если что-то пойдёт не так, Гант не покажет проблему. // Из статьи «Диаграмма Ганта vs Канбан-доска» на Хабр
Хуже всего, что Гант за счёт своей простоты может создавать ощущение, что всё понятно и идёт по плану. Но нет — он просто не может показывать форс-мажоры.
Закон Паркинсона: работа займёт всё отведённое на неё время. И синдром студента
Обычно при планировании закладывают большие сроки, чтобы предусмотреть все риски. По факту сначала делается что угодно, но не задача, потому что времени же ещё много.
Настоящая работа делается в последний момент. А если что-то произойдёт, то времени исправить уже не будет.
Опоздания передаются, а выигрыши по времени — нет
Гант предполагает, что работа делается поэтапно и в установленные сроки. Если кто-то справился с работой раньше, это значит, что всем последующим звеньям нужно тоже начинать раньше.
Но мир устроен по-другому. Даже если кто-то из цепи сможет начать раньше, то точно не все.
При таком раскладе можно только делать работу к сроку или опаздывать. Что-то всегда идёт не по плану, и опоздания будут. А они как раз могут сдвигать сроки в другую сторону.
И остальные будут вынуждены работать в спешке.
Из статьи «О чём молчит диаграмма Ганта или почему проекты всегда опаздывают» на Хабр
Гант не подходит проектам, в которых ничего не понятно
Гант предполагает наличие конкретных этапов проекта и сроков. Если непонятно:
— насколько продукт актуален,
— какие этапы должны быть,
— что в продукте нужно, а что нет,
То использовать Гант и другие жёсткие методы планирования — это самоубийство.
Например, вам нужно разработать продукт, которого нет на рынке. Понятно, что здесь сложно оценить конкретные сроки целого проекта.
Если не знаете, что делать, зачем вообще вам Гант?
Нужно действовать аккуратно: планировать короткими отрезками и постоянно получать обратную связь.
Дальше рассмотрим Ганта на примерах реальных кейсов и увидим проблемы в действии.
Airbus A380 выпустили на 3 года позже и при чём тут Гант?
Стандартный самолёт вмещает 183 человека.
Но самолёт Airbus A380 вмещает от 525 до 853 пассажиров, в зависимости от сборки.
Компания Airbus сделала самую большую модель самолёта на рынке. Но какой ценой?
Если бы процесс производства планировали с помощью Ганта, выглядело бы это так:
Очень упрощённый план — его достаточно
Выглядит красиво, но на этом плюсы заканчиваются: на диаграмме не видно ничего, кроме сроков.
А 380 делался на разных заводах в разных частях света. Первая проблема возникла ещё на этапе проектирования: немецкие и французские заводы использовали разные версии программ для проектирования. Это привело к несовместимости цифровых моделей между разными площадками.
Потом — проблема с электропроводкой: электрические системы во французском и немецком подразделениях работали по разным стандартам. Из-за этого в каждом самолёте пришлось переделывать 500 км электропроводки (это не опечатка).
Ещё некоторые части самолёта в итоге не стыковались — из-за тех же проблем с изготовлением в разных странах.
Всё это привело к задержкам в других этапах производства.
И сроки сильно сдвинулись.
В итоге компания потеряла часть заказчиков и 6 млрд долларов. Проект оказался сомнительным с самого начала — более рентабельно закупать обычные самолёты и продавать все места. Когда на самолёте мест в 3 раза больше обычного, их редко выкупают полностью.
Сейчас A380 не делают, компания так и не окупила вложенных средств.
Здесь помог бы метод критической цепи
Скорее всего, Airbus столкнулся с классическими ошибками планирования, о которых мы говорили в начале:
— Планирование раздутых сроков, чтобы учесть риски.
— Это время потом растрачивается, потому что всё равно все делают в последний момент. Ну или растягивают работу на весь срок. А если произойдёт форс-мажор, времени его исправлять уже нет.
— Это приводит к опозданиям. Если не на первом этапе, так на каком-нибудь точно. И следующие звенья цепи либо тоже опаздывают, либо работают в спешке.
— Даже если кто-то закончит работу раньше, следующие звенья не смогут начать работу раньше.
Всё это лечится критической цепью. Рассмотрим её на примере кейса Airbus A380.
1. В план работ для каждого этапа закладывается ровно то время, которое для него нужно. Без подстраховок.
Если ничего не случится, на работу будет уходить только то время, которое она занимает. У сотрудников не будет повода заниматься чем-то не тем.
2. Создаётся буфер времени для всего проекта.
Как бывает обычно:
Работа делается за X времени
В план на эту работу закладывают 2X времени
В критической цепи закладывают 1,6X от времени выполнения работы. Причём X — на работу в цепь, и 0,6X — в конец проекта.
Это общее время для всех звеньев. Если что-то случилось или какое-то звено не успевает закончить работу, оно может взять время из общего буфера. За это время отчитываются.
Это изначальный план работ по Ганту. Розовая часть блоков — это время на подстраховку
А это критическая цепь — здесь время на подстраховку лежит в конце проекта. Так им могут пользоваться все
В итоге что-то плохое обязательно случится. Только обычно проекты с критической цепью заканчиваются или раньше, или вовремя. Как раз потому, что буферным временем можно воспользоваться в крайнем случае.
Если сотрудники всё равно срывают сроки
Критическая цепь будет работать лучше, если в компании настроены процессы. Это когда:
руководитель знает, сколько времени занимает каждый этап работы
сотрудники знают, как делать работу в срок
сотрудники знают, что делать, если они не успевают закончить работу в срок
срочные задачи не выбивают проект из колеи
и ещё много-много всего.
Некоторые процессы можно настроить с помощью базы знаний. Например, онбординг или обучение. Это удобно: у новичков есть доступ к информации, а опытных сотрудников не дергают лишний раз.
Если вы не заботитесь о времени опытных сотрудников, то посчитайте время, которое они тратят на помощь джунам и переведите его в деньги.
В Minervasoft есть функционал базы знаний и платформа для обучения.
Здесь работает умный поиск. Нужный материал найдётся, даже если запрос с ошибками или на другой раскладке.
Ещё можно использовать виджет Copilot — тогда не придётся переключаться из другой системы, чтобы найти нужный ответ. А генеративный ИИ позволит сделать это быстро — подготовит короткий ответ на основе статей из базы знаний.
Copilot встраивается в другие системы компании и подсказывает ответы в зависимости от контекста.
Ещё в Minerva Knowledge создавать документы могут несколько человек сразу. Как в Google Docs.
Тут можно комментировать текст, вставлять графики, диаграммы Draw.io и PlantUML, данные из «Яндекс.Карт», YouTube, GoogleDocs, Miro и их аналогов.
В Minerva Learn можно создавать курсы из знаний, опубликованных в Minerva Knowledge, а ещё — составлять проверочные задания и контролировать успеваемость. Если в контенте произойдут изменения, можно уведомить об этом сотрудников и даже назначить мини-тесты для проверки знаний.
Удобно создавать учебные материалы на основе контента из базы знаний.
Чтобы точно улучшить бизнес-метрики после внедрения базы знаний, можно использовать Minerva Result: наша команда проверит состояние статей и документов, поможет разработать шаблоны, стандарты и концепцию управления знаниями. А ещё расскажет, как использовать базу знаний так, чтобы она точно приносила пользу бизнесу и команде.
Позаботьтесь о своих сотрудниках — это выгоднее, чем текучка. Да и более благородно.
Попробовать Minervasoft
Amazon планировали порвать рынок, а получилось только потерять репутацию и деньги
В 2014 году Amazon решил сделать телефон, который смог бы конкурировать с iPhone и Samsung.
Продукт делали тайно: хотели всех удивить новым крутым продуктом.
Вот Гант на основе плана проекта. Видно, что произошло в итоге?
Что придумали:
1. 3D-экран:
Поворачиваешь голову, и картинка на телефоне меняется.
2. Можно навести камеру на любой предмет, и телефон найдёт его в Amazon.
3. Живой консультант, который 24/7 помогает с вопросами по телефону.
4. Платная подписка в Amazon вместе с покупкой телефона.
Интересно, конечно. Вот что из этого получилось:
В июле 2014 телефон начали продавать за $649 (без контракта с оператором связи) или за $199 (с двухлетним контрактом AT& T). В сентябре цену снизили за $1 (с контрактом AT& T).
В октябре Amazon списал $170 млн убытков из-за непроданных телефонов.
В августе 2015 прекратили производство, а в сентябре — поддержку телефонов. На волне разбирательств компания уволила 3 тысячи сотрудников.
А почему никто не захотел покупать телефон от Amazon?
Во-первых, телефон делали 4 года так, чтобы о нём никто не знал. Продукт не получал обратной связи.
Когда телефон выпустили на рынок, Amazon узнал, что 3D- экран быстро надоедал и даже укачивал, поиск товаров работал не очень, а популярные приложения (типа YouTube и google-карт) на самом деле нужны людям, а Amazon Fire Phone их не поддерживал.
Во-вторых, $650 или за непонятный телефон (или $200, если с контрактом оператора связи) — дорого. Ровно за эти деньги можно было купить проверенный новый iPhone.
В-третьих, телефон работал только с оператором связи AT&T, а он неважно работал в некоторых регионах. Да и к 2014 году люди привыкли, что они могут выбирать оператора связи сами.
Здесь помог бы Scrum
Главная ошибка Amazon — работа в стол 4 года. Для новых продуктов критически важно получать обратную связь от мира.
Поэтому было бы правильно работать по Agile-методикам, например в Scrum:
1. Планировать работу короткими промежутками времени (спринтами). Обычно они длятся 1–4 недели. После каждого спринта получать обратную связь.
2. Сначала сделать самые базовые функции, которые нужны пользователям в телефоне, только потом придумывать и разрабатывать что-то новое.
3. Ориентироваться на мнение потенциальных покупателей. Не разрабатывать то, чем не будут пользоваться.
В случае с Fire Phone планирование выглядело бы как-то так:
И дальше на основе решений планируются следующие спринты
Сайт со страховками подорвал репутацию государства
Для этого кейса нужен контекст:
Медицина в США — это больно и дорого. Какой-нибудь перелом руки до сих пор может разорить семью: счёт за лечение может достигать двух ежемесячных зарплат.
Поэтому без медицинской страховки никак — она покрывает часть расходов на лечение.
До 2013 года в США была такая картина: страховку в основном давали работодатели. Сами страховые компании могли отказать в страховке больным людям и тем, у кого были деньги, если считали таких людей невыгодными клиентами. Государство помогало только пожилым и бедным.
В 2013 году начинал действовать закон, который обязывал американцев иметь страховку. А ещё государство с этого момента начало помогать обычным людям её оплачивать. Чем меньше доход, тем больше компенсирует государство.
Так вот. Healthcare.gov — это сайт, на котором можно сравнить предложения страховых компаний и подать заявку на частичную её оплату государством.
Разработка велась с 2010 по октябрь 2013 года. Начали её ближе к 2011.
Диаграмма Ганта с планируемым процессом разработки. Понимаете, что будет дальше?
В день X, когда новый закон о страховке вступал в силу, healthcare.gov тоже должен был начать работать.
Но… сайт рухнул. Зарегистрироваться смог только 1% из тех, кто зашёл на сайт, а потом он совсем перестал открываться.
Сначала думали, что падение сайта вызвал шквал посетителей. Но потом оказалось, что проблемы систематические.
Был политический скандал. Президенту пришлось публично признать, что это провал.
В конце концов сайт доделали. Но ценой времени и превышением бюджета в 18! раз.
Что пошло не так?
Как всё получилось на самом деле
На самом деле, в процессе работы над проектом допустили много ошибок:
1. Проектом занимались больше 50 компаний, и между ними не была налажена коммуникация. Каждый отвечал только за свою часть работы, но не за то, чтобы это нормально работало в совокупности.
2. Требования к проекту постоянно менялись, и всё считалось очень важным.
Например, за месяц до запуска кто-то решил, что пользователи должны создавать аккаунты до просмотра страховых планов. Это сильно изменило паттерны использования системы и создало дополнительную нагрузку на серверы.
3. Тестирование системы начали делать за 2 недели до запуска. И сразу нашли 200+ дефектов. Времени на исправление не было, поэтому продукт выпустили с ними.
4. Руководство не хотело слушать подчинённых. Подрядчики знали о проблемах задолго до запуска, но их предупреждения игнорировались или не доходили до лиц, принимающих решения. Бюрократическая структура управления привела к тому, что даже простые решения нужно было согласовывать неделями.
Здесь помог бы DSDM
Проблему коммуникаций DSDM не решит, а всё остальное — вполне.
В случае с healthcare.gov были важны сроки — их нельзя было сдвигать. А также это разработка нового продукта, во время которой могло произойти всё что угодно.
Значит, нужно что-то среднее между жёсткими методами планирования типа критической цепи и гибкими типа Agile — это DSDM.
Здесь важно разделить задачи по приоритетам MoSCoW:
1. Must have (с анг. «должно быть») = без этих функций продукт бесполезен, их нужно сделать в первую очередь. Занимает 60% ресурсов.
2. Should have («следовало бы быть») = довольно важные функции, но можно запуститься без них. Занимает 20% ресурсов.
3. Could have («может быть») = полезные функции, но не критичные, 15% ресурсов
4. Won’t have («не будет») = классно, если сделаем, но можно безболезненно отложить на следующие версии, 5% ресурсов
Важен только первый приоритет, это необходимый минимум работ. Без всего остального можно обойтись — это и есть решение в случае с healthcare.gov: делаем, что успеваем, остальное в следующий раз.
С healthcare.gov это могло быть так:
— Must have
Регистрация на сайте
Просмотр базовых планов страховки
Простой калькулятор стоимости
Заявка на субсидию
— Should have
Сравнение планов страховки
Подробные описания покрытия
Расчёт субсидий с базовой проверкой данных
— Could have
Автоматическая проверка доходов через налоговую
Интеграция с базами других ведомств
Расширенный поиск планов
— Won’t have:
Мобильное приложение
Чат с консультантом
Интеграция с личными кабинетами страховых компаний
Его главный принцип — нельзя двигать сроки и снижать качество. Но можно урезать функции.
В DSDM планируют таймбоксами. В них задачи тоже сортируют по приоритетам. Если что-то не успевают, убирают should have с could have и не вспоминают о них. В спринтах по-другому — там незавершённые задачи переносятся.
Почему Гантом всё-таки пользуются
Как инструмент планирования Гант плох. Но всё-таки у него есть положительная сторона.
Гант отлично визуализирует процесс работы. Его можно использовать в презентациях и докладах, а ещё в продажах.
И, к счастью, сейчас Ганта используют в основном с этой целью
Гантом можно иллюстрировать другие способы планирования, и это хорошо. Просто надо держать в голове, что Гант — хороший инструмент визуализации, а не планирования.
У Minervasoft есть свой блог в Telegram — там будут выходить другие статьи про спорные вопросы в найме, менеджменте и планировании. Подпишитесь, чтобы не пропустить.
