Как оценить работу программиста

5

Как разработчику оценить трудозатраты

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

В начале пути, когда давал оценку будучи разработчиком, я постоянно недооценивал. Каждый раз выявлялась работа, которую я не учел. Коллеги советовали умножать оценки на 2, на 3, на число ПИ — но это не помогало улучшить точность оценок, а только добавляло других проблем. Например, когда нужно было объяснить, откуда взялась высокая оценка.

С того времени прошло 10 лет. За это время я участвовал в оценке более 200 проектов, набил много шишек и хочу поделиться с вами мыслями на тему оценки проектов.

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

Зачем давать оценки?

Процент «успешных» проектов не превышает 29% (Исследование The Standish Group за 2015 год). Остальные 71% либо провальные, либо вышли за рамки тройного ограничения (сроки, функционал, бюджет).

Из этой статистики делаем вывод, что оценка проектов часто не соответствует действительности. Значит ли это, что оценку давать нет смысла? На просторах интернета даже появилось движение за то, чтобы не давать никаких оценок, а просто писать код — и будь, что будет. Что успеем, то успеем (поищите по тегу #noestimates).

Не давать никаких оценок — звучит заманчиво, но давайте отвлечемся и представим, что вы заказываете такси. Вы спрашиваете водителя: «сколько стоит доехать до такой-то улицы», а он отвечает: «не знаю, садись в машину, доедем — скажу, сколько заплатить по приезду».

Или, например, вариант в стиле Agile: «Ну, мы будем ехать, а ты будешь платить мне каждые 10 минут в дороге — и так пока не кончатся деньги) Как кончатся — высажу, но, возможно, мы доедем, или будем уже рядом. Ну, а если не рядом, то это твои проблемы — не повезло.»

Примерно так ощущают себя заказчики в ИТ, когда им предлагают начать работы без каких-либо оценок.

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

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

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

Причины недооценивания

Игнорирование теории вероятности

Давайте представим, что менеджер спрашивает разработчика, за сколько он сделает задачу. Разработчик уже делал подобное ранее и дает «наиболее вероятную» оценку. Пусть это будет 10 дней. Есть, конечно, вероятность, что задача займет 12 дней, но эта вероятность ниже, чем вероятность того, что задача займет 10 дней. Так же есть вероятность, что задача займет 8 дней, но и эта вероятность будет меньше.

Часто предполагается, что оценки на задачу/проект распределяются по нормальному закону распределения (подробнее о нормальном распределении). И, если изобразить распределение оценок и их вероятностей в виде графика, то мы получим следующую картину: Ось Х соответствует оценке, а ось Y -вероятности того, что эта оценка окажется верной, и задача займет именно этот срок (ни больше, ни меньше). В центре, как вы видите, — точка с наибольшей вероятностью или наиболее вероятная оценка. Эта вероятность соответствует нашей оценке в 10 дней.

Площадь под кривой дает суммарную вероятность в 100%. Получается, что если мы дадим наиболее вероятную оценку, то мы завершим проект/задачу в срок или ранее с вероятностью в 50% (площадь под графиком до оценки 10 часов — это половина площади фигуры, и равна 50%). Т.е., руководствуясь данным принципом и давая наиболее вероятную оценку мы должны срывать примерно 50% сроков.

И это при условии, что распределение вероятности действительно соответствует нормальному распределению. При нормальном распределении вероятность закончить раньше наиболее вероятной оценки равна вероятности закончить позже нее. Но, если задуматься, на практике вероятность того, что что-то пойдёт не так, гораздо выше того, что случится чудо, и мы закончим раньше. Другими словами, суммарное значение всех негативных рисков всегда больше, чем «рисков» позитивных (возможностей).

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

Получается, что если взять «наиболее вероятную» оценку в 10 дней, то вероятность того, что задача будет готова в этот срок или раньше — меньше 50%.

Игнорирование текущего уровня неопределенности

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

Исследования Луиса Ларанхейра (PhD, Associate Professor at The University of Brasilia) также показывают, что точность оценки программного проекта зависит от степени проясненности требований (Luiz Laranjeira 1990). Чем более прояснены требования, тем точнее оценка. Оценка не точна, прежде всего, потому, что неопределенность заложена в самом проекте/задаче. Единственным способом сокращения неопределенности в оценке является сокращение ее в проекте/задаче.

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

Итак, основные причины недооценивания — это неопределенность и игнорирование теории вероятности.

