Performance review

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи Управление разработкой в горизонтальных компаниях, где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан.

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

Гости

• Сергей Кононенко, CTO в Райффайзенбанке

• Никита Прудников, CTO в Mindbox

• Михаил Юматов, руководитель разработки в Циан

• Ведущий: Алексей Рыбак, CTO Везёт.

Темы второй части

• Чем leadership внутри плоской команды отличается от менеджмента?

• Как в горизонтальной структуре решаются вопросы безопасности?

• Какие плюсы от открытых зарплат в Mindbox?

• Как команда соблюдает technical excellence?

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

• Есть ли у вас и как устроен Performance Review?

Чем leadership внутри плоской команды отличается от менеджмента. Как решаются вопросы безопасности. Technical excellence. Решение конфликтов

Алексей Рыбак: Давайте сейчас перейдем к вопросам из зала. Я начну зачитывать те вопросы, которые есть в текстовом чате. Первый вопрос был от Димы Кушникова. Сергей, а чем leadership внутри команды отличается от менеджмента?

Сергей Кононенко: Менеджмент command and control. Command and control никто из этих троих людей, которые входят у нас в leadership team, не занимается.

Алексей Рыбак: Понял. Следующий вопрос тоже от Дмитрия. Банковское обслуживание довольно регулируемая индустрия. Наверняка есть огромное количество требований, которые необходимо соблюдать, чтобы регулярно проходить аудит безопасности? Что случилось с политикой безопасности в процессе трансформации?

Сергей Кононенко: Ничего не случилось, они все с нами. Аудиты есть не только по безопасности, есть много других аудитов, которые мы регулярно проводим: как внутренние, так и внешние, так и групповые из Raiffeisen Group.

Алексей Рыбак: Следующий вопрос был тоже от Дмитрия. Сергей, кто и как контролирует, что команда соблюдает договоренности, technical excellence? Как происходит изменение требований technical excellence?

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

Алексей Рыбак: Хорошо, следующий вопрос. По-видимому, уже всем. Вопрос от Вадима Назарова. Отличный, кстати вопрос. Как организуется решение конфликтов, если платформенной команде в рамках своего проекта требуются какие-то доработки от продуктовых команд, а у продуктов тоже свой бэклог?

Сергей Кононенко: Мне, наверное, проще всего ответить. У нас нет платформенных команд, которым нужны какие-то особенные доработки. Платформенные команды выставляют definition of done, что значит разработка на их платформе. Если этот definition of done под продуктовые команды не соблюден, то их инкремент просто не принимается в платформу.

Алексей Рыбак: Понятно. Никита, как у вас?

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

Алексей Рыбак: То есть через какую-то специальную встречу, где происходит какая-то договоренность. Хорошо, тогда такой вопрос. Во всех liberated структурах есть всегда такой стиль, когда ты, с одной стороны короче, вежливое нет, вежливое постоянное нет. Структура позволит это сделать, но в случае, если постоянно идет отказ: Да, но не сейчас. Нет времени, слушай, такой важный проект. Да, техдолг, но не сейчас, и постоянно, постоянно откладывается. Что произойдет? Встречаемся: Слушай, не могу, не можем.

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

Алексей Рыбак: У тебя есть платформенная команда, которая переходит с одной версии API или базы данных на другую. И логику надо переписать, потому что тот SQL, который я написал, или тот API, который я использую, новым софтом не поддерживается. Я должен переписать достаточно важный кусок. Я не хочу его трогать, оно поломает дофига всего. Я объяснил это продакту, который говорит: Не-не-не, вы вчера сломали что-то. И в прошлом месяце что-то сломали. Нет, сейчас мы делать не будет, потому что у нас очень важные планы, бла-бла-бла

Никита Прудников: Да, я понял, могу ответить.

Алексей Рыбак: Ну, привет! А когда? Вы встретились, сказали: Встретимся через две недели и поговорим. За две недели произошло еще что-то, через две недели тоже. Вот такой сценарий. Дальше?

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

Алексей Рыбак: Кто влезет в бизнес-логику? Платформенная команда влезет в бизнес-логику, перепишет какие-то вызовы, платформу?

Никита Прудников: В том числе она может так сделать, конечно.

Алексей Рыбак: Я понял. У вас были такие кейсы? В реальности были такие ситуации или нет? Как они разрешались?

Никита Прудников: Давай подумаем. У нас часто нет такой суперантогонизации между ролями команд. То есть, если такие кейсы возникали, чаще всего не было конфликта. Платформенная команда договаривалась с продуктовой, у которой вообще-то есть выделенный постоянно ресурс на технический долг, который она может тратить. И они решали, что эту часть чуваки сделают у себя, потому что это business critical, и они очень сильно в домене это знают, эту часть запулит себе платформенная команда.

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

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

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

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

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

Алексей Рыбак: Хорошо. Михаил, у вас конфликты тоже решаются больше на более ранней стадии общения? Или можешь вспомнить какие-то примеры, когда они выплеснулись куда-то, не смогли решить?

