Третий и заключительный текст нашего мини-цикла будет посвящен суровой реальности - организации performance review в не самых крупных, но зрелых командах из мира IT. Мы предлагаем вам набор стартовых вопросов, с которого когда-то начинали наша компания. С этим набором вы можете начать обсуждать ваш performance review с командой, тим лидами и всеми, кто заинтересован в оценке производительности команд.
Если вы пропустили наши предыдущие тексты:
Принципиально решаемые задачи не изменились - наш PR нацелен в первую очередь на оценку процессов разработки, а не разработчика. Компания аутсорсинговая и дает клиенту очень широкие права контролировать разработку (это наша фишка). Поэтому, проблемы в основном связаны с коммуникацией PM-а заказчика и команды (разработчиков и менеджера). Другая особенность нашего ревью - лишь небольшая часть связана со скиллами программиста. PR это не средство постановки “диагноза” разработчику, а средство поиска симптомов, которые могут оказаться ложными, правдивыми, но смотреть всё равно придётся не туда и т.д.
Итак, вопросы. Они связаны с классической пятёркой процессов разработки в Waterfall. Нет, мы не придерживаемся этой концепции, просто взяли оттуда разделы вопросов, чтобы чётче понимать в каком месте процесса разработки мы проседаем.
Сбор и получение требований
Достаточно ли понятны и не противоречивы требования с которыми тебе приходится работать?
Варианты ответов:
- мне приходится вытягивать требования клешнями
- требования есть, но они не структурированы или противоречивы
- требования понятны, но небольшую часть мы выясняем в ходе работы
- у меня самые чёткие требования на районе
Аналитика требований
Случаются ли ситуации, когда тебе приходится переделывать код или расширять оценку из-за ошибок связанных с аналитикой требований? (например, неучтённые особенности системы)
- да
- нет
Проектирование
Случаются ли ситуации когда тебе приходится переделывать код или расширять оценку из-за ошибок связанных с проектированием?
- мои задачи не так велики, чтобы ошибиться в процессе проектирования
- да, случаются, но не критичные
- нет
- да, недавно мы сильно облажались
Разработка
Достаточно ли понятен код, с которым ты работаешь? (тут можно выбрать несколько ответов)
- код который я пишу сейчас понятен и прост
- код который я пишу сейчас достаточно сложен для понимания, но такова его природа
- когда я нахожу свой код спустя месяц мне требуется усилие, чтобы вспоминать зачем он и как работает
- когда я нахожу свой код спустя месяц мне практически ничего не стоит вспомнить как он работает
Ты пишешь переиспользуемый код?
- да
- у меня часто нет времени написание на хорошо обобщённого кода
- какой переиспользуемый? - я просто затыкаю дыры, чтобы это всё не пошло на дно
- я пишу код, который будет использоваться только один раз и переиспользование невозможно (такое случается у начинающих ребят, когда их ставят например на задачи написания виджетов с уже использованием какого-то фреймворка)
Что там по рефакторингу?
- мне хватает времени на рефакторинг только того что я пишу сам(а)
- мне хватает времени на рефакторинг того, что пишу сейчас я и постепенное улучшение всей системы
- “Господь жги, тут уже никого не спасти”
Тестирование / проверка качества
Часто ли тебе возвращаются твои таски на доработку?
(да, мы задаём этот вопрос, но в идеале его тут быть не должно, так как это должны считать за нас таск трекеры)
- чаще чем хотелось бы
- бывает, но это не бесит
- никогда!
- бывает, что другие таски ломают мою работу (регрессия)
Поставка
Достаточно ли легко проходит процесс деплоя? Случаются ли ситуации, что что-то ломается в процессе поставки твоих тасков на прод?
(Сейчас мы этот вопрос не задаём, так как уже не актуально - мы решили эти проблемы практически на всех проектах)
В ревью включены и несколько открытых вопросов -для запуска рефлексии и предоставления развернутой обратной связи.
- Что следует начать делать? (или делать больше\чаще)
- Что нужно перестать делать?
- Что организовано хорошо и нужно продолжать?
Качество коммуникации:
Оцени ваши митинги по 10-бальной шкале.
Вдобавок, есть и еще одно поле для открытого ответа - в нем мы предлагаем сотруднику написать о том, что не было покрыто другими вопросами, вне зависимости от содержания. Этот вопрос был источником всех последующих изменений в нашем PR - ребята сами накидывали пункты, по которым стоит отслеживать состояние дел в команде.
Опрос для оценки третьего лица устроен заметно проще - в нем мы задаем те же открытые вопросы и всего три из нашего списка закрытых - о понятности кода, переиспользуемости кода коллеги и рефакторинге кода коллег.
С вопросами разобрались, переходим к чтению результатов. На этом этапе ответственное лицо с серьезным видом поглядит на собранную информацию, вычисления и графики, дайджест обратной связи и подготовит персонализированный план общения с каждым из программистов. Тут у вас должен возникнуть вопрос - о каких же результатах и графиках идет речь, вы же просто перепечатали опросник. Что ж, давайте посмотрим на него более пристально.
Каждый закрытый вопрос имеет одинаковую структуру: собственно, сам вопрос и четыре варианта ответа, обогащенных контекстом для точности оценки. Ответы эти можно условно заменить на “Все норм”, “Хорошо, но не без косяков”, “Хуже ожидаемого” и “Сделайте что-то, чтобы это прекратилось”. Своего рода шкала, четырехбалльная, чем мы и воспользуемся, переведя ответы в баллы. Нескромно скажем, что благодаря сервису, разработанному авторами текста, кодирование осуществляется автоматически. Автоматически же рассчитываются средние и медианные значения каждого из параметров. Так наше оценивающее лицо понимает примерную среднюю температуру и видит, на какие моменты стоит обратить внимание.
Итак, менеджер собрал фидбек и теперь должен подготовиться к серии 1:1 с членами команды. Как и с другими частями ревью, к ним мы подходим неформально и без привязки к человеку и уж тем более оценки его в духе “хороший-плохой”. 1:1 это своего рода беседа уровня “как дела?”, в которой менеджер лишь слегка подталкивает человека к развернутому комментарию по тому или иному поводу.
В первую очередь, как и в опросе, речь идет о комплексной оценке проекта - все ли там в порядке с качеством, коммуникацией внутри команды и с заказчиком. Дальше, менеджер плавно переходит к самому сотруднику - развивается ли он на проекте, видит ли он себя там через полгода или ему уже становится скучно без роста сложности или в рамках данных технологий. Наши команды сидят на больших и долгосрочных проектах, поэтому мы можем перемещать людей между ними, если кто-то откровенно засиделся. Конечно, такие беседы возможны если у сотрудника есть представление о том, как он развивается и в какую сторону хочет двигаться дальше - такой осознанности мы от них и ждем.
Итоги 1:1 фиксируются менеджером в формате отчета в свободной форме - по сути, лог беседы и выдержки из комментариев коллег, программиста и своих замечаний. Если вы, совместно с сотрудником, сформировали план развития - зафиксируйте и его, помогает воспринимать договоренности более серьезно.
Так как наше ревью ориентировано на процессы, то часто мы замечаем те или иные провисающие места, которые могут привести к проблемам на проекте (а может уже привели, просто пока участники еще терпят). Для нас это является главной ценностью - чем раньше менеджеры заметили проблему, тем проще ее исправить. Как именно - всегда вопрос индивидуальный, но диагностика была бы сложнее без правильного инструмента, которым для нас стало ревью.
Еще одним плюсом для нас стало потепление в отношениях между разработчиками и менеджерами. Программисты гораздо более открыты к диалогу и не замалчивают проблемы, так как видят искреннее намерение улучшать их положение в компании и помочь профессиональному росту. Постоянный диалог упрощает микро- и макроменеджмент, практически в режиме он-лайн предоставляя более полную картину о состоянии дел в коллективе. Согласитесь, стоит затрат времени на его проведение.
Вот и подошел к концу наш мини-цикл о перформанс ревью. Надеемся, что было познавательно как тем, кто только задумывается о введении, так и уже использующим этот инструмент для работы с сотрудниками. Если вы хотите узнать об опыте компании чуть больше, либо о практике в целом - пишите в комментарии или авторам лично. Мы же на этой ноте уходим в тень, но ненадолго - впереди и другие материалы, посвященные работе с людьми на основе проведения корпоративных опросов. Спасибо всем, кто читал и участвовал в обсуждении!
Александр Амосов: tg