1. Описания уровней не очень подробные — мы когда-то делали ревью подобных документов во многих компаниях и я увидел странную тенденцию: маленькие «открытые», много рассказывающие о себе компании стараются расписать максимально подробно, а большие — наоборот. Я все-таки пока думаю, что подробное описание — это стратегический риск, но спрос на подробное описание со стороны сотрудников всегда есть. Здесь важен балланс, чтобы не породить ошибочные ожидания и обиды. Что касается ценностей — здесь другой процесс, это по большому счету часть стратегии в-целом: что важно, что нет, какие мы, кто нам нужен, что хорошо что плохо, обязанности сотрудников — и система ревью и описание уровней должны быть частью этой пирамиды, однако мы их их сделали сильно задолго до осознания важности HR-стратегии, так что я бы сказал, что уровни от неё отвязаны (особенно верхние — т.к. они в первую очередь про области ответственности). У нас идёт большой проект по доделке этого хозяйства, но это титанический труд и результатов пока нет.
2. Да.
3. Отвечал выше — пока нет внятной статистики, мы ориентируемся на отзывы коллег. Есть небольшое число менеджеров, от которых есть запрос на более четкое описания, дескать, размытость формулировок мешает им принимать и обосновывать решения. И сюрприз (на самом деле нет), есть корреляция между желанием формализовать описания уровней — и желанием изобрести формулу оценки.
Спасибо за уточнение! Странно, ну в статье почему-то об этом ничего не говорится, поэтому я и подумал, что это такая «институциональная» критика, и последние абзацы они же про ревью в-целом: «И формальная система оценок для определенного вида деятельности, особенно творческой, уникальной, играет не положительную, а отрицательную роль». Читается именно как тезис о неприменимости ревью в программистских компаниях. Впрочем если от ABBYY выйдет ретроспективная статья о том, что вы делали и на какие грабли наступали — возможно, это расставило бы все точки над i ;)
нет, системный риск скорее обратный: «всё норм» (выше отвечал). впрочем, есть ньюансы (порой это напоминает известный анекдот «приезжает комиссия в ад» — https://www.anekdot.ru/an/an9802/j980225.html#2).
(1) Утверждается (Bock, 2015), что в среднем по больнице только треть сотрудников ставит системе ревью положительную оценку, в то время как в гугле таких чуть больше половины. Фактических данных у нас к сожалению нет — надо это собирать, но руки пока не дошли. Поскольку наш процесс очень похож на гугловый, а также зная степень свободы в компании (мы приветствуем критику, и за 7 лет я не помню ни одного серьезного обсуждения «давайте свернем программу») — можно предположить, что процент не хуже, чем у Гугла.
(2) Это наверное сделать можно но (1) на большом масштабе (часть компании перевели, часть нет — типа A/B теста) и (2) с довольно дорогой поддержкой на уровне организации и опросов. Когда мы это внедряли мы очень сильно росли, и никаких ресурсов на плавный запуск у нас не было. Так что фарш назад уже не провернуть. Это как пытаться сравнить готовый проект с разными фреймворками или стеком технологий — чтобы сравнить по уму, надо проект переписать на каждый стек и так пожить несколько лет в продакшене — конечно так никто не делает, так что сравнивается исключительно синтетика.
(3) так же — это работает как пирамида, снизу вверх: менеджер собирает результаты, выбирает пиров, получает оценку от своего менеджера, она калибруется другими менеджерами.
Мне показалось, что вопрос задан в предположении, что сотрудники в любой компании находятся на положении таких бедных родственников, что всегда нужно что-то «доказывать», иначе — ничего не получишь. Задача ревью как раз в том, чтобы все просто делали свою работу — и были замечены, поддержаны и отблагодарены.
если очень упростить, то приложение Badoo — это:
— 5 разных клиентских приложений (iOS, Android, WP, Web, MobileWeb)
— SRV-часть для 5 разных клиентов (построено на едином API)
— биллинг с интеграцией платежных систем по всему миру, антифродом и прочими радостями
— бэкофис с интерфейсами переводов на лету на 40+ языков, CRM для клиентов, модерацией
— платформа с быстрыми сервисами на C/Go «облачными» технологиями для того, чтобы остальным командам проще жилось
это вот если совсем грубо. при ближайшем рассмотрении появится безопасность, антиспам, рассылки пушей-емейлов, эксперименты и многое другое — десятки задач в каждом релизе.
1) «вроде норм» — решает калибрация. Калибрация не заработает в «болоте», где все говорят «вроде норм» — калибрация работает там, где есть большая часть часть энтузиастов, которые не могут делать криво вот просто потому, что не могут и всё — и тянут (либо выталкивают) остальных.
2) Кто оценивает — менеджер + калибрация
3) Снова калибрация :) Ну и «нерабочее» — расплывчато; многие «нерабочие» характеристики на самом деле очень даже рабочие. Ну банально если человек супер-крутой, но злобно несотрудничает с новичком — это «потери», которых могло бы и не быть, но они произошли конкретно из-за личных качеств.
4) В идеале — S.M.A.R.T., на практике главное T (time-specific). Учить фреймворк, когда его нет в планах — конечно занятие бесполезное, здесь неправильно думать, что рост — это «что-то знать». Рост — это выполнять задачи сложнее, или выступать со-владельцем каких-то проектов. Если говорить про новые технологии, то начать выполнять задачи на каком-то другом языке и тем самым увеличить например delivery команды (раньше тебе такие задачи давать не могли) — почему нет, но это справедливо только для начала карьерного пути. Учить новое постоянное — это _нормально_, это вообще _обязательно_ начиная с какого-то уровня профессионализма без этого нельзя в принципе, поэтому никакого особенного ожидания вознаграждения за это и нет.
Да ни в чём, если много времени и рук, а не было ни того, ни другого. мы очень подгоняли время и всё делали наспех, выбрали партнёра с готовой платформой, и всплыла куча ньюансов уже когда пошли инвайты. Всем всё отправим!
Если Вы боитесь возраста — это ерунда, никаких специальных возрастных ограничений у нас нет, да и вообще это незаконно. Но если Вы не разрабатывали коммерческий софт под Android, то объективно Вам будет сложнее конкурировать с другими Android-разработчиками, у которых такой опыт есть — просто потому что когда Вы строите программу самообучения, то она с большой долей вероятности покрывает то, что Вам интересно, а не то, что необходимо сейчас в софтверных компаниях. С другой стороны, если Вы «на коленке» изучили достаточно хорошо платформу, и к тому же у Вас есть солидный опыт разработки в другой среде — у Вас есть все шансы. Пройдите тест — и всё станет понятно.
Я понял этот вопрос как вопрос про книжки, хотя наверное он был шире. Я ответил, во-первых, что немного читаю книжек, и второе — что в блогах и сми много шума, и что раньше читал сильно больше. Но это не значит, что я не читаю вообще :) Почти все новые идеи как раз в первую очередь появляются в блогах, периодике, на конференциях, ну и активно обсуждаются внутри, так что я лично недостатка в этом не испытываю.
Может быть, вам тошно именно от вашего процесса Performance review именно в вашей компании? Процесс процессу рознь. Как выглядит ваш процесс — вы не описали, и отчего вам тошно — тоже не указали. Раз в год вспоминать, что было сделано за год, — сложно и мучительно.
Написать раз в месяц кратко список своих задач за 4 недели занимает 20-30 минут и как мы уже писали, помогает собраться с мыслями и понять, есть ли прогресс. Нужно также помнить о том, что review делится на две составляющие: (1) карьерный путь, долгосрочная вещь, рост экспертизы и ответственности и (2) оценка результатов работы вне зависимости от уровня знаний — краткосрочная вещь. В Badoo есть и то, и другое, и месячное ревью — это (2). К сожалению, формат комментария не позволяет ответить подробнее, надеюсь когда-нибудь написать про это статью.
Уместить в одном HR-процессе (1) и (2) — частая ошибка. Бежать целый год без осмысления проделанной работы не эффективно, не даёт возможности быстро прореагировать. Понять как можно раньше, что тут вот можно быстрее и больше или, наоборот, отметить, что за этот месяц был большой прогресс — эффективнее.
Рабочие темпы у всех компаний разные, мы релизимся два раза в день — высокий темп, и о результатах задумывается тоже часто — раз в месяц, без долгих мучительных процессов – наши ребята тратят на это полчаса раз в месяц. 1:1 конечно проводит непосредственный руководитель, но когда компания горизонтальная — этого недосаточно. Руководители проводят 1:1 раз в неделю, если есть что обсуждать, если агенды нет, раз в две недели, встреча по результатам Performance review совпадает с этими встречами.
(1) Терминилогия. Если честно, я какого-то особенного дискомфорта не испытываю, и в общем-то первый раз слышу о том, чтобы увеличение числа бакетов как-то именовалось отдельно, а перераспределение данных по серверам — отдельно. хотя термины, которые вы предлагаете — мне они нравятся.
(2) Реализация узлов на практике. Что прокси, что координатор — spof, их нужно готовить именно хотя бы как m/s, и это здорово, что вам это очевидно. Поверьте, оно очевидно не всем. Но вот дальше уже неоднозначно. Если «пользовательская» нода — это мастер и пара реплик (т.н. replica set) то вы получаете утроение мощностей с куста, если грубо: лучше забить на redundancy/failover и 1/1000 кластера пусть может быть полежит, пока ребилдится RAID, чем иметь 3000 серверов в кластере.
(3) Как на базе чего-то «односерверного» и сделать «кластер». Это отличная тема, но я боюсь, что вы несколько переоцениваете как возможности уложить это в формат конференции (30 минут), так и способности аудитории за эти самые 30 минут это понять. У меня есть некоторый опыт подобного рассказа про MySQL — это несколько часов, причем без дискавери (дискавери — это maintenance нахлобучка, она сама по себе на архитектуру и понимание работы не влияет, а людям интересны чисто программерские темы — джойны, уникальность ключей, аналитика и тд). Что касается транзакций между нодами: так «сбоку» их прикрутить как раз и не получится, их можно только заменить асинхронно через внутренние очереди.
почему нельзя всё решить — можно, только способов очень много, то есть понимать это нужно так, что ты должен предложить сразу несколько механизмов — и только тогда ты можешь претендовать на универсальность. для примера типичная проблема «автошардинга»: переезд данных одного шард-ключа между дц, например (потому что «формула», и по ней перевозить можно только «бакет»).
А что именно показалось слабоваты — показались простыми темы, или что-то освещено неверно/неполно?
Это keynote, и он всегда ориентирован на максимально широкую аудиторию. Что касается глубины: когда я начинал что-то рассказывать, это было лет десять назад, было очень много проектов, которые переходили из состояния «пара серверов» в состояние «много серверов»; люди вообще боялись что-то рассказывать (из некоторых компаний — до сих пор боятся), поэтому очень многое было в новинку. Теперь это в большей степени рутина, проектов уже не единицы, больших проектов только на нашем рынке уже сотни (или тысячи), информации полно, может быть, поэтому основы кажутся банальными и хочется чего-то более интересного? На этом юбилейном Хайлоаде будет доклад про использование MySQL в Badoo — там уже будет практика шардинга. Ну или приходите в нашу фейсбук-группу, обсудим что-нибудь небанальное https://www.facebook.com/groups/feedme.ru/
2. Да.
3. Отвечал выше — пока нет внятной статистики, мы ориентируемся на отзывы коллег. Есть небольшое число менеджеров, от которых есть запрос на более четкое описания, дескать, размытость формулировок мешает им принимать и обосновывать решения. И сюрприз (на самом деле нет), есть корреляция между желанием формализовать описания уровней — и желанием изобрести формулу оценки.
(2) Это наверное сделать можно но (1) на большом масштабе (часть компании перевели, часть нет — типа A/B теста) и (2) с довольно дорогой поддержкой на уровне организации и опросов. Когда мы это внедряли мы очень сильно росли, и никаких ресурсов на плавный запуск у нас не было. Так что фарш назад уже не провернуть. Это как пытаться сравнить готовый проект с разными фреймворками или стеком технологий — чтобы сравнить по уму, надо проект переписать на каждый стек и так пожить несколько лет в продакшене — конечно так никто не делает, так что сравнивается исключительно синтетика.
(3) так же — это работает как пирамида, снизу вверх: менеджер собирает результаты, выбирает пиров, получает оценку от своего менеджера, она калибруется другими менеджерами.
— 5 разных клиентских приложений (iOS, Android, WP, Web, MobileWeb)
— SRV-часть для 5 разных клиентов (построено на едином API)
— биллинг с интеграцией платежных систем по всему миру, антифродом и прочими радостями
— бэкофис с интерфейсами переводов на лету на 40+ языков, CRM для клиентов, модерацией
— платформа с быстрыми сервисами на C/Go «облачными» технологиями для того, чтобы остальным командам проще жилось
это вот если совсем грубо. при ближайшем рассмотрении появится безопасность, антиспам, рассылки пушей-емейлов, эксперименты и многое другое — десятки задач в каждом релизе.
2) Кто оценивает — менеджер + калибрация
3) Снова калибрация :) Ну и «нерабочее» — расплывчато; многие «нерабочие» характеристики на самом деле очень даже рабочие. Ну банально если человек супер-крутой, но злобно несотрудничает с новичком — это «потери», которых могло бы и не быть, но они произошли конкретно из-за личных качеств.
4) В идеале — S.M.A.R.T., на практике главное T (time-specific). Учить фреймворк, когда его нет в планах — конечно занятие бесполезное, здесь неправильно думать, что рост — это «что-то знать». Рост — это выполнять задачи сложнее, или выступать со-владельцем каких-то проектов. Если говорить про новые технологии, то начать выполнять задачи на каком-то другом языке и тем самым увеличить например delivery команды (раньше тебе такие задачи давать не могли) — почему нет, но это справедливо только для начала карьерного пути. Учить новое постоянное — это _нормально_, это вообще _обязательно_ начиная с какого-то уровня профессионализма без этого нельзя в принципе, поэтому никакого особенного ожидания вознаграждения за это и нет.
п.4 учитывайте, что в Badoo очень большая часть доходов сотрудников (десятки процентов) сидит в бонусах, а на глассдор "сливается" база без бонуса.
Написать раз в месяц кратко список своих задач за 4 недели занимает 20-30 минут и как мы уже писали, помогает собраться с мыслями и понять, есть ли прогресс. Нужно также помнить о том, что review делится на две составляющие: (1) карьерный путь, долгосрочная вещь, рост экспертизы и ответственности и (2) оценка результатов работы вне зависимости от уровня знаний — краткосрочная вещь. В Badoo есть и то, и другое, и месячное ревью — это (2). К сожалению, формат комментария не позволяет ответить подробнее, надеюсь когда-нибудь написать про это статью.
Уместить в одном HR-процессе (1) и (2) — частая ошибка. Бежать целый год без осмысления проделанной работы не эффективно, не даёт возможности быстро прореагировать. Понять как можно раньше, что тут вот можно быстрее и больше или, наоборот, отметить, что за этот месяц был большой прогресс — эффективнее.
Рабочие темпы у всех компаний разные, мы релизимся два раза в день — высокий темп, и о результатах задумывается тоже часто — раз в месяц, без долгих мучительных процессов – наши ребята тратят на это полчаса раз в месяц. 1:1 конечно проводит непосредственный руководитель, но когда компания горизонтальная — этого недосаточно. Руководители проводят 1:1 раз в неделю, если есть что обсуждать, если агенды нет, раз в две недели, встреча по результатам Performance review совпадает с этими встречами.
(1) Терминилогия. Если честно, я какого-то особенного дискомфорта не испытываю, и в общем-то первый раз слышу о том, чтобы увеличение числа бакетов как-то именовалось отдельно, а перераспределение данных по серверам — отдельно. хотя термины, которые вы предлагаете — мне они нравятся.
(2) Реализация узлов на практике. Что прокси, что координатор — spof, их нужно готовить именно хотя бы как m/s, и это здорово, что вам это очевидно. Поверьте, оно очевидно не всем. Но вот дальше уже неоднозначно. Если «пользовательская» нода — это мастер и пара реплик (т.н. replica set) то вы получаете утроение мощностей с куста, если грубо: лучше забить на redundancy/failover и 1/1000 кластера пусть может быть полежит, пока ребилдится RAID, чем иметь 3000 серверов в кластере.
(3) Как на базе чего-то «односерверного» и сделать «кластер». Это отличная тема, но я боюсь, что вы несколько переоцениваете как возможности уложить это в формат конференции (30 минут), так и способности аудитории за эти самые 30 минут это понять. У меня есть некоторый опыт подобного рассказа про MySQL — это несколько часов, причем без дискавери (дискавери — это maintenance нахлобучка, она сама по себе на архитектуру и понимание работы не влияет, а людям интересны чисто программерские темы — джойны, уникальность ключей, аналитика и тд). Что касается транзакций между нодами: так «сбоку» их прикрутить как раз и не получится, их можно только заменить асинхронно через внутренние очереди.
Это keynote, и он всегда ориентирован на максимально широкую аудиторию. Что касается глубины: когда я начинал что-то рассказывать, это было лет десять назад, было очень много проектов, которые переходили из состояния «пара серверов» в состояние «много серверов»; люди вообще боялись что-то рассказывать (из некоторых компаний — до сих пор боятся), поэтому очень многое было в новинку. Теперь это в большей степени рутина, проектов уже не единицы, больших проектов только на нашем рынке уже сотни (или тысячи), информации полно, может быть, поэтому основы кажутся банальными и хочется чего-то более интересного? На этом юбилейном Хайлоаде будет доклад про использование MySQL в Badoo — там уже будет практика шардинга. Ну или приходите в нашу фейсбук-группу, обсудим что-нибудь небанальное https://www.facebook.com/groups/feedme.ru/