Pull to refresh

Comments 19

Ради интереса, а что можно релизить по два раза на дню на сайте знакомств (кроме исправления багов)?
Новый функционал конечно же. Я думаю, что больше 50% задач в каждом релизе — это различные улучшения (не исправления багов). Не всегда это именно новый функционал от продуктовой команды, но, например, какие-то технические улучшения кода, чтобы работало быстрее, сбор дополнительной статистики, запуск новых А/Б тестов и т.п.
если очень упростить, то приложение Badoo — это:
— 5 разных клиентских приложений (iOS, Android, WP, Web, MobileWeb)
— SRV-часть для 5 разных клиентов (построено на едином API)
— биллинг с интеграцией платежных систем по всему миру, антифродом и прочими радостями
— бэкофис с интерфейсами переводов на лету на 40+ языков, CRM для клиентов, модерацией
— платформа с быстрыми сервисами на C/Go «облачными» технологиями для того, чтобы остальным командам проще жилось
это вот если совсем грубо. при ближайшем рассмотрении появится безопасность, антиспам, рассылки пушей-емейлов, эксперименты и многое другое — десятки задач в каждом релизе.
UFO just landed and posted this here
1) «вроде норм» — решает калибрация. Калибрация не заработает в «болоте», где все говорят «вроде норм» — калибрация работает там, где есть большая часть часть энтузиастов, которые не могут делать криво вот просто потому, что не могут и всё — и тянут (либо выталкивают) остальных.
2) Кто оценивает — менеджер + калибрация
3) Снова калибрация :) Ну и «нерабочее» — расплывчато; многие «нерабочие» характеристики на самом деле очень даже рабочие. Ну банально если человек супер-крутой, но злобно несотрудничает с новичком — это «потери», которых могло бы и не быть, но они произошли конкретно из-за личных качеств.
4) В идеале — S.M.A.R.T., на практике главное T (time-specific). Учить фреймворк, когда его нет в планах — конечно занятие бесполезное, здесь неправильно думать, что рост — это «что-то знать». Рост — это выполнять задачи сложнее, или выступать со-владельцем каких-то проектов. Если говорить про новые технологии, то начать выполнять задачи на каком-то другом языке и тем самым увеличить например delivery команды (раньше тебе такие задачи давать не могли) — почему нет, но это справедливо только для начала карьерного пути. Учить новое постоянное — это _нормально_, это вообще _обязательно_ начиная с какого-то уровня профессионализма без этого нельзя в принципе, поэтому никакого особенного ожидания вознаграждения за это и нет.
А как вы боретесь с искушением у сотрудников вместо доказывания что ты хорош на перформанс ревью,
сходить доказать что ты хорош на интервью в другую компанию — и получить то же самое повышение?
Мне показалось, что вопрос задан в предположении, что сотрудники в любой компании находятся на положении таких бедных родственников, что всегда нужно что-то «доказывать», иначе — ничего не получишь. Задача ревью как раз в том, чтобы все просто делали свою работу — и были замечены, поддержаны и отблагодарены.
Наверное я слишком циничный, но в целом мне плевать на ценности компании и на ее будущее. Весь интерфейс взимодействия с компаний сводится к тому, что вот у нас есть такие цели, мы готовы за их решение платить такие-то деньги. Как не сможете, я уйду в другую.

Весь процесс ревью сводится к тому, чтобы определить как соотносится работник и круг задач его, где хорошо, где надо подтянуть, имея при этом ограниченные ресурсы.
Весь успех компании зависит от того, какие люди стоят на каких местах. Я бы сказал даже ключевой момент поставить правильного человека в нужное место. А далее все просто корми его целями и задачами, попутно разбавляя г-ном рутиной или тем, что надо делать, потому что в жизни по другому не бывает. И будет вам счастье.
… рекомендую прочитать книжку Ласло Бока “Работа рулит!”, где в нескольких главах подробно рассматривается система оценки производительности в компании Google (наш процесс во многом повторяет процесс в Google)

За статью и опыт в этом деле — спасибо. Но как насчёт следующего:
1) Что думают сами сотрудники о review?
2) Есть ли возможность сравнить эффективность компании с ревью и без него, для понимания эффективности этого процесса?
3) Как проходит ревью самих менеджеров и лиц над ними (исключая владельцев, разумеется)?

(1) Утверждается (Bock, 2015), что в среднем по больнице только треть сотрудников ставит системе ревью положительную оценку, в то время как в гугле таких чуть больше половины. Фактических данных у нас к сожалению нет — надо это собирать, но руки пока не дошли. Поскольку наш процесс очень похож на гугловый, а также зная степень свободы в компании (мы приветствуем критику, и за 7 лет я не помню ни одного серьезного обсуждения «давайте свернем программу») — можно предположить, что процент не хуже, чем у Гугла.
(2) Это наверное сделать можно но (1) на большом масштабе (часть компании перевели, часть нет — типа A/B теста) и (2) с довольно дорогой поддержкой на уровне организации и опросов. Когда мы это внедряли мы очень сильно росли, и никаких ресурсов на плавный запуск у нас не было. Так что фарш назад уже не провернуть. Это как пытаться сравнить готовый проект с разными фреймворками или стеком технологий — чтобы сравнить по уму, надо проект переписать на каждый стек и так пожить несколько лет в продакшене — конечно так никто не делает, так что сравнивается исключительно синтетика.
(3) так же — это работает как пирамида, снизу вверх: менеджер собирает результаты, выбирает пиров, получает оценку от своего менеджера, она калибруется другими менеджерами.
В subversion для того, чтобы посмотреть, кто написал строчку кода, есть команда svn annotate. У нее есть синонимы svn praise (похвалить) и svn blame (обвинить). С кем ни общался, все эту команду называют blame — никто не полезет не то, что хвалить, а просто посмотреть.
Про svn — отчасти шутка, конечно, но нет ли и у вас проблемы, что обвинения на ревью господствуют над похвалами?
нет, системный риск скорее обратный: «всё норм» (выше отвечал). впрочем, есть ньюансы (порой это напоминает известный анекдот «приезжает комиссия в ад» — https://www.anekdot.ru/an/an9802/j980225.html#2).
Алексей, спасибо большое за статью. Было очень приятно увидеть крайне похожую систему организации ревью программистов, тем более что работаю я в ABBYY :)

