go/ wiki/ staff/

В книге Software Engineering at Google рассказывается про документацию в Гугле, которая обёрнута в специальный сокращатель ссылок go/. Идея очень простая, что если тебе, например, нужно узнать что-то про MySQL, то ты идешь по урлу go/mysql. «Урл» в кавычках потому что я не знаю реально ли этот урл разыменовывается, или просто это удобное сокращение похода через сервис. Ниже ответ.

Забавно, что в Яндексе подобное сокращение урлов (а тут без кавычек) тоже используется, но на уровне сервисов,. Т.е мой профиль в интранете может быть доступен по урлу https://staff.yandex-team.ru/mokhov/, а может быть доступен по урлу staff/mokhov. А вот про инфохабы как-то не догадались.

Подобное сокращение урлов — это удобная альтернатива поисковым механизмам по интранету, особенно если следить за актуальностью. go/mysql — всегда будет ссылаться на хаб по тому, как внутри компании используется mysql. А staff/volozh — ну вы поняли :)

p.s. Комменты можно писать к прошлому посту для комментов. Я пока разбираюсь с поддержкой телеграма

Фил (канал Life of Phil) рассказал конкретнее как это устроено. Собственно как в Яндексе, есть шорткаты на уровне dns в интранете и это удобно

Ну давай я тогда сюда напишу просто?

«Урл» в кавычках потому что я не знаю реально ли этот урл разыменовывается, или просто это удобное сокращение похода через сервис.

В гугле ты можешь зарегистрировать свой домен первого уровня во внутренней сети: все эти go/..., me/..., они будут резолвиться на уровне dns, но их относительно сложно сделать. Надо что-то настраивать, ждать.

И есть го ссылки, ты можешь просто в UI нажать кнопку, заполнить 2 поля "go/oleg" --> "https://t.me/teamleading", и тогда по ссылке https://golink.google-intranet/oleg" будет кидаться редирект на твой канал. Ну и дальше у тебя просто первым способом сделан DNS CNAME http://go на https://golink.google-intranet.

Технически всё чуть сложнее, но концептуально так работает.

Чем ты хочешь заниматься?

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

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

Даже в горизонте полгода можно визуализировать картинку. Купленный абонемент в спортзал или билеты в отпуск гарантированно дают её.

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

Ответом на этот вопрос должен быть не просто лозунг «Быстрее, выше, сильнее», а вполне конкретный ответ. И не то чтобы есть слишком много шансов поэкспериментировать. Трудоспособный возраст в РФ с 18 до ~60 лет. Итого, есть примерно 42 попытки выбрать чем хочется заниматься в горизонте года. И всего 8 попыток в горизонте 5 лет. Многие, кстати, одну попытку израсходуют на университет. 

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

Я начал искать как ответить на этот вопрос и набрел на икигаи. Вместо того чтобы пытаться ответить сразу же на вопрос экзестенциальный, сначала надо ответить на 4 других вопроса:
1. Чем вы любите заниматься?
2. Что у вас получается хорошо делать?
3. За что вам готовы платить?
4. Что нужно миру от вас?

И пересечения ответов есть разные жизненные сценарии. Например, пересечение «Что у вас получается хорошо делать?» и «За что вам готовы платить?» — это работа. А «За что вам готовы платить?» и «Что нужно миру от вас?» — призвание. А пересечение всех 4-х — это икигаи. И, пожалуй, если после ответа на 4 вопроса у вас нашлось занятие которое присутствует везде, то на перепутии я бы выбрал именно это направление движения.

Ко мне очень часто приходят мои подопечные с вопросом «А что мне делать дальше?». И раньше я всегда отвечал вопросом: «А что ты хочешь?». Кто-то отвечал, но звучало это чаще всего как те же «Быстрее, выше, сильнее». И вот недавно я понял, что можно не только задавать открытый вопрос, но и помогать искать ответ на этот вопрос. Принцип икигаи — это один из способов, который вы, как руководитель, можете предложить сотруднику, когда составляете PIP (Personal Improvement Plan) или когда беседуете по душам о его будущем. Принципом икигаи можете воспользоваться и вы сами, если есть желание что-либо поменять...

Пост для комментариев

Сколько менеджеров нужно на встрече?

