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

Неприятная ситуация

У вас по каким-то причинам возникла идея сменить текущего программиста на проекте. По каким-то причинам он вас перестал удовлетворять:

1. возможно слишком низкое качество и множество ошибок;
2. делает долго;
3. задает постоянно дурацкие вопросы (сложно взаимодействовать);
4. постоянно просит повышения ЗП;
5. деньги тратятся, а серьезного профита для проекта это не приносит.

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

Точно уверены, что вам следует сменить разработчика?    

Для начала нужно определиться - точно менять или нет. Зачастую проблема не в программисте, а в ожиданиях.

Тыжпрограммист - это выражение появилось не просто так.

Оно означает, что на технаря вешают абсолютно все - разработка ТЗ, замена картриджа, обслуживание серверов, создание сайта и т.д.

Если вы из таких руководителей - то вероятно проблема в вас, а не в вашем программисте.

В каким случаях вы НЕПРАВЫ:

1. формулировка задач очень размыта, программист делает, как он понимает и не угадывает ваши потаенные желания;
2. вы очень долго прорабатываете лого, дизайн, название, а потом вы даете программисту задачки на внедрение с дедлайном в несколько дней. Т.е. работа программиста как бы несложная, автоматическая, главное же скреативить, а остальное дело техники.
3. вы постоянно отбрыкиваетесь от неудобных КОНКРЕТНЫХ вопросов программиста. Какой надоедливый попался, однако.
4. у нас 100500 хотелок, причем никак не связанных, из них половину мы уже забываем через день. Ну а программисты должны как-то успевать разбирать этот поток создания великого начинателя.

Все это примеры проблемного руководителя проекта (со стороны заказчика), а не программиста.

Если вы узнали здесь где-то себя, то лучше подумать, как сделать свои методики работы на проекте более эффективными.

Когда программиста с большой долей уверенности нужно убирать с проекта:

1. когда замечен в явном саботаже работ.
2. когда намеренно принял заведомо плохое решение в проекте (но выгодное ему). Хотя и это в некоторых случаях может быть простительно.
3. когда имеет место множественное нарушение принципов работы на проекте (не хочет человек работать по правилам проекта). Это очень важный момент, т.к. код создаваемый человеком, потом нужно поддерживать. Любые неточности увеличивают сложности и затраты при сопровождении. Некоторые отхождения от основного процесса создают такие ситуации, что придется переписывать весь модуль, что совсем плохая ситуация в плане бюджета.

Как повлияет уход программиста из проекта на сам проект?

Потеря программиста - это не просто выход одного человека. Это системным образом влияет на проект:

1. замедляет ход текущих работ,
2. нужно искать замену со сходными навыками и опытом (а это сильно непросто),
3. нового программиста надо обучать, он будет довольно сильно отвлекать других участников проекта (если вы еще такого найдете),
4. поднимаются риски безопасности, т.к. приходится давать доступ к коду новым людям,
5. если вы обидели уволенного человека (или он таковым себя считает), то он может мстить. Об этом ниже еще поговорим.

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

Тут важный момент - требуйте от специалиста конкретики. Не просто "че-то он не то пишет", а что конкретно хорошо или нехорошо он делает в коде. Это крайне важный момент. Нам интересно не впечатление, а конкретные аргументы за и против. Это не фигурное катание с оценками, а вполне объективно оцениваемая область по фактам.

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

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

Что важно сделать перед сменой разработчика на проекте?

Итак, считаем, что вы приняли все же решение менять программиста на проекте. Очень важно заранее подготовиться к данному изменению в проекте.

Что необходимо учесть перед уходом разработчика?

Наличие исходного кода проекта

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

У вас в любой момент времени должен быть доступ к исходному коду. Также необходимо периодически делать копию, недоступную разработчикам. Это убережет вас от возможных "террористов", которые со своим уходом уничтожают все данные проекта (то, что бывают "неадекваты", думаю, все знают).

Документация по проекту

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

Обязательно должна быть документация администратора и документация программиста.

Дока программиста даже важнее, т.к. если не описаны нюансы разработки, то очень сложно будет все это воспроизводить по исходному коду.

Хорошие отношения с уходящим разработчиком

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

1. ниже риск вредительства;
2. возможная помощь в будущем по проекту. Не забывайте, что этот человек является источником знаний по вашей системе.
3. помощь в будущих доработках (особенно когда вы не найдете ему замену или потребуется срочно увеличить скорость доработок).
4. возможно он приведет замену сам себе.

Если вы расстаетесь по-плохому, то вы вероятно сэкономите 50-100 тыс руб, но при этом теряете все плюсы, обрезаете возможные будущие контакты и повышаете риски проекта (вредительство, плохая молва).

Иметь на примете варианты замены

В идеале всегда иметь список из 3-10 человек, которые потенциально могли бы влиться в ваш проект. И постоянно пополнять его. Чем больше у вас подобных кандидатов, тем выше шансы, что вы не останетесь с мертвым проектом.

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

Создавайте такой список заранее, а не когда вам уже нужно искать замену.

Сформулировать честные объективные причины

Имеет смысл подумать над причинами увольнения человека. Если это просто "Свободен" без всяких объяснений, то это может сильно обидеть. А обиженный программист нам никак не нужен. 

