Как выбрать ИТ-подрядчика

Почему компании, которые совмещают IT-консалтинг и разработку, чаще приводят проекты к бизнес-эффекту — и где обычно ломается подход “просто сделайте по ТЗ”.

Разбор процессов: разработчики, консалтинг-команды и агентства — без лозунгов и магии.

Есть один неприятный тип ИТ-проектов. Они не проваливаются. Они не горят. Их даже нельзя назвать неудачными — на бумаге всё красиво.

Проект “сделан”. Система “работает”. Функционал “соответствует ТЗ”. Релиз “в срок”.

А бизнес смотрит на это и не понимает: почему стало не лучше?

Люди всё ещё ведут часть процесса в Excel. Сотрудники стараются обходить систему, если можно. Любая доработка превращается в отдельный бюджет и отдельные сроки. А руководитель ловит себя на мысли: “мы вложились, но эффекта не получили”.

И вот тут начинается самое опасное. Не проблемы с системой — проблемы с доверием. После такого опыта внутри компании появляются фразы вроде:

— “мы уже пробовали автоматизацию” — “ИТ — это всегда долго и дорого” — “давайте не будем снова в это влезать”

А значит, компания теряет не конкретный проект. Она теряет способность быстро меняться.

Чаще всего бизнес ищет “сильную разработку”. И выбирает подрядчика по признакам:

— хороший стек, — уверенная команда, — портфолио, — адекватные сроки, — понятная цена.

Это логично. Но в сложных проектах этих критериев недостаточно.

Потому что у чистой разработки есть своя природа: разработчик по умолчанию — исполнитель. Его работа начинается там, где заканчивается обсуждение “что нужно сделать”.

Если входящие требования неверные или неполные — разработка всё равно их реализует. Не потому что “плохие”, а потому что модель такая: меньше спорить — меньше рисков сорвать сроки и ответственность.

В итоге получается ситуация, которая и делает проекты “формально успешными, но бесполезными”.

Чтобы не было иллюзий, разберём типовой сценарий. Он встречается очень часто, и в нём нет ничего злого — просто так работает рынок.

1) Требования принимаются как данность Вы приносите ТЗ или набор хотелок. Их уточняют, “дошлифовывают”, иногда предлагают улучшения по UI или архитектуре. Но фундаментальный вопрос “а это точно нужно?” обычно не задаётся. Потому что это означает выйти за роль исполнителя.

2) Проект превращается в список задач Всё раскладывается по спринтам: экраны, роли, интеграции, отчёты. Управлять этим удобно. Но здесь происходит подмена: команда начинает измерять успех количеством закрытых задач, а не изменениями в бизнесе.

3) Сдача по критерию “соответствует ТЗ” Финал действительно может быть качественным: тесты, документация, демо, релиз. И всё равно результат может не работать на бизнес. Потому что ТЗ — это не всегда бизнес-цель. Чаще — описание текущей реальности. Со всеми её компромиссами, ручными обходами, “так исторически сложилось”.

И если эту реальность просто цифровизировать, получится ровно то, что описали: автоматизированная версия старых проблем.

Система будет работать. Просто не будет помогать.

На практике ТЗ пишется из трёх источников:

1. привычки команды (“мы всегда так делали”),
2. текущие болячки (“вот тут неудобно”),
3. компромиссы (“сейчас делаем так, потому что иначе не получается”).

В ТЗ редко попадает главный слой:

— какой эффект нужен бизнесу — какие метрики должны измениться — где настоящие узкие места — что мешает росту, а не просто раздражает

Если этот слой не поднят на старте, проект почти обречён стать “вещью”, а не “изменением”.

Когда у подрядчика есть консалтинговая экспертиза, его роль другая. Он не начинает с “что реализовать”. Он начинает с “что изменить”.

Это принципиально другой процесс — и он обычно выглядит так.

1) Диагностика: сначала понимаем систему, в которую внедряемся Такой подрядчик изучает не только требования, но и реальность: процессы, людей, данные, ограничения. Он ищет причины, а не симптомы.

