HRBP

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

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

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

Мне в последние 5 лет невероятно везет с моими hr-партнерами. Все, с кем я работал - супер-классные профессионалы и потрясающие люди, что в этой профессии строго обязательно. Безмерно их люблю и уважаю.

Что им позволяет быть такими ценными для команды? В первую очередь - развитые софты. Эмпатичность, понимание людей и "третье ухо", чтобы слышать несказанное. Во многом HRBP - почти что психологи. Они могут выявить проблемы у ребят, найти правильный подход к каждому, проработать и поднять мотивацию. К ним приходят плакаться, жаловаться, хвастаться (но чаще - плакаться). HR-партнёр должен быть и “человечком рядом”, и профессионалом, который не растворяется в проблеме, а помогает найти решение. Они могут диагностировать выгорание и помочь его остановить. Реально - психологи. Только в отличие от врачей-психологов - они погружены в твои проблемы изутри и варятся в тех же процессах, а значит - лучше тебя понимают. И от того - тоже могут выгореть. Так что берегите своих HRBP.

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

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

Техноцели (1/4)

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

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

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

Техноцели (2/4)

Техноцель - по сути, это все, что не исходит от продукта/бизнеса напрямую.
 
Оно может появляться из разных (И)сточников:
1. Изнутри команды. Чаще всего, вам самим видней, что болит, и во что нужно проинвестировать. Тут вам нужно уметь объяснить "чтобы что". Например, мы хотим потратить месяц на рефакторинг сервиса Х, потому что сейчас разбор каждого дьютика по нему занимает час+, а после рефакторинга мы сможем дать техсапу тулинг самостоятельного разбора жалоб.
2. От руководства. В рамках какой-то стратегии или вижена. Руководство тоже должно объяснить "чтобы что". Например, переписать легаси-сервис Х на стек У, потому что найм разработчиков на стеке У дешевле и мы хотим в перспективе переходить на него.
3. От инфры. Обычно связано с какими-то масштабными переездами/стройками. Тот редкий случай, когда аргументации "чтобы что" может не быть. Например, переезд в новый оркестратор деплоя, потому что старый закапывают (а вот с хрена ли, и кому станет лучше - не всегда легко выяснить, но сделать с этим иногда ничего нельзя).
 
Другой разрез целей - их условный (Р)азмер/продолжительность. Тут цели бывают
4. Маленькие. То, что можно сделать за 1-2 спринта. Просто сделайте и не любите голову, как их оформлять и отчитываться, дольше расписывать. Просто если это важное, предупредите соседние команды, кому полезно знать, и, может, расскажите о результатах на техновстрече, если есть что поведать. Например, "а кстати - мы тут запилили клевый линтер, можете переиспользовать".
5. Небольшие. Делаются за квартал или два. Их надо нормально описать и защитить, они составляют костяк утилизации техноквоты. Например, написать драйвер для постгреса под ноду.
6. Большие. Занимают больше полугода, иногда год-два. По ним нужно самое четкое описание и обоснование. Их нужно делить на этапы/вехи/майлстоуны. Иногда можно сразу весь проект расписать на несколько кварталов вперед, но чаще - ближайший этап описывается подробно, а последующие - верхнеуровнево. Важно, чтобы ближайший этап был четко обозрим, конечен, и должен уже приносить пользу даже до окончания проекта целиком. Например, распил очередного монолита.
7. Вечные. Это те направления деятельности, которыми нужно в той или иной степени заниматься перманентно - иногда более интенсивно, иногда менее. Например, выполнение метрик technical excellence, ZBP, secutity error budget. Тут важно четко понимать, где сейчас что западает, куда сильнее навалиться.
 
С точки зрения (П)ланируемости - тут все просто, есть всего два типа.
8. Можно запланировать заранее. Мы заведомо знаем, что это надо делать. Например, адопшен какой-то технологии.
9. Влёты. В планах не было, но внезапно появилась такая потребность. Например, уперлись в производительность какого-то куска и надо его оперативно сделать более масштабируемым.
 