В книге Джеффа Паттона есть короткий абзац-история про компанию ThoughWorks (в печатной книге страница 138). Суть такая, что команде нужно было обсудить бэклог, но при этом в продукте было 25 людей, принимающих решение и попытка собрать их в одной комнате обернулась сущим кошмаром для команды и она не смогла нормально запланироваться. Решение, которое предлагает Джефф очевидное и на поверхности — дробиться на небольшие группы и прорабатывать частички бэклога уже в них. Не так эффективно по времени, но эффективно по результату.

Казалось бы это элементарно, Ватсон. В доковидную эпоху это работало само собой, благодаря ограничениям размера переговорок, когда в маленькую переговорку не позовёшь 20 человек. Но в эпоху Zoom’митингов мы вернулись к формату похожих монстровстреч и соответствующих проблем. Сравните картинку из шедеврума и скриншот из зума (взято отсюда). Лично у меня нет ощущения во втором случае что когда я начну говорить то меня будут слушать 50 человек.

Итак, о чём я?
Вводная 1: надо собрать встречу, чтобы что-то обсудить
Вводная 2: все начинают звать всех кто мало-мальски заинтересован в любой теме, которая может быть поднята на встрече
Итог: на встречу приходит 30 человек и вместо обсуждения, автор встречи ведет плохой монолог-доклад-презентацию, все не довольны, потому что обсуждения не получается, а на выходе ощущение что всех поставили перед фактом.

Знакомо?

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

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

Хочется обсудить — собираете до 10 человек и обсуждаете. Затесался 11? Увы, это уже презентация 😉 (табличка «sarcasm»)

Как всегда комментарии можно писать под этим сообщением. Поддержка не отвечает что происходит и почему в длинных постах нет ссылок на комменты.

О, чёрт, я кажется догадался в чём дело и почему под постами нет ссылок на обсуждение.

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

За сим вопрос к сообществу: подскажите хороших спам-ботов?

Сколько менеджеров нужно на встрече? Часть 2.

Друзья, ну я прямо удивлён. Ни один человек не написал мне, что я намеренно вас всех обманул, несмотря на то что у Паттона про дискуссии на встречах всё написано. Итак, процитирую Джеффа:

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

Позвольте небольшим группам работать вместе и принимать решения, а затем продолжите общение, в разговорной форме сообщив результаты всем остальным.

Мне кажется в переводе не совсем точно перевели второй параграф, в английском варианте было так

Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.

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

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

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

Но допустим у вас не так, есть дискуссии, тимлид постоянно что-то спрашивает и уточняет у ребят. Я вас расстрою, это всё ещё плохой открытый микрофон. В хороший качественный процесс обсуждения должны быть вовлечены все члены команды, потому что в хорошей команде все должны быть заинтересованы в том, чтобы спринт сошелся, релиз состоялся, GMV росло и т.д. А если это волнует только тимлида, который бегает между разработчиками и пытается их расшевелить, то это всё ещё нифига не командная работа. «Я свои компоненты сделал, это тестирование не протестировало и поэтому релиза не будет» ничем не отличается от «Защитник отдал пас вперёд, но там никого не было». И это уже было обшучено 20 лет назад в КВНе моими любимыми Уральскими Пельменями.

Cколько менеджеров нужно на встрече? Часть 3

Предыдущие две заметки должны были подвести вас к одному вопросу, и если вы его ещё не задали себе, то давайте зададимся им прямо сейчас. Итак: зачем нужно помнить о каком-то количестве менеджеров на встрече?

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

Я считаю, что в норме у мидла в неделю должно быть не более 2 часов встреч, помимо процессных встреч, т.е планирований, стендапов, демо и ретроспектив.

Как действовать если календарь кишит регулярными встречами? map-reduce! Проходимся по списку встреч и задаём три вопроса про каждую из них:
1. Участвовал ли я активно в последних 3-х регулярках?
2. Что произойдет если я не приду на эту встречу?
3. Нужно ли мне знать что было на той встрече, и если да то каким образом мне комфортнее всего получать информацию о происходившем на ней?

Третье — это самое интересное. Менеджеры на столько обленились, что, вместо того чтобы писать follow up’ы, зовут на встречи всех подряд, чтобы «просто послушать». Ну уж нет уж господа менеджеры. Встреча — это тикет, а follow up — это пулл реквест с последующим мерджем в транк, поэтому давайте не будем игнорировать важность фиксации договорённостей после встречи. Собственно вы, как участник этой встречи, можете подсказать организатору как именно хотели бы получать follow up.

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

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

