Смерть от тысячи микросервисов

В подавляющем большинстве случаев микросервисы принесут вам намного больше проблем в долгосроке, чем пользы в краткосроке. Думаю, вы уже и сами видите, что хайп на микросервисы довольно сильно упал, и некоторые компании, которые смогли его пережить и не загнуться от счетов от AWS, уже пытаются собрать свои монолиты по кусочкам обратно. Самые смешные примеры – это, конечно, Uber, которые были евангелистами микросервисов много лет, и Amazon Prime, хотя казалось бы.

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

На глазок как методика оценки сроков

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

Чтобы такой подход сработал, важно соблюдать несколько правил:

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

Авито ищет сразу трёх тимлидов в разные команды. Ныряйте вниз за подробностями.

➡️ Тимлид разработки в команду маркетплейса
➡️ Тимлид разработки в команду «Запчасти и аксессуары»
➡️ Тимлид разработки в команду Data Quality

ЗП обсуждается с кандидатами лично, но вот что предлагают прямо сейчас:
• Талантливая команда и возможность реализовать свои идеи в проекте с многомиллионной аудиторией;
• Мощное железо, дополнительные мониторы и всё, что нужно для комфортной работы;
• Прозрачная система премий;
• Личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
• ДМС со стоматологией с первого дня;
• Замечательный офис в двух минутах от «Белорусской»: панорамный вид на центр города, места для уединённой работы и зоны отдыха.

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

Вакансия Team lead на Go от Ozon Tech

Команда rFBS Ozon Tech развивает формат взаимодействия Ozon с продавцами, при котором они сами хранят, формируют и доставляют заказы. А Ozon работает как витрина с десятками миллионов лояльных клиентов. Компания хочет порадовать пользователей новыми фичами уже в этом сезоне распродаж.

Чтобы достичь амбициозных целей, Ozon формирует новые команды. Сейчас они в поисках тимлида с опытом разработки на Go.

Их проект — это:
— Работа в одной из самых быстрорастущих вертикалей Ozon,
— Высокие нагрузки до 300k rps,
— Архитектурные вызовы в контексте масштабируемости сервисов,
— Быстрый time-to-market,
— Возможность работать из офисов России и Казахстана / удалённо / гибридно.

Стек: Golang, PostgreSQL, Kafka, gRPC.

Узнать подробности о проекте, вакансии, бенефитах и откликнуться можно на этом лендинге.

Техническая стратегия

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

Техническая стратегия – хороший инструмент для того, чтобы снять часть такой неопределенности. Автор статьи использует фреймворк из книги Good Strategy, Bad Strategy, но прикладывает его именно к специфическому кейсу инженерной стратегии. Если кратко, то ее структура такая:

🕵️‍♀️Диагноз – теория, объясняющая проблему, которую стратегия хочет решить.
👉Направляющая политика – набор принципов и трейдоффов, которые помогают двигаться к решению проблемы.
🗺️Согласованный план – конкретные шаги по решению проблемы, соответствующие направляющей политике.

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

Как руководителю не растерять технические навыки

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

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

Обновление роадмапа для продактов

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

Как и зачем менеджеру строить команду из своих пиров

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

Один из способов выйти из такого состояния – построить команду менеджеров-пиров (на русском языке звучит по-дурацки, но хорошего аналога не придумал). Например, из руководителей отделов, которые находятся напрямую под СТО. Эта команда должна быть сосредоточена на анализе общей картины происходящего в компании и на поиске решений для общих проблем. Вот какие плюсы можно получить:

👉Не нужно ожидать вмешательства или воли СТО для того, чтобы в компании происходили полезные изменения.
👉Улучшается обмен знаниями о лучших практиках, меньше делается велосипедов.
👉Менеджерам проще учиться друг у друга.

Как планировать рост размера команды

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

Топ-менеджер: что нужно руководителю в 2023

Руководить командой в турбулентное время, выводить бизнес на новый уровень и оставаться мотивационной моделью — та еще задача.

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

Все эти навыки можно прокачать на курсе «Эффективный руководитель» от ProductStar (группа компаний РБК).
Каждому студенту курса доступен индивидуальный план карьерного развития на шесть месяцев и поддержка ментора.

По промокоду ТОП55 действует скидка 55% и курс по Бизнес-английскому от AgileFluent в подарок.

Забронируй скидку:
https://go.productstar.ru/kh5nF6

Что делать, когда сотрудник просит прибавку

Стандартные ошибки, которве можно допустить:

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

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

💬Расскажите в комментариях про то, какие фейлы, связанные с обсуждением повышения зарплаты, были у вас!

Простой подход к приоритизации по cost of delay

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

1️⃣Выпишите на стикеры все инициативы, которые есть в бэклоге.
2️⃣Отсортируйте их по срочности вдоль горизонтальной шкалы. В этот момент вообще не надо думать о важности задачи, а сосредоточиться именно на том, насколько срочно ее надо сделать. По результату разбить всю шкалу на три сектора: Whenever, Soon и ASAP.
3️⃣Теперь отсортировать карточки по важности, уже вдоль вертикальной оси. Срочность остается фиксированной, менять ее нельзя. По результату собрать три категории: Tweak, Optimizer, Game Changer.
4️⃣По итогам предыдущих шагов у вас получилась матрица 3х3. Внутри каждой клетки выделите три сектора – 1-3 месяца, 1-3 квартала, 1-3 года. Подвигайте стикеры между ними, прикинув трудозатраты на каждую инициативу.
5️⃣Как результат, вы получили отсортированный по cost of delay бэклог. Посмотрите картинку к посту – зеленые секторы самые приоритетные, желтые – средненько, а на красные можно забить.

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

Новый выпуск подкаста “Бреслав и Ложечкин”

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

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

А если вы вдруг пропустили предыдущие выпуски, то вот их каталог:

🤝5: Делегирование
📊4: Performance management инженерных организаций
🤔3: Что должен уметь руководитель?
🎁2: Что является продуктом работы руководителя?
🔁1: Из эксперта в руководителя и обратно

Обсудить этот и другие выпуски можно в комментах в канале подкаста @breslavandlozhechkin.

Как общаться с топ-менеджерами

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

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

Почему компании загоняют людей в офисы

Рациональное объяснение от сотрудника Амазона:

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

Оба пункта в первую очередь про США, но для международных компаний политики часто становятся общими на все страны.

Что надо указывать в вакансии

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

👉Наличие зарплатной вилки не влияет на количество откликов в компаниях с больше 5000 или меньше 100 сотрудников.
👉В вакансиях с удаленкой конверсия в отклик в 2 раза выше. Особенно влияет на большие компании.

А сам чеклист вот такой:

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

История роли SDET в Microsoft

Рассказ про то, как в Microsoft появилась выделенная роль Software Engineer in Test, какие минусы она с собой принесла, и как через несколько лет от нее героически отказались и стали продуктивнее.

Подборка заметок про системный дизайн

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