#кейс_стади
Задача на подумать для менеджера. Итоги эксперимента

Привет, читатель!

Как ты уже, наверное, заметил, последние 5 рабочих дней я публиковал каждый день с утра по одной управленческой задаче. Это был экспериментальный контент. Хотелось проверить, зайдёт ли такой формат, оживит ли он активность в канале и не станет ли мне накладно его писать

Спойлер: "накладно не стало!" Более того, я пишу посты примерно на неделю вперёд, и проблема скорее в том, чтобы выбрать из кучи тем для кейсов, чем придумывать что-то новое

Теперь к сути. Перед запуском этого эксперимента у меня было несколько гипотез:

1. Если выпускать задачи утром (в районе 9–10 по Москве), это будет удобно для аудитории. Думал, что такой тайминг даст 2–3% прироста вовлечённости;
2. Ежедневный контент покажет, что канал более живой и активный чем обычно. Это должно было привлечь новых подписчиков — хотя бы на 20–30% больше обычного;
3. Если публиковать кейсы в формате открытых вопросов, это увеличит количество реакций и комментариев.** Ожидал прироста на 20% день ото дня.

Что же получилось на практике?


1️⃣ Утренний тайминг
Утро оказалось действительно удобным временем. Большинство просмотров собирается в первые 1–2 часа после публикации (до 57% от общего охвата). Но, увы, прироста вовлечённости на 2–3% не случилось. ERR держится в привычном диапазоне 16–24.8%.

2️⃣ Ежедневные посты
Тут интересно. Активность подписчиков стабильна, но бури новых подписчиков не случилось. За месяц +14 человек — это примерно в рамках стандартного роста. То есть аудитория оценила регулярность, но это не сделало канал виральным

3️⃣ Формат открытых кейсов
Комментарии есть, но их мало (0–2 на пост). Реакций тоже немного (в среднем 12–20). Ожидаемого прироста на 20% не произошло. Видимо, чтобы разговорить аудиторию, нужно искать другие подходы — пока этот формат работает, но без фейерверков

Дополню двумя наблюдениями

4️⃣ Длина постов.
Я пробовал оставлять задачи максимально лаконичными, без лишней воды. И это сработало. Длинные кейсы не дали никакого прироста в охвате или вовлечённости. Короткие формулировки удобнее воспринимаются.

5️⃣ Регулярность
Честно, ежедневный постинг требует дисциплины, но для меня это пока нормально. Заметил, что слишком частые публикации (каждый день) могут слегка "примелькаться", и ERR остаётся на том же уровне, что и при менее частом постинге. Может, стоит подумать над форматом "пост через день" или миксовать с чем-то большим и более глубоким

А теперь мне интересно твоё мнение! Понравился ли тебе этот эксперимент с задачами? Стоит ли продолжать?

👉 Оставить детальную обратную связь можно по этой ссылке

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

P.S. Что будет дальше - я возьму паузу до конца недели собрать обратную связь и подумать что делать с форматом. А еще вечером сегодня запущу новый, также ради теста!

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

#напутствие
Еще новый тип постов

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

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

#напутствие
Почему я работаю менеджером

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

#напутствие
Почему я работаю менеджером

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

#мнение
Опять про сторипойнты и эти оценки из agile

Здравствуй, читатель! Почему относительные оценки — не серебряная пуля, но работают (иногда)

Когда речь заходит об оценке задач в а-жаль, всегда найдутся те, кто скажет: "Story Points спасут мир!". Смотри, это точнее, проще, удобнее! А абсолютные оценки (в часах или днях) — прошлый век. Давай в очередной раз разберемся: так ли это на самом деле?

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

Почему Story Points не идеальны?

1) Неточность заложена в подход

Оценки всегда субъективны. Что абсолютные, что относительные. Разница лишь в том, что Story Points маскируют вашу неуверенность под "умные" числа. И ими проще отбиваться от чрезмерного микроменеджмента. Как выяснилось из исследования https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3333, опыт команды почти не влияет на точность. Даже эксперты могут ошибаться — просто чуть реже, чем новички;

2) Они не универсальны

Если вы работаете с новичками, они могут переоценивать простые задачи и недооценивать сложные. Если команда не привыкла к Story Points, результат будет таким же хаотичным, как и при абсолютных оценках;