Михаил Юматов: Бывают ситуации, когда команда платформы не может договориться с продуктовой командой. В этом случае они подключают меня или это может дойти до уровня CTO, где мы можем разрешить этот конфликт. И это либо укладывается в квартальное планирование, если это какие-то большие истории, которые затрагивают много продуктовых команд, и нужно разрезать весь этот проект продуктовым командам плюс платформе. Либо это какие-то небольшие истории в рамках квартала. И, соответственно, либо продуктовые команды самостоятельно договариваются вместе с платформой, либо не договариваются и эскалируют выше. И мы уже вместе принимаем решения.

Открытые зарплаты: какие от них плюсы. Рыночные зарплаты, воронка кандидатов. Описание задач

Алексей Рыбак: Ясно, спасибо. Никита, к тебе вопросы. Два вопроса. Первый вопрос от Димы Кушникова. Какие плюсы вы получаете от открытых зарплат?

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

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

Никита Прудников: А какого отрицательного давления?

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

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

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

Алексей Рыбак: То есть ты думаешь, что настолько все привыкают, в том числе к такого рода культуре, что и уже уходить некуда? Ты это имеешь в виду?

Никита Прудников: В каком-то смысле я это вижу. У нас компания, с точки зрения нагрузки, серьезная. Именно day-to-day workload большой. И мы даже со своей стороны, сейчас интересный минус расскажу открытых зарплат, мы до сих пор не придумали хорошего процесса, чтобы люди самостоятельно пушили свою зарплату.

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

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

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

Алексей Рыбак: Разные бывают ситуации, особенно когда большие коллективы. Такой еще вопрос, перекликается с одним из последних, по-моему, вопросов. А как часто вы делаете рыночный обзор зарплат? И есть ли у вас процесс, который оценивает, произошел ли gap up? Или люди скромно работают, а потом в какой-то момент им поступает предложение и они находятся в ситуации, когда: Блин, нифига себе. Это почему у нас

Никита Прудников: Ну, gap большой. Но это то, про что я рассказал.

Алексей Рыбак: Вопрос был довольно прямой: рыночные ли у вас зарплаты? Я здесь развернул: как часто у вас происходит такого рода ревью? Что из себя представляет этот процесс?

Никита Прудников: Ревью обычно происходит с точки зрения вакансий. Я и еще ряд людей, мы занимаемся интерированием вакансий на HeadHunter. И нам, естественно, с учетом того, что полностью открыты зарплаты внутри компании, этот гэп понятен. То есть у нас есть какая-то вилка на HH, к нам приходят какие-то люди по воронке

Алексей Рыбак: Прости, Никита, не понял. Как он вам понятен? С HeadHunter вы взяли эту информацию?

Никита Прудников: Мы делаем вилку на HeadHunter в вакансии, и к нам в воронку приходят какие-то люди. У нас нон-стоп конвейер собеседований. У меня каждый день примерно по одному собеседованию C#, лидов, я участвую.

Алексей Рыбак: Правильно я понимаю, что вы собираете это с потока входящих?

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

Алексей Рыбак: С потоком такая проблема. Ты ошибся, ты получаешь достаточное количество людей, но не получаешь определенных людей. У тебя получается ошибка смещенной оценки. С одной стороны, ты получаешь достаточное количество людей, которые зааплаились и что-то назвали. И при этом какую-то часть не видишь.

Никита Прудников: Но я в этот момент рефлексирую вилку, с ней же тоже процесс есть, она меняется. Если я вижу, что воронка работает не на меня, в этот момент я ее меняю.

Алексей Рыбак: Хорошо. У тебя есть понимание, какая текучка внутри компании?

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

Алексей Рыбак: То есть 2%? Если 50 человек

Никита Прудников: Я тут боюсь обмануть, честно тебе скажу. Просто я сейчас что-то из памяти вспоминаю. Кажется, оценка такая.

Алексей Рыбак: В любом случае это какие-то части. Давай двинемся дальше. Был еще вопрос, тоже, Никита, тебе. У нас минута Mindbox. Вадим Назаров спрашивает. Чем занимаются архитектор? Есть ли он? Кто ему ставит задачи? Кому подчиняется? Взаимодействует ли он с командой?

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

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

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

Алексей Рыбак: Понял. Никита, спасибо большое. У нас есть первый смелый. Спасибо большое, Георгий. Поднял руку, оказался на панели среди спикеров. Георгий, у вас вопрос. Прошу вас. Только включите, пожалуйста, микрофон.

Георгий: Всем привет. Во-первых, спасибо, Алексей, за такое мероприятие, интересно послушать, как бывает у людей. У меня вопрос к ребятам, к коллегам. Много было сказано по поводу задач. А кто занимается описанием задач? Участвуете ли вы в этом? Насколько глубоко описываются у вас задачи?