Зависимость точности оценки от стадии проекта

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

Если взять оптимистичную, пессимистичную и наиболее вероятную оценки (оптимистичная оценка — это самый ранний срок сдачи из всех возможных, пессимистичная — самый поздний) и показать, как отношение между ними меняется со временем, от начала проекта до его завершения, то получится следующая картина: Эта фигура называется конусом неопределенности. Горизонтальная ось соответствует времени от начала работы над проектом до его завершения. На ней отмечены основные этапы проекта. На вертикальной оси отмечается относительная величина ошибки в оценке.

Так, на стадии исходной концепции наиболее вероятная оценка может отличаться от оптимистической в 4 раза. На стадии готового UI разброс оценки уже варьируется от 0,8 до 1,25 относительно наиболее вероятной оценки.

Для удобства привожу эти же данные в виде таблицы:

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

Чтобы продвинуться по конусу в самую правую точку, где нет неопределенности, нам нужно создать готовый продукт 🙂 Получается, пока продукт не готов, неопределенность есть всегда, и оценка не может быть точной на 100%. Но на точность оценки можно повлиять, снижая неопределенность. При этом, любое действие, направленное на снижение неопределенности, снижает разброс оценки.

Данную модель используют во многих компаниях, в том числе и в NASA. Некоторые адаптируют ее, чтобы учитывать нестабильность требований. Более детально об этом можно прочитать в «Software Estimation: Demystifying the Black Art».

Что считать хорошей оценкой?

Есть много версий ответа на этот вопрос, но на практике, если оценка отклоняется от цели проекта более чем на 20%, то у руководителя проекта нет пространства для маневра. Если оценка колеблется в пределах 20%, то проект можно завершить успешно за счет управления функциональностью, сроками, размером команды и другими параметрами. Это звучит достаточно разумно, поэтому давайте для примера остановимся на этом определении хорошей оценки (это решение должно быть принято на уровне организации — кто-то рискует, и их устраивает отклонение в 40-50%, а кому-то и 10% много).

Итак для нас хорошей оценкой будет считаться та, что отличается от фактического результата не более чем на 20%.

Практика. Оцениваем проект на разных стадиях

Давайте представим, что к вам пришел менеджер проекта и попросил оценить какую-то функцию или проект.

Первым делом нужно изучить доступные требования и понять, на каком этапе жизненного цикла находится описание задачи или проекта (Исходная концепция, Согласованное определение, Завершенные требования, Готов UI, Спроектирована архитектура).

Дальнейшие действия зависят от того, на каком этапе мы находимся:

Стадия 1. Исходная концепция

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

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы дать оценку на данном этапе?

Нужно иметь данные фактических трудозатрат по похожему завершенному проекту.

Какие инструменты больше всего подходят на данном этапе?

• Оценка по аналогии

Алгоритм оценки

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

Например, оценку можно озвучить как «Я не знаю сколько времени займет этот проект, так как данных недостаточно, но чем-то похожий на него проект Х занял Y времени. Чтобы дать хотя бы примерную оценку по данному проекту, нужно прояснить требования.»

Если данных по похожим завершенным проектам нет, то единственный возможный вариант дать оценку — снижать неопределенность и переходить на следующий этап.

Как перейти на следующий этап?

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

В идеале нужно иметь навыки сбора и анализа требований.

Для того, чтобы повысить свои навыки в сборе и анализе требований, неплохо бы прочитать «Разработка требований к программному обеспечению» Карл И. Вигерс, Джой Битти

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

• Для чего нужно приложение? Какие проблемы оно будет решать?
• Какие типы пользователей будут пользоваться приложением? (для задачи, озвученной выше — это, скорее всего, Врач, Пациент, Администратор)
• Какие проблемы каждый тип пользователей сможет решать в приложении?
• На каких платформах будет работать приложение?

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

Стадия 2. Согласованное определение продукта

На данном этапе уже есть понимание, что приложение будет делать и что не будет. Хотя и без подробных деталей.

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы дать оценку на данном этапе?

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

Какие инструменты больше всего подходят на данном этапе?

• Оценка по аналогии
• Оценка сверху вниз

Алгоритм оценки

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

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

Так, например, в случае с приложением «где доктора будут консультировать пациентов» у нас могло бы получиться следующее:

• Регистрация
• Система записи на прием
• Система уведомлений
• Видео консультации
• Система отзывов
• Система оплаты