3) Игра в покер — это не всегда весело

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

Но у них есть плюсы. И важные:

1) Они учат команду думать вместе

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

2) Они помогают избежать споров про часы

Story Points не про время, а про усилия. Это убирает ненужные разговоры вроде: "Как ты можешь делать эту задачу 8 часов, если я бы сделал за 3?";

3) Они проще адаптируются под реальность

Если что-то пошло не так (а в Agile это почти гарантировано), Story Points легче перенастроить, чем абсолютные оценки;

4) Они делают планирование менее неприятным

Никто не уходит с планирование с ощущением, что ему "выставили счёт". Все понимают (если это адекватно внедрено), что оценки — это инструмент, а не правда в последней инстанции.

Что важно помнить, работая с Story Points?

1. Planning Poker — это не про числа, а про общение

Не нужно затягивать процесс. Если вся команда согласилась на одну оценку — не тратьте время, идите дальше;

2. Делайте ретроспективы оценок

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

3. Не превращайте Story Points в часы

Как только начнёте говорить "1 SP — это примерно 2 часа", весь смысл метода исчезнет;

4. Сравнивайте внутри спринта

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

На эту тему я уже писал раньше:
- Почему Story Points — это не ловушка https://t.me/junior_pm/99
- В целом про оценки https://t.me/junior_pm/167

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

P.S.
Story Points — это не серебряная пуля. Но если использовать их правильно, они делают команду сплочённой, а процесс оценки — осознанным и менее токсичным. А если вы ещё не пробовали Planning Poker — самое время начать.

Что думаете? Как у вас проходят оценочные сессии? Делитесь опытом в комментария

#напутствие
Почему я работаю менеджером

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

#напутствие
Почему я работаю менеджером

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

#рецепты
Вводим больше бюрократии с помощью DoD. Часть 1

Здравствуй, читатель!
Последние полгода я, признаться, выключил DoD из наших процессов. Причина — бизнес-критикал кейсы, которые требовали моего максимального вовлечения. Иногда я работал буквально как эникейщик: от настройки инфраструктуры до тестирования багов. Мы даунгрейдили процессы ради выживания. Теперь же я возвращаю DoD и хочу рассказать, почему это намой взгляд важно

Сперва как обычно немного теории, чтобы выровняться и говорить на одном языке

Что такое DoD?

Definition of Done — это минимальные требования, которые должны быть соблюдены, чтобы задача считалась выполненной. Это не про конкретную задачу, а про общий стандарт качества. DoD отвечает на вопрос: как мы поймём, что работа сделана качественно? Например: тесты пройдены, документация написана, код соотв. принятому стилю. Если DoD выполняется по всем задачам, можно “почти быть уверенным” в качестве итогового продукта

Махровая теория: quality gate и shift left

DoD — это часть двух больших концепций: quality gate и shift left. Quality gate — это контрольные точки, где проверяется качество на каждом этапе работы. Shift left — это перенос проверок качества на более ранние стадии, чтобы выявлять проблемы как можно раньше. В этом контексте DoD — это финальный quality gate, который гарантирует, что результат полностью готов

Чем отличаются DoD, DoR и AC?

Их часто путают. Хотя все три — это quality gate, их роли различны:

- DoR (Definition of Ready): требования к задаче, чтобы её можно было начать. Если задача переходит от менеджера к команде, то DoR — это чеклист для менеджера. Например, задача должна быть чётко описана, иметь все входные данные и учтённые зависимости;
- AC (Acceptance Criteria): требования к тому, как должен вести себя результат задачи. Это простой перечень того, что результат должен уметь, чтобы заказчик сказал: «Да, это то, что мне нужно»;
- DoD: критерии, которые показывают, что задача выполнена с должным качеством. Это не только про соответствие ТЗ, но и про тесты, документацию, ревью — всё, что делает результат стабильным и готовым к использованию.

Почему DoD — «дорогая» практика?

DoD — это инвестиция, которая требует усилий.

