Как выбрать подрядчика для ИТ-разработки и получить результат, который принесет пользу бизнесу? Инструкция JetStyle
Если вам предстоит заказывать разработку на аутсорсе, то эта статья поможет понять: какой сценарий ИТ-аутсорсинга вам подойдет? на что обратить внимание при выборе подрядчика? в какой логике вести процесс разработки? и как не ошибиться в выборе? Обо всем этом — в мини-инструкции от CEO JetStyle Алексея Кулакова.
Разработка внешней командой позволяет ускорить автоматизацию, когда ресурсов инхаус-разработки не хватает, и обеспечивает более дешевый старт по сравнению с формированием собственной ИТ-команды с нуля. Давайте поговорим о том, что важно учесть при принятии решения о выборе подрядчика.
Но начнем с того, в каких случаях не надо заказывать разработку:
1. Если вы умеете управлять разработкой (во-первых) и не испытываете проблем с расширением штата квалифицированных программистов (во-вторых), то разработка собственными силами будет выгоднее.
2. Если вы собираетесь автоматизировать процесс, которого еще не существует, не тратьте ресурсы — новый софт не поможет создать этот процесс. (А в следующей статье расскажу, как понять, какой процесс главный и как развернуть вокруг него разработку. Подпишитесь на наш телеграм-канал, чтобы не пропустить анонс.)
Но если есть процесс, который нужно автоматизировать, и есть дефицит разработки — читайте дальше.
Два сценария ИТ-аутсорсинга
Обычно компании обращаются к заказной разработке, когда у них внутри не хватает либо ресурсов, либо ИТ-экспертизы для автоматизации тех или иных процессов или масштабирования бизнеса.
При этом компании, у которых внутри есть ИТ-экспертиза, и те, у которых ее нет, будут вести себя по-разному.
Первый вариант — когда ИТ-экспертиза есть, но ее не хватает. Все довольно просто: нужно отдавать на аутсорс отделимые части системы/продукта/вотэвер.
Чем более квалифицирован заказчик в таком случае, тем больше шансов, что команда снаружи будет выбрана подходящая, задачи поставлены корректно и бизнес получит именно тот эффект, который ему нужен.
Второй вариант — когда у компании внутри нет ИТ-экспертизы, а процессы, требующие автоматизации, у бизнеса есть. Чаще всего потребности в таких случаях формулируются как «разработать интернет-магазин», или «маркетплейс», или «CRM», или другую ИТ-систему, или что-то подобное.
Здесь кроется главный риск для такого типа заказчиков. Потому что если внутри ИТ-экспертизы нет, то в большинстве случаев и экспертизы по управлению ИТ тоже нет. Часто тогда задание формулируется как набор фич, и по дороге теряется связь между решением и смыслом деятельности. И в результате внедрения получается так, что, даже если система работает «как заказывали», в процессы она встроена плохо, выгоду из нее получить сложно и реальной пользы она не приносит.
Поэтому, если в компании нет своей ИТ-экспертизы, критически важно найти толкового исполнителя, который экспертизой поделится.
Постановка задач: ТЗ или продуктовый подход?
Теперь давайте посмотрим, где и какая разница возникает при постановке задач.
Чаще всего компании, где нет или недостаточно ИТ-экспертизы, пытаются снизить риски, связанные со скоростью, предсказуемостью и качеством будущей системы, за счет составления подробного технического задания. Но требование следовать детальному ТЗ снижает адаптивность решения под реальные нужды бизнеса, которые в свою очередь могут быть уточнены только путем экспериментов. И если в начале отношений мы гвоздями прибили, что именно должна из себя представлять ИТ-система функционально, то потом это уже сложно изменить. В результате компания рискует получить решение, которое в лучшем случае хорошо выглядит и даже не слишком глючит, но только выгоды не приносит, потому что построено не в той части процесса, которую стоило автоматизировать, и не тем способом.
Однако ТЗ поможет в том случае, когда нужно воспроизвести что-то уже работающее, например, если имеющиеся средства автоматизации показали свою эффективность, но какие-то их части устарели технически и нужно просто обновить эти части. То есть чем больше задача похожа на сценарий «давайте ничего не будем изобретать, а сделаем так же, как уже работает», тем с большей вероятностью техническое задание окажется правильным решением.
А вот чем больше в деятельности инноваций, чем больше компания пытается оценить что-то, что изменит ситуацию к лучшему за счет какого-то изобретения (неважно в чем: в менеджменте, в маркетинге, в производственной технологии и т. д.), тем больше придется экспериментировать — а значит, тем меньше подходит разработка по ТЗ и тем важнее найти подрядчика, с которым можно будет работать в продуктовой логике — он даст возможность не прибивать гвоздями будущий образ ИТ-системы, а гибко и итеративно, тестируя различные гипотезы, приближаться к образу результата.
Выбор подрядчика: на что обращать внимание?
Снова рассмотрим наши два случая: когда в компании есть ИТ-экспертиза и когда ее нет.
Когда у компании есть свои разработчики, ИТ-экспертиза, менеджмент и методология, по которой построено управление разработкой, и она ищет возможность усилить или расширить свои ресурсы, самое важное — найти подрядчика, который работает в похожей логике и безболезненно встроится в существующие процессы.
Обычно в таких случаях смотрят на следующие вещи:
- есть ли у подрядчика необходимые компетенции и навыки ИТ-разработки,
- работает ли он с нужным стеком технологий,
- делал ли он системы с похожим функциональным портретом,
- похожа ли ИТ-культура подрядчика на ИТ-культуру заказчика.
В целом, нужно ответить на вопрос: «Насколько представления подрядчика о том, как надо, похожи на наши?»
А когда у компании нет разработчиков и собственной ИТ-экспертизы, донором культуры разработки станет подрядчик, который будет нанят. Это в свою очередь значит, что нужно найти такого подрядчика, которому будет важно не просто получить побольше денег в момент и раздуть контракт, а совместно развивать будущую ИТ-систему. Он должен быть настроен на долгосрочное сотрудничество и заинтересован не в том, чтобы просто отчитаться в формате «я все сделал, давайте деньги», а в том, чтобы результат усилий для компании-заказчика окупился — потому что тогда клиент станет для него постоянным и, скорее всего, чек будет увеличиваться, потому что заказчик будет видеть, как его затраты окупаются.
Важно, чтобы подрядчик не просто взял ответственность за дизайн и программирование, а вместе с заказчиком искал решение задач бизнеса с помощью ИТ, чтобы он мог простыми словами объяснить, каким образом бизнес-гипотезы будут проверяться и какими средствами. Поэтому хороший симптом — когда подрядчик сразу говорит о том:
- как результат его усилий будет оказывать влияние на бизнес-показатели
- и как ускорить получение измеримой выгоды в процессах заказчика.
В современном мире, когда дело касается создания цифровых продуктов, компетентный заказчик чаще выбирает гибкую методологию и, следовательно, итеративную разработку вместо разработки по ТЗ, особенно если речь идет о создании нового продукта. Поэтому мы считаем, что самый правильный способ найти подрядчика на аутсорсе — это найти внешнюю команду продуктовой разработки.
Очень подробно я говорил об этом в статье про разницу между аутсорсом, аутстафом и продуктовой разработкой. Если вы сейчас в поиске внешней команды разработки, эта статья поможет вам понять, как вообще устроен рынок, и найти для себя оптимальный вариант.
Или можете просто написать мне в телеграме или забронировать слот в моем календаре для короткого звонка в зуме — обсудим вашу задачу и вместе определим дальнейшие шаги.