И для оценки блока «Регистрация» можно взять оценку с одного проекта, а для оценки блока «Система отзывов» — с другого.

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

Так, например, модуль «Система отзывов» может нам показаться в 2 раза сложнее модуля «Регистрация». Соответственно, для этого модуля мы можем взять оценку, в 2 раза превышающую оценку на модуль «Регистрация».

Этот метод (оценка одного блока относительно другого блока) очень не точный, и его лучше использовать, только если количество блоков, которые никогда не делались, не превышает 20% от блоков, по которым есть исторические данные. В противном случае, это будет гадание на кофейной гуще.

После этой процедуры оценку по всем блокам нужно сложить, и это будет наиболее вероятная оценка. Пессимистичную и оптимистичную оценки можно рассчитать, используя коэффициенты, которые соответствуют текущему этапу — х0,5 и х2 (см. таблицу коэффициентов).

В идеале, это уже можно озвучить менеджеру, он должен разобраться, что с этим делать.

Если же так случилось, что разобраться менеджер не может и просит одно число — есть способы дать и одно.

Как из 3-х оценок (пессимистичная, оптимистичная и наиболее вероятная) сделать одну, я расскажу позже в разделе «Как из 3-х оценок получить одну?».

Как перейти на следующий этап?

Чтобы перейти на следующий этап, нужно подготовить полный список требований. Есть много разных способов документирования, но мы рассмотрим распространенный вариант с User Story.

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

Так, например, для блока «Система отзывов» после сбора и анализа требований мы могли бы получить следующее:

• Пациент может просмотреть все отзывы о выбранном докторе
• Пациент может оставить отзыв доктору после видео консультации с ним
• Доктор может видеть список отзывов, которые ему оставили пациенты
• Доктор может написать комментарий к отзыву на свою консультацию
• Администратор может видеть список всех отзывов на сайте
• Администратор может редактировать выбранный отзыв на сайте
• Администратор может удалять выбранный отзыв на сайте

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

• На каких платформах должно работать?
• Какие операционные системы нужно поддерживать?
• С чем нужно интегрироваться?
• Как быстро должно работать?
• Сколько пользователей должно поддерживать одновременно?

Прояснение этого будет означать переход на следующий этап.

Стадия 3. Требования собраны и проанализированы

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

Когда имеет смысл давать оценку на данном этапе?

Когда нужно дать примерную оценку на проект перед стартом работы по модели T&M. Оценки задач с данного этапа могут быть использованы для приоритизации конкретных задач на проекте, для планирования даты релиза и бюджета всего проекта. Также их можно использовать для контроля производительности команды на проекте и оценке ее эффективности.

Что нужно, чтобы дать оценку на данном этапе?

• Список функциональных требований
• Список не функциональных требований

Какие инструменты больше всего подходят на данном этапе?

• Оценка снизу вверх
• Оценка по аналогии

Алгоритм оценки

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

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

Например, для нашей User Story «Пациент может просмотреть все отзывы о выбранном докторе» могла бы получиться следующая картина (иллюстрации ниже специально сделаны от руки, чтобы показать, как процесс оценки может выглядеть на практике): Тут мы разделили задачу на 3 составляющие:

• Создать инфраструктуру в базе данных
• Сделать уровень DAL, для выборки данных
• Сделать UI, где будут выводится сами отзывы

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

Если вы хотите повысить свои навыки в проектировании интерфейсов, неплохо бы прочитать «Интерфейс» Джеф Раскин и «Об интерфейсе. Основы проектирования взаимодействия» Алан Купер.

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

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

Оценку, которую вы получили после описанной процедуры, можно считать оптимистической, так как, скорее всего, она учитывает кратчайший путь из точки А в точку Б (при условии, что вы ничего не забыли).

Теперь самое время подумать о тех вещах, которые вы, возможно, пропустили, и скорректировать свою оценку. В таких случаях, как правило, помогает чек-лист. Вот пример такого листа:

• Тестирование
• Дизайн
• Создание тестовых данных
• Поддержка разных разрешений экрана
• …

Один из возможных вариантов такого чек-листа вы можете посмотреть тут.

После прохода по этому списку нужно дополнить список задач тем, что, возможно было пропущено:

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

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

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

Оставшиеся две оценки можно рассчитать, используя коэффициенты, которые соответствуют текущему этапу — х0,67 и х1,5 (см. таблицу коэффициентов).