1. Ресурсы. Нужно время на написание тестов, документации, проведение ревью;
2. Замедление работы. На первых этапах команда работает медленнее, но это снижает количество багов в будущем;
3. Повышение планки. Например, если в DoD прописано писать юнит-тесты или релиз-ноутсы, команда должна этому научиться;
4. Долгосрочная выгода. В будущем DoD снижает затраты на доработки, стабилизирует продукт и улучшает отношения с заказчиками.


В следующем посте я расскажу, как мы вернули DoD, какие шаги предприняли и какие трудности пришлось преодолеть

P.S. Если хочешь вспомнить и другие похожие аббревиатуры, загляни в https://t.me/junior_pm/35 😉
P.P.S. А еще мы решили вернуть DoD потому что стали забывать некоторые важные вещи делать и он позволяет не забывать

#полезности
Вводим больше бюрократии с помощью DoD. Часть 2

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

1. Собери команду. Важно, чтобы разработчики, тестировщики, менеджеры и любые другие ключевые участники обсудили, что они понимают под «готовностью»;
2. Проведи воркшоп. Вместе составьте список минимальных требований для всех типов задач (баги, фичи, техдолг). Это должна быть командная работа, чтобы все приняли DoD как свой инструмент. Важно учесть что для разных типов работы может быть разный DoD. Мы пока сделали только для фичей;
3. Протестируй DoD. Введите его на несколько спринтов, фиксируя проблемы и улучшения;
4. Закрепите DoD. После тестирования утвердите DoD как обязательный стандарт.

Важно, чтобы DoD пересматривался на ретроспективах (если их нет, то вообще была опция его обсудить и пересмотреть). Это живой документ,

Почему DoD должен охватывать весь процесс команды, а не только финальный этап

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

Пример: если DoD охватывает только тестирование и релиз, никто не проверит читаемость и адекватность на код-ревью. Как результат, вероятность ошибки потом при апдейтах новой фичи сильно возрастет

DoD должен покрывать весь процесс. Условно:

- Стадия планирования: план разработки, систем ревью. Тут важно держать баланс с DoR;
- Стадия разработки: код проверен и покрыт тестами;
- Стадия тестирования: все критичные дефекты устранены;
- Стадия релиза: релиз-ноутсы оформлены и фича работает на проде.

Такой подход предотвращает «эффект снежного кома», когда небольшие недочёты превращаются в крупные проблемы.

Наш текущий DoD:

Вот текущий DoD, который мы используем в моей команде:

- Фича-флаг Firebase (если применимо);
- Ремоут-конфиг Firebase (если применимо);
- Диплинк (если применимо);
- Написан юнит-тест или заведена задача на его написание;
- Описание, как ревьюить;
- Описание, как тестировать;
- Заполнен дев-компонент;
- MR направлен в корректную ветку;
- Пройден код-ревью;
- QA обеспечивает тестовое покрытие (тест-кейс, чек-лист и т.д.);
- Задача протестирована, есть комментарий с результатом;
- MR влит в корректную ветку.

Это не-универсальный набор для любой задачи, пока только для сторей

Как я устанавливал и дорабатывал DoD заново

После периода «выключения» DoD я начал возвращать его шаг за шагом.

1. Анализ ситуации. Я оценил, почему прошлый DoD не сработал, и какие элементы команды были не готовы соблюдать. Например, отсутствие знаний в написании тестов или отсутствие документации. В нашем случае он был слишком абстрактным и неконкретным;
2. Собрание команды. Мы провели (и еще проведем) несколько встреч, где обсудили ценность DoD и его влияние на продукт. Важно было убедить команду, что DoD — это не просто бюрократия, а инструмент, который помогает;
3. Постепенное внедрение.** По-хорошему стоит добавлять элементы DoD не сразу, а поэтапно. Сначала — ревью, потом написание мануал тестов, затем тесты документации и так далее. Это позволит избежать перегрузок команды одномоментно;
4. Регулярные проверки. Мы обсуждаем, что работает, а что — нет. Некоторые пункты придется доработать. Например, упростить требования к юнитам;
5. Закрепление. После тестового периода я закреплю DoD как обязательный стандарт. Но уже он — неотъемлемая часть наших процессов.

В общем в лучших традициях ADKAR

#иное
Итоги эксперимента с задачками и напутствиями

