#артефакты
Тренажёр постановки задач на коленке

Здравствуй, подкованный читатель

Я встал в легкий ступор, особенно после последней обратной связи на посты. Мне нравится давать контент, который можно утащить и переиспользовать, а не просто прочитать слегка задуматься. И тут я застрял, а чего бы такого написать из того что мне нравится, ибо давать шаблон условной матрицы требований, если условный Grok это сделает лучше. Хороший статей не особо много именно про то как ставить задачи, а не писать ТЗ и так родился этот пост

Я собрал на коленке Task-Setting Trainer — GPT-S https://chatgpt.com/g/g-68088b1d1b648191845465ffe163f8c1-gpt-s-task-setting-trainer, который учит формулировать постановку на разработчика чуть сложнее чем User Story

Когда я задумал Trainer, первая идея была: реализовать всё на Google AppScripts — дергай данные из гугл табличек, сохраняй инструкции в Drive, строй UI прямо в браузере. Но быстро я осознал, что OAuth, квоты и тонны boilerplate-кода превратят прототип в эпопею, а чтобы ты горел как я с вайб-код генерации я не хочу. Поэтому я свернул AppScripts и остановился на JSFiddle: чистый HTML+JS, мгновенный запуск и минимум геморроя

Второй мой просчёт — я забыл, что у многих нет GPT-Plus или Team. Чтобы не оставить тебя без тренажёра, я прикладываю в комментариях все файлы с инструкциями и канвой работы. Копируй их в DeepSeek или любой аналог n8n — и твоя копия бота заработает без ChatGPT

P.S. Жду твоих идей и новых сценариев для тренажёра!

#рецепт
Как правильно работать с капасити и велосити

Здравствуй неутомимый читатель! Я услышал твою обратную связь и пришел с более практическим, менее AI-вылизанным и менее частым контентом

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

- Начни с простого: объяви команде, что капасити и велосити — это один и тот же «спидометр»

- Велосити считай по трём самым удачным спринтам, когда «звёзды легли». Если вдруг текущий результат ниже 50 %, смело говори: «Метрика сомнительная и плавающая, не обращайте внимания”

- Длина итераций — тема для творчества. На этой итерациии сделай спринт на 10 дней, в следующей — на 15. Аргументируй “под гибкость рынка” и “неотменимостью запросов продактов”

- Спишишь? Перезапусти спринт на середине. Всё, что недоделано, выкинь из истории: «Мы же итерируемся, ребята!». Исторические данные как бы ничего не говорят

- На планировании подмигни команде и скажи: «Учёные доказали: story points чудесно складываются — 2 + 5 = 7, главное верить». Сошлись на центральную предельную теорему — большинство перестанет задавать вопросы после слов «агрегация» и «мода»

- Капасити? Планируй под единственный возможный сценарий: «никто не болеет, отпусков нет, встреч нет. инцидентов нет». Аргумент: «Scrum‑гайд про февральские простуды молчит, значит их не бывает»

P.S. Вторая порция в комментариях. Следуй этим приёмам регулярно и ваш скрам точно будет достоин рассказа на конференции
P.P.S. Чего на твой взгляд еще не хватает в списке?

#рекомендация
Где бизнес встречает философию, а аналитика — творчество

Здравствуй, размышляющий менеджер

Ты когда-нибудь задумывался, как можно связать рынок электромобилей, вызовы AI и «Цветы для Элджернона» так, чтобы это не было несвязным потоком мысли? Мне на днях попался канал Репродуктор Белоусова, где автор объединил философию с предпринимательским опытом, а заодно научился аналитическое мышление дружить с творчеством. Причём всё это подаётся так, что мозг ловит приятное дежавю: вроде бы ты уже сталкивался с такими темами, но теперь смотришь на них с другого угла (не голландского)

В мире, где все пытаются стать экспертами узкой ниши, этот человек предлагает настоящее путешествие по широкой карте идей: истории с неожиданными выводами, любопытные параллели между бизнес-процессами и сюжетами из классической литературы, плюс мысли, которым тесно в 280 символах. И любопытно, автор хочет привить любовь изложению мыслей бумаги и рефлексии, поэтому 30 апреля он разыгрывает Onyx Boox KANT 3 – идеальный гаджет для тех, кто обожает читать и размышлять без границ. Условие участия простое: быть подписанным на его канал

Советую заглянуть — вдруг там ты найдёшь именно то вдохновение, о котором даже и не подозревал

В последнее время очень сильно упало число просмотров, реакций и в целом вовлеченность. Что то поменялось в контенте, формате и вам стало менее интересно? Или я что-то упускаю?

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

Ты проджект менеджер в компании Целестиал и вызрабатываете аналог Scopify, движок для интернет-магазинов. У вас в компании ПМ являются частью продуктового офиса, подчинаются CPO и больше работают в формате сервис деливери менеджеров.

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

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

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

Какую сторону ты займешь? Как выйдешь из этой ситуации?

#рекомендация
Хватит переслушивать созвоны, ты же менеджер!

Здравствуй, мой торопливый читатель! Если ты тоже как я завяз в бесконечных встречах, грумингах (PBR) и собеседованиях, а после судорожно выискиваешь слот переслушивание и структурирование записей — я тебя прекрасно понимаю. Кстати везде их по разному называют, я называл итоги встречи, пока меня не переучили называть их MoM

Сам недавно на ретро осознал, что половина существенная часть дня — это не только встречи, но бесконечное «переваривание» их результатов

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

Потестировал и нашел что качество транскрибации часто даже выше tl:dv, даже жалею, что я раньше тратил на переслушивание записей вручную

Memo AI реально экономит нервы и часы жизни. Можно даже специально заточенные отчёты получить, например, для Scrum-мастеров и продуктовых менеджеров — разложат тебе daily и кастдев в понятную структуру action-айтемов

Первые 30 минут расшифровок бесплатные, пробуй!

@VoiceTextAI_bot

#рецепт
Секретное оружие: ресурсное планирование

Здравствуй, дорогой читатель. Ты не поверишь, но многие начинающие менеджеры в последнее время совсем забывают про важнющую штуку — ресурсное планирование. Главное помни правило клуба - НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть)

Классическая логика планирования

В водопадном подходе план идёт от требований к расписанию. Подробнее смотри у Селиховкина:
https://drive.google.com/file/d/1uCV7cu_1JgVGYk9pXP-LFCv1E1EdNF3m/view?usp=sharing

1. Формируем матрицу требований (матрицу трассировки), чтобы связать каждый запрос заказчика с конкретными результатами: https://habr.com/ru/articles/831922/;
2. Далее — WBS, декомпозиция проекта на мелкие задачи (чтобы сразу было понятно, что за чем идёт):https://kaiten.ru/blog/model-wbs/;
3. Потом строим сетевую диаграмму, чтобы увидеть зависимости между задачами: https://forpm.ru/сетевой-график);
4. На основе WBS и сети определяем ресурсы, причём есть неплохая статья про это: https://probusiness.io/master_class/529-chto-nado-znat-pro-raspredelenie-resursov-chtoby-ne-zagubit-dazhe-khoroshiy-plan-proekta.html;
5. А параллельно оцениваем трудоёмкость/продолжительность — и в итоге получаем календарный план (диаграмму Ганта).

Основные этапы ресурсного планирования

1. Оценка доступности: учитываем, кто у нас вообще есть в команде, загружен ли кто-то другой работой, не ушёл ли в отпуск и тд.;
2. Оценка ёмкости: определяем, сколько времени реально может выделить каждый человек (FTE, часы и т.д.). Планировать 100% загрузку — наивно; оставь буфер на форс-мажор и обязательные митинги;
3. Предварительный прогноз качества ресурсов*: если задача сложная, то нужны опытные люди (например, только синьору можно);
4. Аллокация: распределяем, кто что делает. Связываем ресурс с задачей на диаграмме Ганта, в Excel таблице или таск-трекере;
5. Переоценка задач: смотрим, не вышло ли так, что один спец назначен сразу на три фронта. Если что — меняем план, ищем дополнительные руки;
6. Выровнивание ресурсов: обрезаем перегрузки, двигаем задачи, включаем автоматику (Microsoft Project и др.), чтобы не было «двойного бронирования»;
7. Актуализация и контроль: постоянно проверяем, как загрузка сходится с реальностью, ведь у нас могут уйти люди, или задачи сдвинулись.

И да, если у менеджера нет формальных подчинённых, часто помогают тимлиды и руководители отделов: они же владельцы «ресурсов». В итоге получаем документ (или диаграмму, или таблицу) — там расписано, кто и когда участвует в проекте. Без этого велик риск перегрузить команду и потом делать ночные овертаймы

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

P.P.S А у тебя на работе есть ресурсное планирование? Поделись, как оно организовано!

#мнение
Вайбкодинг выходного дня

Здравствуй, околоайтишный читатель! Сегодня я хочу поделиться своим обзором сервиса от Google https://studio.firebase.google.com/, который я опробовал в рамках разработки моего веб-приложения по приколу. Сказать что мы все ближе к замене разработчиков сложно, но мы определенно к этому идем

Сервис обещает быстрый прототайпинг, объединяя облачную IDE, визуальный редактор и все возможности Firebase «из коробки»
При старте работы создаётся новый workspace, где можно создать новый проект на различных языках или загрузить уже существующий (например, из GitHub). Сервис позволяет работать в двух режимах:

Режим превью: сразу отображается созданный сайт в основном окне (при желании можно открыть его в отдельной вкладке);

Классическая IDE: по сути, это браузерная версия VS Code с поддержкой всех настроек и расширений, что устраняет необходимость настраивать локальное окружение

Мое специфичное мнение:

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

2. Отсутствие объяснений решений
Сервис не поясняет, почему так или иначе был сгенерирован код, что усложняет понимание логики работы приложения;

3. Недостаток логического мышления и планирования
Платформа практически не умеет выстраивать план решения задачи или демонстрировать какие-либо рассуждения. Фактически, под капотом ощущается работа Gemini 2.0 flash, без продуманного ризонинга;

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

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

6. Удобная облачная IDE
Разработчики не стали выпендриваться – платформа предоставляет привычный интерфейс VS Code в браузере, освобождая от заботы о локальных настройках. Наличие расширений делает работу ещё удобнее;

7. Интеграция с Gemini через API
Есть возможность интегрировать Gemini как AI через API, что позволяет давать ей задачи и тонко настраивать генерируемое решение под конкретные нужды проекта;

8. Плюшки Firebase «из коробки»
Есть множество инстурментов: эп-хостинг, линтер, аналитика, CI/CD и другие инструменты, что значительно ускоряет процесс разработки и публикации;

9. Публикация в GitHub одной кнопкой
Возможность выложить проект в GitHub нажатием всего одной кнопки – огромное удобство для быстрого деплоя и работы с вершн-контролем;

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

11. Интуитивный визуальный редактор
Применение визуального редактора, где можно кликать по элементам или выделять области (рисовать квадратики), позволяет быстро дать понять системе, что именно требуется изменить в интерфейсе;

12. Проблемы с UX и производительностью
Минусом является то, что разработчики, судя по всему, спешили: обнаруживается множество багов, интерфейс работает медленно, а UX оставляет желать лучшего. Глаза вытекали пока работал;

13. Бесплатность и моментальная публикация
Один из самых весомых плюсов – сервис бесплатен. Всего три действия, и твой проект запаблишен, а код готов развернуться даже на моём хостинге. Естественно пока в бета-тесте.

