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

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

Постбэк на 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 недели с новой экспертной системой, обещанный старым менеджером, но никто не понимает, реально ли это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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