Тармолов про работу

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

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

Давайте разберёмся вместе.

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

При найме мы ориентируемся на то, насколько знания кандидата соответствуют нашим требованиям.

Когда я пришел в Яндекс, в нашей команде был сугубо мужской коллектив. Это было естественно, так как 99% резюме, которые мы получали, были от ребят. Когда же в команду пригласили первую девушку, мой руководитель шутливо сказал: «Может перестанем ругаться матом?» Спойлер: иногда мат всё же проскакивал, но точно реже.

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

Также я убежден, что смешанные команды работают лучше.

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

Иногда бывает и наоборот, конечно. Но история все же подтверждает параграф выше.

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

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

Итого. На вопрос "Кого лучше нанимать: девушек или ребят?" опытный руководитель ответит просто: "Да!".

#руководство

Дайджест 01.06.2024—31.12.2024

Байки
- Появление престейбла в картах

Безопасность
- Небезопасные смс-ки

Гео
- 20 лет геосервисам

Инциденты
- Появление престейбла в картах

Карьера
- Карта и чеклист развития руководителя
- Как расти младшим грейдам
- Как расти старшим грейдам
- Как я "соревновался" с руководителем

Книги
- SRE. Рецепты выживания в продакшне для инженера по надежности

Лайфхаки
- Про чтение
- Десятипальцевый метод печати

Менеджмент
- Главная hr-метрика

Новости
- Заопенсорсили YaFSDP
- YDEX
- Геоаналитика
- Нейрогеокодер в Казахстане
- YaC 2024

Разработка
- Метрики разработки
- Метрика скорости производства
- Метрики качества
- Метрики надежности
- Про “кубики” и паттерны решений
- Про уточек
- DORA
- Архитектура сервисов повторяет административную иерархию

Руководство
- Карта и чеклист развития руководителя
- Добавленная стоимость руководителя
- Сдвигайте медиану компетенций вправо
- Про руководителей-стажеров
- Руководители деградируют как специалисты?
- Span of control
- Как развивать HR-бренд

Финансы
- Принцип водонапорной башни в финансах

Яндекс
- Telegram-каналы яндексоидов
- Динозавр в Яндексе

#дайджесты

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

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

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

С наступающим Новым годом! 🎉

Что бы такого посмотреть за ужином? Обычно это очень сложная задача, т.к. нужно учесть множество факторов и все предпочтения.

Давайте, я вам облегчу задачу и посоветую классный сериал — YaC 2024 :)

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

Сериал позволит узнать, чем живет и дышит наша компания в очень концентрированной и красочной форме. На самом деле, просмотр YaC 2024 даст вам также понимание технологических трендов. Так что оно того стоит!

Приятного просмотра!

#новости

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

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

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

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

Построить HR-бренд крупной компании, такой как Яндекс, одними усилиями отдела HR или маркетинга невозможно. Деятельность руководителей имеет решающее значение.

Идеально, если руководители создадут условия, в которых бывшие сотрудники захотят вернуться и будут положительно отзываться о компании.

Только так можно построить по-настоящему сильный HR-бренд.

#руководство

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

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

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

Какой у вас найм?
Какой отток? А нежелательный отток?
Какие средние показатели по отрасли?

Ответы на эти вопросы позволят оценить эффективность работы HR-директора и качество построенного HR-бренда.

HR-директор должен контролируемо снабжать компанию сильными кадрами для ее роста и минимизировать нежелательный отток.

Но сделать это совсем непросто :)

P.S. В первом комменте еще добавил своих рассуждений.

#менеджмент

Две недели назад была опубликована новость про взлом компании "Раппорто". Из описания может быть непонятно, насколько она важная и пугающая.

Сотни клиентов использовали "Раппорто" в качестве SMS-шлюза для отправки SMS-сообщений конечным пользователям, в том числе коды авторизации для входа в аккаунты или коды восстановления доступа. Стало страшнее, правда?

Хочу с вами поделиться советами нашей службы безопасности для повышения безопасности аккаунтов:
1. Используйте связку пароль + одноразовый пароль из Яндекс Ключа.
2. Актуализируйте свои данные в информации об аккаунте для упрощения верификации вашей личности в случае угона аккаунта.
3. Запретите восстановление доступа к аккаунту по номеру мобильного телефона.