Вывод
Для быстрого прототипирования данный сервис уже сейчас является мощным инструментом

Мой собственный сервис AccentCoach: https://studio--accentcoach-bjcdj.us-central1.hosted.app/

P.S. Помни, иногда скорость и оперативность важнее идеальной отлаженности каждого механизма

#рекомендация
События влияющие на менеджерскую парадигму

Здравствуй, общительный читатель!

5 сигналов, что пора учиться управлять людьми, а не только тасками:

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

Если что-то из этого — про тебя, обрати внимание на конференцию PeopleSense

Это 2 дня про управление командами, процессами и собой — опыт, кейсы и инструменты от тимлидов, СТО, HRD и основателей компаний

🎯 Что сможешь вынести из конференции, если ты — джун или мидл в роли тимлида или PM:

1. Как проводить результативные вантуаны
Мастер-класс «Звездная карта 2-в-1: инструмент развития команды и тимбилдинг»

2. Как давать честную обратную связь, без скатывания в «ну вы молодец»
Доклад «Коммуникации, которые работают: как IT-лидеры создают ясность и вовлекают команды через корпоративную антропологию».

3. Как разобраться, где вы как руководитель сильны, а где буксуете
Мастер-класс «Exit the Loop: играй, находи свои грабли и переставай на них наступать»

🔥 А вот что будет полезного для тех, у кого уже есть опыт:

1. Сложные разговоры: увольнение, конфликты, саботаж
Доклад «Лидер, которому доверяют: как выстроить доверительные отношения в команде и компании»

2. Командная фасилитация: как перейти от споров к решениям
Мастер-класс «Вертикальная фасилитация: инструменты для зрелых командных решений»

3. Что делать, если у вас 5 джунов и ни один не берёт на себя ответственность
Доклад «Менеджмент 18+: сотрудник — не ребёнок, менеджер — не родитель»

📅 19–20 мая, Москва, Loft Hall #4.
🌐 Или онлайн с доступом ко всем записям.

В программе:
— 30+ докладов.
— 20+ мастер-классов.
— И много «А так можно было?!»

Посмотреть темы докладов и спикеров →

P.S. Это от авторов продуктсенса!

#почтовый_ящик
Бомбардировка задач. Часть 3

1. Стать сервисным партнёром, а не конторой-подрядчиком
Гораздо круче работать с заказчиком на партнёрских условиях. Скажи открыто: «Команда загружена, но если это очень важно, мы можем увеличить команду под эту задачу». Честность тут будет большим плюсом. Постепенно заказчики поймут, что вы не просто код пишете, а помогаете им достигать бизнес-целей

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

P.S. Поверь, и я когда-то думал, что иначе работать нельзя. Но можно. И нужно. Особенно, если тебе нравится быть живым, а не вечно загнанным в угол «заложником ситуации»

#почтовый_ящик
Бомбардировка задачами. Часть 2

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

Ты, как молодой менеджер, наверняка ощущаешь вину за то, что не справляешься, начинаешь работать до восхода солнца и заканчиваешь за полночь, а сверху всё прилетает и прилетает. И тут дело не в тебе, а в самой системе — это как наливать 15 литров воды в 10-литровое ведро и удивляться, что почему-то льется через край

У меня был похожий случай: таскал 11 проектов одновременно, и кажется, тоже жил на работе. Чем это закончилось? Выгоранием, просадкой по здоровью и потерей мотивации. Тогда-то я и понял, что вся эта гонка не имеет смысла без адекватного ресурсного и портфельного планирования

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

— Что будет, если оставить всё как есть?

— Чего не будет, если оставить всё как есть?

— Что будет, если ты начнешь что-то менять?

— Чего не будет, если ты начнешь что-то менять?

Теперь что можно сделать прямо сейчас (краткосрочно):

Во-первых, начни постепенно вводить частичную прозрачность. Я понимаю, руководство требует лукавить, что команда занимается исключительно задачами заказчика, но тебе нужно научиться договариваться иначе: «Чтобы качественно выполнить задачу, команде нужно вот столько времени». Это не «вышибалы», а честность, которая, к слову, является основой нормальных отношений с заказчиком. Лучше сказать реальный срок сразу, чем потом оправдываться за срыв

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

Долгосрочные решения:

1. Внедрить ресурсное планирование
Тебе нужно четко понимать доступность и емкость сотрудников хотя бы на месяц вперед. Для начала можешь использовать простую Excel-таблицу:

— Зафиксируй сотрудников и их доступность (часы или дни) на период, включая дейоффы, праздники, отпуска и тд;

— Учти запланированные встречи, регулярные активности и резерв на непредвиденные ситуации или риски;

— Аллоцируй сотрудников на задачи с учетом последовательности;

— Выравнивай ресурсы по задачам, соблюдая баланс между нагрузкой и приоритетностью задач;

— Это поможет тебе аргументированно говорить руководству и заказчикам о том, что ресурсы ограничены и задачи нужно планировать с учетом реальной загруженности, а не «тяп-ляп»

2. Начать управлять портфелем проектов
Проекты должны оцениваться и приоритизироваться с учетом бизнес-показателей:

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

— Составь карту портфеля и выяви пересечения проектов по срокам, ресурсам и задачам;

— Учти влияние проектов на финансовые потоки (cash flow) компании, чтобы руководство видело прозрачную картину и понимало важность более качественного и планового подхода;

— Это позволит тебе иметь объективную аргументацию и четко понимать, когда стоит отказаться от задачи или перенести ее на другое время, сохранив и ресурсы, и репутацию компании;

3. Начать вести прозрачный диалог внутри компании
Тебе нужно показать руководству, что честность и предсказуемость важны клиентам. Вместо того, чтобы скрывать загрузку команды, предложи фокусироваться на долгосрочных контрактах и понятной аллокации ресурсов. Это снизит количество «пожаров» и повысит доверие к вам как к профессионалам

#почтовый_ящик
Бомбардировка задачами. Часть 1

Здравствуй, ответственный читатель.

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

“

Ситуация реальная, сам хз как решить, в данный момент ищу варианты

Я джун РМ в it компании, у мебя под крылом 8+ проектов, 5+ заказчиков и на все 1 команда (1 бэк, 2 фронта, 1 дизайнер, 1 QA, 1 content manager). Каждый заказчик думает, что команда занимается только его проектом. 7 проектов на этапе поддержки(развития), 1 из проектов пилится с нуля, сейчас на этапе отрисовки прототипов.

Я как РМ выступаешь в роли BA, SA и РМ соответственно

Методология: хз, какая, но похоже на канбан.

В данный момент задачи поступают следующим образом:
Клиент приходит, ставит задачу не понимая до конца что он хочет, РМ обрабатывает её, передает на оценку команде, после согласовывает оценку с клиентом и берем в работу.

Задачи сыпятся с неба астроидами на бедные головы команды, я как РМ не успеваю их обрабатывать (технической подкованности не хватает, следовательно не высокая скорость работы. Пока разберусь что от меня хотят). Из-за этого снижается качество проработки каждой задачи мной как РМом и командой (баги наше всё)
*сказать заказчику нельзя, что есть другие проекты по мимо его.

Как мне РМу выстроить свою работу и работу команды таким образом, чтобы:

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

Вместо 8 часов работаю 10-14.
Если сможешь мне чем то подсказать или закинуть это в канал для обсуждения будет прекрасно иначе я скоро повешусь в петле задач)))

“

P.S. Как можно жить в таких условиях и сохранить здравый рассудок — обсудим в следующем посте

#полезности
Симулятор PMP

В догонку сообщению выше. Тут PMI релизнули GPT-s с симулятором экзамена. Вполне себе рабочая штука!

https://chatgpt.com/g/g-elRZlGQcX-pmi-infinity-pmp-exam-simulator

#рекомендация
Не канал, а менеджерская аптечка

Здравствуй, дорогой читатель

Недавно нашёл очень уютный канал для PM-ов — 3PM. Это такой приятный менеджерский уголок, где нет ушлых формулировок и лишней воды. Ребята пишут чётко, с иронией и примерами из жизни. Здесь про проекты, продуктовый менеджмент, Agile и даже экзамен PMP (да-да, тот самый)

Особенно зацепил кейс про Андрея, руководителя проектов из стройки. У него случилась типичная PM-боль: в компании не оказалось экспертизы по нужной технологии. Брать подрядчиков или растить внутри — звучит просто, но вот нюансы с контрактами, деньгами и юристами… Короче, типичная менеджерская задачка. Почитать, как Андрей с этим справился, можно тут: https://t.me/ampmby/211

На канале вообще много таких ситуаций из реального опыта менеджеров компаний типа Lyft, Stripe, IBM, Juno. А авторы даже написали книгу «Проджект-менеджмент: как быть профессионалом» — читается легко и реально помогает разобраться с PMBOK и другими штуками, от которых обычно тянет в сон

Если хочешь полезного контента про менеджмент без скуки и занудства, советую подписаться:
https://t.me/ampmby

P.S. Особенно порадует тех, кому нужен PMP — сложные и оторванные от реальности формулировки там разложены так, что становится понятно даже в самый сонный понедельник

#мнение
Аджайл — это не фреймворк и вообще не про гибкость. Часть 2

Отсюда вывод: хотелось бы вместо притягивания за уши модных слов вроде «аджайл» слышать в профессиональном сообществе разговоры о конкретных инструментах, которые вы использовали в тех или иных сферах своей работы. Использовали адаптивность? Отлично! На каких этапах строительства и с помощью каких инструментов? Пусть вас при этом не удивляет, что что-то подобное использовали многие другие, включая тех, кто про аджайл даже не слышал. Для успешного применения адаптивности знать про аджайл совсем не обязательно.

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

Эмпирический подход, сюрприз, тоже отчасти про то, на что напирали создатели аджайл-манифеста. Нам нужно наводить прозрачность, чтобы проводить инспекцию. А её мы проводим, чтобы адаптироваться (вот у нас и вылез опять тот самый Adaptive). Необходимость адаптироваться к текущей ситуации — вещь довольно очевидная, и она не означает, что мы используем аджайл или скрам.

Скрам придуман из необходимости адаптироваться к БЫСТРО меняющейся среде. Если ваша среда меняется не быстро, то вполне вероятно, вы сможете хорошо адаптироваться к ней и без всякого скрама. И вполне адаптивным решением будет НЕ использовать скрам.

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

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

P.S. Если я скажу здесь словечко «собачка», которое, казалось бы, гораздо проще «аджайл» или «скрам», то, поверьте, все представят в голове совершенно разные вещи (от собак разных пород и размеров до «@» и молнии на ширинке). И наши споры вокруг этих слов вызваны тем, что в головах разные картинки. Ценности доказать кому-то, что твоя картинка более правильная, мало. А вот от рассказа о том, что именно ты используешь в работе и каким образом (к какому бы умному слову ты это ни причислял), довольно много

#мнение
Аджайл — это не фреймворк и вообще не про гибкость. Часть 1

Здравствуй, задумчивый читатель! В очередной раз поиграю в капитана фанатастика с длиннопостом. Частично утащил у https://t.me/fenix_xx

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

Называется это дело «Manifesto for Agile Software Development». Тут, наверное, снова сюрприз. Речь велась именно про разработку программного обеспечения, то есть говоря о строительстве, например, и применяя словечко «аджайл», мы уже как будто бы что-то не туда натягиваем.