Как быть, если слушатели горят желанием послушать? У Паттона описан метод «Аквариум». Во встрече активно участвуют до 5 человек, а остальные наблюдают. Если кто-то хочет подключиться к активной части, то нужно произвести замену, т.е чтобы кто-то из активных участников отключился от обсуждения. В оффлайне это сделать проще, чем в зуме. Но я думаю вы поняли, что смысл здесь в том, что эффективное обсуждение возможно только небольшой группой.

В конце хочу ответить на ещё один не заданный вопрос, почему мои посты называются «сколько менеджеров нужно на встрече?» Менеджер — это управленец, руководитель, а не только люди с M в названии должности (TPM, PM, Продакты). Руководителем можно быть не только группы, службы, отдела, но и функциональности, проекта, и даже эпика. И когда вы вступаете на эту дорогу руководства (если вы мидл, то уже наверняка бывали feature lead), то сразу же получаете кучу встреч впридачу, что сильно размывает ваш фокус, несмотря на то что подавляющее количество встреч вам посещать не обязательно.

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

Ходите только на полезные для вас встречи.

Право на работу

Вы, наверное, слышали что недавно в Австралии ввели закон, запрещающий работодателю звонить и писать работнику во вне рабочие часы. Хоть я этот тренд не разделяю, это отличное начало и я понимаю почему многим это нужно. Людям тяжело отказать руководителю в личной переписке, а многие руководители в вопросе «можно ли им не отвечать по выходным?» играют в молчанку.

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

Я, особенно в преддверии выходных, хочу сегодня написать на другую тему — право на работу.

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

Недавно я прочитал книгу Nordic dads. Книга эта скорее вдохновляющая и развлекающая, но автор делает явный акцент на том что в северных странах есть право на отцовский декрет. Это право даёт отцам при рождении ребёнка уйти в декрет, который они не могут* пошарить с мамой ребёнка. Это не то же самое, что просто уйти в декрет — такое есть и в России. А это именно оплачиваемый государством декретный отпуск отца.

Так вот, что интересно, когда этот декрет вводили, то были люди, которые переживали за то что отцы будут брать отпуск не для того чтобы с ребёнком сидеть, а для того чтобы ездить на рыбалку, очень популярное занятие на северах. Но разум возобладал и с течением времени появилось много активных отцов, занятых в воспитании детей. Если в прошлом веке, когда отцовский декретный отпуск вводили, его брали от силы 10%, то сейчас в некоторых странах эта цифра доходит до 50%.

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

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

Другой пример. Командировки. Текущая система командировок устроена так, что если тебе нужно максимизировать рабочее время в командировке, то придется или обязательно захватывать выходной в командировке**, или тратить своё личное время, или минимум пол-дня выпадет в пути.

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

Таких примеров может быть больше (приглашаю в комментарии). Если вы хотите стабильности ваших проектов, то я предлагаю вам ввести «правила на работу» и заранее продумать как это будет работать и оплачиваться. И да, вы точно будете первое время терять деньги на этом, но если ваша цель стабильность проекта, то оно того стоит.

Ну что ж, а мой рабочий день закончился, всем отличных выходных! :)

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

** Выходной день оплачивается либо х2, либо х1 и дополнительный отгул. Даже если ваш самолёт приземляется в субботу в 00:05 — это уже считается полностью оплачиваемым выходным. Именно это я подразумеваю под «захватывать выходные»

p2p feedback
и как его улучшить в рамках ревью?

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

Отзывы — это старт, а для многих уже и финиш, ревью. Нужно запросить отзывы на себя у коллег, написать отзывы самому и сделать самоотзыв. У кого запросить? Где-то пользуются 360 degree feedback, где-то в полуавтоматическом режиме, где-то сам человек решает. Различается так же и то как фидбек даётся: в свободном стиле, или подробные опросники, или даже шкалы оценки. Все полученные фидбеки руководитель аггрегирует и ставит оценку перфоманса.

Так вот из года в год я наблюдаю одну и ту же картину. Какая бы схема фидбека не была бы выбрана, какие бы рекомендации не были бы даны по тому у кого запрашивать отзывы и как их писать. Всё равно большая часть отзывов сведется к мастерству авторов в написании простыней общий смысл которых будет «всё норм» 👌. Таких отзывов 90%, они представляют собой восхитительные рассказы, содержащие и эмоции, и перечисления всех тикетов и встреч, и так же истории о том какой человек классный и приятный. Но не факты. А даже если факты и будут, то они зачастую продублируют те что человек написал сам про себя в самоотзыве.

