Инструменты методики АЦТ, часть 14: паспорт проекта (Project Charter), диаграмма Ганта (Gantt Chart), Канбан в управлении проектами (Kanban) и иерархическая структура работ (WBS)

Это четырнадцатая статья цикла по инструментам методики «Аккордная цифровая трансформация». Открываем подгруппу B2 «Визуализация и планирование» — инструменты B2-01, B2-02, B2-03 и B2-04.

Подгруппа B2 — про то, как сделать проект видимым: описать его, разложить на задачи, наметить сроки и держать все под контролем. Четыре инструмента этой статьи складываются в естественный порядок запуска. Паспорт проекта (B2-01) официально открывает проект и фиксирует его цель и ответственного. Иерархическая структура работ (B2-04) раскладывает проект на управляемые задачи. Диаграмма Ганта (B2-02) ставит эти задачи на шкалу времени. Канбан (B2-03) управляет потоком задач в ходе работы.

B2-01 — Паспорт (хартия) проекта (Project Charter)

Откуда появился инструмент. Паспорт проекта — не изобретение одного автора, а управленческая практика, которую закрепил Институт управления проектами (PMI) в своде знаний PMBOK. Логика инструмента проста: расходованию ресурсов должно предшествовать формальное открытие проекта, которое закрепляет его цель, ожидаемый результат и ответственного руководителя. В PMBOK эту практику оформили как отдельный процесс «разработка устава проекта» (Develop Project Charter), добавленный в третьем издании руководства (2004). Документ официально санкционирует существование проекта и наделяет менеджера проекта полномочиями распоряжаться ресурсами организации. Выпускает его инициатор или спонсор — тот, кто стоит над проектом и выделяет на него средства.

Суть и механика. Паспорт проекта — короткий документ, который официально открывает проект. В нем фиксируют цель проекта, ключевые результаты, спонсора и заинтересованные стороны, необходимые ресурсы, ограничения, главные контрольные точки, бюджет, а также полномочия менеджера проекта. Пока паспорт не утвержден, проекта формально нет. Главная ценность документа заключается в том, чтобы превратить идею в официально признанный проект с понятными целями, рамками и ответственным.

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

Границы применимости. Паспорт нужен любому проекту как точка официального старта — это базовый и простой инструмент (12 часов на освоение). Он задает рамку, но не содержит детального плана: что именно делать и в какие сроки, определяют дальше — через иерархическую структуру работ (B2-04) и календарный план (B2-02).

Чек-лист перед составлением паспорта проекта:

Сформулирована цель проекта: зачем он и какую проблему решает.
Определены ключевые результаты и границы проекта (что входит, что нет).
Указаны руководитель, менеджер проекта и его полномочия, заинтересованные стороны.
Обозначены ресурсы, бюджет и главные ограничения.
Заданы ключевые контрольные точки и ориентировочные сроки.
Паспорт утвержден руководителем — тем, кто санкционирует проект и ресурсы.

Типовые ошибки:

Старт без паспорта. Проект начинают на словах, без официального открытия, — рамки и ответственность размыты. → Зафиксировать цель, рамки и полномочия в паспорте до старта работ.
Паспорт вместо плана. В него пытаются вписать детальный план всех работ. → Держать документ коротким; детализацию выносить в WBS (B2-04) и график (B2-02).
Нет утверждения руководителем. Паспорт составили, но руководитель его не утвердил — у проекта нет реальных полномочий. → Получить утверждение того, кто выделяет ресурсы.
Размытые рамки и цель. Цель и границы сформулированы общо, и проект расползается. → Конкретизировать результат и явно указать, что в проект не входит.

B2-02 — Диаграмма Ганта (Gantt Chart)

Откуда появился инструмент. Диаграмму назвали по имени американского инженера Генри Ганта, который около 1910–1915 годов предложил наглядный график для планирования работ: задачи откладывают полосами вдоль оси времени. Похожую идею, «гармонограмму», еще раньше, в 1896 году, выдвинул польский инженер Кароль Адамецкий, но его работы вышли на польском и русском и не получили мировой известности, поэтому метод закрепился под именем Ганта. Диаграммы применяли уже в крупных проектах начала XX века, а с распространением компьютеров они стали стандартным инструментом планирования.

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

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

