Тендеры и лиды
Информация
Найти ИТ-партнера или расширить команду разработки — результат зависит от целей бизнеса и зрелости процессов
Большинство ИТ-подрядчиков пытаются работать по схеме: дайте нам техническое задание, и мы все сделаем. Однако у бизнес-заказчика не всегда хватает насмотренности в ИТ, чтобы отразить в ТЗ именно то, что он хочет.
Как правило, бизнес хорошо знает свою предметную область — ритейл, e-commerce, логистику, но ИТ-процессы ему не до конца понятны. В итоге заказчик пишет техническое задание, ориентируясь на то, что увидел у конкурентов: «у них есть приложение — значит, нужно и нам».
При этом изменения в ИТ почти всегда инициированы не абстрактным «пора обновиться», а стратегическими целями роста. Выйти на новый рынок, увеличить выручку, увеличить объем продаж. Дальше уже ИТ должен просчитать, какая инфраструктура для этого нужна. Без экспертизы в технологиях это сделать сложно, а у бизнеса такой экспертизы может не быть.
Другой вариант — текущая ИТ-инфраструктура перестала справляться. Частые сбои, медленные ответы сервера, заказы, которые не оформляются, растущее число ошибок в каждом релизе. Найти за этими симптомами корневую причину — задача, которую не напишешь в ТЗ. Сначала нужен технологический аудит, который по совокупности признаков покажет, что именно чинить.
Кроме того, прежде чем переходить к разработке, требуется оценить, когда инвестиции в ИТ должны окупиться и на какие расходы на IT-команду в будущем готова компания.
Когда цели определены и бюджет на разработку согласован, возникает вопрос: есть ли внутри компании люди, способные ей управлять.
Роли, которые играют важную роль в создании цифровых продуктов — это технический лидер, менеджер продукта и аналитик. Техлид понимает, как управлять командой разработки, продакт-менеджер следит за тем, чтобы решение обеспечивало бизнес-цели и нужные показатели, а аналитик упаковывает бизнес-требования в техническое задание.
В зависимости от того, как закрыты эти роли в компании, возможны два подхода к выбору модели разработки.
Первый сценарий: техническая и продуктовая экспертиза есть внутри
Есть технический лидер.
Задачи сформулированы и приоритезированы.
Есть роль аналитика или продакт-менеджера.
В этом случае разработкой управляет непосредственно бизнес-заказчик, а внешние специалисты встраиваются в готовую систему. Результат также зависит от заказчика, а не от подрядчика.
Главное преимущество такого подхода: можно быстро закрыть дефицит ресурсов и масштабировать то, что уже работает.
Второй сценарий: нет команды и выстроенных процессов
Нет технической экспертизы.
Нет процессов управления задачами.
Нет ресурса управлять разработкой.
В таком случае нужна не пара специалистов, а полноценная экспертная команда. Подрядчик выступает партнером, берет на себя организацию процессов, управление задачами и технические решения, клиент платит за управляемый результат.
Такой подход снижает операционную нагрузку на бизнес, повышает предсказуемость сроков и бюджета и позволяет запустить продукт с нуля без внутренней экспертизы. Ценность здесь — не только в коде, а в управлении и выстраивании системы.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13700 тендеров
проведено за восемь лет работы нашего сайта.
Для компаний, которые хотят развивать внутреннюю ИТ-команду, но им не хватает компетенций для этого, есть третий, отдельный путь — консалтинг.
Он включает:
построение процессов разработки;
формирование ИТ-стратегии;
обучение управлению командами;
выстраивание работы с подрядчиками.
Консалтинг не решает задачу здесь и сейчас, но создает систему внутри компании и в дальнейшем позволяет более гибко выбирать формат работы с разработкой.
Выбор модели разработки пугает заранее: долго, дорого, муторно. Из этого страха рождаются управленческие ошибки — выбирать ИТ-подрядчика только по цене, не учитывать того, как работают собственная ИТ-система, полностью перекладывать ответственность на исполнителя.
Если изменения откладываются, система не остается на месте — она деградирует. Усложняется легаси — объем уже написанного кода, растет количество узких мест в коде, могут добавляться серверы и облака, которые не решают проблему по существу, но увеличивают издержки на ИТ. В какой-то момент это становится проще переделать с нуля, чем распутать.
При этом полная переработка системы почти никогда не окупается — это большие вложения без бизнес-эффекта здесь и сейчас, хотя тот же результат уже есть на текущей инфраструктуре.
Грамотный ИТ-партнер понимает, что продажи, производство, обслуживание клиентов нельзя приостанавливать на время перестройки. Поэтому любые изменения идут параллельно с текущей деятельностью компании. Приоритет при этом всегда один — в первую очередь оптимизировать узкие места.
Также составляется карта рисков: что может пойти не так на каждом этапе, кто в проекте принимает решения, кто консультирует, — и план по митигации этих рисков. Там, где принятие решений затягивается, теряется управляемость и растет объем работ.
Еще одна иллюзия — рассчитывать, что продукт можно один раз разработать и забыть о нем. Цифровой продукт — это динамично развивающаяся структура, требующая регулярных вложений.
Второе условие того же порядка — открытый разговор о бюджете. Работа строится гораздо эффективнее, если заранее обозначить подрядчику реальные условия и рамки. Это позволяет подобрать оптимальный вариант. К примеру, для малого или среднего бизнеса сложная архитектура на старте не нужна — но в дальнейшем продукт нужно будет поддерживать и масштабировать.
Поэтому бизнес-заказчику важно погружаться в процесс: разбираться, как строится взаимодействие с командой, ходить на демо и ретроспективы, понимать базовые технические детали. Это гарантия того, что в итоге получится нужный результат.
Выбор ИТ-модели сводится в итоге к одному вопросу: есть ли внутри компании люди, которые могут управлять разработкой?
Если есть техлид и выстроенные процессы, задачи понятны и приоритеты расставлены — подходит усиление команды.
Если нет процессов и экспертизы, систему нужно строить с нуля — нужна внешняя команда разработки или консалтинг. В обоих случаях ИТ-подрядчик выступает партнером для бизнеса.
Сценарий, где можно ограничиться только техническим заданием, перестал работать. Оптимальнее передать ИТ-компании составление дорожной карты и постановку задач, оценку рисков и разделить с ней ответственность за бизнес-эффект. Это другая модель отношений — партнерская, и с компаниями, которые ее освоили, работать выгоднее.