Откуда исходит вопрос? Я на своей практике знаю, что хорошее описание задачи это большой залог успеха и скорости выполнения.

Алексей Рыбак: Спасибо большое. Кто хочет ответить из вас?

Сергей Кононенко: Давайте я отвечу. Задачи прорабатываются внутри команды. Если задача не имеет понятного acceptance-критерия, то есть критерия, по которому мы поймем, что задача сделана, то, скорее всего, она будет сделана не сразу, не очень качественно, и у нас будут сюрпризы. Поэтому, пока команда не поймет, что они понимают, что нужно сделать, скорее всего, задача в работу не пойдет.

Алексей Рыбак: В связи с этим у меня вопрос. Это искусство описывать задачи, в том числе это искусство Мы это всегда называли PRD, спеки не важно. Спеки более технический текст, PRD более продуктовый. Там идет взаимодействие с дизайнером, там идет взаимодействие, может быть, не с одним продактом. Продакт, если будет описывать задачу, зашьется. Дизайнер не всегда готов описывать. UX-человек, если есть отдельный UX-специалист или UX-дизайнер, то он, может быть, каких-то аспектов продуктовых не знает. То есть это всегда магия.

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

Сергей Кононенко: Все очень просто. Команда делает команда описывает. Если команда описала сначала так, что потом не смогла сделать, то они это поймут, дадут себе обратную связь и в следующий раз сделают иначе.

Алексей Рыбак: Давай представим себе, что мы члены команды, а ты продакт. Ты принес идею, которая вообще никаким образом не описана, просто ее на словах принес. И дальше все остальные сели и сказали Появилась некоторая задача, которая должна быть описана. Но это же часть бэклога, получается, описать такую-то задачу?

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

Алексей Рыбак: Спасибо, Сергей. Михаил, ты включал микрофон, видимо, хотел что-то ответить.

Михаил Юматов: У нас все опять же зависит от команды. Где-то, может быть, в наиболее сложной предметной области есть project-менеджер, который берет какую-то идею сырой от продакта и описывает уже более детально. И с этим детальным описанием уже выходит к команде разработки, где вся команда ревьюит это дело.

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

Как решаются вопросы безопасности

Алексей Рыбак: Следующий вопрос был Уже вопросы из Youtube пошли. Вопросы безопасности как решаются в ваших структурах? Я так полагаю, что так или иначе вопросы безопасности идут через платформенные команды. И они есть как в Mindbox, так и в Циане.

А есть ли платформенные команды все-таки у вас, Сергей? И вопросы безопасности каким макаром решаются? Потому что команда собралась и сама решила, как делать с точки зрения безопасности это не самый лучший set up.

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

Алексей Рыбак: У меня в связи с этим следующий вопрос. Во-первых, резюме. Достаточно мощная служба безопасности, автоматизация процесса деплоя таким образом, чтобы происходили почти все проверки автоматически.

Ревью. Означает ли это, что это какой-то процесс фоновый, или означает ли это, что каждый коммит должен пройти ревью безопасника?

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

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

Сергей Кононенко: Chaos Monkey?

Никита Прудников: Я думаю, скорее, пентест ты имеешь в виду.

Алексей Рыбак: Больше пентест, но нормальный пентест, когда никто не предупрежден.

Сергей Кононенко: Пентесты и BCP практикуем обязательно. Но совсем без предупреждений мы не можем, потому что банк работает 24/7. Вы, извините, приедете на заправку, а у нас пентест, и вы не сможете заплатить карточкой.

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

Сергей Кононенко: А мало ли, пенетрейшн удастся, и система упадет.

Алексей Рыбак: Ах, в этом смысле. Хорошо. Давайте дальше, про безопасность сообразили.

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

Алексей Рыбак: Михаилу вопрос. Как вы шарите ресурсы между командами, если шарите?

Михаил Юматов: Ресурсы это люди, наверное? Если люди, то стараемся этого не делать. Вот такой ответ. Иногда такое бывает, но это ад и для команд, и для человека.

Алексей Рыбак: Использует ли кто-то таймшиты? Если нет, то почему? Я не знаю, что такое таймшиты. Видимо, какая-то диаграмма или какое-то расписание?

Михаил Юматов: Это, видимо, отчетность по времени, как я понимаю.

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

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

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

Алексей Рыбак: Кто-нибудь еще хочет ответить?

Никита Прудников: Во-первых, мы стараемся очень сильно лайнить продукты с командами. То есть команда редко что-то делает, не относящееся к их продукту. Но процессы бюджетирования похожи, только мы вместо сторипоинтов просто используем эти блоки, карточки и также пропорционально делим. И из этого строим продуктовый P&L.

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

Алексей Рыбак: Хорошо. Ребята, еще быстрый вопрос всем. Просто давайте да или нет. Есть ли у вас performance review? Никита?

Никита Прудников: Все сложно. Что ты подразумеваешь под performance review?

Алексей Рыбак: Performance review это когда у тебя есть процесс, когда ты оцениваешь работу каждого человека в отдельности.

