Диаграмма Ганта не работает. Показываем на примере правительства США, Airbus и Amazon

Мы в Minervasoft думали, что диаграмма Ганта — нормальный способ планирования. А потом кое-что поняли.

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

Но почему с Гантом нужно быть осторожным? Давайте разбираться.

Гант — это инструмент, который показывает, как выполняются запланированные действия с течением времени.

Чтобы было нагляднее, вот Гант на основе учебного расписания.

Было:

1 пара (8:30-10:05) — Менеджмент в рекламе

2 пара (10:15-11:50) — Производство видеорекламы

3 пара (12:00-13:35) — Реклама и PR в соцсетях

Стало:

Пример с парами многим знаком, но чаще Гант используется как инструмент планирования в компаниях. И это приводит к плохим последствиям.

Это просто графическое изображение длительности этапов работы.

Хуже всего, что Гант за счёт своей простоты может создавать ощущение, что всё понятно и идёт по плану. Но нет — он просто не может показывать форс-мажоры.

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

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

Но мир устроен по-другому. Даже если кто-то из цепи сможет начать раньше, то точно не все.

При таком раскладе можно только делать работу к сроку или опаздывать. Что-то всегда идёт не по плану, и опоздания будут. А они как раз могут сдвигать сроки в другую сторону.

И остальные будут вынуждены работать в спешке.

Гант предполагает наличие конкретных этапов проекта и сроков. Если непонятно:

— насколько продукт актуален,

— какие этапы должны быть,

— что в продукте нужно, а что нет,

То использовать Гант и другие жёсткие методы планирования — это самоубийство.

Нужно действовать аккуратно: планировать короткими отрезками и постоянно получать обратную связь.

Дальше рассмотрим Ганта на примерах реальных кейсов и увидим проблемы в действии.

Стандартный самолёт вмещает 183 человека.

Компания Airbus сделала самую большую модель самолёта на рынке. Но какой ценой?

Если бы процесс производства планировали с помощью Ганта, выглядело бы это так:

Выглядит красиво, но на этом плюсы заканчиваются: на диаграмме не видно ничего, кроме сроков.

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

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

Ещё некоторые части самолёта в итоге не стыковались — из-за тех же проблем с изготовлением в разных странах.

Всё это привело к задержкам в других этапах производства.

В итоге компания потеряла часть заказчиков и 6 млрд долларов. Проект оказался сомнительным с самого начала — более рентабельно закупать обычные самолёты и продавать все места. Когда на самолёте мест в 3 раза больше обычного, их редко выкупают полностью.

Скорее всего, Airbus столкнулся с классическими ошибками планирования, о которых мы говорили в начале:

— Планирование раздутых сроков, чтобы учесть риски.

— Это время потом растрачивается, потому что всё равно все делают в последний момент. Ну или растягивают работу на весь срок. А если произойдёт форс-мажор, времени его исправлять уже нет.

— Это приводит к опозданиям. Если не на первом этапе, так на каком-нибудь точно. И следующие звенья цепи либо тоже опаздывают, либо работают в спешке.

— Даже если кто-то закончит работу раньше, следующие звенья не смогут начать работу раньше.

Всё это лечится критической цепью. Рассмотрим её на примере кейса Airbus A380.

1. В план работ для каждого этапа закладывается ровно то время, которое для него нужно. Без подстраховок.

Если ничего не случится, на работу будет уходить только то время, которое она занимает. У сотрудников не будет повода заниматься чем-то не тем.

2. Создаётся буфер времени для всего проекта.

Как бывает обычно:

В критической цепи закладывают 1,6X от времени выполнения работы. Причём X — на работу в цепь, и 0,6X — в конец проекта.

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

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

Критическая цепь будет работать лучше, если в компании настроены процессы. Это когда:

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

В Minervasoft есть функционал базы знаний и платформа для обучения.

Ещё можно использовать виджет Copilot – тогда не придётся переключаться из другой системы, чтобы найти нужный ответ. А генеративный ИИ позволит сделать это быстро – подготовит короткий ответ на основе статей из базы знаний.

Ещё в Minerva Knowledge создавать документы могут несколько человек сразу. Как в Google Docs.

В Minerva Learn можно создавать курсы из знаний, опубликованных в Minerva Knowledge, а ещё — составлять проверочные задания и контролировать успеваемость. Если в контенте произойдут изменения, можно уведомить об этом сотрудников и даже назначить мини-тесты для проверки знаний.

Чтобы точно улучшить бизнес-метрики после внедрения базы знаний, можно использовать Minerva Result: наша команда проверит состояние статей и документов, поможет разработать шаблоны, стандарты и концепцию управления знаниями. А ещё расскажет, как использовать базу знаний так, чтобы она точно приносила пользу бизнесу и команде.

В 2014 году Amazon решил сделать телефон, который смог бы конкурировать с iPhone и Samsung.

Продукт делали тайно: хотели всех удивить новым крутым продуктом.

Что придумали:

1. 3D-экран:

2. Можно навести камеру на любой предмет, и телефон найдёт его в Amazon.

3. Живой консультант, который 24/7 помогает с вопросами по телефону.

4. Платная подписка в Amazon вместе с покупкой телефона.

Интересно, конечно. Вот что из этого получилось:

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

Когда телефон выпустили на рынок, Amazon узнал, что 3D- экран быстро надоедал и даже укачивал, поиск товаров работал не очень, а популярные приложения (типа YouTube и google-карт) на самом деле нужны людям, а Amazon Fire Phone их не поддерживал.

Во-вторых, $650 или за непонятный телефон (или $200, если с контрактом оператора связи) — дорого. Ровно за эти деньги можно было купить проверенный новый iPhone.

В-третьих, телефон работал только с оператором связи AT&T, а он неважно работал в некоторых регионах. Да и к 2014 году люди привыкли, что они могут выбирать оператора связи сами.

Главная ошибка 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 не решит, а всё остальное — вполне.

В случае с 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 — там будут выходить другие статьи про спорные вопросы в найме, менеджменте и планировании. Подпишитесь, чтобы не пропустить.