Границы применимости. Диаграмма Ганта — простой и универсальный инструмент (12 часов), полезный почти в любом проекте для наглядного календарного плана. На очень больших проектах с сотнями задач она становится громоздкой, а сложные зависимости и расчет критических сроков лучше показывает метод критического пути (B2-05). Сама по себе диаграмма не управляет проектом: ее нужно поддерживать в актуальном состоянии, иначе график быстро расходится с реальностью.

Чек-лист перед построением диаграммы Ганта:

Список задач проекта составлен (удобно — на основе WBS, B2-04).
Для каждой задачи оценена длительность и заданы сроки начала и окончания.
Определены зависимости: какие задачи идут последовательно, какие параллельно.
Назначены ответственные за задачи.
Отмечены контрольные точки и общий срок проекта.
Предусмотрено регулярное обновление диаграммы по фактическому ходу работ.

Типовые ошибки:

График составили, но им не пользуются. Диаграмму нарисовали один раз и не обновляют — она расходится с реальностью. → Регулярно актуализировать по факту выполнения.
Зависимости не учтены. Задачи расставили по срокам, не связав зависимости, — план нереалистичен. → Задать связи между задачами: что от чего зависит.
Слишком детально. В диаграмму заносят сотни мелких задач, и она становится нечитаемой. → Держать уровень задач управляемым; детали — в WBS.
Оценки сроков наугад. Длительность задач берут произвольно, и график не сбывается. → Оценивать сроки обоснованно, привлекая непосредственных исполнителей.

B2-03 — Канбан в управлении проектами (Kanban)

Откуда появился инструмент. Производственный канбан придумал Тайити Оно в Toyota в конце 1940-х — начале 1950-х как часть системы «точно вовремя» (в методике это отдельный инструмент, A3-02). А канбан как метод управления проектами и интеллектуальной работой создал британский эксперт Дэвид Андерсон: в 2004 году он применил вытягивающую систему в подразделении Microsoft, а в 2006–2007 годах на проекте компании Corbis оформил то, что теперь называют методом Канбан, — с доской, лимитами незавершенной работы и управлением потоком. Подход он описал в книге «Kanban» (2010). Идею производственного канбана он перенес с цеха на работу команд: визуализировать задачи и управлять их потоком.

Суть и механика. Канбан в управлении проектами — метод, построенный на визуализации работы. Все задачи выносят на доску с колонками по стадиям выполнения (например, «в очереди», «в работе», «готово»), и каждый видит актуальный статус. Ключевые принципы: прозрачность (статус задач доступен всей команде), ограничение незавершенной работы (лимит на число одновременно выполняемых задач, чтобы не перегружать людей), управление потоком (постоянный анализ движения задач и поиск узких мест) и понятные всем правила работы с доской. В отличие от спринтов Scrum, канбан не делит работу на фиксированные циклы, а выстраивает непрерывный поток задач.

Пример. Команда ведет поток разнородных задач, и непонятно, кто чем занят. Заводят доску с колонками «очередь — в работе — на проверке — готово» и выносят на нее все задачи карточками. Сразу видно: в колонке «в работе» скопилось двенадцать задач на пятерых. Вводят лимит: не более двух задач в работе на человека. Поток выравнивается, задачи доводят до конца быстрее, а узкие места (например, застой на проверке) становятся видны и устраняются.

Границы применимости. Канбан хорош для потока разнородных задач, поступающих неравномерно, — в поддержке, эксплуатации, непрерывной разработке; его легко начать поверх текущих процессов. По методике это простой инструмент (18 часов на освоение). Он управляет потоком, но сам по себе не планирует сроки и бюджет — для календарного плана берут диаграмму Ганта (B2-02), а для разовых проектов с фиксированным результатом ближе проектные методологии группы B1. Канбан часто сочетают со Scrum (B1-05). Не путать с производственным канбаном (A3-02): общий корень, но разные области применения.

Чек-лист перед внедрением Канбана:

Процесс разбит на понятные стадии — колонки доски (очередь, в работе, проверка, готово).
Все задачи вынесены на доску карточками, статус виден всей команде.
Установлены лимиты незавершенной работы (WIP) на ключевых стадиях.
Заданы понятные правила: когда задача переходит в следующую колонку.
Налажен регулярный разбор потока и узких мест.
Доска поддерживается в актуальном состоянии всеми участниками.