Никита Прудников: Если этот человек заводит карточку на повышение зарплаты, а это происходит автоматически, публично. В смысле, он же там пишет цели и то, чего он достиг.

Алексей Рыбак: Если он не завел эту карточку?

Никита Прудников: Если он работает как работает, в смысле нет вопросов с точки зрения стейкхолдера и других чуваков, то регулярного performance review нет. Если есть вопросики, тогда да, поехали. То есть on demand.

Алексей Рыбак: Сергей, как у вас?

Сергей Кононенко: Есть performance review команды. У команды есть performance-цели. И раз в год команда оценивается, и от этого зависит, получит команда бонус или не получит команда бонус.

Алексей Рыбак: Раз в год и всей командой?

Сергей Кононенко: Да.

Алексей Рыбак: Понял, спасибо. Как у вас, Михаил?

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

Алексей Рыбак: То есть у конкретного сотрудника есть performance review?

Михаил Юматов: Да.

Алексей Рыбак: Раз в какое время?

Михаил Юматов: Если говорить про какой-то общий процесс, то это может быть раз в полгода или год. Но на регулярной основе с лидом на one-to-one это постоянный процесс скорее.

Алексей Рыбак: Окей, то есть он такой Процесс performance review, если этот процесс, то у него есть определенный таймлайн, подготовка, заранее известные сроки, сколько раз в год. У кого-то один раз, у кого-то четыре раза. Хорошо, ладно.

Алексей Рыбак: Давайте двинемся дальше. Опять два вопроса Никите. Как техлиды оценивают технический уровень разработчиков не из своего стека?

Никита Прудников: У нас практически full stack. Просто из-за специфики компании У нас нет мобильной разработки, у нас очень ограниченный фронт, по сути, ограниченный облачной админкой нашего продукта. И очень много бэка. И большой проблемы с тем, что человек не разбирается в соседнем стеке, нет. Нам буквально только-только потребовались фронтенд-heavy истории. И в одной из команд появился выделенный фронтенд-лидер, который формулирует архитектуру фронта и все такое. И есть точка экспертизы и с точки зрения другого стека. Тут большой проблемы нет: ни в тех командах, где нет фронта, ни в той команде, где есть фронт. А с ним самим работаем совместно.

Алексей Рыбак: И следующий еще был вопрос, тоже, Никита, тебе. Про T-shape. В процессе работы компании возникает специалист с уникальным набором навыков. Как и надо ли это как-то выравнивать с рынком?

Никита Прудников: Если честно, я не совсем понял вопрос. В смысле, что он недооценен становится или в смысле, мы не понимаем, сколько ему платить? Давайте на какой-нибудь из этих вопросов отвечу.

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

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

Сторипоинты. Системы премирования, мотивационные схемы. Перерасход людей

Алексей Рыбак: Хорошо, мы поговорили про эстимейты. И кто-то использует эстимейты, кто-то не использует, кто-то использует сторипоинты, кто-то не использует. Вопрос был: расскажите про детали использования сторипоинтов. Кто-нибудь может рассказать, что из себя они представляют? Как вы с ними работаете? Как происходит оценка через сторипоинты? Я так понимаю, что Никита делал.

Никита Прудников: У нас нет сторипоинтов. У нас пулятся карточки одинакового размера.

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

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

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

Алексей Рыбак: Михаил, Сергей, у вас есть сторипоинты?

Сергей Кононенко: Есть, работаем по классике. То есть команда, planning poker, все дела.

Алексей Рыбак: Какие есть варианты сторипоинтов? Сколько: 1 2, 1 5, 1 48?

Сергей Кононенко: Обычно это исправленное Фибоначчи, то есть: 1, 2, 3, 5, 8, 10, 20.

Алексей Рыбак: Мы когда-то давным-давно, более десяти лет назад, когда пробовали, степени двойки использовали. Короче, что-то тоже похожее.

Сергей Кононенко: Можно использовать все что угодно, главное, чтобы команде было комфортно квантифицировать свой got feeling сделаем или не сделаем, много или мало.

Алексей Рыбак: Понял. Что у вас, Михаил? Сторипоинты есть?

Михаил Юматов: Нет, у нас сторипоинтов нет, у нас часы обычные.

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

Сергей Кононенко: Мне, наверное, проще всего ответить. Никакой ребалансировки нет, потому что каждая команда отдельная структура, которая живет в своих реалиях.

Алексей Рыбак: Вопрос, мне кажется, задан больше в предположении, что какая-то есть в компании смесь между какая-то именно матрица, когда есть какая-то большая функциональная часть, у нее есть какие-то подчасти. Как-то побили, а потом оказалось, что побили неверно, потому что что-то куда-то навалилось. Если, с другой стороны, стримы продуктовые разбили изначально и достаточно жестко поделили, то кажется, что и такой ребалансировки быть не должно.

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