Последний месяц я тестировал два новых формата контента:
1. Управленческие задачи (#кейс_стади) — короткие кейсы для размышления
2. Напутствия (#напутствие) — мои поддерживающие мысли о работе, управлении и бытии руководителем

Эксперимент получился интересным, но не всё зашло так, как хотелось.

Что с задачками
Ежедневный формат не сработал так, как я рассчитывал.

— Усталость аудитории: многие отключили уведомления, часть подписчиков просто перестала читать;
— Комментариев и реакций оказалось меньше, чем ожидалось: 2–5 комментариев, 12–20 реакций на пост;
— Тайминг с утра работает: 57% просмотров в первые два часа, но вовлеченность не выросла.

Что меняю:
— Больше не каждый день, а 2–3 раза в неделю

— Буду разбирать решения и показывать своё мнение через 1–2 дня после кейса

— Добавлю голосования и варианты решений

Что с напутствиями
Этот формат работает лучше.

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

Что меняю:
— 1 раз в неделю, а не чаще
— Добавлю больше историй из жизни и работы

— Чередую стили: не только мотивация, но и ошибки, инсайты, неожиданные выводы

Адаптированный контент-план

📌 Понедельник — управленческая задача, голосование, обсуждение
📌 Вторник — разбор кейса;
📌 Среда — напутствие;
📌 Четверг — что-то еще;
📌 Пятница — напутствие.

Протестирую этот формат 2 недели, потом соберу обратную связь. Между ними нерегулярные средние посты и крупные. Пока я попробую еще себя в эссе и сторителинге.

Если есть мысли или предложения — пиши в комментарии!

#рецепт
Cписок книг для начинающих менеджеров проектов

Привет, читатель

Я принес для тебя еще чтиво, правда, не мое, но очень уважаемых товарищей. Если ты уже умеешь ставить задачи в Jira, но не понимаешь, почему все застряло в «in progress» на третью неделю — возможно, дело не в Scrum, Kanban или волшебных методологиях, а в фундаменте.

В статье на habr, linkedin или vc можешь прочитать подробнее, а здесь будет выдержка.

Представляю 10 книг, которые помогут прокачать базу:

📌 «Общее и промышленное управление» — Анри Файоль

Файоль выделил 5 функций менеджмент*: планирование, организация, руководство, координация и контроль. Это не скучная теория, а каркас, на который ложатся все современные практики управления.

📌 «Принципы научного управления» — Фредерик Тейлор

Как выжать максимум из системы? Тейлор заложил основы эффективности, которые работают даже сейчас (с огромными оговорками, но он прадедушка, его знать надо).

📌 «Эффективный руководитель» — Питер Друкер

Главный вопрос Друкера: «Что делает менеджера по-настоящему эффективным?». Книга поможет не путать «занятость» с результативностью.

📌 «Динамика администрирования» — Мэри Паркер Фоллетт

Если Друкер — про эффективность, то Фоллетт — про лидерство и влияние. Классика, которая объясняет, как управлять не командуя, а направляя.

📌 «Экономический контроль качества продукции» — Уолтер Шухарт

Контроль — не про отчеты ради отчетов, а про предотвращение проблем, а не героическое их тушение.

📌 «Управление проектами: быстрый старт» — Дмитрий Завертайлов

Практическое руководство: как стартовать проект без погружения в теоретические дебри.

📌 «Канбан Метод. Базовая практика» — Алексей Пименов

Как сделать так, чтобы Kanban не превратился в «вот тебе доска, и сам разбирайся».

📌 «Антихрупкость в IT» — А. В. Бындю

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

📌 «OKR. Инструмент, который изменит вашу компанию» — Нивен, Ламорт

Не «давайте придумаем KPI», а как действительно ставить осмысленные цели.

📌 «Коучинг agile-команд» — Лисса Адкинс

Scrum-мастерам и agile-менеджерам сюда. Про командную динамику, рост специалистов и эффективное лидерство.

Вывод:

Фреймворки и методологии — это инструменты. Но если не понимать зачем, любые Agile-практики превращаются в пляску с бубном. Освой базу, и тогда ты сам будешь решать, какой метод выбрать: кроль, брасс или баттерфляй.

P.S. Да, все эти книги читаются не за один вечер, но PM без базы — это Моисей без скрижалей
P.P.S. Дополнительно советую еще 2 книги: «Проджект-менеджер маминой подруги» — Семена Колосова (кстати там есть небольшой фрагмент от меня) и «Карьера менеджера IT-проекта...» — Г. Лакман Макдауэлл, Д. Баваро, что также будет очень полезно до начинающих/

#кейс_стади
Задача на подумать для менеджера

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

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

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

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

Ты обсуждал с Вадимом эту ситуацию. Он соглашается, что "не все идеально", но добродушно утверждает, что всё исправится. Каждый раз, когда что-то идет не так, он говорит: *«Разберусь»*, но ты не видишь, чтобы он брал на себя реальную ответственность или предпринимал системные шаги для решения проблем. Он скорее тушит пожары, чем предотвращает их

Ты уже попробовал несколько способов изменить ситуацию:

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

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

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

P.S. Весь ваш фидбэк учел и кейсы будут более конкретными, редкими, с вариантами и моим разбором

#кейс_стади
Задача на подумать для менеджера. Разбор

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

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

В таких ситуациях решения нужно принимать одновременно в двух горизонтах:

1) Краткосрочное — найти костыль, который закроет управленческие провалы Вадима. Это может быть сотрудник в его команде, которому формально или неформально добавляются функции управления, или сам менеджер, который временно берет процессы на себя.
2) Долгосрочное — на позиции Вадима должен оказаться другой человек, обладающий не только техническими компетенциями, но и управленческими навыками