Если подсчитать оценку и приведенного выше примера, мы получим следующее:

• Оптимистическая оценка — 14 часов
• Наиболее вероятная — 20 часов
• Пессимистическая — 31 час

Как перейти на следующий этап?

Чтобы перейти на следующий этап, нужно спроектировать интерфейс пользователя. Лучшим способом сделать это будет создание wireframes.

Для этого есть множество программ, но я бы порекомендовал обратить внимание на Balsamiq и Axure RP.

Прототипирование — это отдельная обширная тема, которая выходит за рамки данной статьи.

Наличие wireframe будет означать переход на следующий этап.

Стадия 4. Интерфейс спроектирован

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

Когда имеет смысл давать оценку на данном этапе?

Для подготовки точной оценки по модели Fixed Price, но также можно и для всего того, что было перечислено на прошлом этапе.

Что нужно, чтобы дать оценку на данном этапе?

• Готовые wireframes
• Список функциональных требований
• Список не функциональных требований

Какие инструменты больше всего подходят на данном этапе?

• Оценка снизу вверх
• Оценка по аналогии

Алгоритм оценки

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

Как перейти на следующий этап?

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

Получаем из диапазона оценок одну

Если у вас уже есть наиболее вероятная, пессимистическая и оптимистическая оценки, то для того, чтобы получить одну оценку, можно использовать наработки Тома ДеМарко, который в своей книге «Вальсируя с медведями» поднял идею, что абсолютная вероятность может быть вычислена путём интегрирования площади под кривой (того самого графика асимметричного распределения вероятностей, что мы рисовали ранее). Оригинальный шаблон для подсчета можно скачать тут (также доступен без регистрации тут). В шаблон нужно просто подставить 3 числа и получить результат в виде списка оценок с соответствующими им вероятностями.

Например, для оценок 14, 20 и 31 мы получим следующий результат (скрин с шаблона excel):

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

Не знаем как оценить — говорим

Если вы не знаете, что от вас хотят, либо не знаете, как именно реализовывать функционал, который вас просят оценить — то в этом случае лучше честно сказать об этом менеджеру, дать ему примерную оценку (если вообще возможно) и предложить ему конкретные действия, чтобы эту оценку уточнить.

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

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

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

Сомневаемся — не обещаем

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

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

Как правило, это характерно для организаций, находящихся на более зрелом уровне модели CMM, в которых процедуры сужения конуса явно описаны и соблюдаются.

Ниже приводится иллюстрация улучшения качества оценок в проектах ВВС США при переходе на более зрелый уровень CMM (Lawlis, Flowe and Thodahl,1995). Думаю, тут есть о чем задуматься. Статистика по другим компаниям подтверждает эту корреляцию.

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

Выводы

• Дать оценку, которая совпадет с действительностью практически невозможно, но в ваших силах повлиять на диапазон, в котором она будет колебаться. Для этого нужно снижать неопределенность на проекте.
• Дробление задач на составляющие поможет повысить точность вашей оценки. В процессе декомпозиции вы более детально продумаете, что будете делать и как.
• Используйте чек листы, чтобы снизить вероятность что-нибудь пропустить при оценке.
• Используйте конус неопределенности для того чтобы понять в каком диапазоне вероятнее всего будет колебаться ваша оценка
• И напоследок — постоянно сравнивайте ту оценку, которую вы дали, со временем, которое реально ушло на задачу. Это поможет вам прокачать свой навык оценки, понять, что вы упустили, и использовать это в последующих оценках.

Полезные книги

На тему оценки трудозатрат очень много литературы, но я приведу 2 книги, которые просто обязаны быть прочитаны:

Как оценить работу программистов и разработчиков

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

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

Существуют критерии оценки программистов, которые помогают понять, чего стоит конкретный сотрудник.

KPI или Как Платить ИТ-специалисту

Бизнес мечтает о введении KPI (ключевых показателей эффективности) для кодеров. Иначе попробуй, пойми, работает программер или занимается ерундой, мало ему платишь или много. Большинство компаний выставляют собственные критерии эффективности программиста:

• ранжировка, отличная от общепринятой (например, junior, junior+, senior, senior+, middle);
• объем закрытых за определенный период задач (оплата почасовая, в некоторых фирмах разработаны системы оценки, где стоимость часа зависит от сложности задачи);
• экзамены, курсы, повышение скилла;
• самостоятельность, инициативность, переработку.

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

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

