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

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

Как работать с риском

Начало обещающей быть очень классной серии статей про управление рисками. Вот некоторые из идей оттуда:

👉Чтобы оценить риск, надо отдельно смотреть на его импакт, и на вероятность его реализации. В большинстве случаев подробная численная оценка вам не нужна, и достаточно сравнительной оценки рисков по матрице 2х2 или 3х3. А если хочется закопаться, то вот офигенный учебник с примерами.
👉Действия для митигации риска чаще всего касаются одной из шкал – вы либо уменьшаете импакт, либо вероятность. Для митигации реальных сложных рисков обычно приходится двигать его сразу по обеим шкалам несколькими действиями.

Виноваты процессы, а не люди

По словам Деминга в 94% проблем компании виновата система, и только в остальных 6% – люди.

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

Про бесполезность еженедельных командных созвонов

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

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

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

Новые выпуски тимлидских подкастов

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

Рабочие группы как инструмент принятия решений

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

В статье предлагают решать эту проблему выделением рабочих групп:

👉Сначала формируется бэклог всех нерешенных вопросов на уровне компании, гильдии или другой горизонтальной структуры.
👉Раз в какое-то время этот бэклог приоритизируется на общем собрании лидов.
👉Каждому вопросу из топа выделяется небольшая рабочая группа из 3-5 человек, из их же числа выбирается руководитель. Рабочая группа отвечает за то, чтобы детально разобрать вопрос и приготовить прототип решения.
👉Прототип ревьюится общим собранием, собирается обратная связь, рабочая группа дорабатывает решение и заходит на еще одну итерацию.

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

Живая запись Бреслава и Ложечкина в Лондоне

Мы решили попробовать сделать классную штуку – организовать живую запись подкаста "Бреслав и Ложечкин" в Лондоне. Помимо самой записи обязательно будет интерактив с гостями и куча организованного нетворкинга.

Если вы живете в UK, то вам надо сделать две вещи:
👉Заполнить форму, чтобы мы могли понять интерес и выбрать площадку
👉Забронировать в календаре 18 марта
👉Отложить что-то около 20-40 фунтов на входной билет

Простая памятка про managing up

Ваш менеджер не должен переживать о чем-то в вашей зоне ответственности сильнее, чем вы.

Основных идей за этим правилом две:

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

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

Как определять SLO

Если вы не знакомы с термином, то SLO расшифровывается как Service-Level Objectives. Это набор целей, которые вы ставите перед надежность вашего продукта. Так вот, держите по ссылке хороший подробный гайд, как с ними работать. Если кратко, то алгоритм такой:

1️⃣Определите самые важные пользовательские сценарии
2️⃣Определите SLI, service-level indicators, которые описывают надежность этих сценариев
3️⃣Выберите целевые показатели, в которых эти SLI должны находиться. Помните, что они должны быть реалистичными.
4️⃣Заложите бюджет на ошибки – проседание этих индикаторов, которое может быть более-менее нормально воспринято пользователями. Его можно расчитать, как процент измерений ваших SLI за какой-то промежуток времени, в который они не попадают в SLO.

Дорофеев про прогнозирование сроков

Очень старый, но все еще бесконечно актуальный доклад Максима Дорофеева про то, как заниматься оценкой сроков в Scrum и Kanban: статистические методы, карты Шухарта и люди-снежинки с руками из жопы.

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

Так вот, мы прямо сейчас стартуем новогодний стрим Подлодки, где не только будем делиться разными полезными штуками, но и разыграем этот самый планшет, так что подключайтесь!
🎄Стрим на YouTube

Лучшие посты за 2024

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

👭Команда
Как проводить оффбординг
Эффект IKEA
Как выражать признание другим людям
Экономия на зарплате вредит бизнесу
Осмысленные карьерные разговоры
Запугивающие вопросы
Про удержание сотрудников

↔️Процессы
Советы по управлению долгими проектами
Как писать статус-репорты
Гайд по внутренним коммуникациям
Очередь задач вместо сторипойнтов
20% на техдолг не работают
Парадокс Тога

🥰Культура
Эффект Мертвого моря
Критика современной культуры менеджмента
Как не терять контакт с реальностью
Культурный контракт с сотрудником
Опасность метрик в менеджменте

🤝Найм
Гайд по поиску работы engineering manager
Рекрутеров можно заменить броском монеты

✨Личная эффективность
Практики таймменеджмента, которые работают
Аудит своей занятости

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

Что вы думаете про открытые зарплаты

Я к идее открытых зарплат отношусь скорее негативно:

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

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

Последняя часть цикла про командообразование

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

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

Что делать, когда вас окружают идиоты

Мой рецепт – сразу же вспомнить про фундаментальную ошибку атрибуции:

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

В статье заходят немного с другой стороны, но с тем же самым результатом:

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

PR/FAQ про AWS Lambda

В Amazon очень сильно развита культура письменных коммуникаций. В частности, обсуждение любой идеи нового продукта или фичи начинается с детально описанного документа, известного под названием PR/FAQ. В чем суть – вы пишете пресс-релиз так, как будто продукт уже вышел, включая туда понятное читателям описание сценариев его использования, преимуществ перед конкурентами, и даже цитаты счастливых пользователей. Помимо пресс-релиза, туда же вы включаете ответы на самые частые вопросы, которые раскрывают уже более глубокие темы как с точки зрения пользователей, так и с точки зрения бизнеса.

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

3X Framework – Explore/Expand/Extract

Все вы знаете Кента Бека как автора XP, одного из подписавших Agile манифест и громкого сторонника TDD. Но помимо всего этого, у него много других классных статей и мыслей.

Одна из моих любимых – про фреймворк 3Х, который очень простым способом объясняет основные стадии жизни продукта и то, как они влияют на подходы к разработке:

1️⃣Explore. Этап прототипирования, когда вы только пытаетесь нащупать рабочую идею, которая получит отклик у пользователей. Правильная стратегия разработки на этом этапе – максимально снижать стоимость экспериментов, и запускать их как можно больше.
2️⃣Expand. Product/market fit нашелся, пошла фаза быстрого роста. В этот момент основной фокус разработки должен быть на поиске бутылочных горлышек в технологиях, процессах и команде, потому что именно они могут остановить рост.
3️⃣Extract. Проблемы роста решены, формула продукта в целом понятна. Теперь вы превращаете создаваемую им ценность в деньги. И тут фокус смещается на устойчивость, снижение костов разработки и поддержки, и вот все то, чем мы любим заниматься в бигтехе.

Какие ключевые мысли дает эта модель:

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

Ретроспектива произошедшего с LLM в 2024

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

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

👉Инференс стал дешевле на порядок, вызов младших моделей теперь стоит совсем копейки
👉Размер контекста существенно вырос
👉Локально можно запускать довольно мощные модели, сравнимые с GPT-4
👉Тренировка на синтетических данных работает, причем иногда лучше, чем на органических
👉В целом плато способностей LLM, которым периодически любят пугать, пока не видно
👉Генерация простых веб-приложений из промптов стала сравнительно неплохо работать
👉Использовать LLM обычному пользователю все труднее, нужно больше знаний об их устройстве, ограничениях и доступной инфре, чтобы добиваться нормальных результатов