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