Предположим, вы или ваше руководство пришло к выводу, что без мобильного приложения бизнес теряет прибыль и обойтись завёрнутым в какую-нибудь программную обёртку веб-сайтом никак невозможно, нужно пилить что-нибудь нативное.
У вас четыре варианта подхода к найму исполнителей.
- Инхаус-команда.
- Один или несколько фрилансеров.
- Аутстаф команда под полным вашим контролем.
- Подрядчик, которому вы поручаете работу под ключ.
У каждого варианта есть плюсы и минусы, давайте разбираться.
Инхаус команда
Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату.
Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры.
Большая ответственность ложится на рекрутера и нанимающего менеджера. Если они наймут недостаточно квалифицированных специалистов, вы потеряете довольно много денег на их зарплаты и урегулирование увольнений без суда (предполагаю, что вы работаете по белому).
Инхаус-сотрудников можно мотивировать корпоративной шизой, давить на совесть, просить переработать во имя будущих бенефитов и применять другие управленческие дарк-паттерны. Во всех остальных вариантах это будет затруднительно или невозможно.
Есть мнение, что инхаус-разработка стабильнее. Что у штатного сотрудника выше мотивация, он внезапно не пропадёт с радаров. Однако работодатели делились со мной историями, как штатный сотрудник просто переставал приходить в офис и брать трубку, даже не забирал трудовую.
Один или несколько фрилансеров
Главный плюс этого варианта — дешевизна. Вы можете найти фрилансеров на совершенно любой бюджет. Даже если у вас буквально три копейки, найдутся люди, которые выполнят заказ и далеко не факт, что некачественно.
Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании.
В остальном же, у этого подхода сплошные недостатки. Например, у фрилансера может быть основная работа, на которой сейчас его не слишком напрягают и у него есть время фрилансить, а через месяц ситуация поменяется. Без договора, фрилансер связан с вами только устными обязательствами и рискует только своей репутацией на данной площадке.
Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов.
За фрилансерами крайне желательно ставить наблюдать штатного специалиста, чтобы он проводил код ревью и добивался качественного, читаемого, поддерживаемого кода. Для того, чтобы когда вам придётся фрилансера заменить, новый специалист не потребовал переписать код с нуля, а мог нормально подхватить недоделанную работу.
Аутстаф команда под вашим контроем
Находите аустаф-компанию, договариваетесь о часовых ставках и грейдах, вам предоставляют специалистов. Вы ставите им задачи, они их пилят и отчитываются в какой-нибудь таск-трекер об отработанных часах. В конце месяца аккаунт присылает отчёт, вы проводите оплату.
Достаточно гибкий вариант. Вы так же, как с фрилансерами, можете формировать и перетасовывать команды как угодно. Если не нравится работа конкретного специалиста, не нужно думать, как его правильно уволить, просто просите аккаунта его заменить.
Недостаток метода в дороговизне. Аутстаферам нужно платить специалистам зарплаты и при этом что-то зарабатывать, поэтому это самый дорогой вариант.
Кроме того, аутстаферы не несут никакой ответственности за результаты и их крайне сложно этой ответственностью наделить. Вы самостоятельно должны их менеджерить, следить за постоянством загрузки и тем, чтобы они делали только приоритетные вещи.
Подрядчик для работы под ключ
Метод подходит для не очень сложных приложений, для которых вы можете составить полное ТЗ и делегировать его производство подрядчику, чтобы он сделал его водопадом за раз, за фиксированный бюджет.
В этом случае ТЗ можно приложить к договору, чётко оговорив критерии качества продукта, который должен получиться в итоге. Возможно, подрядчик захочет написать более детализированное ТЗ и согласовать с вами, на это уйдёт дополнительный бюджет.
Возникает вопрос, как потом поддерживать получившееся приложение. Тут возможны варианты, всё зависит от изменчивости среды и потока изменений. Можно заключить отдельный договор на сопровождение с этим же или другим подрядчиком.
Также возникает вопрос, как в этом случае проконтролировать качество кода с точки зрения последующего обслуживания, развития и доработок.
На практике рассмотренные методы хорошо и правильно комбинировать. Например, нанять инхаус лидов, а для исполнителей использовать аутстаф.