Теперь о главной проблеме. Создатели манифеста, применив слово Agile, создали ещё одну проблему. Особенно для русскоязычного мира, который стал переводить «аджайл» как «гибкость». Но если прочитать манифест, то внезапно выяснится, что он про адаптивность, а не про гибкость. Собственно, слово Adaptive и было основным претендентом для названия манифеста, поскольку лучше всего раскрывало суть, но не было использовано (по слухам, из-за того, что у одного из подписантов уже была книга с таким названием)

Поэтому, когда я говорю про аджайл, я говорю прежде всего про адаптивность, которую, как тут многие уже заметили, мы вполне успешно используем не только в легковесных фреймворках. То есть аджайл про адаптивность — это факт. Но в другую сторону это не работает. Адаптивность не подразумевает автоматически аджайл или все легковесные фреймворки под его зонтиком. p3express и kanban про гибкость, но они ни разу не Agile

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

Важной мыслью является то, что адаптивность не равно гибкость. Для того, чтобы делать качественно и выигрывать конкурентную борьбу, нам зачастую приходится проявлять не гибкость, а твёрдость. То есть адаптация к текущим условиям вполне может привести нас к жёсткой иерархии со всеми вытекающими отсюда последствиями. Или, например, мы можем проявлять гибкость в некоторой части нашего процесса (например, команда разработки), но при этом быть несгибаемыми в бизнесовой части и за счёт этого утирать нос всем нашим конкурентам. Как тут иногда справедливо замечают, гибкость бизнеса и гибкость разработки — это вообще про разное

Если мы перестанем пихать везде модное словечко «аджайл» и поговорим просто про адаптивность, то многие споры подобного рода станет решать гораздо проще

Например, строительство. Как нам тут помогает адаптивность? Она, например, может нам сказать, что нужна некая гибкость во взаимодействии с заказчиком на этапе проработки архитектурного или дизайн-решения. Но при этом нам нужна твёрдость в реализации готового на бумаге проекта. Если мы начнём использовать гибкость тут, то с вероятностью 99% это негативно скажется на качестве результата и сроках реализации проекта, и ещё больше проблем мы можем словить при вводе здания в эксплуатацию (гибкость может обнулить заложенные в изначальный проект требования безопасности и соблюдение строительных регламентов)

Отсюда вывод: хотелось бы вместо притягивания за уши модных слов вроде «аджайл» слышать в профессиональном сообществе разговоры о конкретных инструментах, которые вы использовали в тех или иных сферах своей работы. Использовали адаптивность? Отлично! На каких этапах строительства и с помощью каких инструментов? Набегающая волна? Сюда!

#полезности
Где учиться управлению в Data Science?

Здравствуй, увлеченный читатель! Недавно обсуждали с тобой кейс работы с Data-командами

Очень рад, что ты поучаствовал в обсуждении и опросе

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

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

Также Артем ведет свою
школу по управлению в Data Science, раскладывая все текущие знания по полочкам, в которую вы можете записаться на групповой курс, или пройти ее в экстерне и на личном менторстве

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

#полезности
Где учиться управлению в Data Science?

Здравствуй, увлеченный читатель! Недавно обсуждали с тобой кейс работы с Data-командами
Очень рад, что ты поучаствовал в обсуждении и опросе

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

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

Также Артем ведет свою школу по управлению в Data Science, раскладывая все текущие знания по полочкам, в которую вы можете записаться на групповой курс, или пройти ее в экстерне и на личном менторстве

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

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

На мой взгляд, оптимальным решением в данной ситуации является использование подхода CRISP-DM https://www.datascience-pm.com/crisp-dm-2/. Сейчас расскажу, почему именно этот фреймворк отвечает на вызовы проекта и почему стандартные agile-методики тут не работают

Во-первых, погружение в бизнес-контекст
Проект по автоматизации техподдержки – это не просто набор задач, а целая экосистема: речь идёт о speech-to-text, построении RAG на основе существующей документации, декодировании ответов. Данных здесь много, они слабо структурированы, конфигурация постоянно меняется из-за текучки саппорт-специалистов и различных инцидентов, а требования бизнеса зачастую расплывчатые. Поэтому важно начать с глубокого анализа и систематизации информации для последующего эффективного тестирования гипотез

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

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

В-четвёртых, особенности циклов Data Science
Подходы вроде Data Science Cycle и HADI предполагают параллельное внедрение изменений, что позволяет гибко реагировать на постоянно меняющийся поток данных и расплывчатые бизнес-требования. Да и результаты обучения не стабильны. В отличие от последовательных циклов PDCA или I&A, такой подход помогает быстрее выявлять инсайты и корректировать курс проекта

В-пятых, почему стандартные agile-методики не подходят
Классические agile-фреймворки (Scrum, Kanban и др) ориентированы на фиксированные итерации и гарантированный инкремент – небольшое улучшение, которое можно предъявить заказчику. Однако в DS-проектах изменения затрагивают систему целиком, а результат эксперимента может быть неопределённым. Такой подход больше похож на красивую презентацию, чем на реально эффективное решение

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

Сцепка Data Preparation <-> Modelling и более крупный Business Understanding <-> Evaluating дает больше циклов для обратной связи, не привязываясь к текущей орг. структуре. Она помогает не просто тестировать гипотезы, а связывать их с реальными бизнес-целями – например, снижением нагрузки на саппорт и повышением качества ответов. Такой подход особенно актуален, когда требования бизнеса расплывчатые, а данные требуют тщательного анализа

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

P.S. Как ты считаешь, насколько критично правильно выстроить такой специфический процесс при работе с данными или работа по классике (для меня scrum/kanban уже классика) и так работает в такого рода кейсах?

#полезности
17 фундаментальных метрик для IT команд

Здравствуй, наблюдательный читатель! Ниже тебя ждёт краткое, но точное описание 17 метрик, разбитых на три группы — Crawl, Run, Walk — как в оригинальном списке от одной очень забавной компании, занимающейся ERP II трансформациями. Каждая метрика расскажет тебе, как лучше понимать скорость релизов, качество разработки, безопасность, а также ценность для пользователей и бизнеса. В конце — пользительные ссылки

CRAWL (базовые метрики существования)
Deployment Frequency (DORA)
Частота поставки нового кода в продакшен или конечным пользователям. Показывает регулярность релизов и помогает увидеть узкие места процесса

Lead Time for Changes (DORA)
Время от коммита до развертывания. Если оно слишком велико, значит вы теряете адаптивность

Change Failure Rate (DORA)
Доля изменений, после которых требуется откат или срочное исправление. Чем выше, тем больше говорит о проблемах качества

Time to Restore Service (DORA)
Сколько уходит на восстановление работы после инцидента. Чем быстрее, тем выше устойчивость и меньше потерь

Time Between Failures
Средний промежуток между сбоями. Позволяет оценить, насколько надёжным стал продукт

RUN (стандартные метрики операционной эффективности)
Flow Time
Сколько занимает полный цикл задачи от идеи до продакшена. Выявляет «заторы» — длинные очереди или медленное ревью.

Flow Velocity
Сколько задач в итоге доводится до завершения за единицу времени. Позволяет отслеживать «пропускную способность» команды.

Flow Efficiency
Какую долю всего времени работы задача реально «делается», а не лежит в очереди. Низкий процент сигнализирует о больших простоях

Flow Distribution
Распределение по типам задач (фичи, баги, техдолг и т.д.). Избегает перекосов: не забывайте о балансе между новыми функциями и качеством

Team Health
Условный барометр морального состояния команды, её атмосферы и удовлетворённости. Мотивированная команда работает эффективнее и стабильнее

Mean Time to Detect
Через какое время обнаруживаются неполадки или дефекты. Если долго, уязвимости могут «жить» в системе, создавая риски

Number of Vulnerabilities
Сколько уязвимостей найдено в коде/инфре. Чем оперативнее закрываются критические дыры, тем безопаснее продукт и спокойнее сон

WALK (зрелые метрики фокуса на ценности)
Customer NPS
Индекс лояльности: показатель, насколько пользователи готовы рекомендовать продукт другим. Если NPS падает — звоночек, что люди недовольны

Time to Value
За какое время клиенты получают реальную пользу от новой фичи. Быстрая выгода = довольные пользователи и рост продукта

Service Level Indicators
Метрики, отражающие качество сервиса (доступность, время ответа, процент ошибок). Задают SLO и смотришь, укладываетесь ли в эти цели

Development Costs
Все расходы, связанные с разработкой: зарплаты, инструменты, инфраструктура. Мониторинг затрат нужен, чтобы понимать ROI и не прожигать бюджет

Product Adoption
Насколько активно и регулярно пользователи пользуются новой фичой или продуктом. Высокое adoption = проверка ценности на практике

Полезные ссылки
https://www.aha.io/roadmapping/guide/agile/agile-metrics
https://www.gitclear.com/popular_software_engineering_metrics_and_how_they_are_gamed
https://queue.acm.org/detail.cfm?id=3454124
https://martinfowler.com/articles/measuring-developer-productivity-humans.html
https://kaiten.ru/blog/f4p-framework/

Отдельно выделю: unidraw.io/app/board/b05a2ae081007f362709 — где проделана замечательная работа по канбан-метрикам от деливери-менеджеров Т-банка

P.S. Поделись, что из этого ты уже измеряешь? Какие метрики на твой взгляд буллщит?

#иное
Как я пересмотрел подход к поиску работы

Здравствуй, стохастический читатель!

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

Самое ценное из нашей встречи:
- Конкретные рекомендации по резюме – Влад объяснил, почему «типовое и понятное» лучше «креативного и уникального»;
- Практика самопрезентации – научил говорить коротко и ярко о себе, чтобы запоминаться;
- Советы по использованию HH как базы компаний, а не основного канала откликов. Реальные результаты приносят рефералки и личное общение

Коротко про Влада – карьерный консультант, ex-Lead Product в Т-Банке, ex-CPO в ProductStar, ментор продактов/проджектов и научный руководитель в ИТМО

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

Если ищешь работу или хочешь расти по карьере, рекомендую подписаться – будешь знать, что делать, а не суетиться наугад

#иное
Как я пересмотрел подход к поиску работы

Здравствуй, стохастический читатель!

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

Самое ценное из нашей встречи:
- Конкретные рекомендации по резюме – Влад объяснил, почему «типовое и понятное» лучше «креативного и уникального»;
- Практика самопрезентации – научил говорить коротко и ярко о себе, чтобы запоминаться;
- Советы по использованию HH как базы компаний, а не основного канала откликов. Реальные результаты приносят рефералки и личное общение.

Коротко про Влада – карьерный консультант, ex-Lead Product в Т-Банке, ex-CPO в ProductStar, ментор продактов/проджектов и научный руководитель в ИТМО.

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

Если ищешь работу или хочешь расти по карьере, рекомендую подписаться – будешь знать, что делать, а не суетиться наугад.

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

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

У тебя есть друг Алекс, Senior PM в компании CloudSolve. Уже десять лет ребята успешно продают облачные решения для бизнеса: виртуалки, хранилища, инфраструктуру под ключ. Но рынок устал от «просто облаков», конкуренты демпингуют, а клиенты требуют, чтобы «всё работало само, без звонков в саппорт». Время пришло всерьёз заняться ML и Data Science, и начали они с автоматизации техподдержки 1-го и 2-го уровня