Для параноиков можно еще сделать следующее:
1. Использовать отдельный номер телефона для банковских и сенситивных аккаунтов.
- выпускать номер только на себя;
- не использовать его в роуминге;
- не держать "холодным", чтобы не потерять его из-за неактивности.
2. Защитить сценарии получения доступа к вашему телефону:
- установить пин-код в 6+ символов;
- зашифровать файловую систему;
- использовать телефон известных производителей;
- использовать Lockdown Mode на iPhone;
- отключить отображение содержимого push уведомлений на заблокированном экране.

И также рекомендую освежить в памяти мои прошлые советы по безопасности.

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

Ну и, конечно, не терять бдительности! ;)

#безопасность

Одна из основополагающих технологий в картах — геокодирование. Она распознает геокоординаты и преобразует их в адреса или наоборот. В наших сервисах она представлена продуктом Геокодер.

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

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

Сегодня в Казахстане мы запустили новую версию Геокодера с улучшенным поиском мест. Теперь решение работает на базе искусственного интеллекта и алгоритмов машинного обучения. Внешний интерфейс у него остался неизменным, но благодаря новым "мозгам" Геокодер на ИИ научился лучше обрабатывать неструктурированные запросы с опечатками и ошибками. Полнота ответов и скорость обработки запросов выросли. Соответственно, инструмент теперь способен лучше помогать местным компаниям работать с адресными данными.

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

Так что если вы в Казахстане и используете наш Геокодер, то вам никуда переезжать не надо. Вы уже пользуетесь Геокодером на ИИ 😉

#новости

Разговаривал на работе про span of control и захотел поделиться с вами.

Span of control (SOC) — это количество неруководителей поделить на количество руководителей, т.е. этот коэффициент показывает среднее количество прямых подчиненных у руководителя.

Выделяют два вида организаций:
1. Иерархичные (tall) — низкое значение SOC.
2. Плоские (flat) — высокое значение SOC.

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

Значения SOC у крупных компаний не являются публичной информацией, но утверждается, что компании с высокой капитализацией (такие как Google, Netflix, Microsoft) придерживаются плоской структуры.

Если равняться на техногигантов, то нужно стремиться к значению SOC в районе 6-12.

Вот поэтому наши hr не согласовывали создание подразделений меньше 5 человек. Чтобы растить SOC и вместе с ним эффективность.

#руководство

При переворачивании котлетки меняется административная структура.

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

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

Самый эффективный способ — чётко разделять зоны ответственности и адаптировать их в процессе развития сервисов. Только так один административный руководитель сможет синхронизировать развитие разных сервисов.

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

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

#разработка

Нашел свой пост в этушке от 2012 года про измерение своей эффективности с помощью отчета "Created vs. Resolved" в Jira.

Нужно было делать так, чтобы зеленого (решенного) было больше, чем созданного (красного).

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

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

Количество решенных задач или коммитов может служить неформальной метрикой собственной эффективности.

Но, конечно, важно не только СКОЛЬКО вы решаете задач, но и КАКИЕ именно и с КАКИМ качеством.

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

#карьера

Книга — лучший подарок, особенно если это SRE. Рецепты выживания в продакшне для инженера по надежности Наташи Савенковой. Мне посчастливилось получить её от самого автора.

Эта книга — квинтэссенция опыта из жизни яндексового SRE, без лишней воды, кратко и по делу.

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

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

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

#книги #инфраструктура

Давненько не было баек. Пора это исправить! Расскажу вам, как я сломал Яндекс Карты :)

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

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

Вот мы и доходим до выпуска в продакшен. Заливаю debian-пакет на прод, открываю maps.yandex.ru, а там — сюрприз: только шапка, пустота вокруг и карты как не бывало.

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

Оказалось, что скрипты postinstal debian-пакетов изрядно нам подпортили жизнь. Разработали фикс, запустили его на весь кластер, и проблема ушла.

Фууух, можно выдохнуть и на свежую голову подумать, как предотвратить такое в будущем. Ведь в тестовом окружении всё было окей, а проблема всплыла только в продакшене.

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

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

Что ни говори, а опыт оказался бесценным. И созданный prestable не раз выручал нас, спасая пользователей от неудачных релизов. Как говорится, «кто продакшен не клал, тот настоящей жизни не видал». Ошибки — часть обучения, не так ли? 🙂

#байки #инциденты

На первом курсе мой сосед по общежитию (6-й курс) посоветовал мне: "Вместо игр учись слепой печати. Пригодится. Потом поймешь".

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