Сергей Кононенко: Да, мне, наверное, проще всего. Есть годовые премии, они выделяются на команду. Выделяются по определенной формуле, которая учитывает перфоманс банка, перфоманс команды, перфоманс группы, в которую входит Райффайзенбанк Россия. Внутри команды распределяется тоже по определенным формулам, в зависимости от конкретных сотрудников, ролей, которые они занимают, уровня их экспертизы.

Алексей Рыбак: Означает ли это?.. Сейчас, у меня тут уточнение. Что может быть? Может быть такая ситуация, что это распределение произошло почти автоматом, просто по грейдингу. Подходов к этому несколько, я просто пытаюсь понять. Один подход это когда согласно общему перфомансу выделился бюджет, который потом как-то раскидался. Это один подход.

Второй подход такой, что у меня есть мой персональный план в зависимости от того, какой на меня фидбэк или еще что-то и какой у меня грейд, назовем это так. Это какая-то часть. И еще есть какая-то часть командная. Как у вас?

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

Алексей Рыбак: Понял. Михаил, как у вас?

Михаил Юматов: У нас, кроме повышения в рамках роста между грейдами или внутри грейда, нет никаких премий.

Алексей Рыбак: А как у вас в Mindbox, Никита?

Никита Прудников: Профшаринг.

Алексей Рыбак: Не понимаю, разъясни, пожалуйста.

Никита Прудников: Часть прибыли компании распределяется среди команд. Там тоже формула непростая: частично мы учитываем выручку продуктов или иногда рост выручки, если мы понимаем.

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

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

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

Запускаем новый продукт и говорим: Ладно, мы продуктовая компания, нам нужна микрокоманда вокруг этого продукта. Кто нам для нее нужен? Очевидно, нам нужен тот человек, который будет делать фронт. Если мы делаем при этом какое-то мобильное приложение, значит, нам нужен и iOS, и Android. Нам нужен бэк, обязательно нам нужен QA, QA на все. Одного QA на такое количество людей мало. Ой, bus factor, давай по два. Ой, раз два, давай еще добавим QA. В результате команда разрастается.

Сталкивались ли с подобными вещами при планировании структуры? Как это решали? Наверное, в первую очередь вопрос, Сергей, к вам.

Сергей Кононенко: Мы стараемся нанимать людей широкого спектра. То есть, если QA, хорошо бы, чтобы он умел программировать и писать автотесты, помогал разработчикам. Если разработчик, то а как же он не будет писать автотесты? Если он бэкендер, а давайте он будет еще и на фронте уметь писать. Таким образом мы контролируем безразмерные разрастания команды.

Алексей Рыбак: Но все-таки

Никита Прудников: Я, кстати, соглашусь, у нас похожая история. В смысле, мы стараемся

Алексей Рыбак: Но iOS разработка и бэкенд совсем разные.

Сергей Кононенко: Да-да-да, все правильно, поэтому у нас команды, которые прямо совсем full stack, допустим R-Mobile какой-нибудь, банковское приложение клиентское, там, пожалуйста и Java, и Scala, и Kotlin, и iOS, и базы данных, и DB2 чего там только нет. Но в момент один собирается по одному одному человеку из каждой экспертизы. А до конца года у них цель, чтобы каждый освоил еще две экспертизы.

Алексей Рыбак: Понятно. Михаил, что-нибудь можете добавить?

Михаил Юматов: Я немножко прослушал сам вопрос. Цель собрать команду, подсосать откуда или что?

Алексей Рыбак: Нет. Когда мы делаем новые направления, бывают команды, которые выпускают консюмерные продукты не в каком-то стриме большом, а например, игры делает или какие-то социальные приложения. Делают какие-то небольшие кусочки, эксперименты. И, когда запускается программа, команда, у которой есть мобильная история, веб-история, то у тебя появляется сразу же определенное количество мобильщиков, фронтендеров, QA. И команда сразу становится достаточно большой. Хотя кажется, что для того, чтобы выполнить такой проект, его можно было бы подмешать к какой-то другой команде, более большой, или нужно было бы выделять целую отдельную команду?

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

Да, действительно есть проблемы с тем, что, условно, разработчик iOS, он умеет только iOS. Есть у нас и мы поощряем это ребята, которые развиваются из С# во фронт, с фронта в Python, с Python в C#, и так далее. Но это, наверное, такие кандидаты, которых нужно как раз рассматривать для того, чтобы не раздувать ее.

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

Георгий: Да, у меня есть еще два небольших вопроса. Первое насколько, как у CTO в организациях, ваши возможности ограничены? Что вы можете сделать, что нет? Какие-то есть у вас ограничения или нет?

И второй вопрос про команды. Есть у вас удаленные команды? Вы нанимаете только русскоговорящих или у вас есть иностранцы? Есть ли какие-то ограничения с этой стороны?