Недавно в курилке Алекс рассказал тебе, что деньги на проект дали серьёзные, и набрали лучших из лучших: физтеховцы, олимпиадники, пара аспирантов — вся команда сияет умом, но ни дня не работала над реальным продуктом. Алекс с ужасом осознаёт, что в CloudSolve нет никого, кто хотя бы примерно представляет, как управлять таким проектом. Зато сразу набежала толпа энтузиастов: «Давайте по Agile! Скрам! Ну что там может пойти не так?»

Ты же уже знаешь, что обычный Scrum для дата-саенса — это прекрасный способ красиво слить бюджет и уверенно провалиться. Потому что DS — это не веб-разработка с понятными задачами, тут одни эксперименты, которые могут закончиться ничем, гипотезы, которые то срабатывают, то нет, и бизнес-заказчики, которые говорят только: «ну чтоб умненько было и расходы на саппорт резко упали». PDCA, любимый многими менеджерами, тоже не поможет — разница между экспериментом и простой итерацией огромная. Если Алекс попытается управлять дата-саенс командой стандартными подходами, то скоро обнаружит себя одиноким, грустным и виноватым перед высшим руководством

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

Какой совет по подходу к управлению ты бы дал Алексу?

#рецепт
Как я усилил свой план погружения и вывел его на новый уровень

Здравствуй, придирчивый читатель!

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

Но мой опыт показал, что обычного «ознакомления по верхам» недостаточно: иногда корни проблем уходят куда глубже. Поэтому я с годами выработал свой «план погружения» (он же расширенный онбординг), а недавно, после одного модуля на курсе руководителя отдела от стратоплана, прокачал его ещё сильнее

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

1. Люди
Начинаю с 1–1 разговоров с руководителями (CTO, CIO, CPO, PM) — минут по 45. Пытаюсь понять их фокусы, проблемы, приоритеты. Затем иду к тимлидам (включая Lead QA, Lead DS): тут планирую около часа, беру сведения у HR, выясняю мотивацию и психотип. После этого говорю с каждым участником команды (30 минут на человека), а заодно со смежниками (DevOps, саппорт, дизайнеры, маркетинг, продажи) — ведь часто затыки именно на стыках. На этом этапе рождаются «карточки сотрудников» и общее понимание «кто есть кто»

2. Производство
Чтобы увидеть реальную картину, провожу Value Stream Mapping (VSM), изучаю Jira, устраиваю, если получится, короткий воркшоп STATIK. Ищу узкие места — «бутылочные горлышки», провисание задач, перегрузы. Иногда открываются просадки, о которых даже лиды не подозревали. В итоге получаем «карту производства» со всеми входами/выходами, правилами и важными метриками

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

4. Метрики
Когда уже понимаю общую канву процессов и команд, подключаю анализ метрик. Смотрю дашборды в Jira, прогоняю доски через инструменты вроде Nave (чтобы найти аномально долгие задачи или сбой в SLA). Но этим не ограничиваюсь:

Финансы. Параллельно стараюсь прикинуть ФОТ (фонд оплаты труда), операционные затраты (подписки, железо и т.д.), общий PnL, юнит-экономику (если последние 2 доступны). Изучаю любые вспомогательные дашборды или отчёты, которые у них есть. Если где-то избыточные расходы или, наоборот, узкое место, это важный сигнал для управленческих решений

5. Финальный свод
Все найденные «артефакты», «проблемы» и «риски» укладываю в структуру «Оперативный план – Стратегический план». Сразу становится видно, что горит и что ждёт более глобальных правок. За счёт такого подхода это не формальный аудит, а именно погружение: люди видят, что ты не боишься вникать в их детали, а значит, охотно рассказывают о настоящих болях.

P.S. Это занимает порядка двух недель фулл, кажется долго. Но зато, когда доходишь до выводов, у тебя в руках не набор «бумажек», а реальное понимание, что происходит и как это чинить. Такой онбординг проще объяснить и своей команде, и руководству: «Мы не только почитали регламенты, но и прожили их рутину, вот почему план сработает»

#почтовый_ящик
Пять ПМов сидели в баре… и спорили, кто из них вообще работает

Здравствуй, читатель, который думает что он ненастоящий ПМ
Ты задал мне вопрос “Могу ли я себя считать вообще настоящим проджектом, если я не умею писать ТЗ и ни разу не видел бюджета, да и полномочий увольнять никого нет?” Попробую ответить историей

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

Первый — из маленькой аутсорс-студии, а до этого стартапа. Он дергается, весь вечер с телефоном: то клиент, то фрилансер, то договор не подписан:
— Я и за ТЗ, и за приемку, и за дизайн. Только кофе мне пока не поручали

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

Третий — продуктовый. Он говорит словами «value», «roadmap», «action item»:
— А задачи — это не так важно. Главное, чтобы скрам-команда была зрелой

Четвёртый — из большой госконторы. Сидит с сигаретой, которую забыл зажечь и выглядят прям как макконахи из трудетектива:
— У нас без приказа о запуске проекта даже Яндекс.Трекер не открывается

Пятый — с больших проектов автоматизации вроде SAP и 1C:
— Я не лезу в таски. Работаю с архитекторами, интеграторами, подрядчиками. Отчитываюсь напрямую гендиру

ПМ не управляет бюджетом

1. Я примерно знаю, сколько уходит в деньгах, с меня вест спрос;
2. У нас есть финансовый менеджер. Моя задача — не выйти за лимиты;
3. Бюджет у продакта. Я влияю через приоритезацию;
4. Бюджет спущен сверху. Я просто вписываюсь;
5. Я собираю сметы от всех потоков, обосновываю, защищаю.

Нужно ли ПМу портфолио

1. Да. Без кейсов меня ж не наймут;
2. Да. Особенно если хочешь новый проект или контракт;
3. А зачем? Метрики, влияние на продукт — это и есть портфолио;
4. Нет. Главное — стаж и знакомства;
5. Обязательно. Без кейсов ты просто «ещё один менеджер».

ПМ должен писать ТЗ

1. Ну есть ТЗ от клиента так то;
2. Часто да, если БА нет, кто-то должен;
3. Не обязан, но часто вовлечён на уровне проведения груминга;
4. Для этого есть аналитики, я тут при чем?;
5. Нет, для этого есть лиды и аналитики где-то там. Я координирую и согласовывая большие мазки.

ПМ должен заводить задачи

1. Да. Без меня доска пустая;
2. Да. Сам создаю и выставляю по ним акты;
3. Нет, команда сама умеет джирой пользоваться;
4. Нет. Это делает координатор или постановщик.
5. Нет. Я работаю с руководителями направлений, вы чего.

ПМ должен оценивать сроки

1. Да. Клиенту надо понимать объём и косты;
2. Часто нет, но мы с теми кто шарит оценим;
3. Нет. Это устаревшая практика, у нас спринты и релизы;
4. Мне их уже спустили сверху;
5. Собираю оценки от команд, согласовываю по верхам.

У ПМа есть подчинённые

1. Да, отвечаю за всех;
2. Отчасти, сильная матрица, функциональное подчинение;
3. Зачем мне, я за процессы;
4. Бывает по структуре, но решений ты не принимаешь;
5. Мои тимлиды и есть подчиненные.

ПМ может уволить

1. Да, без проблем;
2. Не напрямую. Пишу фидбек, дальше — HR или владелец ресурса;
3. Увольнение — не моя зона, но инициировать процесс могу при негативном фидбэке;
4. Это долгий процесс. Я могу только подать заявку на ротацию;
5. Могу снять с проекта, но не уволить из компании.

P.S. Если ты думаешь, что во всём этом немножко есть и ты — значит, ты точно ПМ.

P.S. Кто из них тебе наименее понятен и так не бывает?

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

На мой взгляд, самым правильным здесь будет именно первый вариант — провести с Сашей приватную беседу и открыто спросить об использовании AI-инструментов. Сейчас объясню почему

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

Во-вторых, у тебя пока нет доказательств того, что он сливал данные или допускал другого человека к выполнению своей работы. Увольнять «по подозрению» или сразу тащить в HR с обвинением — значит рисковать как собственной репутацией, так и атмосферой в команде. Если ты ошибаешься, это сразу же подорвёт доверие не только Саши, но и всех остальных разработчиков. Подобный риск неоправдан

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

В-четвёртых, даже если подозрения подтвердятся, важно не торопиться «наказывать» или увольнять, а сначала разобраться в деталях: что именно он делал, какие сервисы использовал (Claude, ChatGPT, Copilot, Eleven Labs, HeyGen, Synthesia и т.д.), и какие именно риски это несёт для компании. Это поможет и с пониманием того, какие процессы нужно улучшить и какие барьеры безопасности поставить, чтобы не пострадала бизнес-логика или персональные данные

Почему не другие варианты?

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

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

Конфиденциально обсуждать с HR или руководством без предварительного разговора с Сашей — тоже не лучший путь, пока нет хоть каких-то фактов. Руководство ждёт от тебя решений, а не просто эскалации сомнений

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

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

P.S. Как ты думаешь, насколько скоро мы начнем с ним сталкиваться?

Здравствуй, ищущий новых возможностей читатель!

Могу тебя понять, если ты устал разруливать задачи и чувствовать себя посредником между требованиями и командой. Если тебе хочется наконец научиться управлять, вдохновлять людей и понимать бизнес, то есть одна программа «Управление проектами и командами в IT» от Нетологии в кооперативе с РАНХиГС . Возможно она даст тебе тот самый необходимый для роста толчок

Вот в чём её ценность: там не просто «давайте перескажем методичку Вани Селиховкина про управление проектами. Преподаватели – люди, которые проворачивали большие проекты в Сбере, Luxsoft, DXC и других IT-гигантах. Ты с головой погрузишься в типовые кейсы, научишься чувствовать команду и держать твёрдую хватку в бюджете, планах и управлении персоналом. А по итогу – соберёшь в портфолио несколько учебных проектов и получишь диплом отличной бизнес-школы

Представь, что ты перестаёшь быть «хранителем тасок». Ты уже понимаешь, где явно не хватает механизма change request, а где оптимизировать управленческий бюджет, как превратить смутные требования заказчика в понятный план. Бонусом – перестанешь краснеть на совещаниях, когда речь зайдёт про runaway или прогноз OPEX/CAPEX

Учись на курсе, чтобы расширить свои возможности: https://netolo.gy/d3Cs

Реклама. ООО “Нетология", ИНН: 77264641257. Erid: 2VSb5z5Apcp

#полезности
PSM I: сертификат, который может пригодиться (а может и нет). Часть 2

