Думаю, что все из вас слышали о принципе Парето с известным правилом 80/20: "80% результатов приходятся на 20% усилий". Еще я слышал вариант, что 20% сотрудников дают 80% результата.
Около 10 лет назад мы даже решили проверить его и посчитали коммиты в общий репозиторий. В итоге оказалось, что мой руководитель коммитил больше, чем я и пара моих коллег вместе взятых. Мы еще тогда стали шутить, что может быть нас проще уволить, чтобы мы не мешали нашему руководителю развивать проект :)
Еще один известный всем принцип Мерфи: "Если что-то может пойти не так, то, скорее всего, так и произойдет". Тут без комментариев, с этим принципом сталкивался каждый из нас и не один раз.
Менее известный, но также очень жизненный — принцип Паркинсона: "Работа растягивается на тот объем времени, который для нее отведен". Каждый из нас хоть раз прокрастинировал и откладывал выполнение задачи вплоть до дедлайна. И уже в самый последний момент активизировался и доводил ее до конца. Такой подход еще очень часто практикуют студенты ;)
От wwax (той самой, что поделилась чеклистом запуска нового проекта) я узнал еще о принципе Питера: "В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности".
Когда мне нужно было купить утюг, то мне пришлось стать "экспертом по утюгам" и прочитать тонну обзоров. После этого я пошел в магазин, чтобы увидеть выбранную модель. В итоге выяснилось, что я знаю про утюги больше, чем консультанты в этом же магазине. И куда же делись все компетентные сотрудники? Выросли! Стали менеджерами магазинов или даже еще выше.
Эти все принципы заставляют лишний раз задуматься про свою эффективность. Продолжаю ли я развиваться? Или уже уперся в свой потолок? Я считаю, что еще пока не достиг предела.
И помогает мне в этом принцип Тармолова: обучаться новому и расширять кругозор каждый год. Конечно, этот принцип не так хорошо известен, как предыдущие, но может и станет таковым :)
А какие еще интересные принципы вы знаете и используете в своей жизни?
#карьера
Около 10 лет назад мы даже решили проверить его и посчитали коммиты в общий репозиторий. В итоге оказалось, что мой руководитель коммитил больше, чем я и пара моих коллег вместе взятых. Мы еще тогда стали шутить, что может быть нас проще уволить, чтобы мы не мешали нашему руководителю развивать проект :)
Еще один известный всем принцип Мерфи: "Если что-то может пойти не так, то, скорее всего, так и произойдет". Тут без комментариев, с этим принципом сталкивался каждый из нас и не один раз.
Менее известный, но также очень жизненный — принцип Паркинсона: "Работа растягивается на тот объем времени, который для нее отведен". Каждый из нас хоть раз прокрастинировал и откладывал выполнение задачи вплоть до дедлайна. И уже в самый последний момент активизировался и доводил ее до конца. Такой подход еще очень часто практикуют студенты ;)
От wwax (той самой, что поделилась чеклистом запуска нового проекта) я узнал еще о принципе Питера: "В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности".
Когда мне нужно было купить утюг, то мне пришлось стать "экспертом по утюгам" и прочитать тонну обзоров. После этого я пошел в магазин, чтобы увидеть выбранную модель. В итоге выяснилось, что я знаю про утюги больше, чем консультанты в этом же магазине. И куда же делись все компетентные сотрудники? Выросли! Стали менеджерами магазинов или даже еще выше.
Эти все принципы заставляют лишний раз задуматься про свою эффективность. Продолжаю ли я развиваться? Или уже уперся в свой потолок? Я считаю, что еще пока не достиг предела.
И помогает мне в этом принцип Тармолова: обучаться новому и расширять кругозор каждый год. Конечно, этот принцип не так хорошо известен, как предыдущие, но может и станет таковым :)
А какие еще интересные принципы вы знаете и используете в своей жизни?
#карьера
Миша Трошев, мой коллега, поделился своими мыслями о настойчивости в работе. Осторожно, в его тексте присутствуют нецензурные слова! ;)
Хочу рассказать небольшую историю о настойчивости и терпении. Во времена debian-пакетов мы пользовались специальным сервисом Кондуктор для выкладки сервисов.
Я рассказывал о двух debian-пакетах для каждого сервиса:
1. "статика" для отображения в браузере;
2. "динамика" с серверным кодом.
Необходимо было соблюдать порядок выкладки для получения работающего сервиса: вначале "статика", потом "динамика".
Этот процесс нужно было постоянно контролировать вручную, и это утомляло. Я попросил разработчика сервиса Кондуктор поддержать возможность для того, чтобы автоматически выкладывать пакет с "динамикой" сразу после пакета со "статикой".
Диалог был примерно таким:
— А можешь поддержать последовательную выкладку пакетов?
— Прости, но у меня нет времени :(
— Понимаю. Но это поможет половине Яндекса...
(объясняю, почему это круто и как мы осчастливим много разработчиков)
— Хм. Я подумаю на досуге, можно ли это сделать.
— Когда тебе напомнить?
— Давай через месяц.
(прошел месяц)
— Удалось подумать?
— Нет, не было времени.
— Ничего страшного. Понимаю, что у тебя плотный график. Когда у тебя будет время?
— Месяца через два.
(прошло два месяца)
— Удалось найти время?
— Да, есть идея. Но нужно время, чтобы накидать прототип.
— Класс! А когда получится?
— Думаю, что через неделю.
(прошла неделя)
(еще две)
(месяц)
(полгода)
(год)
(я не сдавался)
(разработчик стал извиняться при встрече со мной в коридоре)
(разработчик не выдержал и все сделал)
В итоге через полтора года я добился желаемого. Но истинная причина была в том, что разработчик сам захотел исполнить свое обещание и уже не мог иначе. И да, я — страшно терпелив! :)
Мораль же проста: если вам что-то нужно и вы верите в это, то стойте на своем и не сдавайтесь при первом же отказе.
#байки
Хочу рассказать небольшую историю о настойчивости и терпении. Во времена debian-пакетов мы пользовались специальным сервисом Кондуктор для выкладки сервисов.
Я рассказывал о двух debian-пакетах для каждого сервиса:
1. "статика" для отображения в браузере;
2. "динамика" с серверным кодом.
Необходимо было соблюдать порядок выкладки для получения работающего сервиса: вначале "статика", потом "динамика".
Этот процесс нужно было постоянно контролировать вручную, и это утомляло. Я попросил разработчика сервиса Кондуктор поддержать возможность для того, чтобы автоматически выкладывать пакет с "динамикой" сразу после пакета со "статикой".
Диалог был примерно таким:
— А можешь поддержать последовательную выкладку пакетов?
— Прости, но у меня нет времени :(
— Понимаю. Но это поможет половине Яндекса...
(объясняю, почему это круто и как мы осчастливим много разработчиков)
— Хм. Я подумаю на досуге, можно ли это сделать.
— Когда тебе напомнить?
— Давай через месяц.
(прошел месяц)
— Удалось подумать?
— Нет, не было времени.
— Ничего страшного. Понимаю, что у тебя плотный график. Когда у тебя будет время?
— Месяца через два.
(прошло два месяца)
— Удалось найти время?
— Да, есть идея. Но нужно время, чтобы накидать прототип.
— Класс! А когда получится?
— Думаю, что через неделю.
(прошла неделя)
(еще две)
(месяц)
(полгода)
(год)
(я не сдавался)
(разработчик стал извиняться при встрече со мной в коридоре)
(разработчик не выдержал и все сделал)
В итоге через полтора года я добился желаемого. Но истинная причина была в том, что разработчик сам захотел исполнить свое обещание и уже не мог иначе. И да, я — страшно терпелив! :)
Мораль же проста: если вам что-то нужно и вы верите в это, то стойте на своем и не сдавайтесь при первом же отказе.
#байки
Дайджест 01.01.2024—31.03.2024
Раз в квартал я публикую дайджесты для быстрого доступа к старым постам.
Для удобства посты разбиты по категориям и отсортированы по алфавиту.
Аналитика
- Yandex Query Language
Байки
- Жалоба пользователя на прыгающую панель
- Как инженеры сваи забивали
- Про настойчивость и терпение
Инфраструктура
- YT — яндексовый MapReduce
Карьера
- Эмоциональный банковский счет
- Диверсификация счастья
- Почему карьерный рост такой непонятный
- Как подводить итоги года и ставить достижимые цели?
- Карты навыков ML-разработчиков и фронтендеров
- Принцип Парето, Мерфи, Паркинсона и Питера
Книги
- Рей Далио. Принципы
Новости
- Выставка роверов в Яндекс Музее
Руководство
- Тимлид — операционная система по Таненбауму
Цитатник
- Hairy Back Syndrome
Яндекс
- Выставка роверов в Яндекс Музее
#дайджесты
Раз в квартал я публикую дайджесты для быстрого доступа к старым постам.
Для удобства посты разбиты по категориям и отсортированы по алфавиту.
Аналитика
- Yandex Query Language
Байки
- Жалоба пользователя на прыгающую панель
- Как инженеры сваи забивали
- Про настойчивость и терпение
Инфраструктура
- YT — яндексовый MapReduce
Карьера
- Эмоциональный банковский счет
- Диверсификация счастья
- Почему карьерный рост такой непонятный
- Как подводить итоги года и ставить достижимые цели?
- Карты навыков ML-разработчиков и фронтендеров
- Принцип Парето, Мерфи, Паркинсона и Питера
Книги
- Рей Далио. Принципы
Новости
- Выставка роверов в Яндекс Музее
Руководство
- Тимлид — операционная система по Таненбауму
Цитатник
- Hairy Back Syndrome
Яндекс
- Выставка роверов в Яндекс Музее
#дайджесты
This media is not supported in your browser
VIEW IN TELEGRAM
Вчера мы запустили в Яндекс Картах — персонализированный режим «Идеи». Если вы из Екатеринбурга, Москвы, Новосибирска или Петербурга, то скорее открывайте мобильное приложение и пробуйте этот новый режим!
Внутри 16 ML моделей (!!!) по поиску заведений и учету предпочтений пользователей. И, конечно, YandexGPT для генерации описания мест на основе отзывов.
Пробуйте, пишите фидбек и помогите нам стать лучше!
#новости
Внутри 16 ML моделей (!!!) по поиску заведений и учету предпочтений пользователей. И, конечно, YandexGPT для генерации описания мест на основе отзывов.
Пробуйте, пишите фидбек и помогите нам стать лучше!
#новости
Не каждый день получаешь письмо с края света края Земли. Это письмо, на минуточку, преодолело тысячи километров до канцелярии Яндекса и в конечном итоге до меня.
Воистину маленькое чудо :)
#яндекс
Воистину маленькое чудо :)
#яндекс
Исторически мы с женой используем Flickr для хранения фотографий и накопили значительный семейный альбом, который очень не хочется потерять по воле случая.
Поэтому задумались, куда и как лучше зеркалировать фотографии для пущей сохранности. В рабочих проектах мы используем облачный S3 для хранения статических файлов. Один хороший SRE подсказал, что этот способ подойдет и для хранения фотографий — дешево и сердито.
С хранилищем определились. Теперь нужно понять, как перегнать данные из Flickr в S3. К слову, про "перегонку данных". А вы знали, что Amazon в течение нескольких лет предоставлял специальный сервис по миграции данных в датацентры Amazon с помощью... грузовиков? Но в итоге сервис не взлетел, вернее, не поехал :)
Мне не нужно перемещать петабайты данных, поэтому небольшой скриптик вполне подойдет. Высокоуровнево мне нужно сделать три шага:
1. Забрать данные через Flickr SDK.
2. Залить полученные данные в S3 Яндекс Облака через AWS SDK.
3. Написать небольшой скрипт с необходимой логикой.
После небольшой отладки скрипт заработал на моем ноутбуке. Но это только полдела. Необходимо, чтобы скрипт работал по расписанию без лишних затрат моей ментальной энергии.
Вот тут и пригодился мой NAS-сервер Synology. Обычно я его использую как хранилище для фильмов, но сервер способен решить и более интересные задачки:
1. С помощью docker-контейнера настроил окружение для своего скрипта.
2. Далее через встроенный механизм Task Scheduler настроил ежедневный запуск своего скрипта вот такой командой:
Не зря Рей Далио советует всем учить программирование. Программирование расширяет ваши возможности и позволяет эффективно решить прикладные задачи не только для рабочих, но и для личных нужд. Например, забекапить свои личные фотографии ;)
#разработка
Поэтому задумались, куда и как лучше зеркалировать фотографии для пущей сохранности. В рабочих проектах мы используем облачный S3 для хранения статических файлов. Один хороший SRE подсказал, что этот способ подойдет и для хранения фотографий — дешево и сердито.
С хранилищем определились. Теперь нужно понять, как перегнать данные из Flickr в S3. К слову, про "перегонку данных". А вы знали, что Amazon в течение нескольких лет предоставлял специальный сервис по миграции данных в датацентры Amazon с помощью... грузовиков? Но в итоге сервис не взлетел, вернее, не поехал :)
Мне не нужно перемещать петабайты данных, поэтому небольшой скриптик вполне подойдет. Высокоуровнево мне нужно сделать три шага:
1. Забрать данные через Flickr SDK.
2. Залить полученные данные в S3 Яндекс Облака через AWS SDK.
3. Написать небольшой скрипт с необходимой логикой.
После небольшой отладки скрипт заработал на моем ноутбуке. Но это только полдела. Необходимо, чтобы скрипт работал по расписанию без лишних затрат моей ментальной энергии.
Вот тут и пригодился мой NAS-сервер Synology. Обычно я его использую как хранилище для фильмов, но сервер способен решить и более интересные задачки:
1. С помощью docker-контейнера настроил окружение для своего скрипта.
2. Далее через встроенный механизм Task Scheduler настроил ежедневный запуск своего скрипта вот такой командой:
docker exec flickr-backup /bin/bash -c "SECRETS_PATH=/etc/flickr-backup/secrets.json node /usr/local/flickr-backup/index.js"
Не зря Рей Далио советует всем учить программирование. Программирование расширяет ваши возможности и позволяет эффективно решить прикладные задачи не только для рабочих, но и для личных нужд. Например, забекапить свои личные фотографии ;)
#разработка
Мне тут коллеги сказали, что я очень люблю "кружочки", т.к. при объяснении чего-либо часто рисую схемки — и кружочки, в частности.
На одной из встреч отдела я рассказывал о своем отношении к работе и о том, как неидеальную работу превращать в идеальную.
Тогда я поделился концепцией Стивена Кови про два кружочка:
- Красный кружочек "Круг забот" — то, что нас беспокоит, но повлиять на это мы не можем. Например, погода за окном.
- Зеленый кружочек "Круг влияния" — то, на что мы можем повлиять. Например, мигающая лампочка в подъезде.
Совет простой: растить зеленый кружочек и уменьшать красный :)
Не тратьте время и силы на то, что за пределами вашего круга влияния. Лучше сосредоточьтесь на том, что вы действительно можете изменить. И действуйте.
#карьера
На одной из встреч отдела я рассказывал о своем отношении к работе и о том, как неидеальную работу превращать в идеальную.
Тогда я поделился концепцией Стивена Кови про два кружочка:
- Красный кружочек "Круг забот" — то, что нас беспокоит, но повлиять на это мы не можем. Например, погода за окном.
- Зеленый кружочек "Круг влияния" — то, на что мы можем повлиять. Например, мигающая лампочка в подъезде.
Совет простой: растить зеленый кружочек и уменьшать красный :)
Не тратьте время и силы на то, что за пределами вашего круга влияния. Лучше сосредоточьтесь на том, что вы действительно можете изменить. И действуйте.
#карьера
Я уже рассказывал о том, что каждый сотрудник должен помогать бизнесу расти. Обычно компания часть своей заработанной прибыли отправляет на свое развитие и рост. Если компания остановится в росте, то погибнет в конкурентной борьбе.
Бизнес — агрессивная среда, напоминающая игру Agar.io, в которой кружочки борются за выживание. Бизнесы также объединяются, разделяются и "поедают" друг друга.
Соответственно, у бизнеса, как у организма, всего два пути:
1. Расширяться на своем локальном рынке.
2. Выходить на новые рынки.
Одна картинка стоит тысячу слов, поэтому делюсь с вами еще одной наглядной иллюстрацией вышеописанных слов. Опять кружочки :)
#карьера
Бизнес — агрессивная среда, напоминающая игру Agar.io, в которой кружочки борются за выживание. Бизнесы также объединяются, разделяются и "поедают" друг друга.
Соответственно, у бизнеса, как у организма, всего два пути:
1. Расширяться на своем локальном рынке.
2. Выходить на новые рынки.
Одна картинка стоит тысячу слов, поэтому делюсь с вами еще одной наглядной иллюстрацией вышеописанных слов. Опять кружочки :)
#карьера
Я часто повторяю один карьерный совет — уменьшайте, а не добавляйте головной боли вашему руководителю.
Обычно руководителям приходится держать в голове широкий контекст, и какие-то направления могут временно "проваливаться". По законам жанра, в момент максимальной загрузки руководителя к нему подходит сотрудник и спрашивает: "Ну, есть у нас что-то интересное поделать? А то я что-то заскучал". Джекпот! Плюс еще одна задачка для руководителя!
Многие руководители, и я среди их числа, желают совершенно иного. Например, когда сотрудник самостоятельно находит то, что выпало из поля зрения руководителя, и предлагает свою помощь. Тем самым прикрывает тыл своего руководителя и дает ему сосредоточиться на других важных вещах.
Или же приходит в качестве волонтера помочь ускорить ту самую медленную сборку проекта, от которой страдает вся команда. Сотрудник сам превращает проблему в амбициозную задачу или даже челлендж, а заодно и убирает часть головной боли руководителя.
Руководители всегда ценят таких сотрудников и стараются находить для них возможности для дальнейшего роста. Ведь нужна изрядная доля смелости, чтобы ввязаться в задачу со многими неизвестными. Если бы все было просто, ее бы уже давно сделали.
А если не знаете, что мучает вашего руководителя, то можно просто к нему прийти и задать вопрос: "Чем я могу тебе помочь? Есть ли что-то, до чего не доходят руки, но очень хотелось бы решить?" ;)
#менторство #карьера
Обычно руководителям приходится держать в голове широкий контекст, и какие-то направления могут временно "проваливаться". По законам жанра, в момент максимальной загрузки руководителя к нему подходит сотрудник и спрашивает: "Ну, есть у нас что-то интересное поделать? А то я что-то заскучал". Джекпот! Плюс еще одна задачка для руководителя!
Многие руководители, и я среди их числа, желают совершенно иного. Например, когда сотрудник самостоятельно находит то, что выпало из поля зрения руководителя, и предлагает свою помощь. Тем самым прикрывает тыл своего руководителя и дает ему сосредоточиться на других важных вещах.
Или же приходит в качестве волонтера помочь ускорить ту самую медленную сборку проекта, от которой страдает вся команда. Сотрудник сам превращает проблему в амбициозную задачу или даже челлендж, а заодно и убирает часть головной боли руководителя.
Руководители всегда ценят таких сотрудников и стараются находить для них возможности для дальнейшего роста. Ведь нужна изрядная доля смелости, чтобы ввязаться в задачу со многими неизвестными. Если бы все было просто, ее бы уже давно сделали.
А если не знаете, что мучает вашего руководителя, то можно просто к нему прийти и задать вопрос: "Чем я могу тебе помочь? Есть ли что-то, до чего не доходят руки, но очень хотелось бы решить?" ;)
#менторство #карьера
Проходя по коридору, я услышал разговор двух коллег:
— У меня слабоумие.
— Понятно. А я думаю, как мне попасть в пирожочки.
И с моими коллегами все в порядке. Просто один сказал, что у него следующая встреча в переговорке "Слабоумие и отвага", а другой искал переговорку "Пирожочки".
Но принцип именования в Яндексе всегда был и остается шедевральным :)
#яндекс
— У меня слабоумие.
— Понятно. А я думаю, как мне попасть в пирожочки.
И с моими коллегами все в порядке. Просто один сказал, что у него следующая встреча в переговорке "Слабоумие и отвага", а другой искал переговорку "Пирожочки".
Но принцип именования в Яндексе всегда был и остается шедевральным :)
#яндекс
Я периодически пишу про разработческую инфраструктуру. Все такие посты можно найти по тегу #инфраструктура.
Но инфраструктура может быть разной. В этом посте хочу вам рассказать, как у меня была устроена небольшая "финансовая инфраструктура" — автоплатежи за коммуналку с помощью дохода от облигаций.
Я назвал свой подход "финансовой водонапорной башней". В основе подхода — очень простая идея, но даже мой финансовый ментор удивился, когда узнал, как у меня все работает.
Уже несколько раз разным людям рассказывал, как у меня все было устроено, поэтому решил задокументировать, чтобы давать ссылку на этот пост :)
📖 Прочитать, что же такое финансовая водонапорная башня
#инфраструктура #финансы
Но инфраструктура может быть разной. В этом посте хочу вам рассказать, как у меня была устроена небольшая "финансовая инфраструктура" — автоплатежи за коммуналку с помощью дохода от облигаций.
Я назвал свой подход "финансовой водонапорной башней". В основе подхода — очень простая идея, но даже мой финансовый ментор удивился, когда узнал, как у меня все работает.
Уже несколько раз разным людям рассказывал, как у меня все было устроено, поэтому решил задокументировать, чтобы давать ссылку на этот пост :)
📖 Прочитать, что же такое финансовая водонапорная башня
#инфраструктура #финансы
Я очень люблю открытость не только в общении, но и в создаваемых решениях. Классно, когда про придуманные решения рассказывают на конференциях или митапах, а еще лучше, если выкладывают в opensource.
Моя платформа для блога также в опенсорсе. Пока у этой платформы только один пользователь — и я его ежедневно вижу в зеркале. Но лиха беда начало! :)
Очень круто, что Яндекс не только делает классные штуки, но и делится ими с сообществом. ClickHouse, CatBoost, YDB, YTsaurus и этот список можно продолжать и дальше.
Сегодня выложили алгоритм YaFSDP для ускорения процесса обучения больших языковых моделей. YaFSDP родился в процессе обучения нашей генеративной модели YandexGPT 3.
YaFSDP позволяет сэкономить затраты на оборудование, что особенно важно для стартапов и научных проектов. А любая экономия ресурсов приводит к дополнительному толчку в развитии нейронных сетей и больших языковых моделей, которые де-факто стали основой всех умных устройств и помощников.
Можно не разбираться в деталях, но вы просто полистайте пост на хабре. Выглядит фундаментально. Так и есть на самом деле :)
#новости
Моя платформа для блога также в опенсорсе. Пока у этой платформы только один пользователь — и я его ежедневно вижу в зеркале. Но лиха беда начало! :)
Очень круто, что Яндекс не только делает классные штуки, но и делится ими с сообществом. ClickHouse, CatBoost, YDB, YTsaurus и этот список можно продолжать и дальше.
Сегодня выложили алгоритм YaFSDP для ускорения процесса обучения больших языковых моделей. YaFSDP родился в процессе обучения нашей генеративной модели YandexGPT 3.
YaFSDP позволяет сэкономить затраты на оборудование, что особенно важно для стартапов и научных проектов. А любая экономия ресурсов приводит к дополнительному толчку в развитии нейронных сетей и больших языковых моделей, которые де-факто стали основой всех умных устройств и помощников.
Можно не разбираться в деталях, но вы просто полистайте пост на хабре. Выглядит фундаментально. Так и есть на самом деле :)
#новости
В мире управления проектов все знают о классическом треугольнике Качество. Скорость. Цена.
Высокоуровнево у каждого проекта есть три основных ограничения:
1. Бюджет.
2. Срок сдачи проекта.
3. Объем работ.
Чтобы выпустить проект с должным уровнем качества, менеджер либо сокращает количество задач в проекте, либо увеличивает бюджет, либо сдвигает срок сдачи.
Я, как руководитель команды разработки, смотрю на три высокоуровневые метрики для оценки работы отдела разработки:
1. Скорость производства (как быстро новые фичи доставляются до продакшена)
2. Качество (количество багов)
3. Надежность (uptime и #инциденты)
Команда — большой молодец, если быстро поставляет новые фичи с минимумом багов и без деградации в надежности сервиса. Легко сказать и сложно сделать :)
Расскажу про каждую из метрик в отдельных постах.
#разработка
Высокоуровнево у каждого проекта есть три основных ограничения:
1. Бюджет.
2. Срок сдачи проекта.
3. Объем работ.
Чтобы выпустить проект с должным уровнем качества, менеджер либо сокращает количество задач в проекте, либо увеличивает бюджет, либо сдвигает срок сдачи.
Я, как руководитель команды разработки, смотрю на три высокоуровневые метрики для оценки работы отдела разработки:
1. Скорость производства (как быстро новые фичи доставляются до продакшена)
2. Качество (количество багов)
3. Надежность (uptime и #инциденты)
Команда — большой молодец, если быстро поставляет новые фичи с минимумом багов и без деградации в надежности сервиса. Легко сказать и сложно сделать :)
Расскажу про каждую из метрик в отдельных постах.
#разработка
Я рассказывал, что процесс разработки можно представить в виде "релизной трубы" для трансформации продуктовых требований в готовые фичи в продакшене.
У этой релизной трубы есть две основные характеристики:
1. Диаметр (влияет на количество одновременных фичей в работе).
2. Скорость движения по трубе (как быстро происходит выпуск фичей).
Диаметр трубы можно расширить наймом дополнительных людей, но вот скорость так просто не увеличить. Нужно работать над эффективностью.
Сейчас мы меряем цикл тайм задач — сколько задача находилась в том или ином статусе. Например, время код ревью, время ожидания тестирования, время тестирования задачи — и сколько проходит времени до ее выкладки в продакшен.
Это позволяет выявить бутылочные горлышки, мешающие выпускать фичи быстрее.
DORA предлагает обращать внимание на две метрики:
1. Lead time — время от коммита до выкладки в продакшен.
2. Частота релизов — как часто сервис релизится в продакшен.
Lead time зависит от количества задач в работе и их правильной декомпозиции. Тут мне есть над чем поработать, т.к. периодически откусываю такой кусок, который с трудом могу прожевать :)
Частота релизов у нас колеблется от сервиса к сервису. Где-то мы релизимся каждый день или несколько раз в день, где-то — по мере накопления изменений. Но в итоге мы пришли к состоянию, что выкатить релиз — повседневная рутина.
#разработка
У этой релизной трубы есть две основные характеристики:
1. Диаметр (влияет на количество одновременных фичей в работе).
2. Скорость движения по трубе (как быстро происходит выпуск фичей).
Диаметр трубы можно расширить наймом дополнительных людей, но вот скорость так просто не увеличить. Нужно работать над эффективностью.
Сейчас мы меряем цикл тайм задач — сколько задача находилась в том или ином статусе. Например, время код ревью, время ожидания тестирования, время тестирования задачи — и сколько проходит времени до ее выкладки в продакшен.
Это позволяет выявить бутылочные горлышки, мешающие выпускать фичи быстрее.
DORA предлагает обращать внимание на две метрики:
1. Lead time — время от коммита до выкладки в продакшен.
2. Частота релизов — как часто сервис релизится в продакшен.
Lead time зависит от количества задач в работе и их правильной декомпозиции. Тут мне есть над чем поработать, т.к. периодически откусываю такой кусок, который с трудом могу прожевать :)
Частота релизов у нас колеблется от сервиса к сервису. Где-то мы релизимся каждый день или несколько раз в день, где-то — по мере накопления изменений. Но в итоге мы пришли к состоянию, что выкатить релиз — повседневная рутина.
#разработка
На вопрос "А у вас сервис — качественный?" можно получить совершенно разные ответы:
- от разработчиков можно услышать: "ничего критичного нет, остались минорчики";
- тестировщик возразит, что "у нас куча багов, которые не пофикшены с прошлого релиза";
- менеджер пожмет плечами: "основное работает, нам нужно новые фичи зарелизить".
Налицо "конфликт" субъективных мнений. Нетривиально понять, сколько времени нужно тратить на фиксы багов, а сколько — на дальнейшее развитие сервисов.
На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
1. Каждому открытому багу выставляется вес согласно критериям.
2. Подсчитывается сумма всех весов.
3. Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
4. На графике проводится горизонтальная линия "максимальной забагованности", которую нельзя пересекать.
Если график ZBP превысил допустимый уровень забагованности, то выделяется больше времени на фикс багов. Если график ZBP в пределах нормы, то можно спокойно пилить фичи.
В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000
Но лучше для разметки весов использовать более бизнес-ориентированные компоненты: важность юзкейса, процент затрагиваемых пользователей, "дыры" в безопасности, влияние на деньги и т.д.
А приоритет бага выставлять уже в зависимости от накопленного веса. Тогда будет меньше споров, почему один баг — минорный, а другой — критичный.
Невозможно найти все баги, и часть из них проскакивает наружу. Поэтому мы дополнительно считаем процент багов, найденных коллегами. Стремимся, чтобы этот процент был минимален :)
И отдельно, конечно, читаем фидбек и жалобы наших пользователей. У нашей команды саппорта также есть ряд метрик по скорости первого ответа, скорости решения проблем пользователей и т.д.
DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах
#разработка
- от разработчиков можно услышать: "ничего критичного нет, остались минорчики";
- тестировщик возразит, что "у нас куча багов, которые не пофикшены с прошлого релиза";
- менеджер пожмет плечами: "основное работает, нам нужно новые фичи зарелизить".
Налицо "конфликт" субъективных мнений. Нетривиально понять, сколько времени нужно тратить на фиксы багов, а сколько — на дальнейшее развитие сервисов.
На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
1. Каждому открытому багу выставляется вес согласно критериям.
2. Подсчитывается сумма всех весов.
3. Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
4. На графике проводится горизонтальная линия "максимальной забагованности", которую нельзя пересекать.
Если график ZBP превысил допустимый уровень забагованности, то выделяется больше времени на фикс багов. Если график ZBP в пределах нормы, то можно спокойно пилить фичи.
В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000
Но лучше для разметки весов использовать более бизнес-ориентированные компоненты: важность юзкейса, процент затрагиваемых пользователей, "дыры" в безопасности, влияние на деньги и т.д.
А приоритет бага выставлять уже в зависимости от накопленного веса. Тогда будет меньше споров, почему один баг — минорный, а другой — критичный.
Невозможно найти все баги, и часть из них проскакивает наружу. Поэтому мы дополнительно считаем процент багов, найденных коллегами. Стремимся, чтобы этот процент был минимален :)
И отдельно, конечно, читаем фидбек и жалобы наших пользователей. У нашей команды саппорта также есть ряд метрик по скорости первого ответа, скорости решения проблем пользователей и т.д.
DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах
#разработка
Помимо вопроса про качество сервиса, также важна его стабильность. Какой толк от качественного и хорошо протестированного сервиса, если он то работает, то нет?
В индустрии принято мерить доступность сервиса с помощью метрики 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 всем, кто заботится о надежности своего сервиса.
#разработка
В индустрии принято мерить доступность сервиса с помощью метрики 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 всем, кто заботится о надежности своего сервиса.
#разработка
Дайджест 01.04.2024—30.06.2024
Раз в квартал я публикую дайджесты для быстрого доступа к старым постам.
Для удобства посты разбиты по категориям и отсортированы по алфавиту.
Карьера
- Круг влияния и круг забот
- Наглядная картинка про рост бизнеса
- Уменьшайте головную боль руководителя
Новости
- Есть идея!
- Заопенсорсили YaFSDP
Разработка
- Метрики разработки
- Метрика скорости производства
- Метрики качества
- Метрики надежности
- Как я делал бекап фотографий
Финансы
- Принцип водонапорной башни в финансах
Яндекс
- Письмо с края Земли
- Разговор двух коллег
#дайджесты
Раз в квартал я публикую дайджесты для быстрого доступа к старым постам.
Для удобства посты разбиты по категориям и отсортированы по алфавиту.
Карьера
- Круг влияния и круг забот
- Наглядная картинка про рост бизнеса
- Уменьшайте головную боль руководителя
Новости
- Есть идея!
- Заопенсорсили YaFSDP
Разработка
- Метрики разработки
- Метрика скорости производства
- Метрики качества
- Метрики надежности
- Как я делал бекап фотографий
Финансы
- Принцип водонапорной башни в финансах
Яндекс
- Письмо с края Земли
- Разговор двух коллег
#дайджесты
Разговор на одной из калибровок:
— У тебя младший специалист на своем грейде уже 2 года. Нет заметного роста.
— Мне норм. У меня есть задачи для его грейда.
Может казаться, что в команде задачи только для младших специалистов. Но если такие задачи поручить старшим, произойдет маленькое чудо.
Старший специалист будет лениться решать простые задачи и либо решит "мета-задачу", либо создаст платформу, упрощающую их решение.
Получается win-win ситуация:
- сотрудники развиваются, решают все более сложные задачи и становятся ценнее на рынке
- руководитель получает более сильную команду и может делегировать ей все больше своих задач :)
Мой руководитель очень емко сформулировал идею выше: сдвигайте медиану компетенций вправо по линейке грейдов.
#руководство
— У тебя младший специалист на своем грейде уже 2 года. Нет заметного роста.
— Мне норм. У меня есть задачи для его грейда.
Может казаться, что в команде задачи только для младших специалистов. Но если такие задачи поручить старшим, произойдет маленькое чудо.
Старший специалист будет лениться решать простые задачи и либо решит "мета-задачу", либо создаст платформу, упрощающую их решение.
Получается win-win ситуация:
- сотрудники развиваются, решают все более сложные задачи и становятся ценнее на рынке
- руководитель получает более сильную команду и может делегировать ей все больше своих задач :)
Мой руководитель очень емко сформулировал идею выше: сдвигайте медиану компетенций вправо по линейке грейдов.
#руководство