Исключение из проекта по необъективным причинам создает также плохую среду и для существующих людей.

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

Парадигма "я начальник, ты дурак" в принципе не может работать в творческом коллективе с открытой системой (когда можно уволиться и найти другую работу).

Даже в замкнутой системе (когда нет выхода из нее, например, госкомпания + льготная ипотека) такой подход порождает апатию, непрерывный стресс и тихий саботаж. Поэтому убирать людей из проекта нужно только по объективным честным причинам. Помните, как о самом человеке, так и о тех, кто остается дальше работать в проекте.

Смена ключевых паролей

Тут все просто. Лучше пароли, к которым имел доступ сотрудник заменить заранее. Особенно в случае, если исключение из проекта идет не совсем гладко, либо человек показывал ранее взрывной характер (а таких лучше вообще не брать - пусть себе взрывается и показывает свой крутой нрав и сложный внутренний мир где-то в другом месте).

Более плотная ревизия последних изменений

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

Так вы лучше поймете, чем он занят на работе и как выполняет свои задачи. Возможно вы увидите, что он не так уж и плох, как казалось. Но если все плохо - у вас будет фактический материал для обоснования, а также вы проверите не было ли какой-то подозрительной вредительской деятельности.            

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

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

Какие угрозы исходят от обиженного программиста:

1. логическая бомба, закладка - это программный код в системе, который позволяет нарушить работу сайта при срабатывании определенного условия (например, в 00:00 1 января). Это очень неприятная штука, ее можно нивелировать только постоянной ревизией всего исходного кода, что является крайне непростой задачей.
2. передача паролей в открытый доступ. Обиженный человек может взять и опубликовать всю конфиденциальную информацию, к которой у него был доступ (например, пароли или техническую документацию). Ответственность за это очень сложно прописать и доказать. Ущерб также сложно доказать. Но оказаться он может при этом просто громадным. Периодически в сети появляются исходники разных программ и порталов (Госуслуги). Где-то это работа хакеров. Но гораздо более простой и понятный путь - это обиженный или мотивированный извне инсайдер.
3. негативная информация о проекте и владельце проекта. Обиженец может начать против вас информационную кампанию в сети. Пойдет на главные площадки и напишет посты о том, какая у вас "замечательная" команда, как у вас "хорошо" работалось и про все ваши "серые" схемы.  Конечно вы все это сможете парировать, но осадочек останется.

Замена программиста - алгоритм действий для владельца продукта

Перейдем к конкретному алгоритму действий по выводу человека из проекта.

1. Подготовиться к смене программиста. Выше мы все это уже обсудили. Главное - код, документация, хорошие отношения, объективные причины. Этот этап главный. Если вы все верно сделали, то остальное уже будет идти в форсированном режиме. 
2. Выработать совместное решение с программистом и командой. Обсудить честно и открыто с человеком все проблемы и выработать общее решение. Можно здесь дать второй шанс с четкими критериями, которые можно проверить. Либо просто выложить на стол свои аргументы и смотреть реакцию человека. Кто-то сразу сам все поймет, кто-то будет сопротивляться и приводить свои доводы. Как минимум выслушайте их, может все же проблема не в программисте, а способе взаимодействия. 
3. Реализовать фиксирующие действия. Это исключение из проекта, блокирование учетной записи, формальное подписание актов расторжения договора или приказа об увольнении.
4. Оставить открытой дверь. Очень важный момент - оставить возможность будущей совместной работы. Человек может работать консультантом или по сдельным часам на удаленной работе и т.д. Не отнимайте у себя эту возможность. Плюс человек будет тоже иметь вас в виду и не будет рубить сгоряча. Некоторые крупные компании даже делают сообщество бывших сотрудников для поддержания связи. Для людей это может быть важно в социальном плане - бывшие коллеги, как там дела у "нас". А для компании - это возможность привлечь проверенные ресурсы, когда в этом будет необходимость.

Заключение

Первое

В целом ситуация со сменой разработчика - плохая. Это недоработка, в первую очередь, менеджмента.

Если человек настолько плох, что его нужно менять, как он вообще проник в вашу систему? Как вы так его проверяли и принимали? Зачем было столько ресурсов вбухивать в него, чтобы потом просто его отцепить от проекта. Просто ужасная ситуация. В идеале такой человек вообще не должен был появиться в проекте и его необходимо было "снять с трека" еще на этапе кандидата.

Второе

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

Фраза "Ничего личного, только бизнес" имеет негативный оттенок. Часто ее употребляют в таком контексте: человек сделал какую-то очевидную гадость и оправдывается этим самым "бизнесом".

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

P.S. "А давайте все перепишем, а?". Иногда возникает идея все бросить и начать заново писать. В большинстве случаев это плохая идея. Если вы не сделали свою "работу над ошибками", если нет кардинальных улучшений в менеджменте, то скорее всего вы получите второй такой же проект.

Поэтому вместо полной переработки проекта, лучше подумать о полной переработке своих подходов к проекту.

Переписывать - не самый лучший вариант

Источник: https://falconspace.ru/blog/zamena-razrabotchika-v-veb-proekte--kak-smenit-programmista-po-khodu-proekta