Где и как готовиться к PSM I:
- Начинаешь с Scrum Guide 2020** (это важно, старые версии не годятся):
- Оригинал (англ.) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
- Перевод (рус.) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Russian.pdf
- Изучи Scrum Glossary (терминологию):
- Scrum Glossary от Scrum.org https://www.scrum.org/resources/scrum-glossary
- Полезно ознакомиться с Nexus и Evidence-Based Management (EBM), которые могут мелькать в вопросах:
- Nexus Guide https://www.scrum.org/resources/nexus-guide
- Evidence-Based Management https://www.scrum.org/resources/evidence-based-management
- Смотри поясняющие видео на YouTube:
- Хороший плейлист с разбором Scrum Guide https://youtube.com/playlist?list=PLKIWQ-FbTWhz9we1Z04L59JyVac7e-1LE
- Лучшие тренажёры и тесты для подготовки (делать их лучше по кругу и первых 2 вполне достаточно):
- Официальный Scrum Open Assessment https://www.scrum.org/open-assessments/scrum-open – покрывает около 10-12% реальных вопросов.
- Тренажёр Михаила Лапшина https://mlapshin.com/index.php/scrum-quizzes/sm-real-mode/ – хороший, но местами устарел (аккуратнее с модальными глаголами).
- Techagilist Practice Exam https://www.techagilist.com/practice-exams/psm-i-practice-test/psm-practice-exam-real-mode-questions/ – неплохой набор вопросов с пояснениями.
- Тренажёр с The Scrum Master https://www.thescrummaster.co.uk/quizzes/professional-scrum-master-i-psm-i-practice-assessment/
- Тренажёр на Internet80](https://internet80.com/psm-i-exam-simulator-1/
- Для любителей курсов Udemy:
- Complete Professional Scrum Master Training & Exam Simulator https://www.udemy.com/course/complete-professional-scrum-master-training-exam-simulator/
- Scrum Master Certification Prep (Mock Exams) https://www.udemy.com/course/scrum-master-certification-preparation-mock-exam-questions-psm-i) — подробный, но «ванильный» пересказ гайда с акцентами и тренажёрами.
- Дополнительные полезности:
- Scrum Reference Card https://scrumreferencecard.com/scrum-reference-card/
- Suggested Reading от Scrum.org https://www.scrum.org/resources/suggested-reading-professional-scrum-master

Как понять, что ты готов?

Делаешь тесты по кругу до тех пор, пока стабильно не начнёшь выбивать 90-95%. Как только смог пройти тесты на 80 вопросов за 10-15 минут с результатом выше 90% — считай, готов

Но имей в виду: это сертификат, который не сделает из тебя профи. PSM I подтверждает только то, что ты прочитал и запомнил Scrum Guide. PSM II — куда более кейсовый и непростой. А PMP и вовсе отдельная сложная история

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

P.S. Возможно, после получения сертификата у тебя возникнет ощущение, что «это всё шиза какая-то». Но даже в этом случае ты будешь увереннее говорить: «Да, я в курсе, как должен работать Scrum. У меня есть сертификат, если что».

#полезности
PSM I: сертификат, который может пригодиться (а может и нет). Часть 1

Здравствуй, задумавшийся читатель!

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

Но тут возникает вопрос: а нужен ли он тебе вообще? В России всё просто: сертификаты знают плохо. PMP ещё как-то слышали, PSM I почти никому не нужен, а про остальные говорят примерно как про сетевые диаграммы — кто-то что-то слышал, но никто толком не знает, зачем они были нужны

Однако всё сильно меняется, как только начинаешь смотреть на глобальный рынок (или хотя бы международные компании с офисами в РФ). Тут уже сертификат по Scrum — это весьма частый гость на собеседованиях и в требованиях к вакансиям. Когда я собеседовался вне России или на позиции, чуть дальше от классического проджекта, каждый 5-й раз возникал вопрос про наличие сертификатов вроде PSM, KMP, SAFe и им подобных

Тогда возникает вопрос номер два: если делать, то какой? Ответ простой: самый быстрый, простой и эффективный вариант, если ты хочешь подтвердить знание Scrum и быстро добавить что-то весомое в резюме — это PSM I от Scrum.org

Почему именно PSM I?

Во-первых, с ним относительно просто. PSM I — это не про реальные кейсы или сложные ситуации на проекте. Он проверяет, что ты действительно внимательно прочитал Scrum Guide, понимаешь его терминологию и различаешь нюансы в формулировках (внимание на модальные глаголы: should, must и could!)

Например, может ли Scrum-команда состоять из 11 человек? Да! Потому что Scrum Guide говорит, что команда должна быть (should be) не более 10 человек, а не обязана (must be). Вот такие детали могут решить исход экзамена. В целом если не знаешь английский, встроенный переводчик в браузер или расширение браузера в помощь

Во-вторых, он доступен и финансово, и организационно: из РФ/СНГ сдаётся онлайн, нужна только стабильная связь и карта для оплаты. Сложностей с этим обычно не возникает

В-третьих, его ценность в соотношении затраченных усилий и результата почти идеальна. Для сравнения: PMP — более замороченный и кейсовый экзамен, подготовка требует много времени и опыта. PSM I — совсем другая история. 15-20 часов суммарной подготовки вполне хватит для уверенного прохождения

#реклама
Легкий единый воркспейс

Здравствуй, прагматичный читатель

Ты наверняка сталкивался с продуктом на букву Б — ну знаешь, эта штука, где можно и задачи вести, и клиентов заводить, и даже CRM встроена. Круто же? Ну, почти. Только потом оказывается, что всё это богатство иногда превращается в медленного и неповоротливого монстра, который бесит, тормозит и требует постоянных танцев с бубном

Так вот, я недавно наткнулся на интересный аналог — O!task. Представь, что Б.. вдруг перестал есть на ночь, записался в спортзал и стал гибким и подтянутым. Это вот про него:

— Легковесный таск-трекер, где сразу понятно, что где горит, кому и когда пора начинать паниковать;
— Учёт финансов и времени без Excel-кошмаров. Можно, наконец-то, просто понять, почему ты снова не укладываешься в плановый кэшфлоу и случился разрыв;
— База знаний и шаблоны документов всегда под рукой, без лишних заморочек;
— CRM сразу внутри, не нужно бегать по десяти вкладкам и вспоминать, кому ты должен ответить;
— Гибкие уровни доступа и даже Telegram-уведомления, чтобы важные сообщения больше не терялись среди сотни непрочитанных писем.

Всё в одном окне — и никаких тяжеловесных интерфейсов и непонятных процессов. Просто удобный, здоровый подход.

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

В общем, если ищешь занятный инструмент, способный легко и непринуждённо поддерживать разные процессы и флоу в одном месте, попробуй O!task

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

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

Ты работаешь tech PM в компании, разрабатывающей платформу автоматизации документооборота и согласований для среднего и крупного бизнеса. Рынок у вас высококонкурентный, постоянно гонитесь за новыми фичами и удобством, стараясь опередить конкурентов. Внутренние процессы классический Scrum: двухнедельные спринты, регулярные ревью, еженедельные ретро и оживленные обсуждения задач на дейликах

Твоя команда небольшая, но сыгранная: два синьора-бэкендера, два фронтендера (мидл и синьор), два мидла Python-разработчика, тестировщик, аналитик, дизайнер и devops-инженер. Команда открытая, с живым общением и дружеской атмосферой

Около полугода назад к вам присоединился Python-разработчик уровня middle — Саша. Парень интересный, хоть и немного интровертный, увлекается шахматами, много рассказывает о походах в горы и любит философствовать на ретро, мол, «жизнь — это непредсказуемый алгоритм с хаотичными данными». Коллегам он понравился, однако рабочие моменты поначалу складывались сложно: на ревью его коммиты прилетали с опозданиями, код был неаккуратным и метался от camelCase к snake_case. Комментарии к задачам в Jira были очень скромные, приходилось вытягивать детали и постоянно напоминать ему о лучших практиках

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

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

Сомнения начали усиливаться: возможно, Саша использует нейросетевых помощников (Claude, ChatGPT, Copilot) для написания кода и комментариев. Вроде формально придраться сложно — задачи делаются, команда ускорилась, заказчик счастлив. Но вопросы этики, конфиденциальности и внутренней политики безопасности данных никто не отменял, а вдруг бизнес-логика проекта уже где-то лежит на сторонних серверах?

Недавно проблемы с интернетом, на которые Саша постоянно ссылался, решились, и он стал активнее общаться голосом и иногда даже включать видео на созвонах. Казалось бы, всё наладилось, но тут появилось новое ощущение, ещё более жутковатое — тот самый эффект «зловещей долины». Ты замечаешь, что движения его лица и губ на видео как будто немного неестественны, иногда чуть запаздывают или опережают слова. Голос ровный и глубокий, но словно слишком «идеальный». Ты начинаешь подозревать, что дело дошло до использования AI не только в тексте, но и голосом и видео с помощью инструментов вроде Eleven Labs, Synthesia, HeyGen или DID. Возможно, перед тобой вовсе не Саша, а его дипфейк-аватар

Ты стоишь перед выбором: принять ситуацию или срочно действовать?

#реклама
Как перестать вести десятки тулов и начать жить

Здравствуй, экономный читатель!

У тебя тоже бывает, что открываешь рабочий браузер, а там 14 вкладок: roadmap, CJM, бэклог, Kanban, гипотезы, и всё срочно нужно держать под контролем? Мне вот знакомо. И держать это всё в голове — примерно как жонглировать горящими мячиками: вроде возможно, но не хочется проверять

На днях ко мне зашла команда flip и рассказала, что сделали сервис для таких же страдальцев, как ты и я. Ребята устали от костылей и создали аналог Miro, только удобнее и точно без внезапного «до свидания»:

— Roadmap и бэклог ведутся наглядно, а не в Excel, от которого глаз дёргается;
— CJM и пользовательские сценарии рисуются прямо там же;
— Вся команда обсуждает задачи и фидбэк в одном месте, а не в десяти мессенджерах;
— Канбан-доски, JTBD, Service Blueprint и другие инструменты уже встроены;
— Ну и AI-генерация картинок, если нужно быстро наклепать слайды и не искать дизайнера в три ночи.

🎁 У flip уже 50 тысяч пользователей, и по такому поводу они дают очень приятную акцию: оплачиваешь 3 месяца подписки и ещё 3 месяца получаешь бесплатно. Акция действует до 31 марта 2025 года

Короче, если устал закрывать бесконечные вкладки — попробуй flip

P.S. Условия и подробности тут: https://clck.ru/3HxX8a

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

Лучшим выбором для тебя будет именно «галера» (второй вариант), и вот почему

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

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

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

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

Почему не другие варианты?

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

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

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

Таким образом, несмотря на то, что каждый из вариантов по-своему хтоничен, именно второй вариант) даст тебе наиболее качественный, структурированный и разносторонний опыт

#мнение
Четыре ипостаси Delivery Manager-а

Здравствуй, вопрошающий читатель!

Давай поговорим о самом таинственном звере в джунглях IT — Деливери Менеджере. И если ты думал, что здесь всё просто, то нет, у меня плохие новости. Тут также как ПМ-ами (удивлен что скрам-мастеры избежали такой судьбы) : на вид одинаково, а вот начинка может удивить. Итак, разбираем по полочкам

1. Agile-коуч здорового человека (новый канбан-толк)

Представь себе Деливери менеджера как опытного терапевта, который лечит не симптомы, а систему. Он смотрит на команду как на чёрный ящик, повышая её стабильность, прозрачность и предсказуемость. Это не про планирование релизов и задач, а про создание условий, чтобы у команды как сервиса ушли препятствия для выполнения работы. В таких ролях DM часто встречается в HH, МойСклад и Спортмастере, Банк СПб. Вообще в больших банках иногда любят запускать с ними эксперименты

2. Тимлид с приставкой «системный» (старый канбан-толк)

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

3. Начальник ПМ-ов (аутсорс и геймдев)

Здесь уже всё бюрократичнее. Деливери менеджер — это почти генерал, который следит за тем, чтобы ПМ-ы не наделали бед и всё отгружалось заказчику по внутренним стандартам качества и срокам. Он же подключается, когда запахло жареным, и начинает тушить пожары, спасая от разборок с клиентом. Короче, процессный менеджер и кей-аккаунт в одном лице, который заботится о репутации компании и сохранении клиентов. EPAM, DataArt и им подобные любят такой подход

