Любой код когда-нибудь станет техдолгом

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

👴🏻Flash, Silverlight и Java апплеты умерли, как и код, написанный для них.
👴🏻Большая часть Objective-C кода с появлением и развитием Swift стала легаси.
👴🏻Стандарт OpenTelemetry сделал написанные ранее инхаусные библиотеки для трассировки неактуальными.

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

Российский скрам

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

Кроме рефлексии про полученный опыт, автор выделяет четыре особенности скрама, которые мешают ему прижиться в России в своей оригинальной форме:

1️⃣Отсутствие роли руководителя
2️⃣Слишком сильная ритуальность
3️⃣Неопределенность роли скрам-мастера
4️⃣Скрам – слишком потогонная система

Отличный пример лендинга для найма от Авито

Сразу предупреждаю – это не реклама, постить лендинг меня не просили, и тут он исключительно потому, что очень сильно мне понравился!

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

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

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

Итак, ты стал(а) тимлидом. Что было дальше?

14 июня в 19:00 ребята из СберМаркета приглашают всех тимлидов и тех, кто хочет ими стать, на митап в Москве. Расскажут про тимлидские боли и поделятся историями о развитии карьеры.

Что будет на митапе?

📝 «Как тимлиду стать Engineering manager’ом» от Сергея Яныкина, engineering manager в CберМаркете.
📝 «Деление клеток, или Как плавно делить команду и не убить её при этом» от Алексея Партилова, тимлида в СберМаркете.
📝 Public talk «Как сделать твою команду эффективной» c Engineering manager’ами СберМаркета и ведущими подкаста «Для tech и этих».

Регистрация по ссылке, количество мест в офлайне ограничено.

Эволюция управления процессом разработки во Фланте

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

Вот основные идеи, к которым пришла команда:

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

Интервью по System Design — это обязательный этап собеседований в большие технологические компании уровня FAANG, по результатам которого принимается финальное решение о найме.

Но на русском языке почти нет материалов для комплексной подготовки!

Поэтому Валерий Бабушкин, Vice President, Data Science в Blockchainꓸcom, и Евгений Нижибицкий, Lead Machine Learning Engineer в AliExpress, создали свой авторский курс, где вы научитесь выстраивать сложные и масштабируемые архитектуры программных систем.

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

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

Записывайтесь на курс по ссылке до 19 июня! Ждём вас!

Техника обучения Фейнмана

Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:

1️⃣Запишите все, что вы знаете о теме, как будто вы объясняете ее кому-то.
2️⃣Отметьте все пробелы в рассуждениях, и вернитесь к изучению темы, пока не закроете их.
3️⃣Переписывайте свое объяснение, заменяя сложные идеи более простыми, пока оно не станет очевидным.

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

Вебинар про карьерный рост продактов

Если есть профессия с еще более беспорядочным набором ожиданий и отличием роли от компании к компании, чем тимлид, так это продакт. Где-то от тебя требуется быть мини-СЕО (материальная компенсация при этом забывает про «СЕО», но не забывает про «мини»). Где-то – ты слепо перемалываешь поставленные кем-то задачи в разработческий бэклог. А где-то – исследуешь, как принести ценность пользователям и бизнесу. Короче, разные ожидания, разные навыки, и совсем разные карьерные пути.

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

Мне нравится, что все спикеры – СРО, а, значит, успели и за свою карьеру повидать всякое, и других продактов вырастить:
— Сергей Ершов, CPO СберОбразования.
— Максим Гришак, CPO Домклик от Сбера, лидер направления небанковских сервисов в недвижимости.
— Женя Агеев, CPO в стриме «Государственные услуги» в ВТБ
— Игорь Мелех, Head of Рroduct в Ozon, Автор телеграм-канала «MVP из палок».

📆Дата: 13 июня, 19:00
👉Регистрация

Как использовать Definition of Ready

Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.

Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.

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

Но проблем от использования DoR в таком формате больше, чем пользы. Вместо итеративной разработки фичи с быстрым фидбэком DoR провоцируют появление этапов работы. Условно говоря, вместо совместной работы разработчика и дизайнера над фичой, у нас появляется два этапа – дизайн и имплементация, между которыми появляется дополнительный гейт в виде ревью макетов. Если макеты не соответствуют DoR, работа над фичей не начинается, пока дизайнер не внесет все правки. А это, конечно, сильно увеличивает среднее время разработки.

Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:

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

Причины плохого перфоманса

1️⃣Сотрудник плохо перформит, потому что вы поставили его на неподходящую ему роль.
2️⃣Сотрудник только вышел на новую роль, на него свалилось много всего неизвестного, и он не справляется из-за переизбытка информации.
3️⃣Причины кроются где-то в личных или семейных событиях.
4️⃣У вас есть неявные ожидания от роли сотрудника, а он привык работать по-другому.
5️⃣Люди меняются, и роли, которые им подходили раньше, могут переставать подходить со временем.

“Анти-требования” для модели данных

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

Распилить модель правильным образом могут помочь “анти-требования”. Идея такая – вы формулируете фейковое бизнес-требование, влияюбщее на отношения атрибутов, и оцениваете его адекватность. Например, “Когда описание товара длиннее 5000 символов, его цена должна измениться на 20%”. Если требование звучит неадекватно – нет никакой необходимости держать эти атрибуты в рамках одной сущности. Если звучит адекватно – связь есть, нужно выделять в отдельную сущность.

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

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

Challenges -> Concerns -> Problems -> Barriers

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

Ищут Тимлида в Облако Selectel.

Тимлид в Selectel это

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

Откликнуться можно тут
По вопросам можно писать сюда

Подробный обзор системы грейдов в Shopify

Shopify зарефакторили свою систему грейдов. Основные идеи следующие:

- Всего у инженеров восемь грейдов, от стажера до fellow.
- Каждый грейд разделен на пять сегментов по “mastery”. Mastery – это технические навыки и доменные знания, получаемые сотрудником по мере приобретения опыта.
- Mastery отдельно оценивается по пяти характеристикам: технические знания, решение задач, принятие решений, лидерство.
- Переход между уровнями не завязан на mastery. Это просто еще одна проекция, в рамках которой можно расти в зарплате, не беря на себя новую ответственность.

Вторая часть обзора системы грейдов в Shopify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

👉Сотрудники сами выделяют, какой процент компенсации получать деньгами, а какой – акциями. Вот тут есть больше деталей.
👉Уровни зарплаты привязаны к локации.
👉По фидбэку сотрудников, появление шкалы Mastery позволяет не ломиться вверх по карьерной лестнице, а спокойно жить обычным сеньором, и постепенно расти в зарплате.

Вторая часть обзора системы грейдов в Spotify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

👉Сотрудники сами выделяют, какой процент компенсации получать деньгами, а какой – акциями. Вот тут есть больше деталей.
👉Уровни зарплаты привязаны к локации.
👉По фидбэку сотрудников, появление шкалы Mastery позволяет не ломиться вверх по карьерной лестнице, а спокойно жить обычным сеньором, и постепенно расти в зарплате.