Никита Прудников: Кто готов ответить? Давайте я. Ограничение роли CTO. Учитывая специфику организации, в принципе, инициировать я могу любое решение, но оно должно быть мотивировано про пользу. Иначе будут несчастливые люди, процессы вето и дальше эскалация, если захочется через всю цепочку вето пройти до совета директоров или до голосования акционеров, если надо. Так любое решение могу принять, какое необходимо, главное, чтобы оно было мотивировано пользой. И главное уведомить про это решение людей, на которых оно повлияет. Если они окей с ним, то все, принято.

А про удаленные команды у нас сейчас нет. Нет опыта, и нет команд удаленных, вся локация в офисе.

Михаил Юматов: Про ограничения мне довольно сложно ответить. Тут, мне кажется, любое решение это будет, скорее всего, результат какого-то обсуждения, навряд ли я буду какие-то истории единолично принимать, но я не CTO.

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

Алексей Рыбак: Русскоговорящая?

Михаил Юматов: Да.

Алексей Рыбак: Окей, мультиязычных команд нет. Ещё быстрый вопрос. Ребята, когда последний раз писали код? Из YouTube вопрос.

Никита Прудников: Вчера.

Михаил Юматов: Сегодня. Но я должен оговориться, что это просто какие-то автоматизации своих

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

Еще раз спасибо огромное всем, кто поучаствовал, гостям. Тема нашего митапа была Управление разработкой в горизонтальных компаниях. Сегодня у нас в гостях были Никита Прудников из Mindbox, Михаил Юматов из Циан и Сергей Кононенко из Раффайзенбанка. Спасибо вам большое.

Если у вас остались вопросы, то можете задать их прямо под этим постом.

У нашего сообщества есть Фейсбук-группа Управление и разработка крупных IT-проектов и канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техноблогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.

Syn ack, хабр!

Если ты зашел сюда, то скорее всего уже знаешь, что такое performance review и скорее всего ты недоволен его результатами:

According to Gallup, only 14% of employees strongly agree their performance reviews inspire them to improve

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

А зачем нужен performance review?

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

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

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

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

Давай разбираться.

Краткое описание процесса performance review

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

1. Ты можешь прийти ВНЕЗАПНО, встретив начальника в хорошем расположении духа, а сам ты заблаговременно произведешь хорошее впечатление на него, поднеся с утра кружку горячего кофе, или показав очень красивую презентацию своих достижений. В итоге, зарплату тебе поднимут иди дадут премию не за весь период твоей работы, а конкретно за этот день.

2. У начальника может не быть информации для сравнения тебя с другими коллегами

3. У компании может не быть бюджета, чтобы вознаградить твой труд

4. Тебя оценивает один руководитель, который может быть предвзят по отношению к тебе

Совокупность этих проблем должно решать performance review. И как же оно их решает?

1. Оценивание твоих заслуг происходит раз в пол года

2. Одновременно с тобой будут оценивать всех твоих коллег

3. Компания заблаговременно выделяет бюджет на поощрение

4. Тебя оценивают несколько руководителей (WTF??)

Рассмотрим каждое решение отдельно.

Оценивание раз в полгода

В теории эта мера предотвращает принятие решений твоим руководителем в состоянии аффекта от твоей текущей деятельности, но что мешает подсуетится перед датой икс начала оценивания (спойлер: оно так и происходит)?

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

Итого, эта мера удобна прежде всего руководителю, а не тебе.

Одновременно с тобой будут оценивать всех твоих коллег

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

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

Но может быть сама система оценки позволяет адекватно оценивать твои возможности?

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

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

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

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

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

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

Обсуждение моего дела в комитете по продвижению.

Я написал документацию по этому компоненту, который никто не понимал, как использовать.

Любой может написать документацию. Какие метрики показывают пользу для Google?

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

Удалить код может каждый, и только по-настоящему достойные повышения кандидаты могут написать его.

Никто не решался испытать новую фичу, которую выкатил Дейв, так что я написал пару end-to-end тестов.

Вот это достойно повышения!

Сертификат на повышение ДЛЯ ДЕЙВА, который смело выпустил новую фичу без end-to-end тестов

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

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

Компания заблаговременно выделяет бюджет на поощрение

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

Тебя оценивают несколько руководителей

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

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

Performance review - личный опыт

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

Всего мне доводилось проходить performance review в 3-х компаниях - о них и пойдет речь

Американская компания с русскими корнями

В этой компании ревью проводилось еще тогда, когда это не было мейнстримом - все-таки головной офис в США давал о себе знать и в российском филиале.

Я попал в ключевую команду, которая разрабатывала ядро всей системы - сервер ip телефонии. Ip-телефония и являлась бизнесом компании (очень успешным на рынке США) и именно с этого сервера началась история компании.

Казалось бы, просто идеальные условия для классного performance review?

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

1. Сервер разрабатывался с 90-х, и похоже, что ядро сервера не переписывалось с этого времени

2. Сервер создавал около 1500 потоков на проде и работал в дебаг сборке - в релиз сборке он просто падал