4. Data-driven менеджер изменений (управление изменениями как функция организации)

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

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

P.S. Прежде чем пойти на собеседование, спроси у рекрутера:
"У вас Деливери больше про метрики и прозрачность, про эффективность и лидершип, про работу с заказчиками или вообще про изменения?"

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

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

Ты — кандидат в проектные менеджеры, настолько зелёный, что у тебя даже студенты синергии вызывают чувство зависти. Последние пол года ты был эдаким «эникейщиком» в стартапе у друга: чуть-чуть потестил, повёрстал лендинги на Тильде, написал пару десятков статей в блог на vc ru, немного поадминил Jira, отсидел все возможные митинги и даже попытался провести ретроспективу, на которой вся команда молчала так, будто ты был у неё денег в долг просить

Внутренне ты считаешь, что менеджер — это больше про общение и процессы, чем про технические детали. Ты уверен, что подход «любой ценой, но лишь бы горело» — это плохо, Agile бывает только в книжках, а планирование нужно хотя бы для того, чтобы было что потом корректировать. Мечтаешь получить работу мечты в компании на букву «Я», но они почему-то тебя пока не зовут

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

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

Вторая компания — жестокая галера, о которой ходят страшные слухи. Процессы там прописаны с точностью до миллисекунды, но никто их не соблюдает, зато все соблюдают «главное правило компании»: «Ты виноват по умолчанию, даже если был в отпуске». Каждое твое движение нужно зафиксировать в таймшите Jira и еще в системе внутреннего контроля, о которой даже системные админы говорят с трепетом. На работе нужно появляться строго к 9:00, за опоздание на минуту надо писать объяснительную на имя замдиректора по кадрам, которому 73 года и он тебя искренне не уважает. Но зато есть ДМС, йогурты по пятницам и ежегодный корпоратив на природе в Карелии

Третья компания — мутнейший аутсорс-оффшор, чей офис формально в Москве, но разработка — в Индии, QA — в Пакистане, а клиент — в Нью-Йорке. Из-за разницы часовых поясов тебе нужно работать в формате 24/7, а таски обычно звучат как «Сделайте ASAP, красиво и бесплатно». Культура общения отсутствует как явление, PM-ы выгорают и увольняются примерно через 4 месяца, а в документации индийского техлида тебя ждет хинглиш и что-то подозрительно похожее на мантры чтобы работало. Зато международный опыт

Четвёртая компания — крупная госконтора, монструозная структура, где слово «цифровая трансформация» означает заменить бумажную почту на скан и отправить его факсом. IT-проекты тут выглядят как «закупить 3000 лицензий и согласовать их через восемь отделов», а слово «инициатива» приравнивается к опасному преступлению. Рабочий день до минуты регламентирован, с 8 до 19 ты ведешь телефонные переговоры, заполняешь служебки и пытаешься найти крайнего в бюрократической паутине. Зато у тебя будет официальная запись «Руководитель проекта» и зарплата чуть выше рынка

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

Куда пойдёшь?

Приглашаем на Пиэмную — бесплатный митап ЮMoney для руководителей IT-проектов 🔥

🕓 20 марта, в четверг, в 18:30 (мск) приходите на митап в Санкт-Петербурге или подключайтесь онлайн.

Спикеры из ЮMoney, «Ренессанс Страхование» и основатель ScrumTrek расскажут, как управляют проектами и командами, а после докладов ответят на вопросы зрителей.

О чём расскажут на митапе:

🟣 AI убьёт Agile? Как ИИ трансформирует работу компаний.
🟣 Менеджер в квадрате, или как принимать управленческие решения не одному.
🟣 Управление проектами в «Ренессанс Страхование»: совмещение ролей продакта и проджекта.
🟣 Я крутой менеджер: что дальше?

Чтобы попасть на митап, нужна регистрация, все подробности — на сайте Пиэмной ✅

#артефакты
Карточки сотрудников или мой карманный инструмент КГБ-шника

Здравствуй, прозорливый читатель!

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

А пока поделюсь инструментом, который я использую (в кои-то веки тег артефактов!)

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

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

Перечень пунктов, которые я описываю, можешь глянуть по ссылке шаблона https://artemletyushev.notion.site/1b8394f4bde5807098c0dc0dd581586c?v=1b8394f4bde58179a439000c6dfd9317, однако поясню несколько спорных и малопонятных вещей

1. Психотип. Да, я использую PAEL Адизеса, потому что он частично сходится с моими наблюдениями. Я в него не верю и не считаю, что это ответ на все вопросы. Для меня это лишь простая форма описания того, что кому-то пофиг на процессы, а кому-то пофиг на взаимоотношения с людьми

2. Мотивация. Тут в целом без разницы что выбрать, я для себя использую Герчикова. Почему? Я работаю в основном на СНГ-рынке, и работы Герчикова неплохо ложатся на постсоветскую ментальность. К тому же это не постоянный фактор, а вопрос того, на чём у человека фокус и какая мотивация прямо сейчас ярче всего выражена.

3. Ну и есть мой личный прикол, по которому я оцениваю, может ли человек выступать как руководитель. Такая вот система координат из трёх измерений: мотивация быть руководителем, навыки быть руководителем и стержень быть руководителем. Для себя я формирую из них квадранты, когда знакомлюсь с людьми, и в основном использую, чтобы применять анекдотичный подход «учить←лечить←мочить» относительно членов команд, но преимущественно лидов, с которыми работаю. Может, как-нибудь напишу об этом подробнее

Как я веду карточки?
В моей отдельной скрытой базе знаний, например, в корпоративном закрытом от просмотра Confluence. Более подробно — на лидов, с которыми работаю напрямую, менее подробно — на моих руководителей и сотрудников моих лидов

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

Что это мне даёт?
Во-первых, я лучше запоминаю своих коллег и лучше раскладываю по полочкам информацию. Во-вторых, я больше про них узнаю и начинаю им больше доверять. Кстати, когда знакомлюсь, стараюсь тоже очень много про себя рассказывать — это должно работать в обе стороны. Ну и, конечно, это помогает точнее конфигурировать команды, с которыми я работаю

P.S. Я еще у меня не самая сильная память, поэтому лучше записывать

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

Правильный вариант – последний: навести прозрачность и организовать отчетность для PMO. Сейчас объясню, почему

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

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

1. Как сейчас идет работа – кто что делает, какие задачи есть, какие блокеры
2. Где реальные проблемы – что сломано в процессах, почему релиз выглядит как утопия
3. Как это исправить – что можно сделать прямо сейчас, а что требует времени

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

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

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

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

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

И последнее – не строить иллюзий про быстрые изменения. В такой ситуации, как правильно заметили в обсуждении, твоя задача не в том, чтобы «срочно починить», а в том, чтобы создать порядок, не стать крайним и продержаться, пока ты не сможешь реально повлиять на ситуацию

P.S. Да я задолбался, несколько переоценил себя и когда стал перегружен несколько отложил блог, вот наверстываю!
P.S. На фото чучело которое не загорелось спустя кучи пыпоток

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

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

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

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

Что ты видишь в первый день:
- Продукт в проде уже 3 года, но технический долг – огромный. Код – легаси с патчами и костылями.
- В Jira – полный хаос, куча старых задач без актуальных статусов, несвязанные тикеты, часть сделанные, но не закрытые
- Команда не работает с доской – дейли митинги проходят в формате "каждый говорит, что делает", без фиксации статуса
- Документация? Она есть. Но только Postman-коллекции и комментарии к коду в репозитории
- Саппорт ненавидит продукт. Он тормозит, неудобен, не обновляется годами. Операторы давно ведут всё в своих гугл-таблицах, чтобы не зависеть от системы или просят некоторых разработчиков делать апдейты сразу в БД

Половина команды (бэкенд, фронт, аналитик, тестировщик) откровенно раздражены сменой проджекта, считают, что ты будешь "опять что-то ломать в процессах". Делятся контекстом неохотно
Старый менеджер слился в другую компанию, оставив Confluence-док с парой ссылок на архитектуру и пару старых встреч в Zoom-записях

Но самое веселое – в проектный офис пришла резолюция:
1. В компании сменился CTO, и теперь все ПМ-ы "на испытательном сроке", идет аудит;
2. В течение 2 недель нужно навести порядок, сделать прозрачную отчетность и статусность проекта;
3. Если этого не будет – будет поднят вопрос о переводе ПМ-а на бенч и дальнейших оргвыводах о полезности в компании

При этом у команды уже поставлен релиз через 3 недели с новой экспертной системой, обещанный старым менеджером, но никто не понимает, реально ли это

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

Как будешь действовать?

#мнение
Баланс компетенций PM

Здравствуй, неуверенный читатель!

90% PM считают, что они профаны, потому что им втирают, что без умения кодить или тестировать никуда. Ребята, пора разобраться. Многие путают харды проектного менеджера с техническими навыками подчинённых. «Понимать, что происходит» – не значит, что надо писать на JS на уровне мидла или проектировать DWH. Это подмена понятий

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

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

Метанавыки – это фундаментальные способности мозга для адаптации и познания, такие как умение учиться или критически мыслить. Кстати, в 2025 советую освоить обучение, которое подходит именно тебе, например пройти курс https://www.coursera.org/learn/learning-how-to-learn

Есть отличные концепции, выступающие проводниками навыков PM, например PMI Talent Triangle. Сейчас он включает три ключевые области:

- Ways of Working – гибкое применение методологий и инструментов (Agile, Waterfall, DevOps) в зависимости от ситуации;
- Power Skills – лидерство, коммуникация, переговоры, умение вдохновлять и влиять;
- Business Acumen – понимание домена, стратегии, финансовых аспектов и бизнес-моделей.

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

Кстати, IPMA в своём стандарте ICB4 (Individual Competence Baseline) тоже даёт похожий взгляд. Там выделяют три группы компетенций: People (работа с людьми и коммуникации), Practice (инструментальные и методологические умения) и Perspective (стратегическое видение и контекст). Всё вместе даёт комплексное понимание, каким должен быть PM, чтобы гармонично сочетать работу с людьми, инструментами и общим бизнес-направлением

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

P.S. Иногда стоит просто дать себе время выдохнуть и вспомнить, что мы не обязаны знать всё на свете – достаточно осознавать, как организовать работу людей, которые это знают. Да и не боги горшки обживают

#полезности

Инфографика и схемы по System Design

Здравствуй, считающий себя техническим менеджером проектов или просто хорошо подкованным в техничке читатель. В дополнение к https://t.me/junior_pm/278 нашел классный набор схем

https://miro.com/app/board/uXjVLw0JIYw=/

Зачем я это публикую? Да как обычно - пишу о том, о чем мне интересно, к тому же пытаюсь наверстывать упущенное и чуть углубляю свое понимание того чем управляю

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

Кожаные мешки, вам тут 👆послание от Макса👆

Говорит, что Клода, Чат GPT и Джемини можно в одном окне теперь использовать и контекст не терять.

👉 Ссылку здесь оставил

#реклама
О рекламодателе

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

Правильного ответа нет. Но совершенно точно нужно отбросить пункт 2 – просто давить на тимлида или CTO тут бесполезно. Сейчас объясню, почему