Это не сильно, но раздражает уже в момент выставления оценки, но ещё больше начинает бесить во время калибровок (выравнивания оценок). Потому что сквозь череду однотипно хвалебных отзывов очень трудно разглядеть смысл отличный от «всё норм».

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

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

Складывается ощущение что отзывы от смежников не нужны совсем (ну, кроме негативных). Это не совсем так. Первый инсайд, который меня осенил совсем недавно, это то что при прочих равных даже отзыв вида «Вася мне очень помог» от автора, который обычно пишет «С Петей/Машей/Витей норм работается» — это вполне сильный сигнал о Васе.

Т.е важно не то какой отзыв написан на Васю. А какой это отзыв среди других отзывов того же автора. Иными словами из 30 отзывов, где 29 являются простынями про то что «всё норм» и один сухой отзыв «Вася крутой» от определённого автора — именно этот один отзыв должен сильнее всего влиять на оценку человека.

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

А пока давайте пообщаемся про то как у вас устроено ревью?

p2p feedback. Часть 2
и как его улучшить в рамках ревью?

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

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

В голове каждого сотрудника есть «рейтинг» и в нём нам не очень важна его нижняя часть. В худшем случае — это люди которые или сами уволятся, или их уволят. А в дефолтном те с кем автор почти не пересекался и не взаимодействовал. А вот верхняя часть интересней. Это люди, чью помощь автор замечает и ценит. Иными словами, те кто помогает ему выполнять его работу.

Теперь представим ситуацию, что в компании работает Фёдор, который выполняет свою работу ожидаемо, в рамках своего грейда, оценка на ревью «норм». Но 10 человек ставят его в своём «рейтинге» на первые места, т.е он им очень помогает в работе, а значит Фёдор ценный сотрудник, даже несмотря на то что остальные показатели у него средние. Это кубик, которого лично мне не хватало, чтобы ревью перестало быть только про результаты проектной работы, и стало ещё и про командную работу, а так же взаимовыручку.

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

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

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

p2p feedback. Часть 3

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

1. Не тратьте время на расписывание отзывов, когда общий их смысл «всё норм». Пары абзацев достаточно для нормальной оценки и я бы явно акцентировал в отзыве внимание лишь на том, что вас всё устраивает и что рабочие задачи совместно решаются эффективно.

2. Потратьте силы на топ «рейтинга» взаимовыручки. Простых «помог мне решить проблему» не достаточно, чтобы объяснить важность этой помощи. Вот здесь-таки нужна история. Например, вы неделю бились над оптимизацией какого-нибудь кода, попросили помощи у Василия, вместе с ним организовали два созвона, и предположение Василия оказалось верным. Оптимизация помогла сэкономить столько-то CPU.

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

Как калибровать людей?

После того как все отзывы собраны, пишется суммаризирующий отзыв. У меня, обычно, отзыв будет выглядеть так: основной отзыв — самоотзыв, на повышенную оценку выделяю следующее <перечисление достижений и результата>. Для удобства самоотзыв копипастится и кладётся под кат.

С удовольствием подискутирую в комментариях о других подходах.

Дальше начинаются калибровки. За почти 10 лет ревью в Яндексе я видел разное. От супержестких калибровок имени Миши Парахина (самая длинная наша калибровка длилась 16 часов, причем последние 6 мы решали задачу «понизить 4 оценки»), до формальных «поставь че-нибудь, лишь бы не всем максимальные оценки».

У любой калибровки должна быть цель. Не важно калибруются 5 человек, или 500. Целью не может быть «просто посмотреть». Глупо для того чтобы «просто посмотреть» собираться в одной комнате, закрывать шторы и тратить 8 часов на то чтобы пробежаться по списку ни на что не ориентируясь.

Вспоминается цитата из фильма ДМБ:
«Жизнь без армии — все равно что любовь в резинке: движение есть, прогресса нет».
Так и тут, если у вас на калибровку нет цели, то это бессмысленная трата времени.

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

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

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

А зачем вообще калибровать людей? Часть 1

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

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

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

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