3. 3000 строк в методе класса было нормой, как и машины состояний, логгеры и прочие крутые штуки на макросах

4. Компилировался он только в Microsoft Visual Studio 2004 - в этой среде и приходилось работать (и это в 2к16).

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

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

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

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

Надо ли говорить, что performance review у наших коллег из других команд проходило гораздо успешнее? Они наперебой демонстрировали фешенебельный набор технологий, которые они осилили - node.js, c++14, rabbitmq, http rest api, docker, redis, qubernetes, erlang и т.д., хвастались, какие большие нагрузки могут выдержать их продукты (наш-то сервер мог выполнять не более 5 запросов в секунду, что очень напрягало прод. инженеров), как они классно внедрили новые подходы разработки и так далее и тому подобное.

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

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

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

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

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

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

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

Таким образом, уже в первом примере видно реальную цель performance review, но раскроем ее подробнее чуть позже.

Финтех, который очень хотел стать мировым брокером

Российская компания, которая ВНЕЗАПНО разбогатела на не совсем эко методах в финтехе, но потом очень сильно хотела стать мировым финансовым брокером.

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

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

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

Здесь performance review был очень продвинутым - твоего мнения даже не спрашивали. Ну т.е. могли в один прекрасный день сказать: Парень, мы подумали и решили, что-то ты не очень, давай до свиданья (и это я не утрирую - одной из популярных тем за обедом, были ставки - кого уволят следующим) и на самом деле это даже честнее - по факту на твое мнение наплевать в любом случае, но тут этого даже не скрывали.

И вот, как то, отдел перспективных мировых практик решил начать традицию открытых performance review раз в квартал - составления в конце каждого периода рейтинга команд.

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

1. Desktop девелоперы - команда, которая делала gui (графики, контролы, кнопочки) на базе готового движка

2. Финансовое вычислительное ядро - команда, которая предоставляла интерфейс для совершения сделок, по сути и есть основной и самый рисковый функционал компании

3. Геймификаторы - fullstack команда, которая реализовывала различные сервисы геймификации (лидерборд, оналйн мониторинг текущих сделок и т.д.) как и gui, так и backend.

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

Рейтинг команд распределился следующим образом.

1-ое место. ИНФРАСТРУКТУРНАЯ КОМАНДА

Занимает первое место с большим отрывом:

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

2. Лучшее качество - но никто им не пользовался, кроме вычислительного финансового ядра

3. Все задачи в срок - но ни одна из них не шла в прод, т.к. это была внутренняя инфраструктурная команда

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

2-е место. Desktop девелоперы

Кто больше всех доставляет фич в прод? Конечно они, респект им, новый день и новая кнопка в проде!

3-е место. ГЕЙМИФИКАТОР

В этой команде был я, и на самом деле мы заняли место где-то близкое к 20-му (полный список состоял примерно из 20-ти команд), но когда я узнал, на каком месте оказалось финансовое ядро, я даже как то возгордился!

Последнее место. ФИНАНСОВОЕ ЯДРО

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

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

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

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

Так закончилось первое и последнее открытое performance review компании, которая очень хотела стать мировым брокером, после которого мы гордо называли себя одной из самых херовых команд компании.

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

Компания, привет из СССР

Крупная российская, или даже еще советская (основана под закат СССР) компания.

Performance review в этой компании очень похож на тот, что проходил в американской компании с русскими корнями. Отличием является то, что я еще могу оценить своих коллег. Кого именно оценивать - решает руководство.

Однако, я так и не понял, на что влияет результаты ревью!

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

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

Например, была в моей практике такая история.

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

1. Кросс-платформенная разработка

2. Большее количество инструментов отладки

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

И вот, когда Тамерлан столкнулся с проблемой в разработке, я подошел к нему помочь, и начал объяснять, как ему решить эту проблему:

-Значит так, открывай git kraken переходи на мой коммит в этой ветке, в отдельной консоли зарегистрируй сервис в системе, тут нужна консоль с админскими правами, запускай в ней сервис, иначе будет требовать разрешить открыть порты, в обычной консоли запускай вот этот тест, он проинициализирует сервис, здесь надо запустить wireshark чтобы перехватить траффик, тут в дебаге из clion перехвати запущенный сервис, там точки останова поставь здесь, потом посмотри тут на wiki формат запросов и отправь их из postman по локальному порту, открывай winevents смотри чтобы сервис перешел в нужный режим и следи за ошибками, потом ...

-Твою мать, я запутался в окнах! Почему у меня на проекте раньше хватало только трех окон - почта, браузер и ide, а тут штук 20 уже открыто и все еще не хватает??77

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

И вот, когда настал момент оценивания Тамерлана, я написал в его оценке:

Тамерлану стоит преисполниться в многооконной разработке приложений

И этот мем получил второе дыхание, после того, как начальник не выкупил этого прикола и реально задумался поискать для Тамерлана курсы многооконной разработки!

Зачем нужен performance review в этой компании? Честно говоря, ощущение такое, что хотели сделать как в других 'крутых международных компаниях.

