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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рецепт

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

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

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

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

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

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

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

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

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

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

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

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

#рецепт
Систематизация поиска работы. Часть 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рецепт
Важные для проектного менеджера понятия технички. Часть 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 (подписка, уведомления)

#рецепт
Важные для проектного менеджера понятия технички. Часть 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)

#рецепт
Важные для проектного менеджера понятия технички. Часть 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#полезности

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

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

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

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

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

#мнение
Баланс компетенций 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. Иногда стоит просто дать себе время выдохнуть и вспомнить, что мы не обязаны знать всё на свете – достаточно осознавать, как организовать работу людей, которые это знают. Да и не боги горшки обживают

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

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

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

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

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

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

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

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

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

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