Есть четыре важных момента в ситуации. Во-первых, ты скрам-мастер без опыта, и нужно чётко решить: будешь ли ты держаться каноничной роли СМ-а или выйдешь за её рамки ради спасения ситуации. Во-вторых, клиент, который приносит 30% выручки, — это крупный кит с индивидуальными договоренностями, терять его нельзя. В-третьих, проблема на самом деле не техническая: условный контрагент вроде «Калуга Астрал» наверняка поменял параметры интеграции, и теперь SKU просто не проходят в нашу систему. Фиксится такое быстро, нужны переговоры и пара простых доработок с любой стороны. Четвёртый аспект – команда уже привыкла к коллективной безответственности, и сейлзы вместо того, чтобы отработать партнёрски с клиентом, передают тебе ультиматумы просто от безнадёги и слабых переговорных навыков

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

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

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

#мнение
Один из десятков концептов мотивации

Здравствуй, мотивированный профессионал – читатель!

За последние годы я столкнулся с множеством подходов: психопрофилирование, мотивационные пирамиды и методики вроде DICS и подходы Герчикова. Все они обещают понимание, просветление и простоту, но часто оказываются поверхностными

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

Ознакомившись с выдержками и статьями по мотивационным идеям Дэниела Пинка, я понял, что принципы автономии, стремления к мастерству и ощущения цели полностью совпадают с моими взглядами. Я не читал всю книгу «Драйв» – для формирования мнения мне достаточно было материалов, которые я изучал через статьи и даже прогнал через GPT Structured Output с reasoning

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

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

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

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

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

Ты — новый скрам-мастер в B2B-продуктовой компании, которая разрабатывает SaaS-решение для автоматизации складского учета. Это твоя первая серьезная работа, ты вдохновлен идеями Agile и готов помогать команде работать эффективнее.

Но очень быстро ты понимаешь, что скрам в команде есть только номинально.

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

Ты пытаешься вникнуть, но тут случается катастрофа.

Крупный клиент, который приносит 30% выручки, внезапно присылает письмо: “Ваш сервис не позволяет нам добавить новые SKU, бизнес встал. Если не решите за 24 часа, мы уходим.”

Ты поднимаешь команду, но начинается шоу "это не моя проблема":

— Разработчики: “Это на стороне бэкенда, фронт тут ни при чем.”
— Бэкенд: “Это не у нас, данные от контрагентов пришли в сломанном формате, пусть продукт разбирается.”
— Продукт: “Я не знаю, что тут сломалось, спросите тестировщиков.”
— Тестировщики: “А нам никто не говорил, что это критично, мы не приоритетили этот сценарий.”
— Тимлид: “Ну да, баги бывают, но что вы от меня хотите?”
— CTO: не отвечает на сообщения, видимо, опять на встречах с инвесторами.

А тебе пишут из продаж:

“Ну что, клиент уже нервничает, что сказать? Что делаете?”

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

Как будешь действовать?

P.S Картинка из старого новостного сюжета про то как вокруг тушат пожар, а рыболов невозмутимо удит

#рецепт
Важные для проектного менеджера понятия технички. Часть 3

9) Какие практики автоматизируют ручные операции в IT?

– VCS (ветки, коммиты, мерж, реквесты)
– CI/CD (сборка, тестирование, деплой, Jenkins)
– Контейнеризация (Docker, изоляция)
– Окружения (development, staging, production)
– Управление секретами
– IaC (Infrastructure as Code) (автоматизированное развертывание инфраструктуры, Terraform, CloudFormation)
– Мониторинг и логирование (сбор метрик, Prometheus, Grafana, ELK)
– Управление конфигурацией (единое управление настройками, Ansible, Puppet, Chef)

10) Как обеспечивается масштабирование и высокая производительность?

– Горизонтальное масштабирование (добавление серверов)
– Вертикальное масштабирование (расширение ресурсов)
– Репликация (копирование данных, отказоустойчивость)
– Балансировка нагрузки (NGINX, распределение запросов)
– Кэширование (Redis, Memcached, ускорение доступа)
– Обработка отказов (резервирование, восстановление)
– Load testing (оценка производительности)

11) Как организована IT-инфраструктура и поддержка сервисов?

– Мониторинг (отслеживание состояния, метрики)
– Алертинг (системы оповещений)
– Резервное копирование (backup, периодичность)
– Бэкапы (архивирование, восстановление)
– Облачные сервисы (IaaS, PaaS, SaaS)
– CDN (быстрая доставка контента)
– DNS-серверы (управление доменами)

Теория – это хорошо, но одного прочтения мало. Практика должна закреплять знания. Вот три варианта, как можно это делать:

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

2) Рисуй схемы – составь, например, компонентную диаграмму интернет-магазина или ER-диаграмму для своей базы данных. Используй GPT для визуализации – попробуй GPTs, например по ссылке https://chatgpt.com/g/g-B1Bfoq5qh-uml-diagram-expert, который реально помогает отрисовывать диаграммы.

3) Пиши свой micro-SaaS.http://cursor.ai или аналоги вполне могут тебе помочь

P.S. Сейчас такое время, когда я смог за один вечер с GPT сложить чёткое понимание OSI и TCP/IP, вместо того чтобы валяться над 700-страничной книгой по компьютерным сетям как на ИВТ в ВУЗ-е

P.P.S. Вот также сборная солянка от одного хорошего человека в одном документе https://docs.google.com/document/d/1CzTkVPdiC6-0oit3yoGJlD2AM0xzGJD7pO08PIUNg1w/edit?tab=t.0#heading=h.8wrxytxwlauq и отличная книга https://www.litres.ru/book/aleks-suy/system-design-podgotovka-k-slozhnomu-intervu-67193183/

#рецепт
Важные для проектного менеджера понятия технички. Часть 2

5) Как данные хранятся и обрабатываются?

– Таблицы (строки, столбцы, структура)
– Реляционные и нереляционные БД (таблицы vs документы, кортежи vs key-value, связи и ключи vs графы)
– Нормальные формы (структурирование, целостность)
– SQL-запросы (выборка, вставка, создание, обновление и параметры)
– Индексы (ускорение поиска)
– Транзакции (атомарность, целостность)
– Хранимые процедуры (запрограммированные операции)
– Вьюшки (логические представления)

6) Как работает отправка сообщений без немедленного ответа?

– Очередь сообщений (последовательность, асинхронность)
– Брокер сообщений (маршрутизация, управление очередями)
– AMQP (RabbitMQ) (протокол, гарантированная доставка)
– Kafka (потоковая передача, масштабируемость)
– Redis (Pub/Sub, in-memory, высокая скорость)

7) Как разные части систем организуют в структуру?

– Клиент-серверная архитектура (клиент, сервер, запрос-ответ)
– Монолитная архитектура (единое приложение, централизованность)
– Микросервисная архитектура (независимые сервисы, масштабируемость)
– N-tier архитектура (слоистость: данные, бизнес-логика, представление)
– Энтерпрайз архитектура (корпоративная интеграция, масштаб)
– Serverless архитектура (FaaS, облачные функции, автоматическое масштабирование)
– Фронтенд архитектура (MVC, MVVM, MVP)
– Стили архитектуры (Layered, Event-driven, Microkernel, Service-Oriented, Space-based, Pipe-and-Filter, Broker, Peer-to-Peer)
– Паттерны (API Gateway, BFF, Circuit Breaker, Saga, CQRS и т.д.)

8) Как обеспечивается безопасность?

– Аутентификация (подтверждение, идентификация, токены, сессии)
– 3rd party (аутентификация, токены, типы)
– Авторизация (права доступа, контроль)
– Шифрование (криптография, защита данных)
– SSL/TLS (шифрование трафика, сертификаты)
– Фаерволы (фильтрация, контроль доступа)
– VPN (защищённое соединение, туннелирование)
– IDS/IPS (обнаружение, предотвращение вторжений)
– Двухфакторная аутентификация (otp, totp)
– SSO (единый вход)
– SAML (протокол обмена аутентификационными данными)
– Модели управления доступами (permission shema, ACS)

#рецепт
Важные для проектного менеджера понятия технички. Часть 1

Привет, читатель! Я забыл подготовить задачу, поэтому будет другое, но также полезное

В условиях, когда нейросети всё активнее влияют на нашу жизнь, становится пользительно иметь хотя бы поверхностное представление о том, что происходит вокруг. Знать эти концепции — значит быстрее ориентироваться в том, с чем работает твоя команда, и уметь сложить в голове целостную картину IT-систем. Представь, что ты начинающий PM без глубокого техбэкграунда, а опытный наставник объясняет всё простыми словами, по принципам Фейнмана. Ниже приведён перечень тем, которые стоит поочерёдно разбирать с помощью GPT — по одной теме в отдельном чате. Вот список, который поможет тебе быстро разобраться в сложной терминологии на уровне энтерпрайзных систем, а не университетских лекций по C или Python

1) Что происходит, когда данные передаются по сети?

– Модель OSI (интерфейсы, уровни, преобразование сообщений)
– Модель TCP/IP (протоколы, интерфейсы, маршрутизация)
– Протокол TCP (надежность, установление соединения, контроль ошибок)
– Протокол UDP (скорость, отсутствие подтверждения, неупорядоченность)
– IP-адрес (статический, динамический, адресация)
– MAC-адрес (уникальный физический идентификатор)
– Сетевые порты (идентификация сервисов)
– DNS (разрешение доменных имен)
– Хостинг (серверы, инфраструктура)

2) Что происходит при открытии сайта в браузере?

– URI (схема, путь, параметры, кастомные схемы)
– URL (схема, домен, порт, путь, параметры)
– HTTP (методы, заголовки, параметры, статусная строка)
– HTTPS (SSL/TLS, шифрование, безопасность)
– Браузер (интерпретация, рендеринг)
– HTML (структура, разметка)
– CSS (стили, внешний вид)
– JavaScript (динамика, интерактивность)
– DOM (структура документа)
– Cookies (сессионные данные)
– Кеширование (локальное хранение, ускорение загрузки)

3) Как передаются сообщения в сети интернет?

– REST API (методы, заголовки, параметры, статусная строка)
– SOAP (XML, WSDL, структура обмена)
– GraphQL (запросы, схема, резолверы)
– gRPC (RPC, HTTP/2, бинарный протокол)
– Webhooks (обратные вызовы, события)
– WebSockets (постоянное соединение, двунаправленная связь)
– Пуши (веб и мобильные пуш-уведомления, Server-Sent Events – SSE)

4) Как организуются интеграции между системами в интернете?

– Файловый обмен (форматы, периодичность)
– Общая база данных (совместное использование, консистентность)
– Вызов удалённой процедуры (RPC, прямые вызовы)
– Асинхронный обмен сообщениями (очереди, брокеры)
– Ресурсный стиль (REST) (HTTP, CRUD, JSON)
– RPC-стиль (синхронные вызовы)
– Query-стиль (запросы, получение данных)
– Publisher/Subscriber (подписка, уведомления)

Облака для продуктов: как не утонуть в инновациях

Заметили, как чем больше компаний выкатывают свои продукты, тем сильнее набирает обороты мир SaaS и micro-saas? Ну а я, признаюсь, уже наколдовал пару планов запустить свои micro-saas ради проверки гипотез (да, немного поддался хайпу и пополнил арсенал продуктовыми навыками)

