Почему ИТ-проекты оказываются сложнее, чем кажется в начале
Заказчики приходят с понятной задачей, чётким дедлайном и уверенностью, что основное уже продумано. Именно в этот момент и закладываются сложности, которые потом приводят к пересмотру сроков и бюджета. Джон Серебряков, руководитель проектного офиса Nord Clan рассказывает, где именно скрываются паттерны потерь и как их распознать до старта.
«Быстро подключить интеграцию» не получится
Когда заказчик говорит «нам нужно подключить это к нашей системе», он обычно представляет несложную техническую операцию. На практике интеграция — особенно с тем, что «как-то работает уже 10 лет» — почти всегда оказывается самым трудоёмким местом проекта.
Причина в том, что старые системы часто не имеют нормальной документации, работают через нестандартные протоколы и держатся на решениях, которые никто уже не помнит зачем принимал. Нередко оказывается, что документация описывает одну версию системы, а в работе уже давно используется другая. Часть бизнес-логики вообще может находиться в промежуточных сервисах, которые никогда не документировались. Любое вмешательство в такую систему требует осторожности и времени — а времени в плане, как правило, нет.
На банковских проектах, например, взаимодействие между системами идёт через шину. По этой причине работы на стороне другого подрядчика нужно планировать задолго до старта — иначе к моменту запуска окажется, что нужный компонент просто не готов. Проект может встать потому что никто не синхронизировал графики с подрядчиком на этапе планирования. Иногда собственная разработка уже готова, но внедрить ее невозможно: у смежной команды свое релизное окно, которое открывается раз в две недели или даже раз в месяц.
Именно поэтому опытные команды начинают планирование интеграций не с оценки разработки, а с проверки внешних зависимостей и релизных календарей всех участников проекта. Во многих случаях именно они определяют реальные сроки внедрения.
Процессы на бумаге и процессы в жизни — это разные процессы
Почти в каждом проекте выясняется, что реальные бизнес-процессы не совпадают с тем, что нарисовано в презентации заказчика. Причина проста — то, как всё описано на бумаге, и то, как люди реально работают каждый день, на практике расходится. Один отдел придумал обходной путь, другой ведёт учёт в Excel, третий фиксирует решения устно — и этот рассинхроне не является проблемой до тех пор пока не начинается автоматизация бизнес-процессов.
На этапе обследования становится понятно, что данные представлены в разных форматах, часть операций выполняется вручную без какой-либо фиксации, а «стандартный процесс» на самом деле в каждом филиале работает по-своему.
Здесь действует правило, знакомое всем, кто занимался ИИ-решениями: качество данных важнее качества алгоритма. Если требования сформулированы расплывчато, а источники данных не проверены, разработка строится на песке — и дальше система начинает тиражировать ошибки в промышленном масштабе. По этой причине обследование — не опция, а обязательный этап. Команда, которая пропускает его ради экономии двух недель, потом тратит месяц на переделку.
У каждого отдела своя правда
Даже когда процессы описаны и данные в порядке, все равно остаётся сложность в согласовании интересов всех сторон. У разных отделов внутри одной компании разные представления о том, что должна делать система. Продажи хотят одно, маркетинг — другое, финансы не понимают, зачем нужна автоматизация именно сейчас. Каждый уверен в своей правоте.
Задача руководителя проекта в этой ситуации — выстроить процесс, в котором все ключевые решения принимаются осознанно и фиксируются письменно. Работа с людьми и согласованиями занимает не меньше времени, чем разработка. Это нормально, и это нужно закладывать в план.
Что почти всегда забывают посчитать
Есть несколько статей, которые регулярно выпадают из оценки.
Первое — управление проектом, архитектура и тестирование. Особенно регрессионное и нагрузочное: их объём сильно недооценивают. Во многих корпоративных проектах отдельное время требуется и на приемочные испытания. Если систему используют несколько подразделений, замечания поступают не одновременно, а волнами.
Второе — работа с контентом и данными. «Просто перенести» не работает: данные нужно мигрировать, чистить, приводить к нужному формату, и это отдельный проект внутри проекта. Даже если ошибок всего один процент, при базе в миллион записей это уже десять тысяч карточек, которые невозможно перенести автоматически.
Третье — время самой команды заказчика. Согласования, ответы на вопросы, участие в демо — всё это занимает часы, которые редко закладываются в план реализации. Когда заказчик перегружен операционкой, проект встает.
Но все это — лишь стоимость первой версии системы. После запуска появляются расходы на сопровождение, развитие функциональности, подключение новых модулей и устранение накопленного технического долга.
Поэтому при оценке проекта важно считать не только стоимость разработки, но и стоимость владения системой в течение нескольких лет. Экономия на проектировании и тестировании в итоге почти всегда обходится дороже самой инвестиции.
Разумные решения могут оказаться неправильными
«Сейчас быстро сделаем, потом нормально перепишем» — одно из самых распространённых заблуждений в ИТ-проектах. Переписать потом зачастую не получается. На быстрое решение начинают опираться другие части системы, накапливается технический долг, и стоимость исправления со временем только растёт. Через несколько месяцев оказывается, что временное решение уже используют пять-шесть других компонентов системы. Его замена превращается не в небольшую доработку, а в отдельный проект с новыми рисками. Поэтому любое решение, принятое "на первое время", стоит оценивать так, будто оно останется в системе на годы.
Выбор технологии «потому что модно» работает по той же логике. Технология должна подходить под задачу, а не наоборот. Если команда хорошо знает определённый стек, это аргумент — но не главный. Главный — насколько эффективно инструмент решает конкретную задачу конкретного проекта. Не менее важно учитывать зрелость технологии, наличие специалистов на рынке, стоимость сопровождения и совместимость с инфраструктурой заказчика. Именно эти факторы обычно определяют, насколько система будет поддерживаемой через три-пять лет после запуска.
Третье ошибочное решение — попытка зафиксировать в контракте все детали на старте меняющегося проекта. С одной стороны создаётся иллюзию контроля, с другой — она не защищает ни заказчика, ни подрядчика. Реальность меняется быстрее, чем успевают согласовать документы.Поэтому в крупных проектах важнее заранее договориться о том, как будут приниматься изменения, чем пытаться предусмотреть их все еще до начала разработки.
Как мы видим на практике, три вполне разумных решения часто оказываются неправильными и ведут к потерям.
Проект редко ломается внезапно
Почти любой срыв проекта можно заметить заранее. Обычно за несколько недель или месяцев до него появляются сигналы, которые команда постепенно начинает воспринимать как норму. Релизы все чаще приходится откатывать, тестирование сокращают, чтобы уложиться в срок, а исправление ошибок занимает все больше времени. Это означает, что система начинает работать на пределе своих возможностей, а технический долг постепенно накапливается.
Одновременно команде становится всё сложнее развивать продукт. Всё больше времени уходит на устранение ошибок, новые задачи выполняются медленнее, а архитектура перестает справляться с постоянными изменениями. Если при этом систему может полноценно поддерживать только один специалист, это становится дополнительным риском для проекта.
По отдельности ни один из этих признаков может не выглядеть критичным. Но вместе они говорят о том, что первоначальный план уже перестал соответствовать реальной ситуации, даже если официально проект всё ещё находится «в графике». Чем раньше команда замечает такие сигналы и обсуждает их с заказчиком, тем больше шансов скорректировать план до того, как проблема перерастёт в срыв сроков.
Полностью предусмотреть все изменения в ИТ-проекте невозможно. По мере работы появляются новые требования, обнаруживаются ограничения существующих систем, уточняются бизнес-процессы и возникают внешние зависимости. По этой причине лучше заранее определить, как команда будет работать с такими изменениями: кто принимает решения, в каких случаях пересматриваются сроки и бюджет, как оценивается влияние новых требований на проект. Именно превентивная подготовка к изменениям помогает сохранить управляемость проекта, даже когда первоначальный план приходится корректировать.
Почему срываются сроки — и что с этим делать
Причины срыва сроков — просты и предсказуемы. Первая — изменения по ходу проекта без пересмотра плана. Заказчик добавляет требование, команда молча берёт его в работу, и дедлайн незаметно становится нереалистичным. Каждое изменение должно сопровождаться оценкой его влияния на проект и, при необходимости,пересмотром сроков и бюджета.
Вторая причина — задержки на стороне заказчика. Нужны доступы, нужны решения, нужны ответы — а они не приходят. Команда ждёт, время идёт, дедлайн приближается. Чтобы этого избежать, договорённости о времени реакции нужно фиксировать на старте в самом контракте — как и ответственного со стороны заказчика, который может принимать оперативные решения.Это помогает соблюдать график не хуже, чем дополнительный резерв времени в оценке.
Третья — скрытые зависимости, которые всплывают уже в разработке. Оказывается, что сторонняя система не поддерживает нужный формат, или подрядчик не успевает к нужному сроку, или данные находятся в таком состоянии, что их нельзя использовать без предварительной очистки. Полностью предотвратить это невозможно, но чем раньше такие зависимости выявлены — тем меньше они обходятся заказчику. Именно для этого нужно обследование на старте проекта
Наконец, управление проектом само требует времени. Если руководитель проекта одновременно пишет техническое задание, согласовывает требования и постоянно решает оперативные проблемы, контроль рисков неизбежно отходит на второй план. Между тем именно управление рисками, проверка зависимостей и постоянная актуализация предположений позволяют сохранить проект управляемым по мере его развития.
Что забрать с собой
Большинство проблем в ИТ-проектах не возникают внезапно. Они закладываются на старте — в местах, которые казались понятными и не требующими отдельного внимания. Именно поэтому обследование в начале проекта — не формальность: оно вскрывает реальные данные, требования и внешние зависимости, которые в итоге определяют сроки куда сильнее, чем любая оценка команды разработки. Внешние зависимости обнаруживаются — и вместе с ними становится видно, какие решения придётся принимать наспех. Такие решения, принятые «на первое время», со временем обрастают зависимостями и остаются в системе на годы — вместе со стоимостью поддержки, которую никто не закладывал в смету. Стоимость владения продуктом всегда превышает стоимость его запуска, и это стоит считать заранее. Требования при этом изменятся — не потому что кто-то ошибся, а потому что бизнес меняется. Поэтому договариваться нужно не об их неизменности, а о том, как изменения будут оформляться и влиять на сроки и бюджет. Проект всегда сигнализирует о надвигающихся трудностях заранее — задача руководителя в том, чтобы читать эти сигналы, пока они ещё не стали кризисом.
