Замена разработчика. Как сменить исполнителя по ходу IT-проекта

Смена разработчика: как не угробить проект и сберечь нервы

Представьте: вы вложили в проект деньги и душу. А потом понимаете — программист тянет вниз. Ошибки, горят сроки, на вопросы смотрит как на личное оскорбление. Знакомо?

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

Не дайте себя обмануть. Читайте дальше — и вы спасете свой проект.

Точно ли проблема в программисте? Разбор ситуации

Прежде чем увольнять, спросите себя: «А может, дело во мне?» Часто проблема не в коде, а в ожиданиях.

Тыжпрограммист — это не шутка. На технаря вешают всё: от ТЗ до замены картриджа.

Пример из практики: заказчик просил «сделать красиво», а когда получил результат, сказал: «Я другое имел в виду». Программист не экстрасенс.

Когда стоит винить себя, а не разработчика:

• Задачи размыты, а вы ждете, что он угадает ваши мысли.
• Вы неделями думаете над дизайном, а потом даете дедлайн в 2 дня.
• Игнорируете его уточняющие вопросы — «ну ты же специалист, сам разберись».
• Хотелки меняются каждый день, и половину вы забываете.

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

Когда разработчика точно нужно убирать

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

Пример: один разработчик закладывал «логические бомбы» — код, который ломал сайт после его ухода. Это реальность.

Как уход разработчика влияет на проект

Потеря программиста — это не просто «ушел один человек». Это:

• Замедление работ.
• Поиск замены с теми же навыками (а это ад).
• Обучение новичка, которое отвлекает команду.
• Риски безопасности — доступ к коду получает новый человек.
• Месть обиженного: от плохих отзывов до взлома.

Совет: привлеките независимого эксперта для аудита кода. Пусть он скажет не «всё плохо», а конкретно: «вот этот модуль написан криво, вот тут риск». Не дайте себя развести на полную переделку.

Что сделать до смены разработчика: чек-лист

Итак, решение принято. Не спешите. Подготовьте почву.

1. Исходный код проекта

У вас должен быть доступ к коду в любой момент. Делайте резервные копии, недоступные разработчику. Иначе рискуете остаться с пустым проектом.

2. Документация

Знать технологию сайта — база. Документация администратора и программиста спасет, когда придет новый человек. Без нее он будет гадать, что к чему.

3. Хорошие отношения

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

4. Список замены

Держите под рукой 3-10 кандидатов, которые подходят по навыкам и деньгам. Проверяйте их заранее, а не в аврале.

5. Честные причины

Объясните человеку, почему увольняете. «Свободен» без объяснений — путь к обиде и саботажу.

6. Смена паролей

Смените доступы до увольнения, особенно если человек вспыльчив.

7. Ревизия последних изменений

Посмотрите, что он делал в последнее время. Может, он не так плох? Или, наоборот, найдете улики.

Как обиженный разработчик может навредить

• Логическая бомба — код, который ломает сайт при условии (например, 1 января). Обнаружить сложно.
• Слив данных — публикация паролей или документации. Ущерб огромен, а доказать сложно.
• Черный пиар — посты в соцсетях о «замечательной» работе у вас. Осадок останется.

Подробнее о том, как программисты могут обманывать.

Алгоритм замены программиста: пошагово

1. Подготовка — код, документы, отношения, причины. Это главное.
2. Разговор — обсудите проблемы, дайте второй шанс с четкими критериями. Выслушайте его — может, дело в вас.
3. Фиксация — блокировка доступа, подписание бумаг.
4. Открытая дверь — оставьте возможность консультаций или подработки. Это выгодно обеим сторонам.

Заключение

Первое. Смена разработчика — провал менеджмента. Как этот человек вообще попал в проект? Лучше не допускать такого. Как найти программиста и не пожалеть потом.

Второе. Расставайтесь по-доброму. Выплатите всё, помогите с поиском работы, напишите благодарность. Это прагматично, а не «игра в добряка».

«Ничего личного, только бизнес» — не оправдание для гадостей. Это про фокус на цели проекта, а не на своем эго.

P.S. «А давайте всё перепишем?» — плохая идея. Если не исправить подходы к управлению, получите тот же результат. Лучше переработайте свои методы.

Насколько полезной была статья?

Взаимодействие с подрядчиками - как улучшить работу с программистом

Плохой, хороший программист. В чем ключевые качества программиста?

Доработка сайта - реальный кейс о неприятной ситуации с одним проектом

Постановка задачи программисту. Как ставить задачу разработчику

Заказать сайт: цена вопроса. Как не переплатить и получить результат?

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

Как писать ТЗ программисту?