Как оценивать программистов при приеме на работу

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

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

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

По каким базовым критериям выбирают программиста

Определить, подходит ли вам кандидат, можно по пунктам:

1. Отношение к программированию, увлеченность, кругозор. Как воспринимает IT-специалист свою деятельность: как средство заработка или дело всей жизни. Чем занят в свободное время: изучает новые технологии, лежит на диване или увлекается посторонним хобби. Страсть к профессии — однозначный показатель, что человек будет работать увлеченно и выдаст максимальный результат.
2. Обучаемость — с какой скоростью человек усваивает новое, не вызывает ли у него сильный дискомфорт, вплоть до увольнения, необходимость разбираться в незнакомой технологии.
3. Наличие личных трудов, степень их завершенности.
4. Образование. Высшее/среднее техническое (или самоучка), знание методов и средств разработки, языков программирования, опыт.

Как оценить разработчика по подходу к написанию кода? Уточните, планирует ли айтишник архитектуру решения или сразу приступает к делу, переписывая код в процессе из-за неправильно выбранной тактики. Это влияет на скорость и результат.

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

Многое зависит от уровня. Новичкам засчитывается энтузиазм, желание разбираться, учиться, расти. У айтишников рангом повыше существенна отдача: насколько быстро выполняется работа, не приходится ли потом переделывать решения. Имеет значение соотношение затрачиваемых ресурсов (время на код, время на тестирование, аналитику), и пользы выполненной работы. Для «мамонтов»-middle важно, насколько код ориентирован на будущие нужды.

Техническая оценка разработчиков

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

1. На какой области, технологии вы специализируетесь?
2. Какие инструменты вы выберете для проекта с нуля?
3. Версия «рабочего» языка, которая вам больше всего нравится.
4. Есть ли будущее у вашего направления, приведите аргументы.

Вопросы для личностной оценки программистов

Максимальные показатели эффективности программиста, разработчика получают, когда предпочтения сотрудника совпадают с обстановкой в компании. Эти вопросы помогут понять, будет ли кандидат мотивирован работать с высокой отдачей. Захочет ли потенциальный сотрудник строить карьеру, каковы его планы, ищет он постоянное место работы или промежуточную станцию роста.

1. Определение идеального ИТ-специалиста с вашей точки зрения.
2. Самые интересные для вас задачи.
3. Какой коллектив/команда наиболее комфортен для вас.
4. Опишите работу мечты, идеальный рабочий процесс.

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

Подбор айтишников — сложное занятие, требующее подготовки. Важно анализировать не только технические умения. HR-профессионал в критерии оценки разработчика включает коммуникабельность, понимание запросов клиента и иные важные моменты. Благодаря опыту и регулярному обучению рекрутеры BGStaff владеют всеми инструментами оценки ИТ-специалистов. Обратившись в наше кадровое агентство, вы сможете заполучить к себе в команду человека с нужными навыками и качествами.

По всем вопросам свяжитесь с нами любым удобным способом:

Как оценивать работу программистов: примеры системы грейдов в компаниях

Как выстраивать грейдирование разработчиков внутри компании? Что зашивать в мотивацию? Голый оклад, оклад + премия, почасовка? Каким образом оценивать работу программиста? Нужны ли бонусы и премии? Опытом поделились «Нетология», Finch, DD Planet, MediaSoft, Oneway и Digital Wand.

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

Кто-то формирует свою систему грейдов, кто-то не считает это необходимым. А что рассказали опытные команды представителям Pena Production?

В Oneway учитывается общий объём закрытых задач в часах, пройденные курсы и сданные экзамены («Битрикс24»), определённый набор скиллов и опыт в определённых задачах (матрица компетенций).

В компании MediaSoft не используется система грейдов в привычном понимании и в целом отсутствует традиционное деление разработчиков на классы junior, middle и senior.

Эта классификация достаточно условна: как показывает практика, senior часто называют самого крутого специалиста в компании, и это не отражает ровным счётом ничего, кроме уровня самой компании. При попытке устроиться в большую и серьёзную организацию вроде «Яндекса» такой senior может не пройти даже на позицию junior.

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

В Finch список показателей достаточно большой: качество кода, самостоятельность, проектное разнообразие, профессиональный рост, количество проработанного в компании времени и инициативность.

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

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

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

Не менее важны показатели вроде адекватности оценки сроков исполнителем, своевременное и чёткое выполнение задач.