Обратная связь не всегда работает. И тем более не приводит к изменениям. Изменения случаются, если есть три условия:

- Представление о лучшем будущем
- Желание значимого лица изменить статус-кво
- Безопасные шаги для перехода к новой системе

Если этих факторов нет, любые разговоры о развитии останутся без последствий

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

Дальше начинаю фиксировать всё в формате: дата – ситуация – пример (ссылка, скриншот) – что стоило сделать иначе. Когда накапливается достаточно данных, собираю кейс-эффект диаграмму, где фиксирую системные проблемы, их причины и следствия. Это даёт целостную картину: какие конкретно ошибки ведут к каким последствиям

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

В ситуации с Вадимом я поступил именно так: за месяц собрал 22 кейса, визуализировал их влияние и представил его руководству. Этого оказалось достаточно. В итоге произошло перераспределение ролей среди DevOps-лидов, и к нам пришёл новый человек, который действительно занимался процессами. Стало проще и команде, и бизнес

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

#напутствие
Почему я работаю менеджером

Хороший процесс – это не только про то, чтобы гнать команды вперёд, но и про то, чтобы вовремя останавливаться. Так вот, ты тоже часть этого процесса

Работа – это марафон, а не спринт, и если долго игнорировать техдолг своего здоровья и психики, то однажды может прилететь такой факап, который никакими ретро не разберёшь. Хороший менеджер – это тот, кто не только умеет разруливать хаос, но и знает, когда пора сделать паузу. Давать команде передышку – это нормально. Снимать с собственной шеи маленького достигатора и отставать от себя - адекватно

#кейс_стади
Задача на подумать для менеджера

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

Ты вышел на новое место работы — в крупную компанию, которая занимается доставкой цветов (конкурент Flowwow). Бизнес разросся, и вместе с ним выросла глобальная админ-панель для всего бэкофиса. В ней собрано буквально всё: управление партнерами, карточками товаров, логистика, CRM, финансы, маркетинг и еще десятки других систем, которые сплелись в один большой монолит

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

Проект курирует лично Александр, CTO, который пришел из вашего крупнейшего конкурента и «знает, как это делать». Он уже участвовал в похожем проекте и уверен, что у него есть рабочий план. Тебе нужно просто обеспечить прозрачность процесса и следовать лучшим практикам

Вот только проблема в том, что никаких «лучших практик» не видно

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

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

— Сколько осталось работы? Неизвестно, потому что никто не знает, сколько вообще всего есть в монолите.

— Какие сервисы уже готовы? Никакие, потому что пока только разбираетесь в системе.

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

Ты пробовал включить CTO в рабочие обсуждения, но это быстро обернулось катастрофой.