Я думаю, в статье на РБК речь шла всё-таки о попытке «алгеброй измерить гармонию», придумать бессмысленные и беспощадные показатели, которым надо соответствовать, выполнять и перевыполнять. Что-то типа SLOC, количество отправленных в продакшн фич в единицу времени или багов на фичу. Это всё открывает широкие поля для манипуляции и в целом никак не приближает компанию к цели быстрого создания крутого продукта.

В ABBYY же система ревью существует очень давно и в какой-то степени достигла тех же показателей успешности, что и в Badoo (судя по статье). Ежегодно проводится оценка сотрудника коллегами, руководителем, подчиненными и сотрудниками другого отдела, с кем он работал в течение года. Это анкета с цифровыми значениями от -2 до +2 и комментариями, обязательными для крайних оценок. Всё это как раз позволяет легко отсеять «нормальное рабочее поведение» и оценивать именно выдающиеся заслуги или наоборот – проблемы, на которые стоит обратить внимание. Потом идёт обсуждение оценок с руководителем и HR и принятие планов на следующий год.
Раз в месяц я как руководитель отдела провожу встречи один-на-один с каждым из моего подразделения. Встречи эти довольно неформальные и открытые. Это и обратная связь по итогам работы за месяц (причем не только сотруднику, но и мне), и способы улучшений процессов и работы, и какие-то личные вещи, которые влияют на работу.
Практически у всех специалистов в компании есть система уровней и можно подать заявку на переход на следующий грейд, предоставив, например, примеры сложного кода или разработанную систему автоматизации тестирования. Информация, полученная на этом ревью, является основой для принятия кадровых решений.

Так что сходства довольно много. И я буду рад более детально обменяться опытом.
Спасибо за уточнение! Странно, ну в статье почему-то об этом ничего не говорится, поэтому я и подумал, что это такая «институциональная» критика, и последние абзацы они же про ревью в-целом: «И формальная система оценок для определенного вида деятельности, особенно творческой, уникальной, играет не положительную, а отрицательную роль». Читается именно как тезис о неприменимости ревью в программистских компаниях. Впрочем если от ABBYY выйдет ретроспективная статья о том, что вы делали и на какие грабли наступали — возможно, это расставило бы все точки над i ;)
>В ABBYY же система ревью существует очень давно

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

А вот в компании, где я работаю сейчас (Facebook) система перформанс ревью действительно есть, и она действительно очень похожа на то, что описано в статье.

Вот как раз сравнивая два мира — с и без перформанс ревью, я могу сказать, что это действительно две очень большие разницы. Совершенно разные ритмы и стили работы, которые оказывают непосредственное влияние на рабочую культуру и отношение к работе. (Я не говорю «лучше» или «хуже», я лишь говорю «вообще по-другому»).
Спасибо за статью, Алексей (актуальная тема и в нашей компании). Интересно узнать больше о вашей системе:
1. Насколько подробны ваши общие описания уровней или примеры их проявлений по 3м ценностям компании?
2. Уточняете ли вы отдельно ожидания по ролям (разработчик, дизайнер, супорт, тестировщик, техписатель и др.)?
3. Как сотрудники в среднем оценивают ясность и полезность этих критериев?
Для пояснения того, приведу пример другой известной компании:
https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/ (см. Expectations for each Step).
Еще раз благодарю за то, что решили поделиться опытом.
1. Описания уровней не очень подробные — мы когда-то делали ревью подобных документов во многих компаниях и я увидел странную тенденцию: маленькие «открытые», много рассказывающие о себе компании стараются расписать максимально подробно, а большие — наоборот. Я все-таки пока думаю, что подробное описание — это стратегический риск, но спрос на подробное описание со стороны сотрудников всегда есть. Здесь важен балланс, чтобы не породить ошибочные ожидания и обиды. Что касается ценностей — здесь другой процесс, это по большому счету часть стратегии в-целом: что важно, что нет, какие мы, кто нам нужен, что хорошо что плохо, обязанности сотрудников — и система ревью и описание уровней должны быть частью этой пирамиды, однако мы их их сделали сильно задолго до осознания важности HR-стратегии, так что я бы сказал, что уровни от неё отвязаны (особенно верхние — т.к. они в первую очередь про области ответственности). У нас идёт большой проект по доделке этого хозяйства, но это титанический труд и результатов пока нет.

2. Да.

3. Отвечал выше — пока нет внятной статистики, мы ориентируемся на отзывы коллег. Есть небольшое число менеджеров, от которых есть запрос на более четкое описания, дескать, размытость формулировок мешает им принимать и обосновывать решения. И сюрприз (на самом деле нет), есть корреляция между желанием формализовать описания уровней — и желанием изобрести формулу оценки.
Sign up to leave a comment.