Проводя аналогии с разработкой, представим что разработчики бэкенда будут иметь подвиды: разработчик-багофиксер, разработчик-нагрузочник, разработчик-CI/CD'шник или разработчик-скрам мастер. Фигня же?

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

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

Попробуете примерить такой способ описания должностных инструкций к разработчикам?

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

Самое интересное что попытки формализовать были и есть. У всех этих попыток сильно бросается в глаза то что список должностных инструкций для лаконичности восприятия сжимается для 3-4 однословных пунктов и многие, примеряя их к себе, видят себя чуть ли не CTO. Картинка к этому посту — это пример подобной разметки от Андрея Смирнова, руководителя в X5, про который он рассказывал в докладе «Карьерная лестница как дорога в ад».

Это вовсе не означает что это бессмысленная работа. Подобные схемы хороши как ориентир к саморазвитию, но вот как систему для оценки разрядов сотрудников в IT я бы такое применять не стал.

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

А зачем вообще калибровать людей? Часть 2

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

И все-таки в каком-то виде сопоставление скиллов грейдам существует. Тут важно понимать, что любая конкретика неизбежно приводит к формализму, поэтому тут действуют общие принципы: чем выше грейд — тем больше скиллов и самостоятельности. Как именно далее формализовать эти два параметра уже решает каждый руководитель сам. Сениоры бывают как уже готовые тимлиды-переговорщики, но средние по навыкам программирования, так и интроверты-хардкорщики, которые за пять минут найдут баг, не найденный до этого месяцами. Ещё раз повторюсь, что мне не известно, чтобы кто-то в Big Tech ориентировался на строгий чеклист навыков. Тут мы подходим к главному. Зачем калибровать людей? Если в целом Perfomance Review — это подведение итогов полугодия (или года), то калибровки это уравновешивание чаш весов результатов каждого из сотрудников и, соответственно, бенефитов. Потому что строгой функции «f(результат) = оценка» — не существует.

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

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

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

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

До сениор левела возможно расти исключительно скиллами, я часто видел как на калибровке мидлы сравниваются исключительно по хардам. Но после сениора и рост скиллов сильно замедляется, и только их не достаточно. Чтобы получать хорошие оценки на ревью нужно помнить, что оценка — это мультипликация навыков, результата, инициативы и удачи. Где каждый из показателей ещё будет откалиброван.

Так вот, удачи! :)

Изображение к посту защищено © Warner Bros., фильм «Космический джем».

Всегда действуй в интересах команды

В книге «Никаких правил. Уникальная культура Netflix» рассказывается история о политике расходов в Netflix. Один из сотрудников поехал в командировку и, чтобы сэкономить деньги компании, использовал каршеринг вместо такси. После делового ужина с парой бокалов вина он вызвал такси до отеля, но потом ему пришлось компенсировать расходы, так как это не вписывалось в политику компании. Чем был очень возмущён, он же ездил для решение задач компании.

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

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

У меня есть похожее правило: всегда действуй в интересах команды. Я часто сталкивался с бюрократией и «не положено». Единственное, что я понял — если я считаю что это принесет пользу, то я должен быть готов потратить свои деньги.

Когда я организовывал конференцию FrontTalks, политика Яндекса запрещала оплачивать афтепати. В 2018 году я очень хотел, чтобы там выступала кавер-группа и, не имея достаточных обоснований кроме «хочу», оплатил ее самостоятельно. Получилось классно. На фото, кстати, мы с ребятами из группы Everybody Dance.

За идеями для FrontTalks я часто ездил на конференции, в том числе зарубежные. Вообще я очень люблю путешествовать. Но как обосновать 4 конференции в год? Где-то и одну-то с трудом согласуют. И снова, не имея лучшего обоснования кроме «хочу», я оплачивал конференции сам. Профит такого подхода не только в новых знаниях, но и в том, что коллеги не завидовали: конференции я совмещал с отпусками и оплачивал сам, а коллегам доставалось чуть больше денег на важные для них конференции.

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

Когда-то Лёша Башкеев (CEO Яндекс Клауда) говорил, что для привлечения первоклассного кандидата нужно водить его в лучшие рестораны за свой счёт. У меня есть похожая история как-то нам нужно было за 2 месяца нанять почти 10 человек. И я сказал рекрутерам: если получится, всех свожу в ресторан. Влетело мне это тогда в копеечку, но я не жалею, ведь мы достигли результата.

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

А еще говорят что айтишники не танцуют :)