Календарь проекта внедрения почти не сократился, потому что написание кода никогда не было его основной частью. В модельном проекте на 10 недель разработка занимала 19 рабочих дней из 50 — этот календарь мы разбирали в статье про сроки проекта автоматизации. За два года инструменты сжали эти 19 дней до 11. Календарь при этом сократился с 50 рабочих дней до 45 — на одну неделю из десяти, а не на две.
Разрыв объясняется без всякой мистики. Пока разработка была длинной, внутри неё помещались ожидания: подрядчик писал код, параллельно ожидая доступ к тестовому контуру, ответ на вопрос о правилах скидок и выгрузку справочника. Эти ожидания были, но их не было видно в графике. Когда разработка ужалась, прятать их стало негде — и четыре рабочих дня чистого ожидания вышли наружу отдельной строкой.
Ниже — разложение календаря того же проекта в 2024 и в сентябре 2026 года, честная нижняя граница срока, цена участия вашей команды в часах и рублях и разбор того, что действительно сжимается, а что подрядчик просто перекладывает на вас, когда обещает «две недели».
Что действительно ускорилось за два года
Ускорилось три вещи, и все три относятся к работе подрядчика внутри его собственного контура. Это важная оговорка: инструмент помогает там, где человек пишет, а не там, где человек согласовывает.
- Написание типового кода. Обвязка интеграции, разбор форматов, тесты, миграции справочников — то, что раньше набиралось руками, теперь генерируется и вычитывается. Здесь сжатие самое большое.
- Повторное применение готовых сборок. Второй похожий проект в том же контуре стоит заметно дешевле первого: в разборе агентного ИИ на практике второй агент в той же компании обошёлся в 183 000 ₽ против 420 000 ₽ за первый — просто потому, что журнал, тестовый контур и инструменты уже были написаны.
- Документация и тестовые данные. Описание интеграции, схемы обмена, набор проверочных случаев — это больше не отдельная неделя в конце проекта.
Не ускорилось всё остальное, и оно составляет большую часть календаря. Здесь стоит быть точным: речь не о том, что подрядчик работает медленно, а о том, что часть работ физически идёт со скоростью вашей компании — с той, с которой у вас назначаются совещания, выдаются учётные записи и принимаются решения о том, как на самом деле считается скидка постоянному клиенту.
Тот же проект в 2024 и в 2026 году
Модельный проект: связка учётной системы и CRM плюс автоматический разбор входящих накладных. Компания на 60 человек, две системы, один справочник контрагентов в неудовлетворительном состоянии. В 2024 году такой проект занимал 10 недель, то есть 50 рабочих дней.
| Этап | 2024, рабочих дней | 2026, рабочих дней | Что изменилось |
|---|---|---|---|
| Согласование границ и постановка задачи | 7 | 7 | Ничего: упирается в календарь совещаний |
| Получение доступов и учётных записей | 6 | 6 | Ничего: упирается в регламент и отпуска |
| Разбор и приведение данных в порядок | 9 | 8 | Минус день: расхождения видны быстрее, решения по ним принимает человек |
| Разработка и интеграции | 19 | 11 | Минус 8 дней: генерация кода, готовые коннекторы, повторное применение сборок |
| Тестирование на реальных данных | 5 | 5 | Ничего: считается по занятости ваших сотрудников |
| Обучение и приёмка | 4 | 4 | Ничего: считается по людям, а не по строкам кода |
| Сумма этапов | 50 | 41 | Минус 18 % |
| Календарь проекта | 50 дней, 10 недель | 45 дней, 9 недель | Минус 10 % |
Две горизонтальные полосы-календаря друг под другом, обе размечены в рабочих днях. Верхняя подписана «2024, 50 дней»: сегменты «границы 7», «доступы 6», «данные 9», «разработка 19», «тестирование 5», «приёмка 4». Нижняя подписана «2026, 45 дней»: те же сегменты со значениями 7, 6, 8, 11, 5, 4 и отдельный заштрихованный сегмент «ожидание 4». Сегмент «разработка» на обеих полосах выделен цветом, между ними стрелка с подписью «19 → 11». Справа подписи «сумма этапов −18 %» и «календарь −10 %». Все надписи по-русски.
Куда делись четыре сэкономленных дня
Сумма этапов в 2026 году — 41 рабочий день, а календарь — 45. Разница в четыре дня и есть то самое ожидание, которое раньше было незаметно. Оно складывается из мелочей: полтора дня на выдачу доступа к тестовой базе, день на ответ «а как считается скидка для этой группы клиентов», полдня на согласование формата номенклатуры, день на то, чтобы бухгалтер нашёл время выгрузить нужный срез первички.
В 2024 году эти же четыре дня существовали, но лежали внутри девятнадцатидневной разработки — подрядчик просто занимался другой частью задачи. Ускорив разработку, вы не убрали ожидание, вы сняли с него маскировку. Это неприятная, но полезная новость: то, что видно в графике, можно сокращать, а то, что спрятано, — нельзя.
Схема из двух горизонтальных дорожек. Верхняя подписана «подрядчик»: блоки «разбор данных», «разработка 11 дней», «тестирование», «сдача». Нижняя подписана «заказчик»: блоки «решение о границах», «выдача доступов», «выгрузка справочников», «участие в тестах», «приёмка». Между дорожками пять вертикальных стрелок-стыков, каждая подписана числом дней ожидания, в сумме 4 дня. Красной линией выделен критический путь — он идёт по нижней дорожке. Внизу подпись: «нижняя граница календаря — 34 рабочих дня, около 7 недель». Подписи по-русски, чертёжный стиль.
Уберите разработку целиком — представьте, что код появляется мгновенно и бесплатно. Останутся согласование границ (7 дней), доступы (6), разбор данных (8), тестирование (5), обучение и приёмка (4) и те же 4 дня ожиданий на стыках. Это 34 рабочих дня, около семи недель, и эту границу задаёт не подрядчик, а темп вашей компании. Любое предложение «за две недели» либо описывает не проект, а его часть, либо переносит эти семь недель за границу договора.
80 часов, которые нельзя купить
Главный ограничитель календаря — не бюджет и не квалификация подрядчика, а занятость людей заказчика. У владельца процесса проект не единственная работа: типично он даёт ему четыре часа в неделю, и это не лень, а нормальная загрузка руководителя подразделения. Из этих часов и складывается скорость принятия решений — а значит, и календарь. Что происходит, когда владельца процесса нет вообще, мы разбирали отдельно: проект без владельца процесса встаёт не на этапе разработки, а на этапе первого спорного вопроса.
Эти 80 часов — не накладные расходы, а часть проекта. Их нельзя делегировать: подрядчик не может вместо вас решить, кто согласовывает скидку выше 15 %, и не может вместо кладовщика проверить, что распознанная накладная совпала с приходом. Именно поэтому попытка «ускориться, наняв подрядчика подороже» почти никогда не сокращает календарь: вы удорожаете ту часть, которая и так не была узким местом. Как эти роли распределяются по проекту, подробно разобрано в материале про то, кто что делает в проекте автоматизации.
Горизонтальная столбчатая диаграмма из четырёх строк, единицы — часы: «владелец процесса — 36 ч (64 800 ₽)», «два сотрудника на тестах — 24 ч (16 800 ₽)», «бухгалтер — 14 ч (11 816 ₽)», «собственник — 6 ч (15 000 ₽)». Справа итоговая плашка «80 часов, 108 416 ₽ — 18 % бюджета проекта в 600 000 ₽». Ось подписана «часы за 9 недель проекта». Все подписи по-русски.
Что сжимается честно, а что просто переносят на вас
Полезно разделить работы на две группы: те, где инструмент действительно сокращает время, и те, где сокращение возможно только за счёт переноса работы на заказчика или отказа от неё.
| Работа | Сжимается инструментами | Что происходит на практике |
|---|---|---|
| Прототип экрана или диалога | Да, в разы | Два дня вместо недели, но прототип — это не проект |
| Типовая интеграция по документированному API | Да, заметно | 3 дня вместо 8, если API живой и доступы уже выданы |
| Документация, тестовые данные, миграции | Да | Генерируется, остаётся вычитка инженером |
| Разбор чужих данных | Частично | Расхождения видны быстрее, но решение по каждому принимает человек |
| Получение доступов | Нет | Зависит от регламента, отпусков и того, у кого лежит пароль |
| Решения о правилах процесса | Нет | Идёт со скоростью совещаний, а не со скоростью кода |
| Тестирование, обучение, приёмка | Нет | Считается по занятости людей: 24 часа в модельном проекте |
Отсюда и правильное чтение обещания «сделаем за две недели». В 2026 году оно стало технически правдоподобнее — и от этого опаснее. Две недели — реальный срок сборки прототипа или одной интеграции по живому API при готовых доступах. Это не срок проекта: за границей двух недель остаются разбор данных, тестирование на реальном потоке и приёмка, то есть те самые 34 дня нижней границы. Разбор того, что стоит за таким обещанием, есть в отдельной статье: «сделаем за неделю» как красный флаг.
Как сократить срок по-настоящему
Раз доля разработки в календаре упала с 38 % до 24 %, ценность подготовки заказчика выросла: теперь она не «немного помогает», а определяет срок. Для компании на 30–100 человек это означает конкретную домашнюю работу до старта — и ровно в такой последовательности.
- 1Собрать доступы одним списком до подписания. Учётные записи в обеих системах, тестовый контур, доступ к почтовому ящику, из которого приходят накладные, права на выгрузку справочников. Шесть позиций, собранные заранее, снимают из календаря целый этап в 6 дней.
- 2Назначить одного человека, принимающего решения, и записать его четыре часа в неделю в его же план. Не комитет и не «согласуем со всеми»: комитет добавляет к каждому спорному вопросу неделю ожидания.
- 3Выгрузить справочники и посмотреть на них самому. Дубли контрагентов, пустые единицы измерения, номенклатура в свободной форме — это 8 дней этапа данных, и половина из них уходит на решения, которые может принять только заказчик. Что именно смотреть, разобрано в материале про данные перед внедрением.
- 4Разрешить приёмку по этапам. Когда решения копятся к финалу, они превращаются в одно длинное совещание и две недели правок. Приёмка по частям растворяет их в календаре и не даёт ожиданию накопиться.
Эти четыре действия не требуют денег и не зависят от подрядчика. В модельном проекте они убирают этап доступов целиком и половину ожиданий на стыках — это около трёх недель. Дальше сокращать календарь можно только уменьшением объёма: брать один процесс вместо трёх, отказаться от второй интеграции в первой очереди, вынести отчётность во вторую итерацию.
Что из этого устареет первым и как это заметить
Первым устареет число 11. Разработка — единственная строка календаря, которая двигается быстро, и через год она вполне может стать 7–8 днями. Заметить это просто: если подрядчик показывает работающий прототип на реальных данных в первую неделю, а не на третьей, значит, сборка снова подешевела. На календарь проекта это повлияет слабо — нижняя граница в 34 дня останется прежней, а доля разработки просто упадёт с 24 % до 15 %.
Вторым устареет этап доступов, но не из-за инструментов, а из-за порядка внутри компаний: там, где заведён нормальный реестр систем и владельцев, шесть дней превращаются в один. Это единственная строка таблицы, которую вы можете сократить приказом.
Что почти наверняка не изменится за ближайший год — темп принятия решений и участие людей в тестировании. Признак, по которому это стоит перепроверять: если у вас проект начал занимать заметно меньше девяти недель без изменения объёма, посмотрите, не переехало ли сокращение в пропущенную опытную эксплуатацию. Обычно переехало, и счёт приходит через квартал в виде правок.
Когда сокращать срок не надо
Есть три ситуации, в которых борьба за календарь приносит убыток, а не выгоду.
- Процесс не описан и меняется прямо сейчас. Ускорять внедрение поверх нерешённого процесса — это оплатить переделку заранее. Сначала решение о том, как процесс устроен, потом сроки.
- Сокращение идёт за счёт опытной эксплуатации. Две недели параллельной работы старого и нового контура — не запас на всякий случай, а этап, на котором вылезают расхождения в данных. Убрав его, вы получите те же дни, но уже после запуска и с испорченными данными.
- Экономия времени не превращается в деньги. Если процесс сезонный и результат всё равно понадобится к декабрю, три недели выигрыша в сентябре не стоят ни рубля. Как считать эту разницу — в материале про то, что считать экономией от автоматизации.
Проект идёт со скоростью самой медленной дорожки. Последние два года ускоряли не ту.
