Лекция 4. Сроки, оценки и критический путь. Базовый курс.

Лекция 4. Сроки, оценки и критический путь. Базовый курс.

Если предыдущие два блока были про то, что мы делаем, то этот — про то, сколько это займёт. Самый частый вопрос в управлении проектами: «А когда будет готово?». И самый частый неправильный ответ: «Где-то месяца через три». Сегодня мы разберём, как отвечать на этот вопрос правильно — так, чтобы и срок был реалистичным, и заказчик был доволен, и команда вас не проклинала. Спойлер: секрет не в волшебной формуле, а в честной оценке и правильной математике.

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

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

Отдельно стоит поговорить о печально известном законе Паркинсона и его брате — студенческом синдроме. Закон Паркинсона: работа заполняет всё отпущенное на неё время. Если вы дадите задаче две недели, она займёт две недели, даже если реально её можно сделать за три дня. Студенческий синдром: люди начинают работать за два дня до дедлайна. Что из этого следует? Никогда не сидится просто: «запас в срок» бессмысленен, если люди знают срок. Секрет в том, чтобы закладывать запас невидимо для команды: планируйте на реалистичную продолжительность, но в коммуникации с заказчиком держите буфер. Команда работает по понятному графику, а не по игре «успей до дедлайна».

Теперь про главный инструмент этого блока — сетевой график. Когда у вас есть WBS со списком задач, вы начинаете соединять задачи связями: какая задача должна закончиться, чтобы началась следующая? Например: «сделать проект» и «утвердить проект» — связаны: второе невозможно без первого. «Установить оборудование» и «обучить персонал» — связаны: сначала оборудование, потом обучение. Когда все связи расставлены, получается сеть — граф, по которому видно, какие работы идут последовательно, а какие параллельно. Сетевой график — это, по сути, карта последовательности работ, и именно из неё рождается реалистичный срок проекта.

А из сетевого графика появляется критический путь. Критический путь — это самая длинная цепочка зависимых задач, которая определяет общую продолжительность проекта. Если любая задача на критическом пути задержится — задержится весь проект. Если задача не на критическом пути задержится — проект может не пострадать, если задержка укладывается в «запас» этой задачи. Критический путь — это буквально нерв проекта: он показывает, что должно идти без задержек, а не прощает их. В каждом проекте есть минимум один критический путь, а часто их несколько — например, техническая разработка и параллельно с ней подготовка помещения. Задержка на любом критическом пути сдвигает весь проект.

Как находят критический путь? Классический метод CPM — метод критического пути — считает четыре цифры для каждой задачи: ранний старт (самое раннее время начала), ранний финиш (самое раннее время окончания), поздний старт (самое позднее время начала, чтобы не сорвать проект) и поздний финиш. Разница между поздним и ранним — это запас задачи: сколько задача может задержаться, не навредив проекту. У задач на критическом пути запас равен нулю. Считать это вручную для большого проекта — мучение, но понимать логику важно. Всё это делают программы вроде Microsoft Project, но если вы не понимаете, что программа считает, вы не поймёте и почему она выдаёт ту или иную дату.

К слову о программах. Диаграмма Ганта — это шкала времени, на которой задачи нарисованы полосками: где начинаются, где заканчиваются, кто за них отвечает, какие между ними связи. Это, пожалуй, самый популярный визуальный инструмент менеджера проектов. Но только не думайте, что диаграмма Ганта — это и есть план. Диаграмма Ганта — это экран, на котором отображается план. Сам план — это содержание (WBS), оценки и связи. Многие новички борются с красивой диаграммой, не имея за ней содержания, — и получают красивый рисунок, по которому нельзя работать. Сначала WBS и оценки, потом Гант, только в этом порядке.

Важный сюжет — сжатие сроков. Что делать, если директор говорит «срок нереалистичен, четыре месяца вместо шести»? Вариантов четыре. Первый: сократить содержание — по-английски scope reduction. Убрать часть функций, этапов, «приятных бонусов». Это честный путь. Второй: параллельное выполнение — fast tracking. Делать задачи, которые обычно последовательны, частично параллельно: начать тестирование, не дожидаясь окончания всей разработки. Это экономит время, но добавляет риска: придётся переделывать, если требования сместились. Третий: добавление ресурсов — crashing. Нанять больше людей, работать в две смены, заплатить за сверхурочные. Это дорого и не всегда работает: в некоторых задачах больше людей не помогают — «девять женщин не родят ребёнка за месяц». Четвёртый: пересмотр техпроцесса — изменить метод работы. И вот менеджер должен объяснить директору: сжать сроки можно, но за что-то из этого придётся заплатить.

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

Оценки — это ещё и про статистику. Есть простой, но очень полезный метод трёх точек: на каждую задачу эксперт даёт три оценки — оптимистичную (всё пойдёт идеально), реалистичную (как обычно) и пессимистичную (всё пойдёт по плохому сценарию). Формула расчёта: (оптимистичная + 4 × реалистичная + пессимистичная) / 6. Плюс — она выводит на свет вашу неопределённость: если задача из «двух-трёх дней» на самом деле «от одного дня до двух недель» — это уже плохая новость, и её лучше знать заранее. Метод трёх точек заставляет и менеджера, и экспертов честно признать: «мы не знаем точно, но вот диапазон».

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

Не забываем и про буферы. В суровом мире проектов есть правило: закладывайте резерв на непредвиденное. Обычно 5-15% к продолжительности и 5-10% к бюджету, в зависимости от рисковости проекта. Резерв — это не распущенность, это профессиональный стандарт: вы заранее договариваетесь, что непредвиденное случится, и закладываете на это деньги и время. Ключевой момент: резервом управляет менеджер, а не заказчик. Если заказчик знает, что у вас есть резерв, он его «съест» на «мелкие пожелания». Поэтому про резерв лучше не распространяться: он существует для страховки, а не для раздачи.

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

И про роль менеджера в сроках. Менеджер — не тот, кто «знает сроки», а тот, кто их создаёт и защищает. Создаёт: инициирует оценку, собирает цифры у команды, строит сетевой график, находит критический путь, закладывает буферы. Защищает: не даёт «мелким пожеланиям» молча растягивать план, ведёт официальный реестр изменений, показывает заказчику последствия по каждому «а давайте», говорит «нет» там, где нужно. И, пожалуй, самое главное: предупреждает о задержках сразу, а не в последний день. Плохой менеджер: «всё идёт по плану» до самого конца, а потом «так получилось». Хороший менеджер: «на третьей неделе мы увидели отклонение, вот что мы делаем, чтобы вернуться в график».

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

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