В этот момент часто выясняется неприятное, но полезное: — часть проблемы не в системе, а в процессе, — данные недостаточно чистые, — роли и ответственность размыты, — сотрудники работают “по факту” не так, как написано в регламенте.

Это не затягивание. Это экономия. Потому что иначе вы просто построите дорогую систему на болоте.

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

И здесь случается то, что многих удивляет: после нормального разбора половина хотелок отваливается сама. Не потому что “сэкономили”, а потому что она не даёт эффекта.

3) Проектирование системы, а не набора фич Когда думают от бизнеса, появляются ответы на вопросы: — как решение будет жить через год — как выдержит рост объёмов — что будет при изменении процессов — как сделать доработки предсказуемыми, а не “каждый раз как новый проект”

4) Синергия: “думать” и “делать” в одной команде Когда консалтинг и разработка в разных компаниях, почти всегда теряется контекст. Консультанты нарисовали “идеально”, разработчики говорят “это нереально”, бизнес получает конфликт и потерю времени.

Когда консалтинг и разработка внутри одной команды: — идеи сразу проверяются на реализуемость, — ограничения всплывают рано, — решения становятся прагматичными, — ответственность не распадается на “мы придумали / они сделали”.

И самое важное: появляется единая связка “анализ → решение → внедрение → эффект”.

Есть вещи, которые не видно изнутри компании. Потому что внутри все привыкли: “так нормально”.

Консультанты, которые много раз проходили похожие проекты в разных отраслях, обычно заранее чувствуют:

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

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

Агентства бывают разными, но у модели “агентство разработки” есть типовые слабые места. Их важно понимать заранее.

1) Экономика агентства — это часы Многие агентства зарабатывают на объёме работ. Значит, их естественная мотивация — чтобы проект продолжался. Бизнесу же нужно обратное: чтобы проблема решилась и проект закончился.

2) Потеря контекста из-за текучки людей Сегодня один разработчик, завтра другой. Меняется менеджер. Контекст плавает. Решения принимаются “по месту”. И вы платите за “вхождение в проект” несколько раз.

3) Много менеджмента, мало ответственности за эффект У агентств часто всё отлично с отчётами. Но если критерий успеха — “в срок закрыть задачи”, бизнес-эффект может остаться без хозяина. А потом неизбежно звучит фраза: “Это не было в ТЗ”.

4) Шаблонные решения там, где нужна настройка под процессы Агентства любят типовые подходы — это ускоряет продажи и разработку. Но сложные бизнес-процессы редко типовые. И попытка “натянуть шаблон” заканчивается тем, что система живёт отдельно от реальности.

Чтобы было честно: есть ситуации, где чистая разработка или агентство подходят.

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

Но если проект влияет на ключевые процессы, деньги и операционку, если нужна устойчивость и развитие — одной разработки обычно недостаточно.

Мы строим проекты от бизнеса, потому что иначе слишком много денег и времени улетает в переделки.

Наш подход выглядит просто: — сначала разбираем, где реально болит и почему, — убираем лишнее и упрощаем до автоматизации, — проектируем систему под рост и изменения, — внедряем и доводим до того, чтобы ею пользовались, а не обходили.

Мы совмещаем консалтинг и разработку в одной команде не ради красивого позиционирования, а потому что так: — меньше потерь на стыках, — больше ответственности за результат, — быстрее принимаются решения, — и главное — итоговая система становится частью реального процесса, а не “ещё одной программой”.

Главная ошибка при выборе ИТ-подрядчика — выбирать “того, кто сделает”, когда вам нужен “тот, кто поможет изменить”.

Чистая разработка сильна в исполнении. IT-консалтинг + разработка сильны в том, чтобы привести проект к бизнес-эффекту.

И если для вас важны не галочки в ТЗ, а результат в метриках, устойчивость и масштабирование — выбирать стоит партнёра, который умеет и думать, и делать.