Необходимость в этом ревью кажется еще более странным, на фоне инструмента поощрения, с которым я столкнулся впервые именно в этой компании:

Максимальную премию получает вся команда, если выпускает продукт в срок!

И что, и это все? Да, и это все!

Выглядит это примерно так:

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

2. В течении отчетного периода реализуешь их

3. ????

4. Профит!

Честно говоря, я не знаю как это работает на уровне всей компании, но конкретно для меня я вижу эту систему наиболее близкой к справедливому распределению благ между сотрудниками:

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

2. Умением планировать ты реально демонстрируешь все свои лучшие качества в коммуникации, профессиональной экспертизе, сотрудничестве, дисциплине и т.д..

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

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

Подведем итоги проведения performance review в компаниях

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

Но может быть это мне так не повезло и вообще нельзя свой личный опыт распространять на инструмент в целом?

Конечно нельзя, но, во первых, как я уже и говорил, само по себе оценивание закрытый внутри компании процесс (а когда его сделали открытым, это было эпично, вспоминаем финтех, который хотел стать брокером), поэтому за неимением более объективной информации приходится прибегать к личному опыту. А во вторых, хоть и Сергей из яндекса пытается давить своим авторитетом и заявляет, что с performance review лучше чем без него (я не сомневаюсь, Сергей, что тебе и другим руководителям стало лучше), но почему тогда так много негативных откликов о яндекс говорит нам о заниженной зарплате и о несправедливом процессе performance review?

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

Performance review - инструмент эксплуатации и занижения твоей реальной стоимости

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

Так почему же компании так упорно продолжают использовать и продвигать performance review?

Ну, потому что это выгодно для компании и ее руководителей:

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

2. Компании проще не повышать тебе зарплату и держать ее ниже рынка - ведь есть объективная система, по которой ты не показываешь результата

3. Не смотря на то, что тебе скорее всего промывают мозг о важности командной работы, по факту performance review ее разрушает. Помоги Дейву, и Дейв получит премию за лидерские качества, а ты нет. Но зачем компании разрушать командную работу? Ну, потому что сплоченная команда может начать бороться за свои права или, что еще хуже, объединится в профсоюз, и собирать с тебя сверхприбыль и тратить ее на роскошные диваны за 4 млн рублей (яндексу привет) станет значительно сложнее.

Исходя из вышеперечисленного, чтобы тебе не пыталась говорить пропаганда о том, как performance review справедливо оценит твои старания, по факту

performance review - это инструмент эксплуатации и занижения твоей реальной стоимости

и это единственная причина, по которой она применяется в твоей компании.

Что делать?

Итак, если ты ожидаешь, что ничем хорошим очередное performance review для тебя не кончится (по не зависимым от тебя обстоятельствам), то можешь сделать следующее:

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

2. Если ты опасаешься за свою дальнейшую карьеру в компании, то лучше перед этим обратись за помощью, например, в профсоюз Платформа Солидарности, который объединяет работников платформенной экономики, в т.ч. и работников айти-отрасли (https://t.me/solidarity_platform, https://vk.com/solidarity_platform, platform.solidarity@gmail.com) и начни с заполнения анкеты - https://forms.gle/PJ14YsgMc88nkZ3b7.

В начале 2021 года у сотрудников гугл появился свой профсоюз. Значит ли это, что в Яндексе, во всем подражающем гугл, тоже появится свой профсоюз, чтобы возразить Сергею Бережному по поводу эффективности performance review?

Значит ли это, что нужно и дальше мириться с этой бессмысленной и невыгодной для работников практикой или бороться с ней вместе со своим коллективом?

Выбор за тобой.

Привет, Хабр.

После такого заголовка логично будет начать пост с "у нас было 2 мешка KPI, 75 полугодичных голсов и гора тикетов всех цветов и размеров, но итоговая премия все равно занимала полсолонки".
Хотя на самом деле грех жаловаться, работать последние полгода было достаточно интересно, да и полсолонки с точки зрения оптимистов "наполовину полон".
Тема т.н. Performance Review обсуждалась неоднократно, и преобладают заметки о несправедливости оценок, несогласованности процессов, отсутствии прозрачности и т.п.

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

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

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

Давайте рассмотрим пару вариантов:

Ты что, не поможешь? У тебя между прочим тоже ревью, хочешь, чтобы я в отзыве написал(а) все, что думаю?
"Какие согласования? Какой фриз? Давай быстренько выкатимся, там точно все работает. А я тебе отзыв классный напишу, как раз под ревью."

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

С другой стороны есть проблема выдержанного подвига (определение придумал на ходу) когда сотрудник или команда искусственно задерживает выпуск обновления или закрытие объемной задачи, а когда приходит время ревью, героически ставит тикету статус Закрыто (Выполнено).

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

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

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

Иногда становиться революционером вовсе не обязательно, достаточно быть собой и придерживаться принципов fair play.