Еще один срез - (С)рочность. Выделим три варианта:
10. Асап. Надо брать задачу вот прямо сейчас. Например, уязвимость 0 дня.
11. К определенному сроку. Например, к моменту вступления в силу какого-нибудь определенного закона.
12. Не важно когда, просто надо сделать. Например, перейти с самопального решения на какую-то поддерживаемую библиотеку.
 
И последнее - (В)ажность.
13. Крит. Нельзя не делать, есть сильный негативный эффект от не-делания. Например, баг, блокирующий функциональность.
14. Важно. Есть понятный положительный эффект от задачи. Например, тыква, которая снижает потери при инцидентах.
15. Nice to have. Лучше сделать, но не болит. Например, перейти на новый ci, потому что в нем есть какая-то фишка.
16. Можно не делать. Если цель попадает в эту категорию, лучше ее сразу закрыть. Ну а нафига.
 
Теперь, собственно, давайте разбираться, какое должно быть целеполагание и процесс трекинга целей в зависимости от их попадания в ту или иную комбинацию срезов выше. Тут буквально 288 вариантов получается, давайте их все раскидаем по форматам работы с целями. Шутка. Или нет?

Техноцели (3/4)

Берем вариант И1-Р1-П1-С1-В1, то есть внутренняя маленькая планируемая асап крит цель. Такие предлагаю пропускать мимо всех процессов. Потому что вряд ли ей кто-то будет интересоваться, задача срочная и важная, лучше сразу сделать и не тратить время на оформительство.
 
Впрочем, то же самое можно сказать про все маленькие цели. Просто если источник - руководство или инфра, а важность - крит или важно, задачу И[2-3]-Р1-П*-С*-В[1-2] нужно
а) точно сделать (не продолбать),
б) сказать об этом заказчику в свободной форме. То есть формализм с целями и планированием тут избыточен, если вы выполняете свои обещания и у вас норм коммуникация с заказчиком.
 
Прежде, чем приступать к планированию, нужно убедиться, что у нас есть актуальная стратегия технологического развития. Потому что если ее нет, не получится убедиться, что проекты в плане не отдаляют нас от целей. В стратегии должны быть зафиксированы какие-то таргет-стейты, целевой стек, чувство прекрасного, а также - утвержденные большие цели (Р3) на горизонте. И уже составляющие этих больших целей должны быть пригодны к планированию. Большие цели планировать бесполезно, их нужно декомпозировать с убывающей детализацией.
 
В стратегии стоит обозначать основные постулаты, что мы считаем хорошим и правильным. Каким требованиям должна верхнеуровнево отвечать система. Какие подходы мы практикуем. Эдакий манифест + таргет-стейт.
 
Про влеты. Очевидно, на то они и влеты, что запланировать их нельзя. Но нужно понимать, что они будут. А значит -
а) оставлять под них небольшой зазор (никогда не планируйтесь "под крышечку"! кстати, продуктовых целей это тоже касается),
б) при появлении влета максимально прозрачно уведомлять стейков тех проектов, которые сдвинутся из-за влета (и на гринлайте/чекапе тоже подсвечивайте).
Асап-криты (И*-Р*-П2-С1-В1) примерно все тут.
 
Про вечные цели. Тут тоже нет большого смысла упарываться в их оформление или планирование. Просто не продалбывайте их показатели, и всем будет все равно, как вы это делаете. Условно говоря, можно не ставить цель "повысить рпс-аптайм в сервисе Х", если на момент гринлайта там будет целевое значение.
 
Таким образом, воронка проектов, пригодных к планированию, состоит из небольших планируемых целей И*-Р2-П1-С*-В[1-3]. Уже не столь важен источник - для прозрачности работы и корректности учета капасити нужно планировать и внутренние задачи тоже. Размер проектов должен позволять уложить их в 1-2 квартала. Если больше - декомпозируйте.
 
