Я два года искал причину срывов сроков и обнаружил, что календарь здесь почти ни при чем

Аннотация

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

Вступление

Долгое время я объяснял задержки одинаково: неправильно оценил объем работы, клиент поздно прислал материалы, подрядчик подвел, задача оказалась сложнее, чем выглядела на старте. Каждое объяснение звучало убедительно. Проблема была в том, что они повторялись почти в каждом проекте.

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

В какой-то момент я понял, что спорить с отдельными причинами бессмысленно. Мне нужна была не очередная техника планирования, а нормальная модель происходящего. Я выгрузил данные из таск-трекера, календаря, переписки и таблиц учета времени за два года. В выборку попали 47 проектов: запуски сайтов, рекламные кампании, интеграции, внутренние инструменты и несколько небольших продуктов. После очистки данных осталось около 2 800 задач и чуть больше 11 000 изменений статусов.

Я рассчитывал найти ошибку в оценке трудозатрат. Нашел другое.

1. Я начал измерять не длительность задач, а время между действиями

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

Я разделил календарное время каждой задачи на три части. Первая — активная работа, когда над задачей действительно что-то делали. Вторая — техническое ожидание, необходимое по процессу: выгрузка данных, модерация рекламной системы, индексация, сбор статистики. Третья — организационное ожидание, когда задача стояла без движения, хотя технических причин для этого не было.

Для анализа я использовал несколько показателей:

1. активное время задачи — сумма периодов, когда исполнитель непосредственно работал над результатом;
2. время ожидания — промежутки между изменениями статуса, комментариями, загрузкой файлов и фактическим продолжением работы;
3. коэффициент потока — отношение активного времени ко всему календарному времени задачи;
4. глубина возврата — количество этапов, на которые задача откатывалась после проверки;
5. возраст незавершенной работы — сколько времени задача находилась в системе с момента старта;
6. число передач — сколько раз задача переходила от одного участника к другому;
7. скрытая очередь — количество задач, назначенных исполнителю одновременно, но не находившихся в активной работе.

Результат оказался неприятным. Средний коэффициент потока по всем проектам составлял около 0,18. Это означало, что задача находилась в активной работе примерно 18 процентов времени. Остальные 82 процента она ожидала следующего действия. Даже после исключения выходных и объективных технических пауз доля организационного ожидания оставалась выше половины общего срока.

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

Раньше я записал бы этот случай как задержку дизайна и верстки. По данным это была задержка принятия решений.

2. Главной причиной оказалась не сложность, а незавершенность входных условий

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

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

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

1. измеримый результат проекта и критерий его приемки;
2. список обязательных материалов и ответственные за их предоставление;
3. границы полномочий участников;
4. порядок принятия спорных решений;
5. технические ограничения;
6. список зависимостей от других команд;
7. допустимый объем изменений после старта;
8. согласованная последовательность этапов.

Проекты с высокой готовностью в среднем отклонялись от первоначального срока примерно на 12–18 процентов. Проекты, которые запускались с формулировкой детали уточним по ходу, задерживались на 60–90 процентов. В нескольких случаях фактическая продолжительность превышала план более чем в два раза.

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

В одном проекте мы две недели собирали внутреннюю панель отчетности. Технически задача была несложной: подключить три источника, нормализовать данные и вывести основные показатели. На старте заказчик попросил показать продажи, эффективность рекламы и поведение пользователей. Формулировка казалась достаточной.

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

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

3. Я нашел повторяющийся сценарий, который незаметно удлинял почти каждый проект

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

Так появлялась задержка второго порядка. Первичное ожидание могло длиться два дня, однако задача продолжалась только через неделю, потому что свободное окно у специалиста уже исчезло. Один день неопределенности на входе превращался в несколько дней календарной задержки.

Я назвал это эффектом повторной постановки в очередь. В обычном плане он невидим. Руководитель видит, что ответ задержали на два дня, и ожидает сдвиг примерно на те же два дня. В реальности задержка зависит от загрузки следующего участника. Если специалист ведет четыре проекта параллельно, возвращенная задача не продолжает движение с места остановки. Она встает в конец внутренней очереди.

На одном из запусков нам потребовалось согласовать способ передачи заявок в CRM. Решение заняло около часа, но согласование откладывалось три рабочих дня. За это время разработчик переключился на другую интеграцию. Когда ответ пришел, вернуться к первой задаче он смог только через шесть дней. Затем тестировщик уже был занят другим релизом, и проверка сдвинулась еще на четыре дня. Формально исходная задержка составляла три дня. Фактическое влияние на проект — почти две недели.

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

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

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

4. Я перестроил управление проектами вокруг скорости принятия решений

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

Я не пытался заранее описать каждую мелочь. Это превратило бы подготовку в бесконечное составление документов. Мне было важно другое: любой ожидаемый вопрос должен иметь понятный способ решения. Если точного ответа пока нет, должно быть известно, кто его принимает, на основании каких данных и за какое время.

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

Теперь блокировка фиксировалась отдельно. У нее появлялся ответственный, срок ответа и описание последствий. Это изменило характер обсуждений. Фраза ждем согласования почти исчезла, потому что стала недостаточной. Нужно было указать, чье решение требуется и какая часть проекта остановится без него.

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

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

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

За следующие полгода я сравнил десять новых проектов с предыдущей выборкой. Масштаб был разным, поэтому прямое сравнение неидеально. Тем не менее медианное отклонение от планового срока сократилось примерно с 46 до 19 процентов. Количество задач, возвращавшихся более чем на один этап назад, уменьшилось почти вдвое. Самым заметным изменением стало сокращение периода, когда проект формально идет, но несколько дней не производит законченного результата.

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

Вывод

Два года я пытался исправить сроки через более подробные планы. Добавлял контрольные точки, дробил задачи, требовал чаще обновлять статусы. Это улучшало видимость проекта, но почти не влияло на его скорость. Я точнее видел задержку, однако продолжал создавать условия, в которых она возникала.

Главная закономерность оказалась такой: проекты затягивались не потому, что команда медленно выполняла работу. Они затягивались из-за несвоевременных решений, незавершенных входных условий и повторного попадания задач в очередь. Чем больше параллельной работы мы открывали, тем дороже становилась каждая небольшая пауза.

Сейчас перед стартом я задаю не вопрос, насколько подробно составлен план. Меня интересует, где проект может остановиться и кто в этот момент примет решение. Затем я смотрю, сможет ли команда вернуться к задаче сразу после ответа или она потеряется среди других обязательств.

Эта проверка занимает меньше времени, чем составление идеального графика. И, как показала моя статистика, влияет на срок сильнее, чем попытки угадать продолжительность каждой отдельной задачи.