Гайд по Performance review. Часть 3

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

Если вы пропустили наши предыдущие тексты:

Принципиально решаемые задачи не изменились - наш PR нацелен в первую очередь на оценку процессов разработки, а не разработчика. Компания аутсорсинговая и дает клиенту очень широкие права контролировать разработку (это наша фишка). Поэтому, проблемы в основном связаны с коммуникацией PM-а заказчика и команды (разработчиков и менеджера). Другая особенность нашего ревью - лишь небольшая часть связана со скиллами программиста. PR это не средство постановки “диагноза” разработчику, а средство поиска симптомов, которые могут оказаться ложными, правдивыми, но смотреть всё равно придётся не туда и т.д.

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

Варианты ответов:

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

(Сейчас мы этот вопрос не задаём, так как уже не актуально - мы решили эти проблемы практически на всех проектах)

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

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

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

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

Каждый закрытый вопрос имеет одинаковую структуру: собственно, сам вопрос и четыре варианта ответа, обогащенных контекстом для точности оценки. Ответы эти можно условно заменить на “Все норм”, “Хорошо, но не без косяков”, “Хуже ожидаемого” и “Сделайте что-то, чтобы это прекратилось”. Своего рода шкала, четырехбалльная, чем мы и воспользуемся, переведя ответы в баллы. Нескромно скажем, что благодаря сервису, разработанному авторами текста, кодирование осуществляется автоматически. Автоматически же рассчитываются средние и медианные значения каждого из параметров. Так наше оценивающее лицо понимает примерную среднюю температуру и видит, на какие моменты стоит обратить внимание.

Итак, менеджер собрал фидбек и теперь должен подготовиться к серии 1:1 с членами команды. Как и с другими частями ревью, к ним мы подходим неформально и без привязки к человеку и уж тем более оценки его в духе “хороший-плохой”. 1:1 это своего рода беседа уровня “как дела?”, в которой менеджер лишь слегка подталкивает человека к развернутому комментарию по тому или иному поводу.

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

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

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

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

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

Александр Амосов: tg

Александр Гуров: tg, fb