Колонки

Аутсорс или свой IT-отдел: что выбрать бизнесу и какие проблемы могут возникнуть в обоих случаях

Колонки
Сергей Костин
Сергей Костин

CEO BSL

Дарья Мызникова

Сергей Костин, CEO компании BSL (Business Solutions Lab), которая занимается разработкой ПО для бизнес-задач, рассказывает, когда стоит создавать свой IT-департамент внутри компании, а когда лучше отдать проект на аутсорс.

Аутсорс или свой IT-отдел: что выбрать бизнесу и какие проблемы могут возникнуть в обоих случаях
Присоединиться

Проблема аутсорса и собственной разработки существует столько же, сколько и сам IT-бизнес, однако я наблюдаю за этими процессами последние 10 лет. С того момента, как компания, в которой я работаю, занялась интеграцией авиационных продуктов и разработкой модулей для них, я постоянно задавался вопросом, что лучше для бизнеса: создавать и растить собственный IT-департамент или передавать эти вопросы на сторону компетентным исполнителям?

Этот вопрос возникал неспроста, и вот почему. Авиационная индустрия является одной из самых технологичных и продвинутых, но мы с коллегами часто обнаруживали, что наши заказчики до сих пор пользовались в работе устаревшими и неэффективными инструментами. Например, сложнейший учет и сбор статистики полностью велись в Excel-таблицах, хотя уже давно существовали профильные решения, которые могли бы облегчить процессы. Но даже при таком уровне технологического оснащения каждый клиент был уверен, что при необходимости ему хватит экспертизы и ресурсов, чтобы разработать для себя программное решение.

Сейчас все компании стремятся быть автоматизированными, цифровыми и следовать IT-трендам, чтобы получать больше статистики и метрик о своих данных. Однако не все знают, как, с помощью чего и зачем это делать. И рано или поздно перед ними встает непростой выбор — создавать свой IT-департамент или отдать проект на аутсорс.

Я выделил несколько проблем, на которые заказчику необходимо обратить внимание, прежде чем принимать такое решение.

IT-экспертиза

Многие заказчики хорошо знают свой бизнес и как им управлять. Возможно, это и подпитывает иллюзии, что они безболезненно справятся с созданием собственного IT-департамента. Прежде чем вступить на этот долгий путь, нужно быть уверенным, что объема работы хватит, чтобы обеспечить полную загрузку будущей команды. Важно четко понимать цели проекта и верно оценить его долгосрочные перспективы. Если уверенности нет, то, возможно, не стоит торопиться с формированием штатной команды.

Зачастую у большинства собственников и топ-менеджеров нет или не хватает экспертизы в создании IT-команды, а это требует большого внимания с их стороны. Нужно знать, какими компетенциями должны обладать техлиды и разработчики, на каком стеке они будут писать, а также разбираться в культуре разработки и процессах тестирования.

Эффективный IT-менеджмент подразумевает правильное распределение ресурсов, знание и использование методологий разработки, а также умение их внедрять. Например, использование таких методологий важно на этапе создания MVP (minimum viable product — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциональными возможностями). Это позволяет выводить действительно нужный рынку продукт, но в минимальной комплектации, в процессе изменяя его в зависимости от ваших гипотез и желаний, а не запланированного бюджета и невыполнимых ожиданий, которые могут привести к созданию нерабочего или неактуального продукта.

IT-сфера каждый день становится сложнее и конкурентнее — разобраться в ней человеку без экспертизы и подготовки, даже если он высококвалифицированный менеджер, будет проблематично.

Но если заказчик точно понимает, что запланированные IT-проекты обеспечат команду работой еще надолго или даже навсегда, тогда есть смысл формировать внутренний департамент. В первую очередь для этого потребуется опытный руководитель с экспертизой в различных IT-областях, чьей первоочередной задачей станет подбор квалифицированной команды.

Нужно быть готовым к тому, что поиск такого профессионала, скорее всего, займет много времени и усилий HR-специалиста (эти издержки тоже нужно учитывать), но зато в будущем позволит избежать многих ошибок в подборе разработчиков, налаживании всех внутренних процессов и установлении культуры разработки.

