Страница-источник на сайте falconspace.ru
Представьте: вы вложили в проект деньги и душу. А потом понимаете — программист тянет вниз. Ошибки, горят сроки, на вопросы смотрит как на личное оскорбление. Знакомо?
Менять разработчика — решение, которое может спасти проект. Или похоронить его. Я как практик с многолетним опытом разложу по полочкам: когда менять действительно нужно, как подготовиться и не остаться у разбитого корыта. Вы узнаете, как избежать типичных ошибок, сэкономить бюджет и сохранить проект живым.
Не дайте себя обмануть. Читайте дальше — и вы спасете свой проект.
Прежде чем увольнять, спросите себя: «А может, дело во мне?» Часто проблема не в коде, а в ожиданиях.
Тыжпрограммист — это не шутка. На технаря вешают всё: от ТЗ до замены картриджа.
Пример из практики: заказчик просил «сделать красиво», а когда получил результат, сказал: «Я другое имел в виду». Программист не экстрасенс.
Когда стоит винить себя, а не разработчика:
Если узнали себя — лучше наладить процессы, а не менять человека. Как улучшить взаимодействие с программистом.
Пример: один разработчик закладывал «логические бомбы» — код, который ломал сайт после его ухода. Это реальность.
Потеря программиста — это не просто «ушел один человек». Это:
Совет: привлеките независимого эксперта для аудита кода. Пусть он скажет не «всё плохо», а конкретно: «вот этот модуль написан криво, вот тут риск». Не дайте себя развести на полную переделку.
Итак, решение принято. Не спешите. Подготовьте почву.
У вас должен быть доступ к коду в любой момент. Делайте резервные копии, недоступные разработчику. Иначе рискуете остаться с пустым проектом.
Знать технологию сайта — база. Документация администратора и программиста спасет, когда придет новый человек. Без нее он будет гадать, что к чему.
Расстаньтесь по-доброму. Это снижает риски мести и оставляет дверь открытой для будущей помощи. Пример: один клиент выплатил бонус при увольнении, и через полгода бывший разработчик помог срочно починить баг за час.
Держите под рукой 3-10 кандидатов, которые подходят по навыкам и деньгам. Проверяйте их заранее, а не в аврале.
Объясните человеку, почему увольняете. «Свободен» без объяснений — путь к обиде и саботажу.
Смените доступы до увольнения, особенно если человек вспыльчив.
Посмотрите, что он делал в последнее время. Может, он не так плох? Или, наоборот, найдете улики.
Важно: Никогда не экономьте на увольнении. 50-100 тысяч сэкономленных рублей могут обернуться миллионными убытками от мести программиста.
Подробнее о том, как программисты могут обманывать.
Первое. Смена разработчика — провал менеджмента. Как этот человек вообще попал в проект? Лучше не допускать такого. Как найти программиста и не пожалеть потом.
Второе. Расставайтесь по-доброму. Выплатите всё, помогите с поиском работы, напишите благодарность. Это прагматично, а не «игра в добряка».
«Ничего личного, только бизнес» — не оправдание для гадостей. Это про фокус на цели проекта, а не на своем эго.
P.S. «А давайте всё перепишем?» — плохая идея. Если не исправить подходы к управлению, получите тот же результат. Лучше переработайте свои методы.