В команде Finch решили остановиться на четырёх уровнях: junior, middle, middle+ и senior. В компании достаточно много разработчиков, которые находятся на стыке двух уровней — middle и senior. Поэтому и приняли решение ввести дополнительный грейд. Делать больше грейдов при штате 55 человек ребята считают лишним. Возможно, со временем лестница будет больше.

В DD Planet, как и в большинстве ИТ-компаний, всех разработчиков подразделяют на четыре уровня:junior, middle, senior, team leader (тимлид).

К уровню junior формально можно отнести выпускников вузов, которые только начинают карьеру. Предпочтение отдаётся серьёзным техническим вузам, например МГУ (факультеты ВМК, мехмат), МГТУ, МИЭМ, НИУ ВШЭ.

Более продвинутый уровень развития специалиста — middle. Сотрудник ещё не принимает самостоятельных решений, но за ним не надо перепроверять правильность реализованных задач. Руководитель говорит, как и что надо сделать, программист выполняет всё в срок и качественно.

Следующий грейд — senior, или ведущий программист. Специалист может самостоятельно принимать решения и несёт ответственность за их реализацию. Также он способен курировать одного или нескольких программистов уровня junior или middle.

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

У DigitalWand — шесть уровней разработчиков: junior, junior+, middle, middle+, middle++, senior.

1. Juniorзнает основы своей технологии, может выполнять простые задачи, но пока не готов работать самостоятельно.
2. Junior+ на простых задачах работает самостоятельно. Умеет применять типовые операции с Git.
3. Middleполностью самостоятельно решает типовые задачи, однако ему может потребоваться помощь в проектировании, ревью кода.
4. Middle+ отлично знает фреймворк, на котором работает, начинает осваивать другие фреймворки, уже может помогать junior-программистам.
5. Middle++ можно доверить работу на production, проведение релизов. Готов заниматься проектированием не слишком сложных систем. Может при необходимости общаться с заказчиком.
6. Senior имеет в своём арсенале несколько фреймворков, у него есть опыт проектирования и разработки сложных систем.

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

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

В студии Oneway рекордное количество уровней — одиннадцать.

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

Работает это примерно так: руководство смотрит, какая зарплата была бы у специалиста, если бы клиент нанял его в инхаус-команду. И вот здесь очень важно не промахнуться с уровнем разработчика. Если его экспертиза окажется ниже, чем нужно клиенту, он попросту не справится со своими обязанностями, если выше — ему будет недоставать мотивации.

Например, в «Нетологии» внедрён процесс Performance Review, который проходит два раза в год, весной и осенью. Это ретроспективный процесс, где каждый разработчик рассказывает о своих результатах за последние полгода, получает обратную связь от коллег и рекомендации — на что стоит обратить внимание в будущем. Это могут быть как технические навыки, так и личностные качества.

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

В Oneway для каждого пишется личный план развития, есть чёткий чек-лист — что нужно сделать для достижения следующего грейда. Такой план обновляется раз в месяц, и если показатели достигнуты, запускается бизнес-процесс на согласование повышения.

В Finch линейные руководители раз в месяц ставят оценки сотрудникам. Критерии оценки формируются из ключевых показателей грейдирования.

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

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

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

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

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

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

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

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

Заработная плата программистов MediaSoft формируется динамически: к фиксированному окладу также добавляется переменная часть, которая считается по затраченным часам и зависит от того, сколько платит за эту работу клиент.

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

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

Система призвана рассчитывать эффективность групп и каждого сотрудника по отдельности. На основании полученных данных формируется уровень зарплаты для каждого грейда.

В Oneway сегодня маржинальность проектов не учитывается.

В команде Finch маржинальную прибыль также не учитывают, но считают такую практику весьма интересной.

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

В DD Planet показатели маржинальности проектов не используются. Безусловно, правильность оценки сроков и своевременное выполнение задач влияет на маржинальность. Однако при принятии решения о повышении грейдов этот фактор не учитывается. В DD Planet уровни зарплат программистов соответствуют грейдам. Напрямую от маржинальности проекта заработная плата разработчика не зависит.

У каждого разработчика может быть свой стек технологий, а кто-то владеет сразу несколькими. Как же это учитывать?

DD Planet специализируется на разработке сложных проектов, на 60% типовых решений и технологий приходится 40% нестандартных. В связи с разработкой высоконагруженных проектов, нетиповых задач встречается очень много.

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

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

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