Дальше осталось приоритизировать проекты, исходя из их срочности и важности. Тут уже можете сами выработать формулу отношения порядка. Но интуитивно - срочное-важное должно попасть в план с сильно большей вероятностью, чем бессрочный найс-ту-хэв. Рекомендую попробовать посчитать такую метрику как cost of delay - и брать в работу в первую очередь те проекты, откладывание которых стоит дороже. Но, очевидно, если задача асап - ее надо сразу брать в работу. Если есть конкретный срок, и он в планируемом ку, надо брать (если в следующем ку, но работы много - нужно брать уже в этот). И сначала критичное и важное. И уже потом полости в плане заполнять не-срочными и найс-ту-хэв вещами. Ими же можно заполнять полости в процессе квартала, например если не было влетов, а зазор остался.

Техноцели (4/4)

Кстати, о непосредственно работе над техноцелями. (Врочем, этот абзац в той же степени справедлив для продуктовых целей.) Если вы в команде распределяете цели/проекты по людям, которые в дальнейшем тащат их в 1 щачло, вы плохо работаете с рисками. Например, есть 4 человека в команде. И 4 цели/проекта. Если каждый человек будет делать свой проект, то к концу квартала вы рискуете подойти с 4 незаконченными проектами. Напомню, проект, законченный на 90% - это незаконченный проект. Даже если случится чудо, и все успеют закончить свои проекты, пользу от этих проектов мы начнем получать лишь с конца квартала. Не лучше ли сначала командными усилиями, вчетвером, затащить самый ценный проект и уже через месяц начать получать с него профит, потом командой затащить второй, и в середине квартала получать пользу от него, и так далее? Тут работает тот же cost of delay, быстрее обналичиваются эффекты, да и риски легче митигировать.
 
Любой прогресс нужно трекать. Для этого у нас есть ежемесячные гринлайты/чекапы.
Там мы смотрим вот примерно то же самое, что попало в планирование - И*-Р2-П1-С*-В[1-3].
Плюс иногда смотрим на большие цели - есть ли там изменение динамики вследствие успехов/неуспехов локальных вех.
Плюс там рассказываем о влетах и можем упомянуть про мелкие, но важные/интересные задачки.
В конце полугодия полезно собрать итоговый результат - по средним и большим целям, а также по метрикам вечных.
 
Также отмечу, про промежуточные точки контроля нужны не только для того, чтобы проветь свою успеваемость, но и для возможных корректировок планов. Чем чаще мы сверяемся, правда ли текущие усилия приближают нас к целевой картине, тем больше у нас возможностей адаптировать свой план к конъюнктуре момента. Короткая гранулярность сверки помогает быстрее поворачивать в нужную в моменте сторону.
  
Итого, я бы предложил два вида техноцелей - большие (цели) и небольшие (проекты).
Остальная техничка никуда не девается, но ее можно так явно не заводить и не трекать, лишь бы все работало хорошо (ну типа метрики, все такое).
Большие цели обязательно должны декомпозироваться на какое-то количество небольших проектов по принципу OKR - то есть мы верим, что вот такие проекты приведут нас к цели.
При этом не обязательно каждый небольшой проект должен быть привязан к какой-то большой цели, если он сам по себе обоснованно полезен.
Каждый проект должен иметь объяснимую пользу, желательно на метриках.
Если этот проект делается в рамках большой цели - он сам по себе тоже должен приносить частичную пользу.
Также удобно укладывать цели/проекты в дерево, чтобы было наглядней, в какие метрики оно бьет.
 
То есть флоу должен быть примерно такой:
 
стратегия -> цели (зачем?) -> проекты (как?) -> планы -> ... -> профит!!! -> статус-чек
 
Итого получаем каскад от ценностей к конретному плану с оценкой результата и профита. Как-то так.

304 Not Modified

Новостей по проекту #лёха_строит_бэху на этот раз мало.

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

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

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

Сферический код в вакууме

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

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

Но на днях я познакомился с одним человеком, у которого специфика работы не менее занятная. Его код работает ... в космосе! Он пишет ПО для спутников связи. Мне тут же стало интересно - какие ограничения накладывает эта специфика, в сравнении с обычными требованиями, когда код работает у тебя "в руках". Основной подход там - это отказоустойчивость, резервирование и способность к самовосстановлению. Потому что ты не можешь удаленно подключиться и что-то перезапустить (да, там нет kvm/ipmi). То есть система должна сама себя восстанавливать при любых сбоях. И рекомендуется не забывать оборачивать код в трай-кетч :). Уверен, это весьма интересно.