Я принципиально не подглядывал на клавиатуру и приучал пальцы самим находить нужные клавиши. Через какое-то время произошел "фазовый переход", и я стал печатать с той же скоростью, что и раньше. А потом скорость увеличилась уже раза в 2-3.

Но самое важное, что фокус внимания переключился на то, что я делаю, а не как делаю. "Мы не служим клавиатуре. Это сервисное действие" :)

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

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

P.S. Забавно, но я не знаю расположение клавиш. Если начинаю смотреть на клавиатуру, скорость печати падает. Однако когда доверяю механической памяти, все идет отлично. 🙂

#лайфхаки

Сегодня мы запустили «Геоаналитику» — бесплатный инструмент для изучения потенциала районов города на основе геопривязанных данных о трафике и поисковых запросов из Яндекс Карт.

Мы считаем, что «Геоаналитика» поможет определить перспективные места для открытия точек продаж, складов и других объектов. А еще мы впервые открыто поделились уникальными на рынке данными по пешеходному и автомобильному трафикам, чтобы помогать предпринимателям лучше оценивать количество потенциальных клиентов или найти подходящие зоны для застройки и рамещения рекламы в городе.

«Геоаналитика» — это не только полезный и бесплатный сервис, но и красивый инструмент. Кликать по гексагонам на карте своего города — очень увлекательно!

#новости

В конце прошлой недели с коллегами обсуждали "тяжелую долю" руководителей.

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

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

Давайте обсудим это чуть подробнее.

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

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

Но стоит помнить, что снижение в одной области компенсируется ростом в другой. Руководитель меньше пишет кода, но БОЛЬШЕ его читает и видит БОЛЬШЕ различных решений. Условно, если разработчику опыт приезжает по дороге, то в руководителя опыт летит с многополосной автострады :)

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

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

Такие размышления успокоят не всех. Поэтому я рекомендую начинающему руководителю провести эксперимент:
1. Освободить себе 1 день в календаре.
2. Выключить мессенджер.
3. Погрузиться в детали какого-то проекта.
4. Выкатить правку в тестинг.

Так можно увидеть, что страхи преувеличены, и успокоиться ;)

#руководство

Геосервисам исполнилось 20 лет! Как время летит! Успехов и новых свершений всем нам!

#гео

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

Я визуализирую создание сервиса или процесса в виде детских кубиков. Из кубиков можно построить домик, башню или крепость. В разработке и управлении аналогичные "кубики" — это паттерны, методологии, концепции и подходы.

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

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

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

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

Речь идет про Continuous Integration (CI). Существует множество систем CI: Teamcity, Jenkins, Bitbucket Pipelines, AWS CodePipeline, GitLab.

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

Если вы придете в компанию, например, в Яндекс с самописным CI, глубокие знания Teamcity не особо помогут. А правильное высокоуровневое видение всегда полезно.

#разработка

Год назад я писал заметку про то, что когда становишься руководителем, то очень многое меняется.

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

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

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

Ну если вы, конечно, хотите стать хорошим руководителем.

#руководство

— Какова вероятность встретить на улице динозавра?
— 50%. Либо встречу, либо нет.

Яндекс. Пятница.

#яндекс

Если младшему специалисту достаточно фигачить, то с более старшими специалистами такой трюк не пройдет. Делать только текущие задачи — недостаточно, нужно научиться делать другую работу.

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

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

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

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

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

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

И помнить, что запуск сервиса — только начало пути :)

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

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

А рассказывать статус по проекту с нужным уровнем абстракции для разных потребителей — высочайший полет в менеджменте, к которому нужно стремиться!

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

#карьера

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

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

После такого откровения больше половины младших специалистов предпочитают искать советы где-то еще и иногда за пределами нашей компании. Увы :(

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

Быстрее делайте свои текущие задачи и жадно набирайте новые.

Чтобы выросла скорость, нужно растить свою эффективность, а для этого:
- нужно внимательно слушать советы во время codereview;
- не сидеть сложа руки, если основная задача застопорилась;
- узнавать как работает проект;
- и т.д.

Фактически вы просто ускоряете свою личную релизную трубу:
1. Быстрее шипите типовые задачи в продакшен.
2. Руководитель дает вам все больше задач.
3. В итоге вы делаете все более разнообразные задачи.
4. Опыт и экспертиза накапливаются.

И как результат — неизбежно становитесь опытным разработчиком или "мидлом".

Поэтому, если вы — младший специалист, то не мучайте руководителя составлением индивидуального плана развития, а просто фигачьте :)