Но, друзья, чтобы эти сервисы не улетучились в небеса, нужно правильно подобрать облачного провайдера, который даст не просто «облако», а реально managed-решение. Ведь инфраструктура – это не игрушки: стабильность и безопасность здесь на первом месте. Даже AWS во Франкфурте время от времени подкидывает сюрпризы (на деле там uptime по опыту ни разу не 99.999%), так что к облакам надо относиться со всей серьёзностью, не забывая их выгод

И о том, как управлять облаками, запускать собственные сервисы и не сгореть от инфраструктурных вызовов, расскажет конференция K2 CLOUD CONF. Это место, где соберутся профессионалы, чтобы поделиться инсайтами, обсудить реальные кейсы и, конечно, посмеяться над всеми трудностями цифрового мира

Хочешь узнать больше и прокачать свои навыки в облачных технологиях? Жми ссылку и приходи – будет интересно и поучительно!

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

Правильный вариант первый - Следовать указаниям Виктора. Но с хорошим управлением ожиданиями. Ниже напишу почему

Если смотреть через призму PAEL, то фаундер здесь классический E — предприниматель, живущий перспективами и идеями «взять всё и сразу», а менеджер (ты) — больше P, человек результата и четкости. Многие в комментариях говорили, что «это вообще не кейс, ведь очевидно, что менеджер должен был выстроить процесс планирования, и шеринг ресурсов в аутсорсе — нормальная практика». Но важно учитывать, что у любой бюрократии есть косты, и не всегда целесообразно делать громоздкий процесс в маленькой студии. Особенно когда «A»-компонента (процедуры, формальности) может быть лишь в меру — ведь каждая дополнительная регламентация отнимает время и деньги.

Ситуация классическая: E хочет всё и сразу, и видит это как гениальный прорыв, а P считает, что мы можем в полной мере сделать только один проект, чтобы его не загубить. Отсюда основная задача — выровнять ожидания и договориться, ради чего мы вообще рискуем. Телемедицина — флагман и наша кормилица, там dedicated-команда на полную загрузку, плюс долгий контракт. А энергетика пока выглядит как возможность «прокачать портфель» и повысить статус компании, но без четкого ТЗ и непонятными рисками.

Значит, нужно вернуться к «стратегии» или, если никакой формальной нет, хотя бы к здравому смыслу. Задать себе вопрос: в ближайшие полгода важнее доходность и кэшфлоу или репутационные/имиджевые кейсы? Ресурсы не обязательно просчитывать детально, но хотя бы «прикинуть на пальцах», насколько может пострадать телемед и чего мы недосчитаемся, если вдруг увлечемся энергетикой. И точно так же обозначить, сколько всего «неизвестных» в новом проекте и насколько они могут потянуть бюджет и время.

Полномочия менеджера заканчиваются там, где речь идет о выборе портфеля. Он не может решить за всю компанию, но должен подсветить риски, предложить варианты и поуправлять ожиданиями. Если фаундер, в роли «E», всё-таки захочет ввязаться, это его решение. Задача менеджера — зафиксировать согласованные риски, сроки, потери и не дать создать иллюзию, будто мы все потянем одной и той же командой, да еще и без ущерба флагману

P.S. Если не видели старенькое это, стоит увидеть https://www.youtube.com/watch?v=EH_3ukkNuwg

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

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

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

Контекст
Студия не слишком большая, но амбициозная: берется за сложные IT-разработки под разные ниши. У вас сейчас несколько средних проектов, но именно телемедицинский — самый прибыльный и долгосрочный. Фаундер компании, Виктор, всегда охотится за новыми контрактами и верит, что можно «усидеть на двух стульях»: взять еще госзаказ в энергетике, без предоплаты, но якобы с «большим статусом» и обещанным «широким горизонтом» (а по факту — пока одна лишь идея и знакомый заказчик).

Проблема
Из-за желания Виктора ввязаться в этот энергетический гостендер мою команду решили периодически «дергать» на новый проект. Однако вы договаривались, что люди будут погружены на 100% в телемедицину, да и заказчик крайне щепетилен к срокам и качеству. Если вы распылите ресурс на два фронта, рискуем завалить оба: телемедицину — по срокам и качеству, госзаказ — по организации и непроясненным ТЗ. Виктор не видит проблемы, а ты опасаешься, что в итоге «не съем и не надкушу».

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

Другие действующие лица

- Виктор (фаундер): видит в гостендере репутационные и потенциально финансовые выгоды, уверен, что «мы все успеем и от этого только выиграем».
- Аккаунт-менеджер: пытается всем угодить, подыгрывает фаундеру, но при этом передает мне тревожные сигналы; понимает, что конфликта не избежать.
- Команда разработчиков: беспокоится о своей загрузке и качестве работ, не хочет работать без четкого ТЗ в новом проекте, да еще и одновременно с телемедициной.

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

#рецепт
Систематизация поиска работы. Часть 2

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

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

Улучшенная версия с гидами и дополнительными инструментами:
https://docs.google.com/spreadsheets/d/1_HHygL-BfZGbhAgLWa4ivyR-lYTMAD9VPi7cO_BxjOM/edit?gid=877236755#gid=877236755

Оригинальный шаблон:
https://docs.google.com/spreadsheets/d/1C_Q-JwlAnBzN7joxXXkYfx5r9InTWcYWFuxA42hR0i8/edit?usp=sharing

Не стесняйся копировать, настраивать и делиться этим инструментом. А если вдруг список компаний станет таким длинным, что ты начнёшь сомневаться, не отправил ли уже резюме на кого-то — знай: даже я иногда теряюсь в собственных таблицах! 😉

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

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

А еще он вызвал некоторое недоумение и позицию «на работе — только работа, а всё остальное оставляйте за порогом офиса». Но мы же живые люди: невозможно одним щелчком рубильника отрубить часть мозга, которая отвечает за эмоциональные реакции. Поэтому естественно, что в рабочем пространстве могут возникать неприязнь, дружба, романтическое влечение или даже непреодолимое желание покурить с коллегами и заодно обсудить, стоит ли нам нанимать, условно, Катю. Ситуация вполне реальна — я сам с ней столкнулся — и считаю, что это отличный вызов для руководителя, который нужно научиться преодолевать

С одной стороны, всё выглядит щекотливо. С другой, если смотреть через призму ценностей и категорического императива Канта, то всё упрощается

Хочу ли я, чтобы в компании множились «романтические отношения»? Нет, ведь ни мы, ни сотрудники сейчас не настолько зрелы, чтобы спокойно это выдерживать

Хочу ли я, чтобы партнёр вёл себя по отношению ко мне точно так же? Тоже нет: я сторонник честности и прозрачности, а наши проблемы ещё можно починить

Могу ли я пофлиртовать с человеком? Да, вежливо и однозначно без перспективы на что-то большее. Могут ли меня неверно понять? Вполне. Стану ли я повторять это снова? Скорее нет

Поэтому, с моей точки зрения, тут в принципе не было «правильных» вариантов. Важно включиться в выстраивание корпоративной культуры, где станет ясно, что допустимо, а что нет; нам нужны конкретные «правила игры». Если подобный флирт всплывёт снова, стоит привлечь HR и отдельно поговорить с сотрудником, а с партнёром сохранять открытость и тепло: ведь мимолётная симпатия не отменяет сути наших отношений. Правда, некоторые люди предпочитают даже такие нюансы обсуждать друг с другом, и это тоже нормальная практика

#рецепт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После этого в ход идут принципы 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 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь

#мнение #реклама

Здравствуй, читатель

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

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

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

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

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

Пока начало обнадеживает: меня не просто записали, а провели через тест управленческой зрелости, разбор кейсов и проверку на адекватность деловой переписки. Хороший знак — значит, подбирают тех, кто реально замотивирован

Буду учиться, расти и делиться инсайтами. Этот год должен принести большой личностный апгрейд — подтянуть техничку, базовый менеджмент, продуктовые компетенции и даже AI (куда уж без него)

P.S. Всегда было интересно, что и как преподают авторы "Чёрной книги менеджера". Надеюсь это даст мне больше уверенности в своей базе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#реклама

Что может быть лучше чем пет-проект?

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

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

А если подробно – вот мои мысли:

1️⃣ Это свобода учиться тому, что важно тебе
Никакой бюрократии, согласований. Просто выбираешь, что хочешь изучить, и берешься за дело. Я, например, недавно залип на 10 часов в интеграцию OpenStreetMap через разделение на кучу виджетов работу с картой для своего приложения. В процессе не только разобрался, как это работает, но и, кажется, наконец понял до конца, что такое async. Пет проекты легко увлекают, а с ними учиться – одно удовольствие

2️⃣ Это способ добрать опыта, которого тебе не хватает
Если ты начинающий менеджер, ты точно знаешь, как сложно конкурировать на рынке труда. В резюме нужны реальные кейсы, а не «общие слова». И тут пет проект - один из немногих выходов. Никогда не управлял мобильной разработкой? Сделай/поучаствуй в пет проекте. Не знаешь, как работают омниканальные маркетинговые механики? Попробуй создать их в своем мини-продукте. Всё, что ты делаешь в рамках пет проекта, легко ложится в резюме как реальный опыт

3️⃣ Это лучшая зарядка для мозга
Когда ты работаешь над пет проектом, ты решаешь сложные и интересные задачи, которые реально увлекают. Ты сути полностью в потоке и за пару недель проделываешь такую работу, которая в обычной рутине заняла бы месяцы. Количество принимаемых твои мозгом решений астрономическое. Это как играть в го или варгеймы (ну и рил тайм стратегии), только лучше

4️⃣ Это возможность получить новый опыт
На работе не всегда дают шанс попробовать что-то новое, домен или технологию которая тебе интересна или нужна в резюме. А в пет проекте ты сам себе режиссер. Например, я так делал сайт для себя и лучше разобрался в rest и socket-механиках

Что делать, если хочется начать, но не знаешь, с чего?

Загляни в канал «Твой пет проект» – там навалом полезной информации: как выбрать идею, найти первую аудиторию и протестировать на ней свою идею

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

Реклама. ИП Табунов ИНН 773379585100 erid: 2VtzqxdncPv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рецепт
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-проекта...» — Г. Лакман Макдауэлл, Д. Баваро, что также будет очень полезно до начинающих/

#реклама
Зачем работодателю обучать проектному управлению

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

Люблю исследования – в них всегда можно найти что-то полезное. А тут мой знакомый Иван Зверев и ScrumTrek проводят классное исследование про обучение управлению проектами в 2025 году.

О чём оно?
– Почему компании отправляют сотрудников учиться?
– Что важно при выборе курсов?
– Сколько готовы тратить на обучение?
– И главный вопрос: насколько это вообще работает?

Сам недавно снова вернулся к обучению (после перерыва в 2024). Решил, что вечно тянуть нельзя, и скоро снова буду обмазываться сертификатами. Было бы для них место в резюме...

Кого зовут?
– ЛПР, которые решали, кого и зачем отправлять учиться.
– Тех, кто сам учился на курсах и готов рассказать, как это было.

Что делать?
1️⃣ Узнать, относитесь ли вы к одной из категорий;
2️⃣ Понять, готовы ли уделить 45-60 минут на интервью в Zoom;
3️⃣ Написать @ivanzverevpm

Что дадут?
Итоговый отчёт ещё до публикации. Для любителей инсайтов – это находка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#полезности
Вводим больше бюрократии с помощью 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

#рецепты
Вводим больше бюрократии с помощью 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 потому что стали забывать некоторые важные вещи делать и он позволяет не забывать