2. Сбор обратной связи
Продолжаю рассказывать про этапы #ревью.
Мы стремимся сформировать объективную оценку нашей работы, поэтому недостаточно только отзыва сотрудника и мнения его руководителя. Нужен еще взгляд со стороны.
Именно для этого мы собираем отзывы от коллег и смежных команд, чтобы сложить полноценную картинку. У нас часто бывает так, что разработчик участвует не только в развитие какого-то сервиса, но и занимается инфраструктурно-технологическими задачами для нужд всего отдела под руководством техлида.
В этом случае необходимо запросить обратную связь у следующих участников:
— руководитель продукта или ответственный менеджер (для оценки участия и успехов в развитии сервиса)
— техлид инфраструктуры (вклад в технологическое развитие сервиса/отдела)
— коллеги, с которыми тесно взаимодействовал (тестировщики, аналитики, дизайнеры и т.д.)
Конечно, нет необходимости спрашивать обратную связь от всех-всех коллег, с которыми хоть чуть-чуть пересекались по работе. Это лишь создаст “паразитную” нагрузку на ваших коллег. Необходимо запрашивать отзыв у коллег, с которыми, действительно, очень тесно взаимодействовали.
Продолжаю рассказывать про этапы #ревью.
Мы стремимся сформировать объективную оценку нашей работы, поэтому недостаточно только отзыва сотрудника и мнения его руководителя. Нужен еще взгляд со стороны.
Именно для этого мы собираем отзывы от коллег и смежных команд, чтобы сложить полноценную картинку. У нас часто бывает так, что разработчик участвует не только в развитие какого-то сервиса, но и занимается инфраструктурно-технологическими задачами для нужд всего отдела под руководством техлида.
В этом случае необходимо запросить обратную связь у следующих участников:
— руководитель продукта или ответственный менеджер (для оценки участия и успехов в развитии сервиса)
— техлид инфраструктуры (вклад в технологическое развитие сервиса/отдела)
— коллеги, с которыми тесно взаимодействовал (тестировщики, аналитики, дизайнеры и т.д.)
Конечно, нет необходимости спрашивать обратную связь от всех-всех коллег, с которыми хоть чуть-чуть пересекались по работе. Это лишь создаст “паразитную” нагрузку на ваших коллег. Необходимо запрашивать отзыв у коллег, с которыми, действительно, очень тесно взаимодействовали.
Найдется все, и даже ботинки
Сегодняшняя история произошла с одним из наших бывших коллег, с которым у нас разошлись пути и он перешел работать в другую компанию. В свой последний рабочий день он разыскивал свои ботинки, которые использовал в качестве сменки в офисе.
Найти не смог и попросил нас ему позвонить, если мы все-таки их найдем. Через какое-то время обнаружили 50% пропажи, т.е. нашли только один ботинок. Конечно, незамедлительно об этом сообщили коллеге. Нас поблагодарили за усердие в поиске, но один ботинок не пригодится. Можно прыгать на одной ноге, но это не особо практично…
Тем не менее выкидывать ботинок мы не стали и положили его в шкаф. Прошло 2-3 ревью (1-1.5 года, если по-человечески). У нас начался переезд из одного офиса в другой: БЦ Мамонтов → БЦ Аврора. После каждого переезда остается какое-то количество “бесхозных” вещей. Их все фотографируют, аккуратно упаковывают и отправляют на склад на хранение.
И вот среди фотографий бесхозных вещей кто-то из нашей команды обнаружил тот самый второй потерянный ботинок! Вы представляете? Написали заявление на возврат драгоценного ботинка со склада и через несколько дней двасапога ботинка вновь стали парой.
У нас найдется все, может быть не сразу, может быть процесс поиска займет 1.5 года, но обязательно найдется 🙂
P. S. Ботинки вернули законному владельцу. Владелец счастлив!
#байки
Сегодняшняя история произошла с одним из наших бывших коллег, с которым у нас разошлись пути и он перешел работать в другую компанию. В свой последний рабочий день он разыскивал свои ботинки, которые использовал в качестве сменки в офисе.
Найти не смог и попросил нас ему позвонить, если мы все-таки их найдем. Через какое-то время обнаружили 50% пропажи, т.е. нашли только один ботинок. Конечно, незамедлительно об этом сообщили коллеге. Нас поблагодарили за усердие в поиске, но один ботинок не пригодится. Можно прыгать на одной ноге, но это не особо практично…
Тем не менее выкидывать ботинок мы не стали и положили его в шкаф. Прошло 2-3 ревью (1-1.5 года, если по-человечески). У нас начался переезд из одного офиса в другой: БЦ Мамонтов → БЦ Аврора. После каждого переезда остается какое-то количество “бесхозных” вещей. Их все фотографируют, аккуратно упаковывают и отправляют на склад на хранение.
И вот среди фотографий бесхозных вещей кто-то из нашей команды обнаружил тот самый второй потерянный ботинок! Вы представляете? Написали заявление на возврат драгоценного ботинка со склада и через несколько дней два
У нас найдется все, может быть не сразу, может быть процесс поиска займет 1.5 года, но обязательно найдется 🙂
P. S. Ботинки вернули законному владельцу. Владелец счастлив!
#байки
Для описания разработки используют очень много разных метафор. Мне нравится следующая аналогия: #разработка — это садоводство: разрабатываемое ПО — это сад, а разработчики — это садоводы. В любом саду постоянно приходится что-то пересаживать (рефакторинг), следить за внешним видом (кодстайл), поливать и полоть от сорняков (поддержка), опрыскивать от всяких жучков-вредителей (фикс багов) и т.д.
На мой взгляд, “садоводческая модель разработки” очень хорошо отражает то, чем мы занимаемся на работе. Я периодически помогаю своей маме-садоводу “саппортить” ее сад и поэтому с уверенностью могу сказать, что садоводство похоже на разработку. Садоводы, кстати, тоже оценивают сад друг друга (кодревью) и делятся друг с другом саженцами (общие библиотеки).
Однако, для некоторых случаев удобнее рассуждать про разработку, как про производство, в котором есть некоторый волшебный конвеер. Т.е. есть “релизная труба”, на один конец которой загружают требования, а с другой стороны выкатываются фичи в продакшен.
“Релизная труба” — это очень упрощенная модель разработки, но она помогает находить общий язык с топ-менеджерами/заказчиками без погружения в обсуждение технических нюансов.
На мой взгляд, “садоводческая модель разработки” очень хорошо отражает то, чем мы занимаемся на работе. Я периодически помогаю своей маме-садоводу “саппортить” ее сад и поэтому с уверенностью могу сказать, что садоводство похоже на разработку. Садоводы, кстати, тоже оценивают сад друг друга (кодревью) и делятся друг с другом саженцами (общие библиотеки).
Однако, для некоторых случаев удобнее рассуждать про разработку, как про производство, в котором есть некоторый волшебный конвеер. Т.е. есть “релизная труба”, на один конец которой загружают требования, а с другой стороны выкатываются фичи в продакшен.
“Релизная труба” — это очень упрощенная модель разработки, но она помогает находить общий язык с топ-менеджерами/заказчиками без погружения в обсуждение технических нюансов.
Требования заказчика продукта можно сформулировать как “хочу шипить в продакшен больше фич, чаще и без багов”. Технический руководитель (например, я) выступает в качестве специальной прослойки к команде и переводит абстрактные продуктовые или бизнесовые требования в более технологическое русло.
На самом деле практически все наши менеджеры (в том числе и наш топ-менеджер) неплохо подкованны технически, поэтому с ними можно пообсуждать технические нюансы и как устроена #разработка. Но тем не менее нам технарям всегда нужно быть готовыми быть “техническим переводчиком”.
На самом деле практически все наши менеджеры (в том числе и наш топ-менеджер) неплохо подкованны технически, поэтому с ними можно пообсуждать технические нюансы и как устроена #разработка. Но тем не менее нам технарям всегда нужно быть готовыми быть “техническим переводчиком”.
При найме в Яндекс каждому новому сотруднику предлагают выбрать внутренний логин (никнейм). И лучше отнестись к выбору логина ответственно. Логин выдается один раз и навсегда. Его нельзя поменять. Даже если уволиться и потом вернуться, то все равно выдадут тот же логин.
Логин — это уникальный идентификатор сотрудника и он “прорастает” в множество внутренних систем (трекер, вики, почта, авторизация на серверах и т.д.). Также очень часто коллеги друг друга называют по никнейму, т.к. имя человека не является уникальным идентификатором, а логин в пределах Яндекса — является.
Наш бывший технический директор Миша Парахин выбрал себе никнейм
Использовать никнеймы в поседневной речи — это уже в днк яндексоидов. Соответственно, лучше, чтобы никнейм был не очень длинным и однозначно читался, чтобы облегчить жизнь вашим коллегам.
Логин — это уникальный идентификатор сотрудника и он “прорастает” в множество внутренних систем (трекер, вики, почта, авторизация на серверах и т.д.). Также очень часто коллеги друг друга называют по никнейму, т.к. имя человека не является уникальным идентификатором, а логин в пределах Яндекса — является.
Наш бывший технический директор Миша Парахин выбрал себе никнейм
imperator из-за того, что ему не нравилась идея обращаться друг к другу по никнеймам. “Не будут же ко мне обращаться ИМПЕРАТОР?”. Как показала практика, будут. Более того, часть Яндекса, находящаяся под управлением Миши, стала называться империей :)Использовать никнеймы в поседневной речи — это уже в днк яндексоидов. Соответственно, лучше, чтобы никнейм был не очень длинным и однозначно читался, чтобы облегчить жизнь вашим коллегам.
Необходимо упомянуть еще важную составляющую в разрезе #ревью — систему грейдов. Это линейная шкала от 1 до N и каждому сотруднику присваивается грейд в зависимости от его компетенций, умений, знаний и опыта.
Грейд — это уровень ответственности, которую может нести человек. Обычно рост ответственности означает, что растет сложность решаемых задач, а также растет уровень неизвестности. Чем выше уровень неизвестности в решаемых задачах, тем выше грейд и выше финансовое вознаграждение.
Начинающему специалисту нужно подробно рассказывать что нужно сделать, обучать верным практикам и постоянно контролировать результат. Топ-менеджеры и руководители компании отвечают за стратегическое движение компании и часто принимают решения в обстановке тотальной неизвестности со сложноизмеримыми рисками. Соответственно, обычно у топ-менеджеров финансовая компенсация выше, чем у начинающих специалистов.
Номер грейда в компании не принято разглашать. Грейд как и размер финансовой компенсации считается приватной информацией, доступной только сотруднику и его руководителю. Но спустя какое-то время работы коллеги начинают представлять примерные грейды друг друга. Ну вот такая вот приватность Шредингера 🙂
Чуть более подробно про грейды и путь развития фронтендера в Яндексе можно узнать в докладе Владимира Гриненко.
Грейд — это уровень ответственности, которую может нести человек. Обычно рост ответственности означает, что растет сложность решаемых задач, а также растет уровень неизвестности. Чем выше уровень неизвестности в решаемых задачах, тем выше грейд и выше финансовое вознаграждение.
Начинающему специалисту нужно подробно рассказывать что нужно сделать, обучать верным практикам и постоянно контролировать результат. Топ-менеджеры и руководители компании отвечают за стратегическое движение компании и часто принимают решения в обстановке тотальной неизвестности со сложноизмеримыми рисками. Соответственно, обычно у топ-менеджеров финансовая компенсация выше, чем у начинающих специалистов.
Номер грейда в компании не принято разглашать. Грейд как и размер финансовой компенсации считается приватной информацией, доступной только сотруднику и его руководителю. Но спустя какое-то время работы коллеги начинают представлять примерные грейды друг друга. Ну вот такая вот приватность Шредингера 🙂
Чуть более подробно про грейды и путь развития фронтендера в Яндексе можно узнать в докладе Владимира Гриненко.
Я уже рассказывал про то, что login в Яндексе — это очень важный идентификатор и его нужно выбирать с умом. Вот про “удачный” выбор логина и будет сегодняшняя байка 🙂
Как-то раз на работу в компанию устроилась девушка с никнеймом
Все внутренние логины хранятся в системе под названием Стафф и из него раз в какое-то время эти логины экспортируются в множество систем. И в одной из таких выгрузок радостно на колестнице покатилась та самая
В этих системах все начало разваливаться. Девопсы подняли панику. Причина проблемы неочевидна. Тем не менее ребята быстро локализовали проблему, “уволили” принцессу и внесли этот логин в список запрещенных. Новый исправленный экспорт, конечно, не сразу подъехал, поэтому какое-то время парочка систем жило на быстрых решениях из палок и чернозема. Но зато внешние пользователи ничего не успели заметить! А все палки и чернозем потом вывезли…
Сейчас логины всех новых сотрудников еще более тщательно фильтруются, чтобы не допустить повторение такого инцидента. Но историю с Касандрой мы будем помнить всегда.
#байки #инциденты
Как-то раз на работу в компанию устроилась девушка с никнеймом
cassandra. Возможно, что она выбрала себе никнейм в честь троянской принцессы и не замышляла никакой пакости. Однако этот выбор обернулся небольшим внутренним “апокалипсисом”.Все внутренние логины хранятся в системе под названием Стафф и из него раз в какое-то время эти логины экспортируются в множество систем. И в одной из таких выгрузок радостно на колестнице покатилась та самая
cassandra. И все бы ничего, но в нескольких внутренних систем использовался Apache Cassanda и новоиспеченная троянская принцесса законфликтовала с дефолтным именем пользователя.В этих системах все начало разваливаться. Девопсы подняли панику. Причина проблемы неочевидна. Тем не менее ребята быстро локализовали проблему, “уволили” принцессу и внесли этот логин в список запрещенных. Новый исправленный экспорт, конечно, не сразу подъехал, поэтому какое-то время парочка систем жило на быстрых решениях из палок и чернозема. Но зато внешние пользователи ничего не успели заметить! А все палки и чернозем потом вывезли…
Сейчас логины всех новых сотрудников еще более тщательно фильтруются, чтобы не допустить повторение такого инцидента. Но историю с Касандрой мы будем помнить всегда.
#байки #инциденты
Тармолов про работу
Для описания разработки используют очень много разных метафор. Мне нравится следующая аналогия: #разработка — это садоводство: разрабатываемое ПО — это сад, а разработчики — это садоводы. В любом саду постоянно приходится что-то пересаживать (рефакторинг)…
Для работы релизного пайплайна нужна #инфраструктура: правила разработки релизов, система контроля версий, CI/CD, инфраструктура для автотестов и т.д.
В итоге #разработка — это не только частые релизы новых фичей с минимум багов, но и налог на инфраструктуру, чтобы релизный пайплайн продолжал функционировать без перебоев. Отдельная команда в Яндексе развивает и поддерживает общие большие “кубики” инфраструктуры, например, единый репозиторий или CI. Команда сервиса адаптирует и подстраивает эти кубики под себя.
В нашей команде нет выделенной команды по работе с инфраструктурой. Девопсы и SRE в рамках виртуальной команды (v-team) вместе улучшают инфраструктуру отдела. Такой подход помогает учесть большинство требований и пожеланий при доработке инфраструктуры.
Участники этого v-team сами используют те инструменты и процессы, которые внедряют. Баги и неудобства чинятся в кратчайшие сроки, т.к. самим же мешают работать. В итоге одни плюсы: меньше багов, лучше инструменты, выше вовлеченность разработчиков, шире разнообразие задач.
В итоге #разработка — это не только частые релизы новых фичей с минимум багов, но и налог на инфраструктуру, чтобы релизный пайплайн продолжал функционировать без перебоев. Отдельная команда в Яндексе развивает и поддерживает общие большие “кубики” инфраструктуры, например, единый репозиторий или CI. Команда сервиса адаптирует и подстраивает эти кубики под себя.
В нашей команде нет выделенной команды по работе с инфраструктурой. Девопсы и SRE в рамках виртуальной команды (v-team) вместе улучшают инфраструктуру отдела. Такой подход помогает учесть большинство требований и пожеланий при доработке инфраструктуры.
Участники этого v-team сами используют те инструменты и процессы, которые внедряют. Баги и неудобства чинятся в кратчайшие сроки, т.к. самим же мешают работать. В итоге одни плюсы: меньше багов, лучше инструменты, выше вовлеченность разработчиков, шире разнообразие задач.
Тармолов про работу
2. Сбор обратной связи Продолжаю рассказывать про этапы #ревью. Мы стремимся сформировать объективную оценку нашей работы, поэтому недостаточно только отзыва сотрудника и мнения его руководителя. Нужен еще взгляд со стороны. Именно для этого мы собираем…
3. Выставление оценки
Результаты каждого из сотрудников оцениваются по следующей шкале:
— результаты ниже ожиданий, т.е. поставленные цели не достигнуты
— результаты соответствуют ожиданиям, когда работа выполнена в срок и без проблем с качеством
— результаты выше ожиданий, когда выполнены не только поставленные цели, но и есть дополнительные успехи сверх
Принципы оценивания немного отличаются от подразделения к подразделению. Однако, основное мерило — это влияние на бизнес компании. Чем выше грейд сотрудника, тем выше вклад в бизнес. Но все же это головная боль руководителей, чтобы команда работала на нужды бизнеса.
Сотруднику нужно понимать принципы получения повышенной оценки:
— объем работы (сделал больше задач, чем коллеги)
— оптимизации (сокращение сроков проектов, скорости сборочного конвейера, скорости запуска приложения)
— сложность (решает задачи следующего грейда, т.е. более сложные)
Разумеется, смотрим на вклад в важные запуски в наших сервисах. Чем он значительнее, тем выше оценка.
Также принимается к сведению и факультативная деятельность: выступления на конференциях, участие в школах разработки, менторство, написание статей и т.д. Не забываем и об обратной связи коллег, о которой я уже писал.
Важно. Руководитель сверяет ожидания сотрудника со своей оценкой и обсуждает разницу в трактовке при расхождении мнений. Однако, руководитель не может обещать конкретную оценку сотруднику до калибровок. После калибровок оценки могут меняться как в сторону повышения, так и в сторону понижения.
Если ваш руководитель вам уверенно обещает повышенную оценку, то отнеситесь к этому со скепсисом. Или это неопытный руководитель, или руководитель нагло врет 🙈
#ревью
Результаты каждого из сотрудников оцениваются по следующей шкале:
— результаты ниже ожиданий, т.е. поставленные цели не достигнуты
— результаты соответствуют ожиданиям, когда работа выполнена в срок и без проблем с качеством
— результаты выше ожиданий, когда выполнены не только поставленные цели, но и есть дополнительные успехи сверх
Принципы оценивания немного отличаются от подразделения к подразделению. Однако, основное мерило — это влияние на бизнес компании. Чем выше грейд сотрудника, тем выше вклад в бизнес. Но все же это головная боль руководителей, чтобы команда работала на нужды бизнеса.
Сотруднику нужно понимать принципы получения повышенной оценки:
— объем работы (сделал больше задач, чем коллеги)
— оптимизации (сокращение сроков проектов, скорости сборочного конвейера, скорости запуска приложения)
— сложность (решает задачи следующего грейда, т.е. более сложные)
Разумеется, смотрим на вклад в важные запуски в наших сервисах. Чем он значительнее, тем выше оценка.
Также принимается к сведению и факультативная деятельность: выступления на конференциях, участие в школах разработки, менторство, написание статей и т.д. Не забываем и об обратной связи коллег, о которой я уже писал.
Важно. Руководитель сверяет ожидания сотрудника со своей оценкой и обсуждает разницу в трактовке при расхождении мнений. Однако, руководитель не может обещать конкретную оценку сотруднику до калибровок. После калибровок оценки могут меняться как в сторону повышения, так и в сторону понижения.
Если ваш руководитель вам уверенно обещает повышенную оценку, то отнеситесь к этому со скепсисом. Или это неопытный руководитель, или руководитель нагло врет 🙈
#ревью
Я периодически оперирую понятием “ментальная энергия” — запас когнитивной энергии для решения повседневных задач. Эта энергия расходуется на рабочие задачи, на выбор еды на завтрак или же на просмотр ленты новостей в социальных сетях.
Вернемся к разработке. В среднем разработчик пишет код не более 2-4 часов в день и я в таком мнении не одинок. Остальное время разработчик думает, обсуждает решения с коллегами, читает ревью и т.д.
На эту деятельность тратится ментальная энергия и ее количество ограничено. Смена контекста — это всегда расход ментальной энергии. Для снижения расхода энергии нужны автоматизации рутинных операций.
Яркий тому пример — переводы статусов в трекере (Open → Review или Commited → Testing). Вроде бы это секундное время и чисто логически автоматизировать это не нужно, т.к. в сумме на этот процесс тратится мало времени. Постоянная смена контекста и потеря состояния потока дает утечку ментальной энергии, которую лучше затыкать автоматизацией.
Благодаря автоматизациям заодно исключаем человеческий фактор и поддерживаем статусы в актуальном состоянии.
Автоматизируйте и экономьте ментальную энергию, чтобы ее можно было тратить на более важные задачи!
#инфраструктура
Вернемся к разработке. В среднем разработчик пишет код не более 2-4 часов в день и я в таком мнении не одинок. Остальное время разработчик думает, обсуждает решения с коллегами, читает ревью и т.д.
На эту деятельность тратится ментальная энергия и ее количество ограничено. Смена контекста — это всегда расход ментальной энергии. Для снижения расхода энергии нужны автоматизации рутинных операций.
Яркий тому пример — переводы статусов в трекере (Open → Review или Commited → Testing). Вроде бы это секундное время и чисто логически автоматизировать это не нужно, т.к. в сумме на этот процесс тратится мало времени. Постоянная смена контекста и потеря состояния потока дает утечку ментальной энергии, которую лучше затыкать автоматизацией.
Благодаря автоматизациям заодно исключаем человеческий фактор и поддерживаем статусы в актуальном состоянии.
Автоматизируйте и экономьте ментальную энергию, чтобы ее можно было тратить на более важные задачи!
#инфраструктура
Искусство споров
Расхожее выражение гласит “в споре рождает истина”, поэтому в нашей команде ведется много дискуссий. Такой подход приводит к оптимальным решениям, но не всегда.
В некоторых спорах аргументы каждой из сторон — это чистой воды “вкусовщина”, например, при обсуждении кодстайла. Какой стиль выбрать для именования переменных? camelCase? snake_case? Правильного ответа нет. Главное, чтобы команда использовала единый кодстайл.
Также в каждой команде есть заядлые спорщики, которых хлебом не корми — дай подискутировать. Если встретятся два таких любителя споров, то дискуссия затянется на часы или даже привести к драке (шутка!).
Однажды два таких спорщика стали обсуждать тему, где можно ориентироваться только на чувство прекрасного. Разумные аргументы быстро закончились, но спор продолжился.
Представьте следующая картину. Двое коллег стоят напротив друг друга. Разгоряченные. На повышенных тонах говорят друг другу последний “аргумент”:
— Да!
— Нет!
— Да!
— Нет!
— Да!
В итоге этот спор закончился ничьей. Каждый остался при своем мнении. Потом ребята сели за рабочие места напротив друг друга и продолжили в привычном режиме переговариваться о багах в проекте и других рабочих вопросах.
#байки
Расхожее выражение гласит “в споре рождает истина”, поэтому в нашей команде ведется много дискуссий. Такой подход приводит к оптимальным решениям, но не всегда.
В некоторых спорах аргументы каждой из сторон — это чистой воды “вкусовщина”, например, при обсуждении кодстайла. Какой стиль выбрать для именования переменных? camelCase? snake_case? Правильного ответа нет. Главное, чтобы команда использовала единый кодстайл.
Также в каждой команде есть заядлые спорщики, которых хлебом не корми — дай подискутировать. Если встретятся два таких любителя споров, то дискуссия затянется на часы или даже привести к драке (шутка!).
Однажды два таких спорщика стали обсуждать тему, где можно ориентироваться только на чувство прекрасного. Разумные аргументы быстро закончились, но спор продолжился.
Представьте следующая картину. Двое коллег стоят напротив друг друга. Разгоряченные. На повышенных тонах говорят друг другу последний “аргумент”:
— Да!
— Нет!
— Да!
— Нет!
— Да!
В итоге этот спор закончился ничьей. Каждый остался при своем мнении. Потом ребята сели за рабочие места напротив друг друга и продолжили в привычном режиме переговариваться о багах в проекте и других рабочих вопросах.
#байки
4. Калибровки
Руководители выставляют оценки, а потом их “калибруют”.
Калибровки — серия встреч руководителей для сравнение оценок сотрудников. Главная цель — коллегиально добиться объективности в трактовке достигнутых результатов на уровне одного и нескольких подразделений.
Калибровки происходят в три этапа:
— в отделе калибруют 50-100 сотрудников
— в бизнес-юните — 300-1000 сотрудников
— в бизнес-группе — более 3000 сотрудников
Также используются “стыковые” калибровки для корректировки оценок конкретной специальности: тестировщики, фронтендеры или менеджеры.
Если на калибровке отдела обсуждают каждого сотрудника, то на калибровке бизнес-группы обсуждают только сотрудников высоких грейдов: старших разработчиков, ведущих разработчиков, руководителей групп и служб. Также участник калибровки иногда ставит “флажок” на сотрудника. Флажки ставятся при возникновении вопросов к оценке сотрудника и обязательно обсуждаются.
Механизм калибровок не является серебряной пулей в достижении объективности оценки результатов в процессе #ревью. Этот механизм не идеален. Но коллективная проверка оценки вселяет веру, что мы близки к объективности🙂
Руководители выставляют оценки, а потом их “калибруют”.
Калибровки — серия встреч руководителей для сравнение оценок сотрудников. Главная цель — коллегиально добиться объективности в трактовке достигнутых результатов на уровне одного и нескольких подразделений.
Калибровки происходят в три этапа:
— в отделе калибруют 50-100 сотрудников
— в бизнес-юните — 300-1000 сотрудников
— в бизнес-группе — более 3000 сотрудников
Также используются “стыковые” калибровки для корректировки оценок конкретной специальности: тестировщики, фронтендеры или менеджеры.
Если на калибровке отдела обсуждают каждого сотрудника, то на калибровке бизнес-группы обсуждают только сотрудников высоких грейдов: старших разработчиков, ведущих разработчиков, руководителей групп и служб. Также участник калибровки иногда ставит “флажок” на сотрудника. Флажки ставятся при возникновении вопросов к оценке сотрудника и обязательно обсуждаются.
Механизм калибровок не является серебряной пулей в достижении объективности оценки результатов в процессе #ревью. Этот механизм не идеален. Но коллективная проверка оценки вселяет веру, что мы близки к объективности
Please open Telegram to view this post
VIEW IN TELEGRAM
Андрей Стыскин показывал примерное распределение оценок по результатам ревью.
Зеленый столбик — это работа в рамках ожиданий. Как видно мы больше хвалим и меньше ругаем :)
Зеленый столбик — это работа в рамках ожиданий. Как видно мы больше хвалим и меньше ругаем :)
5. Озвучивание результатов
Объявить результаты #ревью — сложнее, чем кажется.
Руководителю легко объявлять оценку, которую ожидает сотрудник или которая превосходит ожидания. Однако объявлять оценку ниже ожиданий — непросто. В этом случае руководитель подготавливает аргументы по объяснению оценки и предлагает план-капкан по исправлению ситуации.
Мы стремимся, чтобы видение оценки у руководителя и сотрудника совпадали. Правильная оценка — оценка без сюрпризов, т.е. когда ожидания совпали с реальностью. Ок, приятный сюрприз тоже допускается 🙂
При объявлении оценки руководитель и сотрудник обсуждают цели на следующий период. Поговорить о будущем — логичный шаг для понимания перспектив и новых вызовов, которые стоят перед командой и сотрудником.
Объявить результаты #ревью — сложнее, чем кажется.
Руководителю легко объявлять оценку, которую ожидает сотрудник или которая превосходит ожидания. Однако объявлять оценку ниже ожиданий — непросто. В этом случае руководитель подготавливает аргументы по объяснению оценки и предлагает план-капкан по исправлению ситуации.
Мы стремимся, чтобы видение оценки у руководителя и сотрудника совпадали. Правильная оценка — оценка без сюрпризов, т.е. когда ожидания совпали с реальностью. Ок, приятный сюрприз тоже допускается 🙂
При объявлении оценки руководитель и сотрудник обсуждают цели на следующий период. Поговорить о будущем — логичный шаг для понимания перспектив и новых вызовов, которые стоят перед командой и сотрудником.
Полтора месяца назад я рассказывал байку про стол-стул. И сегодня опять о стуле 🙂
Написал хелпам, что у меня глючит стул. Хелпы — наша команда поддержки инфраструктуры в офисе. Естественно, к своему багрепорту приложил фотографии и объяснил в подробностях в чем причина.
Пришел ответ, который нельзя не показать:
Чувство юмора — must have в нашей работе. Наверное, можно и без него, но будет жить как-то очень не очень. Хорошего настроения и безбажных стульев!
P. S. Хелпы починили мой стул и он до сих пор не глючит!
#байки
Написал хелпам, что у меня глючит стул. Хелпы — наша команда поддержки инфраструктуры в офисе. Естественно, к своему багрепорту приложил фотографии и объяснил в подробностях в чем причина.
Пришел ответ, который нельзя не показать:
Здравствуйте!
Попробуйте перезагрузить стул, возможно это поможет.
Так же, попробуйте попользовать стул соседа, возможно дело не в вашем экземпляре стула а в местоположении/форме сидящего.
Если и соседский стул ведет себя так-же, возможно это общая проблема и о ней стоит оповестить ответственного админа.
Если вышеуказанное не поможет - прошу сообщить!
Чувство юмора — must have в нашей работе. Наверное, можно и без него, но будет жить как-то очень не очень. Хорошего настроения и безбажных стульев!
P. S. Хелпы починили мой стул и он до сих пор не глючит!
#байки
Я расскажу о своем пути, чтобы было понятно кто ж пишет в этом канале.
Будет две части: до Яндекса и в Яндексе.
Часть 1. До Яндекса
Начну издалека —со студенчества.
Меня заселили в комнату к старшекурсникам, которые повлияли на мой путь:
1. Один сосед сказал учить десятипальцевый метод печати. Это лучшая инвестиция моего первого курса. Спасибо Шахиджаняну! Я рекомендую изучить слепой метод каждому разработчику для экономии безумного количества времени в будущем.
2. Второй сосед устроил меня на работу офисным админом. Я работал классическим админом: настраивал сеть, чинил компы, вешал телевизоры, прибивал плинтусы. Это было хорошим стартом карьеры.
3. Третий сосед посоветовал тратить время на изучение LAMP вместо компьютерных игр. Я начал с учебных проектов (pet projects), потом стал использовать этот стек в курсовых, далее перешел на фриланс, а потом в веб-студию.
Я сменил 5 веб-студий за один год (sick!), но во каждой из них быстро упирался в потолок и занимался одним и тем же: верстал, подключал CMS, заполнял контентом, отдавал заказчику. Никакого развития! Скучно!
Как-то раз на меня вышла рекрутер из Яндекса и предложила позицию Javascript-разработчика, хотя я программировал на PHP. “Ну а что ты теряешь? Просто попробуй”, — сказала она.
Тогда ещё кандидатам давали тестовые задания на дом. Я его выполнял с помощью книги с носорогом и Stack Overflow. За вечер получилось адекватное решение, которое приняли и пригласили на собеседование.
Собеседование на разработчика было успешно провалено, но меня все равно взяли за “горящие глаза”. Также я был студентом, деньги мне были не особо важны и я готов был работать за еду. Так я стал стажером в Яндексе.
Через 5 лет я ради интереса спросил своего руководителя почему он меня тогда нанял. Вспомнить он не смог. Так что причина моего найма так и останется загадкой 🙂
#команда
Будет две части: до Яндекса и в Яндексе.
Часть 1. До Яндекса
Начну издалека —со студенчества.
Меня заселили в комнату к старшекурсникам, которые повлияли на мой путь:
1. Один сосед сказал учить десятипальцевый метод печати. Это лучшая инвестиция моего первого курса. Спасибо Шахиджаняну! Я рекомендую изучить слепой метод каждому разработчику для экономии безумного количества времени в будущем.
2. Второй сосед устроил меня на работу офисным админом. Я работал классическим админом: настраивал сеть, чинил компы, вешал телевизоры, прибивал плинтусы. Это было хорошим стартом карьеры.
3. Третий сосед посоветовал тратить время на изучение LAMP вместо компьютерных игр. Я начал с учебных проектов (pet projects), потом стал использовать этот стек в курсовых, далее перешел на фриланс, а потом в веб-студию.
Я сменил 5 веб-студий за один год (sick!), но во каждой из них быстро упирался в потолок и занимался одним и тем же: верстал, подключал CMS, заполнял контентом, отдавал заказчику. Никакого развития! Скучно!
Как-то раз на меня вышла рекрутер из Яндекса и предложила позицию Javascript-разработчика, хотя я программировал на PHP. “Ну а что ты теряешь? Просто попробуй”, — сказала она.
Тогда ещё кандидатам давали тестовые задания на дом. Я его выполнял с помощью книги с носорогом и Stack Overflow. За вечер получилось адекватное решение, которое приняли и пригласили на собеседование.
Собеседование на разработчика было успешно провалено, но меня все равно взяли за “горящие глаза”. Также я был студентом, деньги мне были не особо важны и я готов был работать за еду. Так я стал стажером в Яндексе.
Через 5 лет я ради интереса спросил своего руководителя почему он меня тогда нанял. Вспомнить он не смог. Так что причина моего найма так и останется загадкой 🙂
#команда