У ребят из Finch единый стек под все проекты. Поэтому проблемы с несколькими стеками нет.

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

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

В DigitalWand есть различные технологии для разработки. Грейды разделены на backend и frontend, вёрстку и JS-разработку. В рамках каждого из направлений также есть деление по технологиям.

В Oneway 90% проектов разрабатываются на «Битрикс24», поэтому все грейды для backend-разработки единые. Отличаются только backend и frontend

Компания Oneway использует фактическую оплату по часам. Финально каждую задачу оценивает тимлид. Если человек не выписывается в сроки оценки, то получит меньше, если выполняет задачу быстрее, то сможет получить больше.

В «Нетологии» с зарплатой всё просто: если сотрудник профессионально растёт и сфера его ответственности расширяется, то он получает повышение. С премиями чуть сложнее — обязательной практики премирования нет, но иногда под конкретный проект есть бюджет для команды — это компенсация за овертайм и высокую степень неопределённости.

У Finch нет системы премий, штрафов, выплат за мотивированность и всего такого. Есть чёткий фикс на руки, который обговаривается на собеседовании. Бывали случаи, когда ребятам платили премии. Как правило, это были какие-то особые случаи, в которых просто хотелось сделать приятно человеку. Сейчас от этой практики отказались.

Finch — сторонники нематериальных вознаграждений. Любой человек в компании может съездить на конференцию, сходить на курсы, отдохнуть за счёт компании, если он делает свою работу хорошо. Один из ярких примеров – отправка ребят на Бали. В Finch убеждены, что в таких активностях больше толку, чем в ежемесячной премии.

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

В DigitalWand сейчас фиксированный оклад, но ведётся подготовка к новой системе финансовой мотивации — динамический оклад на основании эффективности, в которой зарплата будет состоять из двух частей:

1. Оклада.
2. Премии.

От чего зависит оклад:

1. Грейд сотрудника.
2. Эффективность работы группы и команды в целом.

Эффективность работы сотрудника, группы и команды зависит от фактической оплаты клиентами по отношению к оплате 100% часов по текущей внешней ставке.

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

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

Сверхурочная работа оплачивается хорошо. Сверхурочные бывают двух видов:

1. Добровольные, оплачиваются по ставке х1,5.
2. По просьбе клиента, оплачиваются по ставке х2.

В MediaSoft действует динамическая система финансовой мотивации. Она включает зарплату с фиксированной и переменной частью, а также квартальную премию.

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

Такая модель сложилась эволюционно: сначала появилась переменная часть, к ней добавилась постоянная, а затем стали выплачивать премию.

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

В каждой команде есть свой стек технологий, своя специфика работы, процессов и производимого продукта. Далеко не все привязываются к прибыльности проектов. Могут ли компании себе это позволить? Ведь позволяют.

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

Как оценить профессионализм программиста за 5 вопросов — отвечают эксперты

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

На мой взгляд, достаточно всего трёх вопросов.

Каковы причины ухода с прежнего места работы?

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

Какой ваш самый интересный реализованный проект?

По ответу на этот вопрос можно определить уровень разработчика: какие задачи он считает действительно сложными, какие решения называет удачными. Если это его личный проект, можно узнать, как программист совмещал роли аналитика, разработчика, тестировщика, как решал вопросы интеграции данных и нагрузки. Рассказ о командном проекте позволяет оценить навык совместной разработки и уровень развития soft skills.

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

Расскажите про свои увлечения

Хороший показатель увлечённости именно программированием — чтение и просмотр профильных статей и подкастов. В том числе интересно, что человек читал или смотрел в последнее время. Это хороший показатель интереса к новым технологиям: даже если программист работает в компании с давно запущенными продуктами, где много legacy-кода, он должен интересоваться нововведениями в области технологий.

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

Любое собеседование в нашей компании — это разговор не только о технологии. Мы стараемся прежде всего узнать и понять человека, который к нам пришел. Впишется ли он в нашу культуру? Будет ли нашей команде комфортно работать с ним в будущем? Не противоречат ли принципы человека принципам компании? От этого зависит, сможет ли человек работать с нами долго и насколько продуктивным будет это сотрудничество.

Поэтому мы начинаем с самого простого, но важного: «Как вы пришли в разработку?». Этот вопрос помогает оценить кругозор соискателя в программировании и понять уровень его вовлечённости. По ответу становится ясно, заинтересован ли человек расти в этой профессии или для него это только «дань моде» и средство заработка.

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