Синергия разработки и бизнеса

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

Аутсорс-компании необходимо чувствовать бизнес и его предметную область, чтобы быть на одной волне с заказчиком, выполнять не только поставленные задачи, но и планировать какие-то вещи наперед. Чтобы не ошибиться при выборе партнеров, важно, чтобы клиенты работали с теми:

  • чей опыт в разработке продуктов подкреплен реальными кейсами;
  • кто может быстро вникнуть в детали бизнеса, активно коммуницируя с клиентом, погружая свои IT-команды в процессы заказчика.

Например, при разработке транспортных решений в BSL наши продакт-менеджеры и тестировщики ездят с пользователями (водителями), чтобы проверить, соответствует ли ПО ожиданиям пользователя.

Аутсорс-компании должны быть открыты к бизнесу. Для многих заказчиков IT-мир и разработка сродни магии и волшебству. Когда клиент чего-то не понимает, ему кажется, что его обманывают, чтобы получить больше денег.Я бы советовал заказчику обратить внимание на стандартные, но не менее значимые вещи. Так, менеджер подрядчика должен: 

  • рассказать, как устроен IT-процесс;
  • из каких этапов он состоит;
  • какие основные блоки будет иметь программное решение;
  • определить четкий график встреч, сроки и критерии сдачи проекта;
  • спрогнозировать ожидаемый результат.

Кроме того, рабочие встречи с командой исполнителя и заказчика должны проходить регулярно, чтобы избежать мискоммуникации. При этом не нужно сыпать терминами и говорить непонятные фразы. Очень важно, чтобы заказчик понимал людей, которые работают на него. Представьте, если бы мы общались с врачами, а они рассказывали нам на латыни о том, что у нас болит. 

photoUnsplash

Тяжелое наследство

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

Мотивы новых разработчиков ясны. Они хотят, чтобы код был оптимальным, легко сопровождался и обладал возможностью масштабирования. Однако достижение этих целей стоит бизнесу дорого. Приходится останавливать текущие бизнес-процессы и работы по внедрению новых функциональных возможностей и выделять дополнительные бюджеты на рефакторинг, хотя неидеальный старый код не мешал пользователям выполнять их задачи.

По моему мнению, оптимальное решение в таких ситуациях — это плавный реинжиниринг. Пусть программное решение не будет оптимальным на 100%, но при этом заказчик не потеряет деньги и продолжит внедрять новые функциональные возможности, оставаясь на плаву. Если ПО решает задачи пользователей, значит, софт рабочий и может приносить профит бизнесу. Но ни в коем случае не забывайте ревизировать технический долг проекта, если он есть, чтобы в будущем его вернуть!

Как достичь максимума

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

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

Как СЕО компании-разработчика я бы предложил организациям, которые только вступают на этот путь, на первых порах воспользоваться помощью экспертов со стороны. Это будет выгоднее с точки зрения затрат на тестирование проекта и идеи в целом, валидации гипотез, а кроме того, даст время составить объективное представление о собственных ресурсах и перспективах и спланировать дальнейшие действия.

Важно помнить, что каждый проект требует индивидуального подхода и самого тщательного анализа и, самое главное, максимально объективной оценки. Думаю, что в вопросе разработок ПО честность в отношении проекта — это лучшая тактика и для клиентов, и для исполнителей. И хороший, ответственный партнер ни в коем случае не станет напрасно тратить время и деньги заказчика, а только поможет эффективно организовать рабочий процесс и достичь самого лучшего результата.


Фото на обложке: Shutterstock/McLittle Stock

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 «Драники, наливочки, колдуны»: почему IT идет в Беларусь
  2. 2 Свой или в аренду: где брать софт для финтех-проектов и что учитывать при выборе
  3. 3 Эта методология поможет вам быстро и качественно разрабатывать IT-продукты. Как она работает?
Relocation Map
Интерактивный гид по сервисам и компаниям, связанным с релокацией
Перейти