Обычно руководители предпочитают создавать, развивать и тестировать IT-продукты силами штатной команды. В других компаниях выбирают для этих целей формат аутсорсинга или аутстаффинга персонала. Давайте разберемся, в каких случаях оправданно набирать штат сотрудников, а когда лучше обратить внимание на другие виды сотрудничества, чтобы оперативно решать разные IT-задачи.
Собственная команда для создания IT-продукта
Такой формат позволяет объединить вокруг себя вовлеченных единомышленников с похожими ценностями, которые будут работать только над вашим проектом и под вашим контролем. Однако придется заниматься наймом, онбордингом, обучением, мотивацией и заменой сотрудников.
Такие издержки обоснованы, если:
- Продукт уже запущен и точно нужен целевой аудитории. Многие стартапы пользуются аутсорсом разработки на этапе создания MVP и релиза, а после получения инвестиций набирают IT-команду в штат.
- Проект долгосрочный с годовым бюджетом от 10 млн рублей. В этом случае затраты на налоги, страхование, аренду офиса в будущем окупятся и помогут выйти в плюс.
- В компании запускается новый проект, и уже есть своя IT-инфраструктура.
Также важно оценить плюсы и минусы перед тем, как собирать собственную команду.
Преимущества штатной IT-команды
- Хорошая слаженность. Работая вместе долгое время, люди начинают лучше понимать друг друга и учитывать особенности каждого, досконально изучают продукт. За счет сплоченности сотрудники быстрее вникают в новые задачи и быстрее справляются с доработками.
- Сильная экспертиза. Со временем во внутренних командах вырабатываются свои методы работы, инструменты и навыки.
- Вовлеченность. Если сотрудников объединяют не только общие проекты, но и внерабочие активности, они сильнее привяжутся к компании. А это значит, что в их действиях будет больше энтузиазма, новых идей и лояльности.
- Быстрая коммуникация. Работая в одном офисе с одинаковым графиком, обсудить вопросы получается быстрее и проще.
Недостатки штатной IT-команды
- Большие затраты на содержание персонала. Нанимая собственных разработчиков, понадобится найти дополнительных сотрудников, которые будут обслуживать этот процесс: HR-менеджеров, рекрутеров, офис-менеджеров, бухгалтеров и тех, кто будет продвигать HR-бренд. Плюс затраты на офис, налоги, страхование, больничные, отпускные, фирменный мерч и пр.
- Найти лидера команды, которому можно доверять, – дело непростое и небыстрое. Для управления IT-специалистами руководителю нужно либо самому хорошо разбираться в технической части, либо найти сильного эксперта, который приведет к результату. Если ошибиться в выборе, можно слить весь бюджет, но так и не получить нужного продукта.
- Долгий поиск подходящих специалистов. Не так просто найти человека с нужными навыками и опытом, который примет именно ваш оффер. На это может уйти несколько месяцев + время на адаптацию + риск, что сотрудник в итоге не подойдет или сам решит уйти.
- Нужно платить зарплату, даже когда нет задач и стабильной рабочей загрузки. Работодатель в любом случае оплачивает часы простоя.
- Человеческий фактор. В процессе разработки могут возникать моменты, которые будут тормозить процесс: кто-то заболел, выгорел, потерял мотивацию или решил уйти прямо перед релизом. И быстро заменить сотрудника будет сложнее.
Формат аутсорсинга для создания IT-продукта
Компания-заказчик делегирует определенные функции и задачи аутсорс-компании на долгий срок и часто без привязки к конкретному проекту. Например, крупные интернет-магазины, ритейл или владельцы стартапов заказывают или дорабатывают мобильное приложение, бэкенд для цифровых продуктов, мобильный дизайн, бизнес-аналитику или отдельные услуги. Бывают ситуации, когда уже идет работа с разработчиками, но отдельно привлекают другого подрядчика, когда нужна дополнительная экспертиза.
К аутсорсингу чаще всего обращаются в трех случаях:
- Нужно быстро создать MVP для тестирования идеи. Нанимать целую команду в штат на начальном этапе нецелесообразно и слишком затратно.
- Если не хватает экспертизы внутри компании. Например, существующий продукт быстро растет, требуя специалистов с другим стеком технологий. Чтобы не рисковать, бывает легче отдать какие-то задачи на аутсорс.
- Разработка – не основное направление работы. Малому и среднему бизнесу бывает достаточно заказать сайт или мобильное приложение с техподдержкой у сторонней компании, чем нанимать для этого целый IT-отдел.
Преимущества аутсорс-команды
- Нет затрат на содержание персонала. Не нужно платить страховые и пенсионные взносы, покупать оборудование, нанимать обслуживающих специалистов, нет издержек за простой. Если задачи закончились, команда просто переходит на другой проект. Оплата только за результат.
- Почти нет бюрократии. Не нужно вести документацию по воинскому учету, решать вопросы с трудовыми договорами и зарплатами.
- Можно быстро найти специалистов под нужный стек и направление работы.
- Гибкий подход к составу команды. Можно попросить подрядчика быстро заменить или убрать неподходящих специалистов, а если продукт не взлетел или отпала необходимость в услуге, расторгнуть договор.
Недостатки аутсорс-команды
- Разница в часовых поясах, языковый барьер, если ищете исполнителей в других регионах или странах. Нужно быть готовым к тому, что подрядчики не всегда быстро отвечают на запросы или работают по собственному графику.
- Есть риск утечки информации. Отдавая задачи сторонней команде, вы предоставляете ей конфиденциальные данные компании и даете доступ к внутренним процессам. Чтобы не попасть в неприятную ситуацию, важно сразу прописать в договоре условия конфиденциальности.
- Трудно с первого раза найти хорошего подрядчика. Если до этого вы никогда не сталкивались с аутсорсом, можно запутаться в своих запросах и большом количестве разных предложений.
Формат аутстаффинга для создания IT-продукта
Такое сотрудничество предполагает «аренду» конкретного специалиста с определенными навыками и опытом. Заказчик и посредник заключают договор о предоставлении персонала. Сотрудник заключает трудовой договор с компанией-аутстаффером, но работает на территории заказчика – в офисе или в корпоративных мессенджерах, следует его графику работы и правилам.
Аутстаффинг отдельных IT-специалистов обычно подходит в случаях, когда:
- Нужно внедрить узконаправленную технологию, но нет разработчиков с подходящим опытом.
- Есть потребность ускорить процессы и запустить проект в срок, но не хватает рабочих рук.
Преимущества аутстаффинга
- Нужного специалиста можно найти за несколько дней, а подходящего человека в штат придется искать месяцами, особенно на рынке с дефицитом опытных кадров.
- Заказчик освобождает себя от юридических и административных сложностей. Большую часть кадрового документооборота берет на себя компания-аутстаффер.
- Гибкое управление сотрудниками. Можно нанять столько людей, сколько нужно, на любой срок. А если сотрудник не подойдет, аутстаффер быстро найдет ему замену.
- Гарантии. Компания застрахована от ситуаций, когда человек может внезапно уйти или нарушить условия договора. За него несет ответственность аутстаффер.
Недостатки аутстаффинга
- Сотрудник может не вписаться в проект и корпоративную культуру. Важно, чтобы даже временный специалист быстро влился в работу и нашел общий язык с командой. Бывает, что компания при найме сотрудника на аутстафф не уделяет внимания софт скиллам, делая упор на технические навыки. Но трудности в общении могут нанести не меньший ущерб проекту.
- «Арендованным» сотрудникам бывает трудно почувствовать себя частью сложившейся команды, особенно, если они регулярно работают на краткосрочных проектах.
- Можно наткнуться на недобросовестных аутстафферов. Например, они могут резко повысить оплату за сотрудника и за продление договора, если уверены, что компания-заказчик особенно нуждается в услугах. Добросовестные подрядчики обычно прописывают такие детали в договоре и стараются сохранить хорошие отношения, но встречаются и не самые честные компании.
Сначала разобраться в нюансах каждого вида сотрудничества бывает трудно, поэтому мы с командой сделали таблицу, чтобы сравнить все форматы работы.
Как сократить риски при взаимодействии с подрядчиком
Чтобы сотрудничество действительно помогало в работе, а не приносило дополнительный стресс, важно правильно выбрать компанию-посредника. Вот несколько советов, которые помогут отсеять недобросовестные команды:
- Смотрите на опыт, кейсы и отзывы. Если компания давно сотрудничает с контрагентами, у нее уже налажены процессы и работа будет идти проще.
- Запрашивайте резюме и собеседования. У добросовестного подрядчика всегда есть подготовленные резюме кандидатов и карта компетенций, которые помогут оценить их навыки. А согласие на собеседование – еще один белый флаг, который покажет открытость компании.
- Прописывайте в договоре все нюансы. Например, за какой срок подрядчик должен найти замену неподходящему сотруднику, или в каких случаях не имеет права поднимать стоимость работы.
Также читайте:
Спасибо, Владислав, за статью! ИТ-тема здесь не явлется самой популярной. Но позволю себе несколько замечаний.
Следует расширить понятие ИТ-проектов, для которых вы разбираете варианты использования рабочей силы. Создание ИТ-инфраструктуры это ИТ-проект или нет? Допустим, что ИТ. А если при этом требуется построить новое здание,новые площадки? Значит госэкспертиза со всеми вытекающими последствиями. А если это сопряжено с массовой заменой и утилизацией старого оборудования? Вряд ли найдётся владелец бизнеса, который захочет создать свою команду под такой проект. А если мы затронем информационную безопасность, то такой проект кратно усложнит задачу.
Хорошо, уменьшим аппетиты и просто рассмотрим проект разработки нового ИТ-продукта. Или проще сразу отмести такую идею, как нереальную? Лет 15 не встречал желающих разрабатывать новый ИТ-продукт с нуля, если нет планов потом продвигать его на рынке. Скорее всего за срок его разработки поменяется и сама команда,и многие бизнес-процессы. Ну в крайнем случае берём что-то типа 1С и внедряем его. Ну ведь так? Скорее всего, ведёте разговор про внедрение, а не разработку.
Но это ничуть не упрощает задачу. Как известно, что кроме сроков, стоимости и качества не стоит отвлекаться от других целей в проекте. Да, некоторые руководители говорят, что им нужно всё сразу - и сроки, и качество, и низкую стоимость. Но так не бывает. И не будет.
Таким образом, если вы ведёте речь про внедрение ИТ-продукта, то изначально нужно опираться на этот треугольник целей, а не оценку того, нужно ли знать техническую часть. Или стараться избегать бюрократии в виде расчёта зарплаты, отпускных, страховых - это всё очень и очень несущественно.
статья запоздала лет на 10. Такие споры велись тогда очень горячо. Или Владислав пишет о небольшой компании, у которой пока мало что есть, кпоме экселя и решил поделится опытом. порассуждать. Разрабатывать свою шнягу вряд ли кто сейчас возьмётся. Ну можно что-то повнедрять. И тут тоже много зависит от того, а что именно внедрять? Бухгалтерию? Сиэрмку? СЭД? Складскую штучку? Сайт?
А что сейчас есть? Или просто десяток челов сидит?
А если в компании хотя бы человек 50, то почему бы не взять в штат руководителя проекта, а уж ему в помощь или аутсорсинг, или аутстафинг?
Глубны явно не хватает.
Обычно при решении какой-то конкретной проблемы в организации сначала как можно точнее формулируется сама проблема, цели и требования к решению, а дальше готовятся варианты и ищется лучший или лучшие.
Вариантов решения бывает много, и, помимо перечисленных в публикации, есть и другие. Причём применяться они могут в любых разумных сочетаниях и меняться со временем.
Пока думаю, что публикация - только начало обшей беседы на эту тему. А автору - благодарность за предложение её начать.
Анатолий, спасибо за обратную связь!
В статье речь идет об ИТ-аутсорсинге, в том числе о заказной разработке мобильных и веб-решений, зачастую с нуля и под ключ. Пишу с позиции руководителя компании-разработчика, у которой немало клиентов с подобной задачей. Обозначал это во введении, но оно претерпело изменения в процессе редактуры.
"Лет 15 не встречал желающих разрабатывать новый ИТ-продукт с нуля, если нет планов потом продвигать его на рынке. Скорее всего за срок его разработки поменяется и сама команда,и многие бизнес-процессы." Да, грамотный подход к созданию продукта подразумевает стратегию его дальнейшего развития, монетизации и т.д. Без этого никуда.
И конечно, в ходе работы над сложными продуктами, системами, интеграциями команда может меняться. Часто над проектом работают несколько команд с обеих сторон: например, у заказчика есть свой отдел разработки, которому не хватает экспертизы для создания конкретного функционала — тогда эти задачи отдаются на аутсорс. При этом дизайн, девопс и прочие вопросы остаются на стороне заказчика. Бывает, наоборот, крупная компания, запуская новое направление, готова отдать весь пласт работ сторонней компании (как правило, если сотрудничали ранее и уже есть доверие). Эта статья нацелена скорее на фаундеров, которые только планируют запуск ИТ-продукта и решают, какой формат сотрудничества выбрать. И на руководителей более крупных компаний, которым нужно нанять команду для нового проекта.
Согласен, проектный треугольник — полезная вещь. На этапе аналитики и составления ТЗ важно согласовать ожидания заказчика и сформировать реалистичную картину, опираясь на три компонента, о которых вы говорите. Если, предположим, заказчику нужно "быстро и за дешево" — обязательно фиксируем допущения в объеме/глубине проработки задач, которые могут иметь место в угоду другим приоритетам.
"Разрабатывать свою шнягу вряд ли кто сейчас возьмётся." — заявление весьма спорное.
У нас, как у подрядчика по заказной разработке, среди клиентов и стартапы, и крупные игроки, которые запускают новые направления, тестируют гипотезы, автоматизируют процессы — и под эти задачи заказывают кастомные решения. Разумеется, с клиентской стороны в большинстве случаев есть проджект-/продакт-менеджер или другие ЛПРы для взаимодействия с аутсорс-командой.
Моей задачей было рассмотреть плюсы и минусы форматов работы, в том числе бюрократические, что актуально и сейчас, и 10 лет назад. Тем более такие "айтишные" темы, как заметил выше Анатолий, не особо распространены на этом ресурсе.
Благодарю Вас, коллега! Тогда всё встаёт на места. Я разделяю ваши мысли в этом плане. Просто у меня gu прочтнеию статьи сложилоьмнеие, что речь идёт о некторой внутренней разработке для внутреннего использования.
В нашей команде используем и аутсорсинг, и аутстафинг - система федерального уровня, множество клиентов..
Я понял вас! С учётом комментариев я тоже некоторым образом вас не так понял. Если ваша команда работает на заказных разработках, то со мнгим согласен.
Рад, что удалось разобраться!
Если система федерального уровня, представляю масштаб работ.