Аутсорс, фриланс или инхаус ❓ - Выбор схемы работы с исполнителем на IT-проект

Привет! На связи со-основатель и коммерческий директор CyberForm Systems + Soft-works. Уже 25 лет я в профессиональной разработке. И прямо сейчас мы продолжаем развивать наш аутсорс-продакшен и постоянно сталкиваемся с тем, что нас сравнивают то с инхаусом, то с фрилансом. Эти 3 англицизма описывают разные форматы организации проектных команд.

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

Не спорим с клиентом. Если у него всё в порядке - прекрасно. Однако мы знаем, что и такие клиенты иногда возвращаются к нам и просят помощи

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

Эти и подобные диалоги - из нашей реальной жизни. В ходе продаж они происходят у нас с клиентами регулярно.

С одной стороны, это значит, что заказчики часто подкованы в вопросе выбора формата, с другой стороны, не редки случаи, когда требуются разъяснения.

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

Коротко, на примере наших проектов, этапы работы - следующие:

Сначала проект получает форму

Затем осуществляется реализация

Итого на проекте помимо заказчика задействованы как минимум 7 ключевых ролей специалистов и менеджеров, если не углубляться в то, что разработке предшествует проектирование UX и создание дизайна, а разработчики представлены фронтенд / бэкенд / mobile / sdet / devops инженерами.

Однако для полноты картины мы начнём с целей. Какую цель преследует заказчик, выполняя проект по разработке веб-сервиса, информационной системы или онлайн-платформы?

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

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

1. Проработка бизнес-модели (причинный слой) - зачем нужен проект?
2. Проработка продукта (продуктовый слой) - что и для кого мы делаем?
3. Проектирование интерфейса (слой UX) - как будет использоваться?
4. Проработка внешнего вида (слой дизайна) - как будет выглядеть?
5. Проектирование системы (слой архитектуры) - как будет устроено?
6. Реализация системы (слой разработки) - как будет реализовано?

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

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

Поэтому мы будем говорить о делегировании слоёв 3 и 4, т.к. на этом специализируется наша компания, и в этом у нас наиболее глубокие компетенции. Что касается слоя 3 (слой UX), то периодически эти задачи мы решаем совместно с партнёрами, с которыми можем с удовольствием вас познакомить.

Поехали. И начнём мы с инхауса.

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

Забегая вперёд, инхаус - отличный подход для проектов, у которых есть ресурс на обустройство всего необходимого для реализации проекта. Однако, давайте посмотрим, что для этого требуется на уровне слоя 4 (слой разработки):

В части управления:

В части исполнения:

Эти 2 списка нам понадобятся в дальнейшем для сравнения. А пока давайте просто посмотрим на них, чтобы понять, что разработка - это не так-то и просто.

Дело в том, что порой заказчики подходят к этому процессу поверхностно, считая, что в нём нет ничего замысловатого.

- Хочу вот это - всё же понятно, просто сделайте хорошо.

Чтобы разобраться в "простом", часто требуется детальный анализ и доработка требований к продукту или же аудит текущего кода и состояния проекта. После этого изначальное видение продукта может радикально поменяться. И делаем мы в итоге другой продукт. Уже более понятный, но как правило, всё же не простой.

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

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

Если же вы не обладаете ресурсами для того, чтобы обеспечить работой и зарплатами (или надеждой на них) такую команду, то инхаус, скорее всего, - не то, что вам стоит выбирать. Хотя и в ограниченных объёмах он может работать. Например, для небольших проектов возможно найти толкового разработчика, который будет в процессе осваивать смежные с известными ему технологиями и тянуть на себе проект.

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

О фрилансе я знаю не меньше, чем об инхаусе и аутсорсе, потому что 25 лет назад начинал свою деятельность именно с него и проработал таким образом как минимум 10 лет.

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

Фрилансеры делятся как минимум на 2 типа:

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

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

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

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

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

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

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

Практика показывает, что ничего из перечисленного у заказчика чаще всего нет, за исключением, может быть, поверхностного списка требований или ТЗ на человеческом языке без технических деталей. Фрилансер же точно не в состоянии, да и не хотел бы, заниматься перечисленными вещами поэтому в лучшем случае он может:

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

Но практически всегда это крайне обеспокоенный заказчик, которого кормили завтраками, в итоге отдали то, что смогли сделать. А при этом у него горят сроки, и проект в неизвестном состоянии, в котором реализована лишь часть того, что требовалось, так, как получилось.

Прошу не принимать на свой счёт написанное выше тех фрилансеров, кто действительно честно и ответственно выполняет свою работу. Я знаю, что такие есть, и я сам работал именно так. Если заказчику повезло найти такого, то разработка на фрилансе может стать успешной.

Но, опять же, не стоит ждать, что при этом будет сделано всё. Один человек никогда не заменит команду. В чём-то он будет лучше, в чём-то хуже. Что-то будет делать с удовольствием, что-то без, а в чём-то будет просто некомпетентен.

Подводя итог, выбор фриланса - большой риск. Оправдан он только в случаях, когда:

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

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

Поэтому мы рекомендуем оценить риски и по возможности воспользоваться аутсорсом. О нём речь пойдёт далее.

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

В этом формате работает наша компания, и рассказать о нём я могу не меньше, чем о предыдущих. Поехали!

Грубо об аутсорсе можно говорить как о внешнем отделе разработки, который работает над вашим проектом.

Грубо - потому что:

Важными задачами заказчика здесь являются:

Мы же как исполнители при этом обеспечиваем:

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

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

Кроме того, на всём протяжении проекта мы:

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

Бывает, что заказчик приходит с готовым техническим заданием, прототипом интерфейса или дизайном. И мы начинаем разработку с того, что уже реализовано.

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

Зоны ответственности фиксируются договором и при необходимости могут гибко меняться допсоглашениями к нему. Это позволяет при возникновении новых задач рассчитывать на помощь аутсорсной команды.

Не штатные сотрудники

Аутсорс - это не ваши штатные сотрудники, которым нужно платить зарплату даже если нет работы. Заказчик может выбирать необходимый проекту объём работ и оплачивать только его. Особенно это удобно, когда активная работа по проекту завершена, и он уже ушёл на поддержку. Аутсорсная команда при этом сохраняется и случае необходимости может снова активизироваться.

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

Разработчикам у нас нравится

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

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

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

Бюджет сравним с инхаусом

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

Заморочены на эффективности

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

По опыту того, как отделы разработки выстроены в непрофильных компаниях, могу уверенно сказать, что подобные системы есть только там, где управляют процессом либо матёрые менеджеры, либо профессиональные разработчики. А такое бывает, как правило, только в продуктовых компаниях, для которых разработка также является важным бизнес-процессом.

Развиваемся устойчиво

Чтобы компания была устойчивой, помимо эффективности, мы заботимся и о развитии сопутствующих процессов:

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

Но это не точно. И об этом можно подискутировать. Обсудим?

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

Такие проекты часто ведут стартапы, фаундерами которых являются IT-предприниматели или уже зрелые бизнесы. Проекты разрабатываются на собственные деньги, внутренние или привлечённые инвестиции.

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

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

Сроки проектов обычно колеблются:

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

На этом большое сравнение аутсорса, фриланса и инхауса на примере опыта нашей компании и своего лично - заканчиваю.

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

И если у вас есть проект, которому требуется надёжная аутсорсная команда - давайте обсудим стоящие перед вами задачи!

Для связи в tg - @yury_ea

О компании - @cyberform.systems