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

Можно, но только если грамотно разделить роли на старте.

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

Рабочая схема такая. Ядро команды — штатные сотрудники, которые остаются навсегда. Тимлид, один-два специалиста на поддержку и развитие. Они будут нужны всегда.

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

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

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

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

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

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

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

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

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

Фриланс в поддержке — утопия. А вот масштабировать разработку и поддержку подрядчиками можно и нужно. Смотрите на их «ДНК»: если их процессы и экспертиза усиливают вашу команду, это хорошее решение, если нет — хаос станет нормой. Стабильный продукт держится на процессах, дисциплине и экспертизе команды. Своей или чужой не так важно.

Решение зависит от смысла и бюджета. Если у интернет-магазина есть долгосрочная стратегия, финансирование и планы на развитие, интеграции и поддержку, инхаус-команда оправдана. Тогда подбирайте не под разовый запуск, а под полный цикл: тимлид, разработчики, QA, DevOps, аналитик. Важно планировать роли на 1–2 года, искать универсалов и обеспечить постоянный поток задач, чтобы после запуска не пришлось расставаться. Нанимать фрилансеров здесь рискованно. Если же твердых планов на следующие этапы нет, выгоднее и безопаснее нанять агентство: оно закроет задачу и не потребует постоянных затрат.

При формировании отдела я бы разделял три типа работ:

1. То, что происходит постоянно: поддержка, исправление ошибок, контроль интеграций.

2. Регулярное развитие: новые функции, автоматизация процессов, развитие личного кабинета, новые сценарии для клиентов.

3. Работы, которые возникают время от времени: большой редизайн, специфическая интеграция.

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

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

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

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

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

Для запуска интернет-магазина нужна связка компетенций: продукт и бизнес-цели, UX/UI, маркетинг, frontend и backend, тестирование, инфраструктура, аналитика, безопасность, интеграции. Ключевая роль здесь у владельца продукта или сильного руководителя проекта. Он держит приоритеты, связывает техническую команду с бизнесом и следит, чтобы решения выбирали под задачу компании, а не ради интересной технологии.

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

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

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

С подрядчиком тоже не всё так просто. Команд, которые умеют системно поддерживать и развивать веб-проекты, на рынке немного. Мы в PetrogradWeb отдельно выстраивали поддержку и развитие как самостоятельную компетенцию. Даже с опытом в разработке и дизайне это оказалось сложнее, чем кажется: нужны процессы, роли, приоритезация, контроль качества, накопление знаний о проекте и понятная коммуникация с клиентом. Одних сильных разработчиков для этого недостаточно.

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

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

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

1. Сейчас появилось много псевдоразработчиков на нейронках, некоторые из которых и простейшую myaql базу через phpMyAdmin развернуть не в состоянии. Выглядит это дешево и возможно такой специалист и доведет сайт до ума, но при первой же серьезной проблеме не будет понимать куда «ткнуть мышкой». Буквально на прошлой неделе чинили клиенту сайт из-за того, что два разработчика банально скопировали код, который им дал ИИ, а так как их сайты были на одном хостинге и одном движке, их кэш смешался и вместо своих страниц они видели страницы друг друга.

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

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

Решение: четко прописывать ответственность в договоре, делать независимые проверки.