Типовые ошибки:

Доска без лимитов. Доску завели, но лимиты незавершенной работы не ввели — команда по-прежнему распыляется. → Установить лимиты WIP на стадиях, это ядро метода.
Доска не отражает реальность. Карточки не двигают вовремя, статус устаревает. → Поддерживать доску в актуальном состоянии, сделать это правилом.
Узкие места игнорируют. Видят застой в колонке, но ничего не меняют. → Регулярно разбирать поток и расшивать узкие места.
Путают с производственным канбаном. Переносят правила цехового канбана (A3-02) на проектные задачи. → Различать: A3-02 — поток материалов, B2-03 — поток задач команды.

B2-04 — Иерархическая структура работ (Work Breakdown Structure, WBS)

Откуда появился инструмент. WBS родилась в крупных оборонных проектах США. В 1957 году ВМС США запустили метод PERT для программы баллистической ракеты «Поларис», где работы впервые разложили по продуктовым категориям. В июне 1962 года Министерство обороны, NASA и аэрокосмическая отрасль выпустили руководство по системе PERT/COST, где этот подход был описан как структура разбиения работ. Само название «work breakdown structure» закрепилось в 1968 году в военном стандарте MIL-STD-881, сделавшем WBS обязательной в оборонных проектах. Позже метод перешел в гражданское управление проектами, и его описал PMI в своде знаний.

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

Пример. Проект «запуск нового цеха» на словах выглядит неподъемным монолитом. WBS разбивает его на блоки: подготовка помещения, закупка оборудования, монтаж, пусконаладка, обучение персонала. Каждый блок дробят дальше: «монтаж» — на установку линий, подключение энергии, проверку. На нижнем уровне задачи уже понятны: их можно оценить по времени и стоимости и поручить конкретным людям. Из этой структуры затем вырастают и график (B2-02), и смета проекта.

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

Границы применимости. WBS полезна почти в любом проекте сложнее тривиального и служит фундаментом для планирования — это простой инструмент (18 часов на освоение). Она показывает, из чего состоит проект, но не задает сроки и последовательность: это делают Диаграмма Ганта (B2-02) и метод критического пути (B2-05), которые строят поверх WBS. Слишком дробная структура порождает лишнюю бюрократию, слишком крупная — не дает оценить работы; уровень детализации подбирают по управляемости.

Чек-лист перед построением WBS:

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

Типовые ошибки:

Пропуски в объеме. В структуру не попали часть работ, и они всплывают по ходу. → Проверять полноту: сумма элементов должна давать весь проект (правило 100%).
Слишком крупные блоки. Декомпозицию остановили рано, задачи неоценимы. → Дробить до уровня, на котором понятны сроки, стоимость и ответственный.
Излишняя детализация. Структуру дробят до микрозадач, плодя бюрократию. → Останавливаться на управляемом уровне, не уходя в избыточные мелочи.
WBS отдельно от плана. Структуру построили, но график и смету делают в отрыве от нее. → Строить график (B2-02) и бюджет на основе WBS.

Резюме

Эти четыре инструмента — азбука планирования проектов, и осваиваются они легче всего в цикле (12–18 часов на освоение). Их сила в наглядности: каждый превращает неосязаемое в видимую форму — идею в официальный паспорт, объем работ в дерево задач, план в полосы на шкале времени, текущую работу в карточки на доске. Поэтому с них и начинают: они дают команде общий язык и общую картину еще до того, как в ход идут тяжелые методологии. Но наглядность не отменяет дисциплину: паспорт без утверждения спонсора не дает полномочий, диаграмма Ганта и доска канбан бесполезны, если их не поддерживать в актуальном состоянии, а WBS с пропусками в объеме подведет и график, и смету. Эти инструменты делают проект видимым, но честную картину дают только при аккуратном ведении.

В следующей статье цикла продолжим разбор подгруппы B2 «Визуализация и планирование» — продвинутыми инструментами: метод критического пути (CPM, B2-05), метод освоенного объема (EVM, B2-06), нотация BPMN (B2-07) и сети Петри (B2-08).