#карьера

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

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

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

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

Освобождайте время для стратегических задач вида:
- подготовки новых проектов и зон ответственности;
- разработки технологической стратегии;
- роста и позиционирования команды;
- внедрения DORA метрики :)

#руководство

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

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

Мои коллеги не сидели сложа руки и собрали каналы яндексоидов в телеграммовскую папку «Пашем-пишем».

Теперь можно в один клик подписаться на всю папку (70+ каналов!) или на ее часть. На мой взгляд, проще вначале подписаться на всю папку, а потом оставить в подписках только интересные для вас каналы.

P.S. В комментах к этому посту можно и нужно шарить ссылки на свои каналы — источник новых открытий и вдохновения ;)

#яндекс

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

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

Больше деталей можно прочитать на специальной страничке про тикер YDEX, а я просто хочу поздравить всех причастных с этим праздником ;)

#новости

Разговор на одной из калибровок:
— У тебя младший специалист на своем грейде уже 2 года. Нет заметного роста.
— Мне норм. У меня есть задачи для его грейда.

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

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

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

Мой руководитель очень емко сформулировал идею выше: сдвигайте медиану компетенций вправо по линейке грейдов.

#руководство

Дайджест 01.04.2024—30.06.2024
Раз в квартал я публикую дайджесты для быстрого доступа к старым постам.

Для удобства посты разбиты по категориям и отсортированы по алфавиту.

Карьера
- Круг влияния и круг забот
- Наглядная картинка про рост бизнеса
- Уменьшайте головную боль руководителя

Новости
- Есть идея!
- Заопенсорсили YaFSDP

Разработка
- Метрики разработки
- Метрика скорости производства
- Метрики качества
- Метрики надежности
- Как я делал бекап фотографий

Финансы
- Принцип водонапорной башни в финансах

Яндекс
- Письмо с края Земли
- Разговор двух коллег

#дайджесты

Помимо вопроса про качество сервиса, также важна его стабильность. Какой толк от качественного и хорошо протестированного сервиса, если он то работает, то нет?

В индустрии принято мерить доступность сервиса с помощью метрики availability. Метрика availability позволяет узнать, какой процент времени сервис работает.

Хочу обратить ваше внимание, насколько дороже получать каждую новую "девятку" в этой метрике. Ниже я перечисляю, сколько времени сервис может "позволить" себе не работать при заявленном уровне доступности:

90% — 36.5 дней
99% — 3.65 дня
99.9% — 8.76 часов
99.99% — 52.6 минуты
99.999% — 5.26 минут

Мы стремимся к 99.99%. Хороший это показатель или нет? Да, вполне. Даже Google не замахивается на 99.999% :)

DORA также советуют смотреть еще на две метрики:
- процент неудачных релизов, требующих хотфиксов или ролбеков
- время, затрачиваемое на восстановление сервиса в случае инцидентов

P.S. Кстати, настоятельно рекомендую прочитать SRE Book всем, кто заботится о надежности своего сервиса.

#разработка

На вопрос "А у вас сервис — качественный?" можно получить совершенно разные ответы:
- от разработчиков можно услышать: "ничего критичного нет, остались минорчики";
- тестировщик возразит, что "у нас куча багов, которые не пофикшены с прошлого релиза";
- менеджер пожмет плечами: "основное работает, нам нужно новые фичи зарелизить".

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

На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
1. Каждому открытому багу выставляется вес согласно критериям.
2. Подсчитывается сумма всех весов.
3. Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
4. На графике проводится горизонтальная линия "максимальной забагованности", которую нельзя пересекать.

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

В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000

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

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

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

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

DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах

#разработка

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

У этой релизной трубы есть две основные характеристики:
1. Диаметр (влияет на количество одновременных фичей в работе).
2. Скорость движения по трубе (как быстро происходит выпуск фичей).

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

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

Это позволяет выявить бутылочные горлышки, мешающие выпускать фичи быстрее.

DORA предлагает обращать внимание на две метрики:
1. Lead time — время от коммита до выкладки в продакшен.
2. Частота релизов — как часто сервис релизится в продакшен.

Lead time зависит от количества задач в работе и их правильной декомпозиции. Тут мне есть над чем поработать, т.к. периодически откусываю такой кусок, который с трудом могу прожевать :)

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

#разработка