Дальше можно переключиться на темы, связанные с фундаментальными знаниями: паттерны программирования, основы объектно-ориентированного программирования, ключевые принципы разработки (SOLID, DRY, OR, KISS и другие).

Оставшиеся вопросы связаны с направлением разработки (frontend, backend, mobile application) и характерной для него специфической областью знаний. Они позволяют выяснить много важных вещей: например понимание принципов взаимодействия пользовательского интерфейса с бэкендом, REST, API, работы с памятью устройств (в случае мобильного приложения) и многое другое. После обсуждения этих моментов уже можно переходить к типовым вопросам конкретной технологии.

Наши программисты занимаются как созданием собственных решений, так и разработкой на заказ, а также сервисами сопровождения, обновления нетиповых конфигураций 1С. Работа построена в небольших командах по 3–4 человека, каждая со своей специализацией: например кто-то глубже знает определённую конфигурацию 1С, кто-то лучше разбирается в обновлениях, свёртках информационных баз.

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

Почему он захотел стать разработчиком?

Этот вопрос помогает «разбить лёд» в начале разговора, найти точки соприкосновения. Позволяет понять, как человек принимает решения, что побуждает его к изменениям, что для него важно в профессии.

Какие личностные качества помогли ему стать разработчиком и какие из них наиболее значимы?

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

Кем он видит себя (на какой должности) через 1 год, 2 года, 5 лет (не обязательно работая в нашей компании)

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

Какие 5 его любимых книг и почему именно они?

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

Чем он может быть полезен нашей компании? Что он сможет привнести нового в работу компании?

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

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

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

1. Дошли ли они до промышленной эксплуатации?
2. Как был организован процесс разработки? Кто и как ставил задачи? Как тестировалось? Кто принимал решение о том, что задача выполнена?
3. Что не устраивало кандидата в процессе разработки? Предлагал ли он идеи по улучшению процесса?
4. Как документировался код?
5. Привык ли кандидат автоматизировать свою деятельность?

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

1. Какие структуры данных и алгоритмы вам приходилось применять в прошлых проектах и в чём польза их использования?
2. Расскажите о плюсах и минусах вашего языка программирования. Почему вы выбрали именно этот язык?
3. Важно ли, чтобы код, написанный вами, был понятен другим? Если да, то почему?
4. Опишите процесс разработки и внедрения программного продукта на прошлых местах работы.
5. Напишите или расскажите словами алгоритм градиентного бустинга над деревьями. Как вариант: метод обратного распространения ошибки в нейронных сетях.

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

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

Формат вербального собеседования в отношении программистов, если он реализуется в виде простого опросника, даёт валидность верификации профессионализма на уровне не более 30 %. Решение практических задач — минимум 80 %.

У нас на собеседовании обязательно попросят рассказать о своих последних проектах. Вопрос может быть сформулирован, например, так: «Чем вы занимались на прошлой работе? Как выглядела команда? И какую роль вы в этой команде занимали?». Из ответа станет понятно, как кандидат идентифицирует себя в команде, как работает внутри неё, насколько он командный игрок.

Следующим вопросом вас могут попросить рассказать о проекте, который разочаровал или наоборот воодушевил? И спросят: «Что бы вы изменили при работе над этим проектом?». Это даст HR понимание того, как человек анализирует свои ошибки, может ли что-то впоследствии изменить, или, возможно, из раза в раз допускает похожие промахи. Кроме того, косвенно из ответа станет понятно, готов ли собеседник к дальнейшему росту и какому более — профессиональному или карьерному.

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

Ещё хороший вопрос: «Как описали бы вас другие разработчики или ваш РП?». Ответ на этот вопрос расскажет нам о самооценке будущего сотрудника, о том, что он лично думает о своих результатах и работе в целом. Здесь я всячески рекомендую говорить правду. Ведь даже ответ: «У всех бывают косяки. Но мы в команде всегда работаем над этим», — даёт HR правильный посыл о личных качествах и верном настрое на диалог.

Также показательный вопрос: «Что в программировании для вас самое сложное?». Ответ на этот вопрос позволяет нам выявить слабые технические стороны кандидата. Честный рассказ о слабостях показывает, что человек адекватно оценивает свои возможности и готов в них развиваться. Например, ответ: «Сложностей нет, я просто с этим не работал», — однозначно говорит о том, что сложности в названной области явно есть.

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

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