— Во-первых, он сразу пошел в микроменеджмент. Вместо стратегии начал разбирать конкретные таски и требовать «просто запустить что-то рабочее».

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

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

Но как дать динамику, если проект только распутывается, а не продвигается?

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

#кейс_стади
Задача на подумать для менеджера

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

После этого в ход идут принципы Disciplined Agile. Вместо жесткого roadmap — адаптивное планирование. Вместо жестких процессов — Way of Working . Стоит подходить к процессам не как к жестким рамкам, а как к пересматриваемому канвасу для удобства, чтобы не разбредаться. Из XP обязательно советую утащить 2 практики как костяк:

Small Releases - команда максимально часто выкатывает изменения, даже если это небольшие куски системы. Это позволяет избежать эффекта «мы три месяца копаемся и ничего не видно».

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

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

Каждую неделю команда должна:
1. Показывать не просто код или записи, а работоспособные куски системы на стенде;
2. Получать обратную связь от тех, кто реально пользуется админкой;
3. Давать CTO возможность перепахивать бэклог, меняя приоритеты и набор задач;

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

Почему другие варианты не работают?
1. Классический WBS с процентами выполнения — дает ложное ощущение контроля. В реальности каждая новая неделя открывает столько неожиданностей, что «50% выполнено» не значит ничего;

2. Работа через списки рисков — CTO хочет не риски, а движение. Без привязки к реальным шагам риск-лог превращается в формальность;

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

4. Прогнозирование через темп команды — пока команда занимается исследованием, темп разработки бесполезен;

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

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

P.S. Конечно это невозможно без первичного кик-офа, общих договоренностей об архитектурном стиле и подготовки окружений. Если команда тратит более 5 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь

#кейс_стади
Задача на подумать для менеджера

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

Постбэк на 14 февраля

Ты недавно зашёл в динамично растущую IT-компанию как деливери-менеджер. Тебе доверили присматривать за процессами и становиться «руководителем руководителей»: под твоим непрямым началом пять продуктовых стримов и команда проектных менеджеров. Компания только формирует культуру ответственности, внедряет карьерные треки и системы развития, и тут на сцену выходишь ты – с новыми идеями и желанием укрепить корпоративные стандарты.

Недавно ты ввел четкий карьерный трек для PM’ов и появились чёткие уровни развития, матрица компетенций и пути например “как из ПМа дорасти до деливери-менеджера” и далее

Самое любопытное, что в компании нет пока жёсткого комплаенса и кодекса поведения: всё на доверии и договорённостях. А по понедельникам люди расслабляются за настолками в офисе. На одном из таких неформальных вечеров к тебе проявляет явные знаки внимания Саша – один из PM’ов. Формально он/она тебе не подчиняется, но твой статус деливери-менеджера всё равно даёт тебе возможность влиять на развитие карьеры Саши: есть же единая система оценки, которую ты помогаешь поддерживать.

Тем временем, у тебя дома всё довольно шатко: партнёр, с которым вы на грани расставания, в общем-то не возражает, если ты решишь «поискать варианты». Да и Саша симпатичен/чна. Но ты понимаешь, что хочешь выстроить крепкую культуру в компании, не сломать едва зарождающиеся правила этики и не выглядеть в глазах остальных как человек, который злоупотребляет служебным положением. К тому же никто в компании пока не прописал, как быть, если вдруг старший по должности начинает встречаться с кем-то из проектных менеджеров. Быть может ничего такого?

Ты ломаешь голову над несколькими исходами.

#рецепт

Критерий софтов менеджера: зовут ли вас на пиво после увольнения?

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

Если к тебе тянутся люди (даже когда вы уже не в одной компании), то при поиске новой работы или наборе «команды мечты» все двери открыты. А если после ухода никто даже не пишет «Привет, как дела?» – возможно, дело не в Agile, Kanban или project delivery, а в элементарном отсутствии доверия и человеческого контакта

P.S. Поделиcь своей историей: с кем удалось сохранить общение после ухода? И как эти «барные связи» помогли тебе в будущем?
P.P.S. Читатель, если ты мой бывший коллега, то я буду рад приглашению от тебя на пиво, давно не виделись!