Две недели назад к проекту подключили внешнего разработчика. Задачи задерживаются, а в рабочем чате всё чаще появляются слова «разбираюсь» и «нужно уточнить».

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

Я Антон Калуцкий, руководитель DEVCOM — экспертного центра аутстаффинга ИТ-специалистов с глубокой экспертизой в 1С. В нашей практике запрос на замену бывает связан и с подготовкой человека, и с тем, как устроена работа на проекте. Прежде чем искать следующего кандидата, я бы посмотрел на несколько конкретных задач: что поручили, где работа остановилась и почему. Иногда после такого разбора действительно нужна замена. Иногда достаточно наконец выдать доступ к базе.

Что именно не получается

Фраза «разработчик не справляется» понятна всем, пока не начинаешь задавать вопросы. Один руководитель имеет в виду ошибки в коде, другой — сорванные сроки, третий недоволен тем, что человек молчит на встречах. Претензия вроде бы одна, а разбираться придётся с разными вещами.

Возьмём сроки. Специалист оценил задачу, но не уложился. Возможно, недооценил сложность. Возможно, в процессе обнаружились старые доработки, о которых никто не предупредил. Или понадобился ответ от команды, которая отвечает за соседнюю систему.

При этом есть существенная разница между «во вторник увидел проблему и сразу сообщил» и «во вторник увидел проблему, а в пятницу, в день сдачи, рассказал». Во втором случае вопросы к разработчику остаются, даже если препятствие было вполне реальным.

Поэтому перед разговором с поставщиком полезно перевести недовольство в примеры. Вместо «он несамостоятельный» — «по трём задачам пришлось заново объяснять уже согласованный алгоритм». Вместо «с ним невозможно общаться» — «он не предупредил о задержке, хотя мы договорились сообщать о таких вещах сразу».

С такими формулировками уже можно работать. И сам человек сможет ответить по существу, а не защищаться от общего ощущения, что с ним что-то не так.

Не хватает опыта или сведений о проекте

Допустим, разработчик хорошо знает типовой функционал 1С, но ему поручили сложный обмен между системами. Он затрудняется выбрать решение, просит технической помощи, допускает ошибки. Здесь стоит вернуться к заявке: какой опыт искали и что проверяли на собеседовании?

Если самостоятельная работа со сложными обменами была обязательным требованием, а на практике человек её не тянет, претензия обоснована. Поставщику нужно предложить специалиста с подходящим опытом.

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

Но есть ещё одна история, внешне похожая на нехватку квалификации. Разработчик спрашивает, почему документ проводится именно так, откуда взялось ограничение и какое поведение система должна выдавать в спорном случае. Команда раздражается: «Ты же опытный, посмотри в коде».

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

Часть вопросов действительно можно закрыть самостоятельно. Но подтвердить, чего ждёт бизнес, должен человек, который имеет право это решать. Когда такого ответа нет, работа останавливается независимо от фамилии исполнителя.

Где проект сам тормозит работу

С доступами всё особенно наглядно. Человек подключён, время идёт, задача назначена, но открыть нужную базу он не может. Можно заменить разработчика, только доступ новому всё равно придётся выдать.

Менее очевидные задержки выглядят вполне буднично: постановщик занят и ответит завтра; приоритеты поменялись; готовую доработку некому проверить. По отдельности ничего чрезвычайного. А потом руководитель смотрит на срок задачи и спрашивает, чем специалист занимался всю неделю.

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

Для начала достаточно разобрать несколько задач, которыми команда особенно недовольна. Когда они поступили? Что было понятно на старте? Сколько времени заняла сама работа, а сколько — ожидание ответов и проверки? Какие замечания касались ошибок, а какие появились впервые при приёмке?

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

Тихий разработчик тоже может хорошо работать

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

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

Здесь легко уйти в разговор о характерах: один активный, другой закрытый, третий «не вписался». Я бы сначала уточнил рабочие ожидания. Нужно ли разработчику обсуждать спорные требования до реализации? Предупреждать о препятствиях? Согласовывать изменения, которые затронут чужой участок? Если без этого команда не может работать, такие обязанности нужно проговорить.

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

А количество реплик на созвоне само по себе мало что говорит о результате. Иногда человек молчит, потому что занят задачей. Иногда потому, что ему нечего сказать. Выяснить разницу полезнее, чем просить его быть поактивнее вообще.

Когда замену уже не стоит откладывать

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

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

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

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

Если решено проверить работу ещё раз, договоритесь, какую задачу человек должен выполнить, к какому сроку и кто оценит результат. «Понаблюдаем пока» легко растягивается на недели. У проверки должна быть дата окончания, после которой принимается решение.

Как не начать всё сначала с новым человеком

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

Какого опыта не хватило? Насколько самостоятельным должен быть человек? Получит ли он готовые постановки или будет сам выяснять требования? Кто поможет разобраться в системе? Если ответы остались только в переписке с прежним разработчиком, поставщик о них не узнает.

Затем нужно собрать текущую работу. Где лежат изменения, что уже проверено, какие задачи не закончены, по каким вопросам ждут решения? Незавершённые наработки кто-то должен посмотреть и решить, можно ли их использовать дальше. Иначе новый специалист потратит первые дни на восстановление событий.

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

Перед отправкой запроса поставщику я бы коротко записал ответы на шесть вопросов:

· Какой конкретно результат нас не устраивает?

· Соответствовали ли задачи той роли, на которую мы брали человека?

· Были ли у него доступы, нужная информация и возможность получить помощь?

· Что мы уже обсуждали со специалистом и что после этого изменилось?

· Какие требования к следующему кандидату теперь нужно уточнить?

· Кто передаст ему текущую работу и в каком состоянии?

По этим ответам проще и подобрать замену, и подготовить её выход. А если через две недели новый разработчик снова остаётся без ответов и ждёт тех же согласований, пора вернуться к условиям работы на проекте. Третье резюме само по себе их не исправит.