А в каких экстремальных средах работает ваш код?

П.С. А познакомился я с этим человеком через штуку, которая называется Сеньёрный разговор. И мне разрешили про нее вам рассказать. Вообще она пока в глубоком пилоте, мы ее анонсировали на нашем Yandex Tech Tour в Казани и Нижнем. Но вы (по секрету) сможете поучаствовать и поделиться фидбеком. Пилот продлится до 22 декабря. Также оговорюсь, что пока оно рассчитано только на разработчиков. Механика простая: идете в бота https://t.me/seniortalks_bot, там отвечаете на пару вопросов о себе, бот ищет вам собеседников. Выбираете собеседника по душе, выбираете слот, созваниваемся по зуму. Среди возможных собеседников - эксперты Городских сервисов Яндекса (разработчики, руководители, но и не только), включая меня. На встречах можно обсудить технологии, конкретные кейсы и обменяться опытом - в целом тематика общения не сильно ограничена. Заходите, поболтаем!

Восьмой класс, вторая четверть

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

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

Я аж сначала не понял, что он хочет сказать. А потом как понял! Для тех, у кого школьная програма по химии за 8 класс уже слегка заплыла рутинными эксельками, напомню: валентностью называют способность химического элемента образовывать связи с другими атомами. Она определяется числом электронов на внешнем энергетическом уровне. Чем больше у атома «свободных» электронов или незанятых мест для них, тем больше связей он может образовать. Думал ли я, что это знание поможет мне в работе? Пожалуй, нет. Я слово-то это, скорее всего, со школы не слышал.

Так и у руководителя. Можно пытаться бесконечно в него вгружать новые команды, проекты, контексты, но в какой-то момент оно просто "не растворится" и упадет на пол. А чтобы между руководителем и вверяемой ему командой/проектом/контекстом образовалась утойчивая химическая связь, у него должно хватить на это валентности.

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

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

str = 'Quoliti Ashurenes'

def test_str_correct():
assert len(str) == 17
assert str.count('s') == 2
wrds = str.split()
assert wrds[0][0]+wrds[1][0] == 'QA'
print('PASS\n')

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

A QA engineer walks into a bar.
Orders a beer.
Orders 0 beers.
Orders 99999999999 beers.
Orders a lizard.
Orders -1 beers.
Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is.
The bar bursts into flames, killing everyone.

(Фьюить-ха!) Так вот.
Есть тестировщики, которые вручную тестируют сервис по тесткейсам. Иногда - без тесткейсов, т.н. исследовательское тестирование.
Есть тестировщики, которые запускают автотесты и интерпретируют результаты. Или сами пишут автотесты, почему бы и нет.
И все они - молодцы и умнички, если того требует конъюнктура момента, команда, продукт, должностные инструкции.

Но есть еще QA-инженеры. Это уже немного другая лига. Что отличает хорошего куа-инженера?
- ориентируется в своем продукте как рыба в воде и точно знает, как продукт должен себя вести, и почему так;
- формирует тест-кейсы, притом на раннем этапе проектирования фичи (подход 3-амиго ftw!);
- участвует в поддержке продукта (л3-л4), чтобы хорошо понимать потребности пользователей;
- знает, что и как нужно проверить, чтобы на самом деле убедиться, что продукт работает как надо (а не как в примерах выше);
- умеет подбирать оптимальный метод проверки в соответствии с пирамидой тестирования (юниты, авто, интеграционные, е2е, ui-тесты);
- заинтересованно участвует в максимальной автоматизации процесса, но понимает ее границы применимости.

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

Но если и есть выделенные люди на задачи QA - они должны не просто тестировать, а двигать команду, продукт и процессы в сторону обеспечения качества. Что бы это ни значило (а значит оно в разных командах разное). Даже если для этого придется внедрять ИИ. Всем кволити!

"Ура, склад!" (с) Шарик

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

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

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

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

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