#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Твоя роль
Ты — проджект-менеджер в аутсорсинговой студии, ведешь коммерчески значимый проект по телемедицине, где изначально обещали полную занятость выделенной команды.
Контекст
Студия не слишком большая, но амбициозная: берется за сложные IT-разработки под разные ниши. У вас сейчас несколько средних проектов, но именно телемедицинский — самый прибыльный и долгосрочный. Фаундер компании, Виктор, всегда охотится за новыми контрактами и верит, что можно «усидеть на двух стульях»: взять еще госзаказ в энергетике, без предоплаты, но якобы с «большим статусом» и обещанным «широким горизонтом» (а по факту — пока одна лишь идея и знакомый заказчик).
Проблема
Из-за желания Виктора ввязаться в этот энергетический гостендер мою команду решили периодически «дергать» на новый проект. Однако вы договаривались, что люди будут погружены на 100% в телемедицину, да и заказчик крайне щепетилен к срокам и качеству. Если вы распылите ресурс на два фронта, рискуем завалить оба: телемедицину — по срокам и качеству, госзаказ — по организации и непроясненным ТЗ. Виктор не видит проблемы, а ты опасаешься, что в итоге «не съем и не надкушу».
Твоя цель
Сохранить фокус команды на телемедицине, не потеряв ключевого заказчика и годовой стабильный доход, но при этом не вступать в открытый конфликт с Виктором и не создать внутри команды хаос и демотивацию.
Другие действующие лица
- Виктор (фаундер): видит в гостендере репутационные и потенциально финансовые выгоды, уверен, что «мы все успеем и от этого только выиграем».
- Аккаунт-менеджер: пытается всем угодить, подыгрывает фаундеру, но при этом передает мне тревожные сигналы; понимает, что конфликта не избежать.
- Команда разработчиков: беспокоится о своей загрузке и качестве работ, не хочет работать без четкого ТЗ в новом проекте, да еще и одновременно с телемедициной.
Ситуация очевидно патовая, и легкого решения здесь нет. Можно либо прогнуть фаундера, рискуя собственной позицией, либо молчать и наблюдать, как тонет твой ключевой проект вместе со всей командой
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Твоя роль
Ты — проджект-менеджер в аутсорсинговой студии, ведешь коммерчески значимый проект по телемедицине, где изначально обещали полную занятость выделенной команды.
Контекст
Студия не слишком большая, но амбициозная: берется за сложные IT-разработки под разные ниши. У вас сейчас несколько средних проектов, но именно телемедицинский — самый прибыльный и долгосрочный. Фаундер компании, Виктор, всегда охотится за новыми контрактами и верит, что можно «усидеть на двух стульях»: взять еще госзаказ в энергетике, без предоплаты, но якобы с «большим статусом» и обещанным «широким горизонтом» (а по факту — пока одна лишь идея и знакомый заказчик).
Проблема
Из-за желания Виктора ввязаться в этот энергетический гостендер мою команду решили периодически «дергать» на новый проект. Однако вы договаривались, что люди будут погружены на 100% в телемедицину, да и заказчик крайне щепетилен к срокам и качеству. Если вы распылите ресурс на два фронта, рискуем завалить оба: телемедицину — по срокам и качеству, госзаказ — по организации и непроясненным ТЗ. Виктор не видит проблемы, а ты опасаешься, что в итоге «не съем и не надкушу».
Твоя цель
Сохранить фокус команды на телемедицине, не потеряв ключевого заказчика и годовой стабильный доход, но при этом не вступать в открытый конфликт с Виктором и не создать внутри команды хаос и демотивацию.
Другие действующие лица
- Виктор (фаундер): видит в гостендере репутационные и потенциально финансовые выгоды, уверен, что «мы все успеем и от этого только выиграем».
- Аккаунт-менеджер: пытается всем угодить, подыгрывает фаундеру, но при этом передает мне тревожные сигналы; понимает, что конфликта не избежать.
- Команда разработчиков: беспокоится о своей загрузке и качестве работ, не хочет работать без четкого ТЗ в новом проекте, да еще и одновременно с телемедициной.
Ситуация очевидно патовая, и легкого решения здесь нет. Можно либо прогнуть фаундера, рискуя собственной позицией, либо молчать и наблюдать, как тонет твой ключевой проект вместе со всей командой
🔥8👍3🎉1💩1
Как будешь действовать в такой ситуации?
Anonymous Poll
9%
Следовать указаниям Виктора, документируя риски и открыто уведомляя заказчика о переносах и причинах
18%
Жесткая позиция, что без полноценной занятости разработчиков проект сорвется
39%
Выделить фиксированные «слоты» под новый проект в команде и прибегнуть к shared team
1%
Позволить команде самостоятельно вести «гос»-часть, лишь поставляя общие рамки
29%
Предложить нанять отдельного PM для энергетики, сохранив мою команду под телемедицину
4%
Твой вариант (напиши в комментариях)
👍3🔥3💩2👏1
#кейс_стади
Задача на подумать для менеджера
Правильный вариант первый - Следовать указаниям Виктора. Но с хорошим управлением ожиданиями. Ниже напишу почему
Если смотреть через призму PAEL, то фаундер здесь классический E — предприниматель, живущий перспективами и идеями «взять всё и сразу», а менеджер (ты) — больше P, человек результата и четкости. Многие в комментариях говорили, что «это вообще не кейс, ведь очевидно, что менеджер должен был выстроить процесс планирования, и шеринг ресурсов в аутсорсе — нормальная практика». Но важно учитывать, что у любой бюрократии есть косты, и не всегда целесообразно делать громоздкий процесс в маленькой студии. Особенно когда «A»-компонента (процедуры, формальности) может быть лишь в меру — ведь каждая дополнительная регламентация отнимает время и деньги.
Ситуация классическая: E хочет всё и сразу, и видит это как гениальный прорыв, а P считает, что мы можем в полной мере сделать только один проект, чтобы его не загубить. Отсюда основная задача — выровнять ожидания и договориться, ради чего мы вообще рискуем. Телемедицина — флагман и наша кормилица, там dedicated-команда на полную загрузку, плюс долгий контракт. А энергетика пока выглядит как возможность «прокачать портфель» и повысить статус компании, но без четкого ТЗ и непонятными рисками.
Значит, нужно вернуться к «стратегии» или, если никакой формальной нет, хотя бы к здравому смыслу. Задать себе вопрос: в ближайшие полгода важнее доходность и кэшфлоу или репутационные/имиджевые кейсы? Ресурсы не обязательно просчитывать детально, но хотя бы «прикинуть на пальцах», насколько может пострадать телемед и чего мы недосчитаемся, если вдруг увлечемся энергетикой. И точно так же обозначить, сколько всего «неизвестных» в новом проекте и насколько они могут потянуть бюджет и время.
Полномочия менеджера заканчиваются там, где речь идет о выборе портфеля. Он не может решить за всю компанию, но должен подсветить риски, предложить варианты и поуправлять ожиданиями. Если фаундер, в роли «E», всё-таки захочет ввязаться, это его решение. Задача менеджера — зафиксировать согласованные риски, сроки, потери и не дать создать иллюзию, будто мы все потянем одной и той же командой, да еще и без ущерба флагману
P.S. Если не видели старенькое это, стоит увидеть https://www.youtube.com/watch?v=EH_3ukkNuwg
Задача на подумать для менеджера
Правильный вариант первый - Следовать указаниям Виктора. Но с хорошим управлением ожиданиями. Ниже напишу почему
Если смотреть через призму PAEL, то фаундер здесь классический E — предприниматель, живущий перспективами и идеями «взять всё и сразу», а менеджер (ты) — больше P, человек результата и четкости. Многие в комментариях говорили, что «это вообще не кейс, ведь очевидно, что менеджер должен был выстроить процесс планирования, и шеринг ресурсов в аутсорсе — нормальная практика». Но важно учитывать, что у любой бюрократии есть косты, и не всегда целесообразно делать громоздкий процесс в маленькой студии. Особенно когда «A»-компонента (процедуры, формальности) может быть лишь в меру — ведь каждая дополнительная регламентация отнимает время и деньги.
Ситуация классическая: E хочет всё и сразу, и видит это как гениальный прорыв, а P считает, что мы можем в полной мере сделать только один проект, чтобы его не загубить. Отсюда основная задача — выровнять ожидания и договориться, ради чего мы вообще рискуем. Телемедицина — флагман и наша кормилица, там dedicated-команда на полную загрузку, плюс долгий контракт. А энергетика пока выглядит как возможность «прокачать портфель» и повысить статус компании, но без четкого ТЗ и непонятными рисками.
Значит, нужно вернуться к «стратегии» или, если никакой формальной нет, хотя бы к здравому смыслу. Задать себе вопрос: в ближайшие полгода важнее доходность и кэшфлоу или репутационные/имиджевые кейсы? Ресурсы не обязательно просчитывать детально, но хотя бы «прикинуть на пальцах», насколько может пострадать телемед и чего мы недосчитаемся, если вдруг увлечемся энергетикой. И точно так же обозначить, сколько всего «неизвестных» в новом проекте и насколько они могут потянуть бюджет и время.
Полномочия менеджера заканчиваются там, где речь идет о выборе портфеля. Он не может решить за всю компанию, но должен подсветить риски, предложить варианты и поуправлять ожиданиями. Если фаундер, в роли «E», всё-таки захочет ввязаться, это его решение. Задача менеджера — зафиксировать согласованные риски, сроки, потери и не дать создать иллюзию, будто мы все потянем одной и той же командой, да еще и без ущерба флагману
P.S. Если не видели старенькое это, стоит увидеть https://www.youtube.com/watch?v=EH_3ukkNuwg
🔥10👍3🤔2💩2👀1
#рецепт
Важные для проектного менеджера понятия технички. Часть 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 (подписка, уведомления)
Важные для проектного менеджера понятия технички. Часть 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 (подписка, уведомления)
👍23🔥11💩2
#рецепт
Важные для проектного менеджера понятия технички. Часть 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)
Важные для проектного менеджера понятия технички. Часть 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)
🔥15💩2
#рецепт
Важные для проектного менеджера понятия технички. Часть 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/
Важные для проектного менеджера понятия технички. Часть 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/
🔥15👍13💩2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу.
Ты — новый скрам-мастер в B2B-продуктовой компании, которая разрабатывает SaaS-решение для автоматизации складского учета. Это твоя первая серьезная работа, ты вдохновлен идеями Agile и готов помогать команде работать эффективнее.
Но очень быстро ты понимаешь, что скрам в команде есть только номинально.
— В спринтах хаос: никто не может сказать, какие задачи точно готовы, а какие застряли.
— Все называют PBR “грумингами”, но их никто не любит, потому что “они для джунов, а тут все и так во всем разбираются”.
— Демо проходят, но в них смысла нет: клиенты редко приходят, а внутренние стейкхолдеры устали от багов и недоделанных фич.
— Ретроспективы собирают одни и те же проблемы, но никто не хочет реально их решать, потому что “так исторически сложилось”.
Ты пытаешься вникнуть, но тут случается катастрофа.
Крупный клиент, который приносит 30% выручки, внезапно присылает письмо: “Ваш сервис не позволяет нам добавить новые SKU, бизнес встал. Если не решите за 24 часа, мы уходим.”
Ты поднимаешь команду, но начинается шоу "это не моя проблема":
— Разработчики: “Это на стороне бэкенда, фронт тут ни при чем.”
— Бэкенд: “Это не у нас, данные от контрагентов пришли в сломанном формате, пусть продукт разбирается.”
— Продукт: “Я не знаю, что тут сломалось, спросите тестировщиков.”
— Тестировщики: “А нам никто не говорил, что это критично, мы не приоритетили этот сценарий.”
— Тимлид: “Ну да, баги бывают, но что вы от меня хотите?”
— CTO: не отвечает на сообщения, видимо, опять на встречах с инвесторами.
А тебе пишут из продаж:
“Ну что, клиент уже нервничает, что сказать? Что делаете?”
И вот ты, скрам-мастер без технического бэкграунда, без авторитета, без реальной власти, но с дедлайном в 24 часа, стоишь посреди хаоса и должен как-то разрулить это.
Как будешь действовать?
P.S Картинка из старого новостного сюжета про то как вокруг тушат пожар, а рыболов невозмутимо удит
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу.
Ты — новый скрам-мастер в B2B-продуктовой компании, которая разрабатывает SaaS-решение для автоматизации складского учета. Это твоя первая серьезная работа, ты вдохновлен идеями Agile и готов помогать команде работать эффективнее.
Но очень быстро ты понимаешь, что скрам в команде есть только номинально.
— В спринтах хаос: никто не может сказать, какие задачи точно готовы, а какие застряли.
— Все называют PBR “грумингами”, но их никто не любит, потому что “они для джунов, а тут все и так во всем разбираются”.
— Демо проходят, но в них смысла нет: клиенты редко приходят, а внутренние стейкхолдеры устали от багов и недоделанных фич.
— Ретроспективы собирают одни и те же проблемы, но никто не хочет реально их решать, потому что “так исторически сложилось”.
Ты пытаешься вникнуть, но тут случается катастрофа.
Крупный клиент, который приносит 30% выручки, внезапно присылает письмо: “Ваш сервис не позволяет нам добавить новые SKU, бизнес встал. Если не решите за 24 часа, мы уходим.”
Ты поднимаешь команду, но начинается шоу "это не моя проблема":
— Разработчики: “Это на стороне бэкенда, фронт тут ни при чем.”
— Бэкенд: “Это не у нас, данные от контрагентов пришли в сломанном формате, пусть продукт разбирается.”
— Продукт: “Я не знаю, что тут сломалось, спросите тестировщиков.”
— Тестировщики: “А нам никто не говорил, что это критично, мы не приоритетили этот сценарий.”
— Тимлид: “Ну да, баги бывают, но что вы от меня хотите?”
— CTO: не отвечает на сообщения, видимо, опять на встречах с инвесторами.
А тебе пишут из продаж:
“Ну что, клиент уже нервничает, что сказать? Что делаете?”
И вот ты, скрам-мастер без технического бэкграунда, без авторитета, без реальной власти, но с дедлайном в 24 часа, стоишь посреди хаоса и должен как-то разрулить это.
Как будешь действовать?
P.S Картинка из старого новостного сюжета про то как вокруг тушат пожар, а рыболов невозмутимо удит
🔥12🌚1
#мнение
Один из десятков концептов мотивации
Здравствуй, мотивированный профессионал – читатель!
За последние годы я столкнулся с множеством подходов: психопрофилирование, мотивационные пирамиды и методики вроде DICS и подходы Герчикова. Все они обещают понимание, просветление и простоту, но часто оказываются поверхностными
Мои наблюдения показали, что айтишники – настоящие ремесленники. Мы ценим возможность работать автономно, видеть рост своих навыков и иметь понятную цель, а не просто "работу в стол"
Ознакомившись с выдержками и статьями по мотивационным идеям Дэниела Пинка, я понял, что принципы автономии, стремления к мастерству и ощущения цели полностью совпадают с моими взглядами. Я не читал всю книгу «Драйв» – для формирования мнения мне достаточно было материалов, которые я изучал через статьи и даже прогнал через GPT Structured Output с reasoning
На практике я применяю эти идеи, предоставляя команде возможность проявлять инициативу, экспериментировать и развиваться. Такой подход помогает сохранить креативность и одновременно двигаться к конкретной цели
Однако абсолютная автономия без четких рамок не всегда работает. В одном из проектов был сотрудник, которого мы условно прозвали «кавасаки». В отличие от тех, кто жаждет свободы и развития, ему было всё равно, что происходит с его задачами. Он требовал лишь, чтобы техническое задание было четко прописано – дал оценку, и дальше его отстраняли от процесса до завершения работы. Он не интересовался общением с командой, избегал развития, отказывался включать камеру на встречах, чтобы его не запомнили. Такой подход не только нарушал коллективную динамику, но и подрывал общий настрой команды. Его формальное отношение к работе показало, что для некоторых людей мотивация 3.0 вовсе не актуальна – им достаточно лишь минимальных требований
Кстати, мы сравнили наши взгляды по этой теме с еще одним Артёмом из канала Плохой Project. Мы с ним написали каждый свой пост на эту тему, и оказалось что хоть и есть общее во взглядах, но многое и разнится
Один из десятков концептов мотивации
Здравствуй, мотивированный профессионал – читатель!
За последние годы я столкнулся с множеством подходов: психопрофилирование, мотивационные пирамиды и методики вроде DICS и подходы Герчикова. Все они обещают понимание, просветление и простоту, но часто оказываются поверхностными
Мои наблюдения показали, что айтишники – настоящие ремесленники. Мы ценим возможность работать автономно, видеть рост своих навыков и иметь понятную цель, а не просто "работу в стол"
Ознакомившись с выдержками и статьями по мотивационным идеям Дэниела Пинка, я понял, что принципы автономии, стремления к мастерству и ощущения цели полностью совпадают с моими взглядами. Я не читал всю книгу «Драйв» – для формирования мнения мне достаточно было материалов, которые я изучал через статьи и даже прогнал через GPT Structured Output с reasoning
На практике я применяю эти идеи, предоставляя команде возможность проявлять инициативу, экспериментировать и развиваться. Такой подход помогает сохранить креативность и одновременно двигаться к конкретной цели
Однако абсолютная автономия без четких рамок не всегда работает. В одном из проектов был сотрудник, которого мы условно прозвали «кавасаки». В отличие от тех, кто жаждет свободы и развития, ему было всё равно, что происходит с его задачами. Он требовал лишь, чтобы техническое задание было четко прописано – дал оценку, и дальше его отстраняли от процесса до завершения работы. Он не интересовался общением с командой, избегал развития, отказывался включать камеру на встречах, чтобы его не запомнили. Такой подход не только нарушал коллективную динамику, но и подрывал общий настрой команды. Его формальное отношение к работе показало, что для некоторых людей мотивация 3.0 вовсе не актуальна – им достаточно лишь минимальных требований
Кстати, мы сравнили наши взгляды по этой теме с еще одним Артёмом из канала Плохой Project. Мы с ним написали каждый свой пост на эту тему, и оказалось что хоть и есть общее во взглядах, но многое и разнится
👍8🤡4🔥3👏1💅1
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. Но совершенно точно нужно отбросить пункт 2 – просто давить на тимлида или CTO тут бесполезно. Сейчас объясню, почему
Есть четыре важных момента в ситуации. Во-первых, ты скрам-мастер без опыта, и нужно чётко решить: будешь ли ты держаться каноничной роли СМ-а или выйдешь за её рамки ради спасения ситуации. Во-вторых, клиент, который приносит 30% выручки, — это крупный кит с индивидуальными договоренностями, терять его нельзя. В-третьих, проблема на самом деле не техническая: условный контрагент вроде «Калуга Астрал» наверняка поменял параметры интеграции, и теперь SKU просто не проходят в нашу систему. Фиксится такое быстро, нужны переговоры и пара простых доработок с любой стороны. Четвёртый аспект – команда уже привыкла к коллективной безответственности, и сейлзы вместо того, чтобы отработать партнёрски с клиентом, передают тебе ультиматумы просто от безнадёги и слабых переговорных навыков
Если копнуть глубже, то это типичная история про пять пороков команды по Ленсиони: отсутствие доверия, страх конфликта, уход от ответственности и вот это вот всё. И решается оно ровно так же, как и вскрывается — через признание проблемы и коллективное взятие на себя ответственности
Глобально тут явно не хватает включения топ-менеджмента, который должен показать всей команде, что такое ответственность за результат. Но вот идти через голову CTO напрямую к CEO или нет — уже сильно зависит от культуры вашей компании и контекста ситуации
В итоге выбирать тебе: либо фасилитировать по классике скрама и уповать на осознанность команды (что тут, похоже, не сработает), либо отходить от канона, включаться в решение руками и показывать, как выглядит ответственный подход на практике
Задача на подумать для менеджера
Правильного ответа нет. Но совершенно точно нужно отбросить пункт 2 – просто давить на тимлида или CTO тут бесполезно. Сейчас объясню, почему
Есть четыре важных момента в ситуации. Во-первых, ты скрам-мастер без опыта, и нужно чётко решить: будешь ли ты держаться каноничной роли СМ-а или выйдешь за её рамки ради спасения ситуации. Во-вторых, клиент, который приносит 30% выручки, — это крупный кит с индивидуальными договоренностями, терять его нельзя. В-третьих, проблема на самом деле не техническая: условный контрагент вроде «Калуга Астрал» наверняка поменял параметры интеграции, и теперь SKU просто не проходят в нашу систему. Фиксится такое быстро, нужны переговоры и пара простых доработок с любой стороны. Четвёртый аспект – команда уже привыкла к коллективной безответственности, и сейлзы вместо того, чтобы отработать партнёрски с клиентом, передают тебе ультиматумы просто от безнадёги и слабых переговорных навыков
Если копнуть глубже, то это типичная история про пять пороков команды по Ленсиони: отсутствие доверия, страх конфликта, уход от ответственности и вот это вот всё. И решается оно ровно так же, как и вскрывается — через признание проблемы и коллективное взятие на себя ответственности
Глобально тут явно не хватает включения топ-менеджмента, который должен показать всей команде, что такое ответственность за результат. Но вот идти через голову CTO напрямую к CEO или нет — уже сильно зависит от культуры вашей компании и контекста ситуации
В итоге выбирать тебе: либо фасилитировать по классике скрама и уповать на осознанность команды (что тут, похоже, не сработает), либо отходить от канона, включаться в решение руками и показывать, как выглядит ответственный подход на практике
👍4💩1
#полезности
Инфографика и схемы по System Design
Здравствуй, считающий себя техническим менеджером проектов или просто хорошо подкованным в техничке читатель. В дополнение к https://t.me/junior_pm/278 нашел классный набор схем
https://miro.com/app/board/uXjVLw0JIYw=/
Зачем я это публикую? Да как обычно - пишу о том, о чем мне интересно, к тому же пытаюсь наверстывать упущенное и чуть углубляю свое понимание того чем управляю
P.S. Если видели хорошие примеры не на хинглише относительно архитектуры и дизайна на пальцах, буду очень рад если подскажите!
Инфографика и схемы по System Design
Здравствуй, считающий себя техническим менеджером проектов или просто хорошо подкованным в техничке читатель. В дополнение к https://t.me/junior_pm/278 нашел классный набор схем
https://miro.com/app/board/uXjVLw0JIYw=/
Зачем я это публикую? Да как обычно - пишу о том, о чем мне интересно, к тому же пытаюсь наверстывать упущенное и чуть углубляю свое понимание того чем управляю
P.S. Если видели хорошие примеры не на хинглише относительно архитектуры и дизайна на пальцах, буду очень рад если подскажите!
👍15🔥3😁1💩1
#мнение
Баланс компетенций 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. Иногда стоит просто дать себе время выдохнуть и вспомнить, что мы не обязаны знать всё на свете – достаточно осознавать, как организовать работу людей, которые это знают. Да и не боги горшки обживают
Баланс компетенций 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. Иногда стоит просто дать себе время выдохнуть и вспомнить, что мы не обязаны знать всё на свете – достаточно осознавать, как организовать работу людей, которые это знают. Да и не боги горшки обживают
🔥36👀7👍3👏3💩2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши, как бы ты действовал в комментариях к опросу.
Ты – проектный менеджер в Enterprise IT-отделе крупного банка. Внутренние команды разрабатывают инструменты для автоматизации операций, отчетности и взаимодействия различных департаментов
Ты последние два года отвечал за стрим мобильного приложения для премиальных клиентов, но теперь тебя ротируют на новый проект – внутреннюю админ-панель для службы поддержки и операционистов. Это большая, старая система, которая агрегирует данные по счетам клиентов, транзакциям, заявкам и жалобам. Она нужна для расследования инцидентов, принятия решений по операциям и проверки подозрительных транзакций
Что ты видишь в первый день:
- Продукт в проде уже 3 года, но технический долг – огромный. Код – легаси с патчами и костылями.
- В Jira – полный хаос, куча старых задач без актуальных статусов, несвязанные тикеты, часть сделанные, но не закрытые
- Команда не работает с доской – дейли митинги проходят в формате "каждый говорит, что делает", без фиксации статуса
- Документация? Она есть. Но только Postman-коллекции и комментарии к коду в репозитории
- Саппорт ненавидит продукт. Он тормозит, неудобен, не обновляется годами. Операторы давно ведут всё в своих гугл-таблицах, чтобы не зависеть от системы или просят некоторых разработчиков делать апдейты сразу в БД
Половина команды (бэкенд, фронт, аналитик, тестировщик) откровенно раздражены сменой проджекта, считают, что ты будешь "опять что-то ломать в процессах". Делятся контекстом неохотно
Старый менеджер слился в другую компанию, оставив Confluence-док с парой ссылок на архитектуру и пару старых встреч в Zoom-записях
Но самое веселое – в проектный офис пришла резолюция:
1. В компании сменился CTO, и теперь все ПМ-ы "на испытательном сроке", идет аудит;
2. В течение 2 недель нужно навести порядок, сделать прозрачную отчетность и статусность проекта;
3. Если этого не будет – будет поднят вопрос о переводе ПМ-а на бенч и дальнейших оргвыводах о полезности в компании
При этом у команды уже поставлен релиз через 3 недели с новой экспертной системой, обещанный старым менеджером, но никто не понимает, реально ли это
Ты в новом для себя домене, в команде, где тебя не ждали, с невнятным бэклогом, злым саппортом и дедлайнами, которые выглядят как билет в ад
Как будешь действовать?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши, как бы ты действовал в комментариях к опросу.
Ты – проектный менеджер в Enterprise IT-отделе крупного банка. Внутренние команды разрабатывают инструменты для автоматизации операций, отчетности и взаимодействия различных департаментов
Ты последние два года отвечал за стрим мобильного приложения для премиальных клиентов, но теперь тебя ротируют на новый проект – внутреннюю админ-панель для службы поддержки и операционистов. Это большая, старая система, которая агрегирует данные по счетам клиентов, транзакциям, заявкам и жалобам. Она нужна для расследования инцидентов, принятия решений по операциям и проверки подозрительных транзакций
Что ты видишь в первый день:
- Продукт в проде уже 3 года, но технический долг – огромный. Код – легаси с патчами и костылями.
- В Jira – полный хаос, куча старых задач без актуальных статусов, несвязанные тикеты, часть сделанные, но не закрытые
- Команда не работает с доской – дейли митинги проходят в формате "каждый говорит, что делает", без фиксации статуса
- Документация? Она есть. Но только Postman-коллекции и комментарии к коду в репозитории
- Саппорт ненавидит продукт. Он тормозит, неудобен, не обновляется годами. Операторы давно ведут всё в своих гугл-таблицах, чтобы не зависеть от системы или просят некоторых разработчиков делать апдейты сразу в БД
Половина команды (бэкенд, фронт, аналитик, тестировщик) откровенно раздражены сменой проджекта, считают, что ты будешь "опять что-то ломать в процессах". Делятся контекстом неохотно
Старый менеджер слился в другую компанию, оставив Confluence-док с парой ссылок на архитектуру и пару старых встреч в Zoom-записях
Но самое веселое – в проектный офис пришла резолюция:
1. В компании сменился CTO, и теперь все ПМ-ы "на испытательном сроке", идет аудит;
2. В течение 2 недель нужно навести порядок, сделать прозрачную отчетность и статусность проекта;
3. Если этого не будет – будет поднят вопрос о переводе ПМ-а на бенч и дальнейших оргвыводах о полезности в компании
При этом у команды уже поставлен релиз через 3 недели с новой экспертной системой, обещанный старым менеджером, но никто не понимает, реально ли это
Ты в новом для себя домене, в команде, где тебя не ждали, с невнятным бэклогом, злым саппортом и дедлайнами, которые выглядят как билет в ад
Как будешь действовать?
💩11😱7👍5🌚3
Как будешь действовать в такой ситуации?
Anonymous Poll
40%
Быстро разобраться – ревизия, приоритезация, контроль хаоса
15%
Жесткий порядок – чистка Jira, строгие процессы, дисциплина
7%
Только релиз – любой ценой закрыть обещанный дедлайн
6%
Работа с пользователями – приоритет боли саппорта и аналитиков
11%
Фокус на команде – мотивация, адаптация, минимум изменений
19%
Отчетность для ПМО - статус инициатив и дальнейшие планы
2%
Твой вариант (напиши в комментариях)
👍6💩2
#кейс_стади
Задача на подумать для менеджера
Правильный вариант – последний: навести прозрачность и организовать отчетность для PMO. Сейчас объясню, почему
Твоя позиция специфична – ты новый человек в команде, которую не устраивает твое появление, но ты не можешь просто наблюдать со стороны. Правила игры поменялись: CTO и PMO требуют отчетности и прозрачности немедленно, и у тебя нет времени на долгий онбординг или завоевание авторитета
Главная задача – не бросаться спасать проект, а сначала понять, что реально происходит. Без этого ты либо утонешь в хаосе, либо сам станешь крайним. Первым шагом стоит предложить понятный формат отчетности, который сразу покажет:
1. Как сейчас идет работа – кто что делает, какие задачи есть, какие блокеры
2. Где реальные проблемы – что сломано в процессах, почему релиз выглядит как утопия
3. Как это исправить – что можно сделать прямо сейчас, а что требует времени
Эту отчетность нужно не просто подготовить, а верифицировать у PMO и, по возможности, у самого CTO. Это позволит не только заручиться поддержкой, но и продемонстрировать три вещи:
1. Ты не просто соглашаешься с их требованиями, а адекватно оцениваешь ситуацию
2. Ты не нагружаешь их деталями, но подсвечиваешь важные моменты, которые им критичны
3. Ты не перекладываешь решения на них, а берешь ответственность, но говоришь честно: тебе нужно время, чтобы разобраться, потому что за две недели выстроить работу и доверие невозможно. С точной информацией ты будешь возвращаться сразу
Параллельно стоит провести аудит, как минимум первую его часть -> знакомство со стейкхолдерами, командой, смежниками, руководителями. Минимум конфликтов, максимум контактов. Выстраивать доверие, но пока ничего не ломать. Без этого любое внедрение процесса вызовет саботаж. Начинать стоит с базы – прозрачности задач в трекере, чтобы понимать, как сейчас идет работа
Многие подметили в комментах, что CTO может оказаться не союзником, а скорее проверяющим, который ждет подтверждения, что команда вообще контролирует ситуацию. Значит, не надо идти к нему с «у нас бардак», а нужно показывать конкретные шаги по организации работы
Еще один ценный момент – проект должен быть нужен кому-то, кроме тебя. В такой хаотичной ситуации легко превратиться в человека, который больше всех хочет, но без поддержки от бизнеса или топов результат обесценится. Поэтому помимо команды важно заручиться поддержкой людей, которым этот проект действительно важен
И последнее – не строить иллюзий про быстрые изменения. В такой ситуации, как правильно заметили в обсуждении, твоя задача не в том, чтобы «срочно починить», а в том, чтобы создать порядок, не стать крайним и продержаться, пока ты не сможешь реально повлиять на ситуацию
P.S. Да я задолбался, несколько переоценил себя и когда стал перегружен несколько отложил блог, вот наверстываю!
P.S. На фото чучело которое не загорелось спустя кучи пыпоток
Задача на подумать для менеджера
Правильный вариант – последний: навести прозрачность и организовать отчетность для PMO. Сейчас объясню, почему
Твоя позиция специфична – ты новый человек в команде, которую не устраивает твое появление, но ты не можешь просто наблюдать со стороны. Правила игры поменялись: CTO и PMO требуют отчетности и прозрачности немедленно, и у тебя нет времени на долгий онбординг или завоевание авторитета
Главная задача – не бросаться спасать проект, а сначала понять, что реально происходит. Без этого ты либо утонешь в хаосе, либо сам станешь крайним. Первым шагом стоит предложить понятный формат отчетности, который сразу покажет:
1. Как сейчас идет работа – кто что делает, какие задачи есть, какие блокеры
2. Где реальные проблемы – что сломано в процессах, почему релиз выглядит как утопия
3. Как это исправить – что можно сделать прямо сейчас, а что требует времени
Эту отчетность нужно не просто подготовить, а верифицировать у PMO и, по возможности, у самого CTO. Это позволит не только заручиться поддержкой, но и продемонстрировать три вещи:
1. Ты не просто соглашаешься с их требованиями, а адекватно оцениваешь ситуацию
2. Ты не нагружаешь их деталями, но подсвечиваешь важные моменты, которые им критичны
3. Ты не перекладываешь решения на них, а берешь ответственность, но говоришь честно: тебе нужно время, чтобы разобраться, потому что за две недели выстроить работу и доверие невозможно. С точной информацией ты будешь возвращаться сразу
Параллельно стоит провести аудит, как минимум первую его часть -> знакомство со стейкхолдерами, командой, смежниками, руководителями. Минимум конфликтов, максимум контактов. Выстраивать доверие, но пока ничего не ломать. Без этого любое внедрение процесса вызовет саботаж. Начинать стоит с базы – прозрачности задач в трекере, чтобы понимать, как сейчас идет работа
Многие подметили в комментах, что CTO может оказаться не союзником, а скорее проверяющим, который ждет подтверждения, что команда вообще контролирует ситуацию. Значит, не надо идти к нему с «у нас бардак», а нужно показывать конкретные шаги по организации работы
Еще один ценный момент – проект должен быть нужен кому-то, кроме тебя. В такой хаотичной ситуации легко превратиться в человека, который больше всех хочет, но без поддержки от бизнеса или топов результат обесценится. Поэтому помимо команды важно заручиться поддержкой людей, которым этот проект действительно важен
И последнее – не строить иллюзий про быстрые изменения. В такой ситуации, как правильно заметили в обсуждении, твоя задача не в том, чтобы «срочно починить», а в том, чтобы создать порядок, не стать крайним и продержаться, пока ты не сможешь реально повлиять на ситуацию
P.S. Да я задолбался, несколько переоценил себя и когда стал перегружен несколько отложил блог, вот наверстываю!
P.S. На фото чучело которое не загорелось спустя кучи пыпоток
🔥9👀6👍3👏1
#артефакты
Карточки сотрудников или мой карманный инструмент КГБ-шника
Здравствуй, прозорливый читатель!
Прошел февраль и уже заканчивается март, а значит многие сменили или в процессе выхода на новое место. Хороший способ в рамках выхода на работу включиться в происходящее и начать заниматься действительно работой руководителя — провести аудит. Про сам аудит я напишу чуть позже
А пока поделюсь инструментом, который я использую (в кои-то веки тег артефактов!)
Это карточка сотрудника. Ее можно воспринимать как досье, но на деле это не документ или книжечка на каждого, а краткая сводка вещей, которые представляют не столько сведения о сотруднике, сколько ключевые наблюдения и выводы, которые должны помочь в работе с ним
Это создано не для каких-то игр разума, а просто элементарно чтобы больше коммуницировать с человеком на его языке, не приходить к нему с вопросами, которые ему не интересны, или четко понимать, к кому с чем лучше идти
Перечень пунктов, которые я описываю, можешь глянуть по ссылке шаблона https://artemletyushev.notion.site/1b8394f4bde5807098c0dc0dd581586c?v=1b8394f4bde58179a439000c6dfd9317, однако поясню несколько спорных и малопонятных вещей
1. Психотип. Да, я использую PAEL Адизеса, потому что он частично сходится с моими наблюдениями. Я в него не верю и не считаю, что это ответ на все вопросы. Для меня это лишь простая форма описания того, что кому-то пофиг на процессы, а кому-то пофиг на взаимоотношения с людьми
2. Мотивация. Тут в целом без разницы что выбрать, я для себя использую Герчикова. Почему? Я работаю в основном на СНГ-рынке, и работы Герчикова неплохо ложатся на постсоветскую ментальность. К тому же это не постоянный фактор, а вопрос того, на чём у человека фокус и какая мотивация прямо сейчас ярче всего выражена.
3. Ну и есть мой личный прикол, по которому я оцениваю, может ли человек выступать как руководитель. Такая вот система координат из трёх измерений: мотивация быть руководителем, навыки быть руководителем и стержень быть руководителем. Для себя я формирую из них квадранты, когда знакомлюсь с людьми, и в основном использую, чтобы применять анекдотичный подход «учить←лечить←мочить» относительно членов команд, но преимущественно лидов, с которыми работаю. Может, как-нибудь напишу об этом подробнее
Как я веду карточки?
В моей отдельной скрытой базе знаний, например, в корпоративном закрытом от просмотра Confluence. Более подробно — на лидов, с которыми работаю напрямую, менее подробно — на моих руководителей и сотрудников моих лидов
Как я заполняю карточки?
Пара дней наблюдений и одна встреча-знакомство, минут на 30. Причем их важно постоянно обновлять. Люди меняются. Меняют их интересы, взгляды, мотивация. Это не стоит упускать
Что это мне даёт?
Во-первых, я лучше запоминаю своих коллег и лучше раскладываю по полочкам информацию. Во-вторых, я больше про них узнаю и начинаю им больше доверять. Кстати, когда знакомлюсь, стараюсь тоже очень много про себя рассказывать — это должно работать в обе стороны. Ну и, конечно, это помогает точнее конфигурировать команды, с которыми я работаю
P.S. Я еще у меня не самая сильная память, поэтому лучше записывать
Карточки сотрудников или мой карманный инструмент КГБ-шника
Здравствуй, прозорливый читатель!
Прошел февраль и уже заканчивается март, а значит многие сменили или в процессе выхода на новое место. Хороший способ в рамках выхода на работу включиться в происходящее и начать заниматься действительно работой руководителя — провести аудит. Про сам аудит я напишу чуть позже
А пока поделюсь инструментом, который я использую (в кои-то веки тег артефактов!)
Это карточка сотрудника. Ее можно воспринимать как досье, но на деле это не документ или книжечка на каждого, а краткая сводка вещей, которые представляют не столько сведения о сотруднике, сколько ключевые наблюдения и выводы, которые должны помочь в работе с ним
Это создано не для каких-то игр разума, а просто элементарно чтобы больше коммуницировать с человеком на его языке, не приходить к нему с вопросами, которые ему не интересны, или четко понимать, к кому с чем лучше идти
Перечень пунктов, которые я описываю, можешь глянуть по ссылке шаблона https://artemletyushev.notion.site/1b8394f4bde5807098c0dc0dd581586c?v=1b8394f4bde58179a439000c6dfd9317, однако поясню несколько спорных и малопонятных вещей
1. Психотип. Да, я использую PAEL Адизеса, потому что он частично сходится с моими наблюдениями. Я в него не верю и не считаю, что это ответ на все вопросы. Для меня это лишь простая форма описания того, что кому-то пофиг на процессы, а кому-то пофиг на взаимоотношения с людьми
2. Мотивация. Тут в целом без разницы что выбрать, я для себя использую Герчикова. Почему? Я работаю в основном на СНГ-рынке, и работы Герчикова неплохо ложатся на постсоветскую ментальность. К тому же это не постоянный фактор, а вопрос того, на чём у человека фокус и какая мотивация прямо сейчас ярче всего выражена.
3. Ну и есть мой личный прикол, по которому я оцениваю, может ли человек выступать как руководитель. Такая вот система координат из трёх измерений: мотивация быть руководителем, навыки быть руководителем и стержень быть руководителем. Для себя я формирую из них квадранты, когда знакомлюсь с людьми, и в основном использую, чтобы применять анекдотичный подход «учить←лечить←мочить» относительно членов команд, но преимущественно лидов, с которыми работаю. Может, как-нибудь напишу об этом подробнее
Как я веду карточки?
В моей отдельной скрытой базе знаний, например, в корпоративном закрытом от просмотра Confluence. Более подробно — на лидов, с которыми работаю напрямую, менее подробно — на моих руководителей и сотрудников моих лидов
Как я заполняю карточки?
Пара дней наблюдений и одна встреча-знакомство, минут на 30. Причем их важно постоянно обновлять. Люди меняются. Меняют их интересы, взгляды, мотивация. Это не стоит упускать
Что это мне даёт?
Во-первых, я лучше запоминаю своих коллег и лучше раскладываю по полочкам информацию. Во-вторых, я больше про них узнаю и начинаю им больше доверять. Кстати, когда знакомлюсь, стараюсь тоже очень много про себя рассказывать — это должно работать в обе стороны. Ну и, конечно, это помогает точнее конфигурировать команды, с которыми я работаю
P.S. Я еще у меня не самая сильная память, поэтому лучше записывать
👍24🔥10👀5😁1
Как будешь действовать в такой ситуации?
Anonymous Poll
18%
Пойду в гаражный стартап, чтобы понять на своей шкуре, как это — тушить пожары
24%
Выберу галеру, чтобы после неё меня больше ничего не пугало
15%
Пойду в мутный аутсорс, чтобы быстро наработать стрессоустойчивость и умение общаться с кем угодно
24%
Выберу госконтору, потому что запись в трудовой книжке «Руководитель проекта» и импортозамещение
18%
Подожду других предложений
1%
Твой вариант (напиши в комментариях)
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты — кандидат в проектные менеджеры, настолько зелёный, что у тебя даже студенты синергии вызывают чувство зависти. Последние пол года ты был эдаким «эникейщиком» в стартапе у друга: чуть-чуть потестил, повёрстал лендинги на Тильде, написал пару десятков статей в блог на vc ru, немного поадминил Jira, отсидел все возможные митинги и даже попытался провести ретроспективу, на которой вся команда молчала так, будто ты был у неё денег в долг просить
Внутренне ты считаешь, что менеджер — это больше про общение и процессы, чем про технические детали. Ты уверен, что подход «любой ценой, но лишь бы горело» — это плохо, Agile бывает только в книжках, а планирование нужно хотя бы для того, чтобы было что потом корректировать. Мечтаешь получить работу мечты в компании на букву «Я», но они почему-то тебя пока не зовут
От отчаяния и бесконечных отказов на HH ты уже думал уйти в тех селлеры маркетплейсов или дауншифтинг на тех сапорта, но внезапно тебе прилетает сразу четыре оффера. Правда, радоваться особо нечему, потому что каждая из компаний похожа на … что-то
Первая компания — классический гаражный стартап, созданный вчерашними выходцами майл.ру. Вместо зарплаты — будущие опционы, а вместо процессов — бесконечный энергетический напиток, матерные крики и хаотичные таски в телеге. CEO постоянно генерит идеи, которые кардинально меняют направление компании каждые два дня, а инвестор вообще считает, что тебе как менеджеру надо еще и таргет в Instagram настроить и мерч футболок придумать
Вторая компания — жестокая галера, о которой ходят страшные слухи. Процессы там прописаны с точностью до миллисекунды, но никто их не соблюдает, зато все соблюдают «главное правило компании»: «Ты виноват по умолчанию, даже если был в отпуске». Каждое твое движение нужно зафиксировать в таймшите Jira и еще в системе внутреннего контроля, о которой даже системные админы говорят с трепетом. На работе нужно появляться строго к 9:00, за опоздание на минуту надо писать объяснительную на имя замдиректора по кадрам, которому 73 года и он тебя искренне не уважает. Но зато есть ДМС, йогурты по пятницам и ежегодный корпоратив на природе в Карелии
Третья компания — мутнейший аутсорс-оффшор, чей офис формально в Москве, но разработка — в Индии, QA — в Пакистане, а клиент — в Нью-Йорке. Из-за разницы часовых поясов тебе нужно работать в формате 24/7, а таски обычно звучат как «Сделайте ASAP, красиво и бесплатно». Культура общения отсутствует как явление, PM-ы выгорают и увольняются примерно через 4 месяца, а в документации индийского техлида тебя ждет хинглиш и что-то подозрительно похожее на мантры чтобы работало. Зато международный опыт
Четвёртая компания — крупная госконтора, монструозная структура, где слово «цифровая трансформация» означает заменить бумажную почту на скан и отправить его факсом. IT-проекты тут выглядят как «закупить 3000 лицензий и согласовать их через восемь отделов», а слово «инициатива» приравнивается к опасному преступлению. Рабочий день до минуты регламентирован, с 8 до 19 ты ведешь телефонные переговоры, заполняешь служебки и пытаешься найти крайнего в бюрократической паутине. Зато у тебя будет официальная запись «Руководитель проекта» и зарплата чуть выше рынка
Каждый из офферов тебе неприятен по-своему, но ты понимаешь, что опыт нужен хоть какой-то.
Куда пойдёшь?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты — кандидат в проектные менеджеры, настолько зелёный, что у тебя даже студенты синергии вызывают чувство зависти. Последние пол года ты был эдаким «эникейщиком» в стартапе у друга: чуть-чуть потестил, повёрстал лендинги на Тильде, написал пару десятков статей в блог на vc ru, немного поадминил Jira, отсидел все возможные митинги и даже попытался провести ретроспективу, на которой вся команда молчала так, будто ты был у неё денег в долг просить
Внутренне ты считаешь, что менеджер — это больше про общение и процессы, чем про технические детали. Ты уверен, что подход «любой ценой, но лишь бы горело» — это плохо, Agile бывает только в книжках, а планирование нужно хотя бы для того, чтобы было что потом корректировать. Мечтаешь получить работу мечты в компании на букву «Я», но они почему-то тебя пока не зовут
От отчаяния и бесконечных отказов на HH ты уже думал уйти в тех селлеры маркетплейсов или дауншифтинг на тех сапорта, но внезапно тебе прилетает сразу четыре оффера. Правда, радоваться особо нечему, потому что каждая из компаний похожа на … что-то
Первая компания — классический гаражный стартап, созданный вчерашними выходцами майл.ру. Вместо зарплаты — будущие опционы, а вместо процессов — бесконечный энергетический напиток, матерные крики и хаотичные таски в телеге. CEO постоянно генерит идеи, которые кардинально меняют направление компании каждые два дня, а инвестор вообще считает, что тебе как менеджеру надо еще и таргет в Instagram настроить и мерч футболок придумать
Вторая компания — жестокая галера, о которой ходят страшные слухи. Процессы там прописаны с точностью до миллисекунды, но никто их не соблюдает, зато все соблюдают «главное правило компании»: «Ты виноват по умолчанию, даже если был в отпуске». Каждое твое движение нужно зафиксировать в таймшите Jira и еще в системе внутреннего контроля, о которой даже системные админы говорят с трепетом. На работе нужно появляться строго к 9:00, за опоздание на минуту надо писать объяснительную на имя замдиректора по кадрам, которому 73 года и он тебя искренне не уважает. Но зато есть ДМС, йогурты по пятницам и ежегодный корпоратив на природе в Карелии
Третья компания — мутнейший аутсорс-оффшор, чей офис формально в Москве, но разработка — в Индии, QA — в Пакистане, а клиент — в Нью-Йорке. Из-за разницы часовых поясов тебе нужно работать в формате 24/7, а таски обычно звучат как «Сделайте ASAP, красиво и бесплатно». Культура общения отсутствует как явление, PM-ы выгорают и увольняются примерно через 4 месяца, а в документации индийского техлида тебя ждет хинглиш и что-то подозрительно похожее на мантры чтобы работало. Зато международный опыт
Четвёртая компания — крупная госконтора, монструозная структура, где слово «цифровая трансформация» означает заменить бумажную почту на скан и отправить его факсом. IT-проекты тут выглядят как «закупить 3000 лицензий и согласовать их через восемь отделов», а слово «инициатива» приравнивается к опасному преступлению. Рабочий день до минуты регламентирован, с 8 до 19 ты ведешь телефонные переговоры, заполняешь служебки и пытаешься найти крайнего в бюрократической паутине. Зато у тебя будет официальная запись «Руководитель проекта» и зарплата чуть выше рынка
Каждый из офферов тебе неприятен по-своему, но ты понимаешь, что опыт нужен хоть какой-то.
Куда пойдёшь?
😁11🤔3👍1
#мнение
Четыре ипостаси Delivery Manager-а
Здравствуй, вопрошающий читатель!
Давай поговорим о самом таинственном звере в джунглях IT — Деливери Менеджере. И если ты думал, что здесь всё просто, то нет, у меня плохие новости. Тут также как ПМ-ами (удивлен что скрам-мастеры избежали такой судьбы) : на вид одинаково, а вот начинка может удивить. Итак, разбираем по полочкам
1. Agile-коуч здорового человека (новый канбан-толк)
Представь себе Деливери менеджера как опытного терапевта, который лечит не симптомы, а систему. Он смотрит на команду как на чёрный ящик, повышая её стабильность, прозрачность и предсказуемость. Это не про планирование релизов и задач, а про создание условий, чтобы у команды как сервиса ушли препятствия для выполнения работы. В таких ролях DM часто встречается в HH, МойСклад и Спортмастере, Банк СПб. Вообще в больших банках иногда любят запускать с ними эксперименты
2. Тимлид с приставкой «системный» (старый канбан-толк)
Эта трактовка уже ближе к жизни большинства команд. Деливери здесь — это менеджер, который в одной руке держит планирование, ожидания заказчиков и KPI команды, а в другой — отвертку и молоток, которыми подкручивает процессы и системы внутри команды. Он не боится быть агентом изменений, даже если официально такой лычки у него нет. По сути, это Тимлид, ПМ или даже Engineering Manager, который попутно делает жизнь команды проще, эффективнее и результативнее. Часто его можно встретить в продуктовых командах, которые работают в режиме постоянного потока
3. Начальник ПМ-ов (аутсорс и геймдев)
Здесь уже всё бюрократичнее. Деливери менеджер — это почти генерал, который следит за тем, чтобы ПМ-ы не наделали бед и всё отгружалось заказчику по внутренним стандартам качества и срокам. Он же подключается, когда запахло жареным, и начинает тушить пожары, спасая от разборок с клиентом. Короче, процессный менеджер и кей-аккаунт в одном лице, который заботится о репутации компании и сохранении клиентов. EPAM, DataArt и им подобные любят такой подход
4. Data-driven менеджер изменений (управление изменениями как функция организации)
А теперь добавим трактовку из Т-Банка и других компаний, которые смотрят на процесс доставки продуктов сквозь призму данных и эффективности всей цепочки. Такой Деливери — это менеджер изменений с аналитическим уклоном, который сокращает время от идеи до релиза и повышает прогнозируемость всего процесса. Он отвечает за то, чтобы бизнес при росте сложности продуктов и процессов оставался гибким, а все изменения проходили не через боль, а через ясные метрики и управляемые эксперименты. Его основная задача — масштабировать практики и управлять изменениями. Т-Банк — отличный пример, который выделяет именно эту трактовку
Как видишь, вариаций много и каждая компания понимает роль Деливери менеджера по-своему. И если резюме на роль Деливери ты писал универсальное, то у меня снова плохие новости: лучше писать отдельное резюме под каждую вакансию с ее специфичной трактовкой. В противном случае — собеседование превращается в лотерею, где ты и интервьюер можете долго удивлять друг друга.
P.S. Прежде чем пойти на собеседование, спроси у рекрутера:
"У вас Деливери больше про метрики и прозрачность, про эффективность и лидершип, про работу с заказчиками или вообще про изменения?"
Четыре ипостаси Delivery Manager-а
Здравствуй, вопрошающий читатель!
Давай поговорим о самом таинственном звере в джунглях IT — Деливери Менеджере. И если ты думал, что здесь всё просто, то нет, у меня плохие новости. Тут также как ПМ-ами (удивлен что скрам-мастеры избежали такой судьбы) : на вид одинаково, а вот начинка может удивить. Итак, разбираем по полочкам
1. Agile-коуч здорового человека (новый канбан-толк)
Представь себе Деливери менеджера как опытного терапевта, который лечит не симптомы, а систему. Он смотрит на команду как на чёрный ящик, повышая её стабильность, прозрачность и предсказуемость. Это не про планирование релизов и задач, а про создание условий, чтобы у команды как сервиса ушли препятствия для выполнения работы. В таких ролях DM часто встречается в HH, МойСклад и Спортмастере, Банк СПб. Вообще в больших банках иногда любят запускать с ними эксперименты
2. Тимлид с приставкой «системный» (старый канбан-толк)
Эта трактовка уже ближе к жизни большинства команд. Деливери здесь — это менеджер, который в одной руке держит планирование, ожидания заказчиков и KPI команды, а в другой — отвертку и молоток, которыми подкручивает процессы и системы внутри команды. Он не боится быть агентом изменений, даже если официально такой лычки у него нет. По сути, это Тимлид, ПМ или даже Engineering Manager, который попутно делает жизнь команды проще, эффективнее и результативнее. Часто его можно встретить в продуктовых командах, которые работают в режиме постоянного потока
3. Начальник ПМ-ов (аутсорс и геймдев)
Здесь уже всё бюрократичнее. Деливери менеджер — это почти генерал, который следит за тем, чтобы ПМ-ы не наделали бед и всё отгружалось заказчику по внутренним стандартам качества и срокам. Он же подключается, когда запахло жареным, и начинает тушить пожары, спасая от разборок с клиентом. Короче, процессный менеджер и кей-аккаунт в одном лице, который заботится о репутации компании и сохранении клиентов. EPAM, DataArt и им подобные любят такой подход
4. Data-driven менеджер изменений (управление изменениями как функция организации)
А теперь добавим трактовку из Т-Банка и других компаний, которые смотрят на процесс доставки продуктов сквозь призму данных и эффективности всей цепочки. Такой Деливери — это менеджер изменений с аналитическим уклоном, который сокращает время от идеи до релиза и повышает прогнозируемость всего процесса. Он отвечает за то, чтобы бизнес при росте сложности продуктов и процессов оставался гибким, а все изменения проходили не через боль, а через ясные метрики и управляемые эксперименты. Его основная задача — масштабировать практики и управлять изменениями. Т-Банк — отличный пример, который выделяет именно эту трактовку
Как видишь, вариаций много и каждая компания понимает роль Деливери менеджера по-своему. И если резюме на роль Деливери ты писал универсальное, то у меня снова плохие новости: лучше писать отдельное резюме под каждую вакансию с ее специфичной трактовкой. В противном случае — собеседование превращается в лотерею, где ты и интервьюер можете долго удивлять друг друга.
P.S. Прежде чем пойти на собеседование, спроси у рекрутера:
"У вас Деливери больше про метрики и прозрачность, про эффективность и лидершип, про работу с заказчиками или вообще про изменения?"
👍22😁1
#кейс_стади
Задача на подумать для менеджера
Лучшим выбором для тебя будет именно «галера» (второй вариант), и вот почему
Во-первых, несмотря на кажущуюся жесть и бюрократический мрак, именно там ты увидишь, как выглядят хорошо структурированные и стандартизированные процессы управления проектами. Это ценно для старта: после такого опыта ты сможешь легко адаптироваться и перестроиться под любой хаос или неопределённость, уже зная, как бывает «по учебнику»
Во-вторых, галеры обычно работают с клиентами из самых разных отраслей и ниш. Это значит, что ты получишь опыт не одного-двух, а десятка разных проектов. За короткое время у тебя будет шанс набраться широкого кругозора, понять специфику множества областей и наработать универсальные менеджерские навыки
В-третьих, крупные аутсорс-галеры работают с серьёзными, долгосрочными и высокобюджетными проектами. Никто в здравом уме не поставит новичка рулить таким проектом в одиночку, без контроля. У тебя всегда будет более опытный менеджер, который будет за тобой присматривать, помогать с первыми шагами и корректировать ошибки. Именно он может стать тем самым отличным наставником, которого так не хватает в начале карьеры
В-четвёртых, несмотря на излишнюю формальность, работа на галере отлично научит тебя дисциплине, тайм-менеджменту, ведению документации и общению с клиентами на профессиональном уровне. Эти «базовые» навыки легко трансформируются в конкурентное преимущество при дальнейшей карьере
Почему не другие варианты?
В стартапе ты рискуешь остаться один на один с хаосом и отсутствием хоть какого-то понимания, правильно ты действуешь или нет. Такой опыт будет трудно переосмыслить и использовать в дальнейшем. Кажется ты уже достаточно получил боевого опыта, раз тебя готовы нанимать и ты уже выстроил позицию чего хочешь. Второй стартап тебе не даст ценности
В мутном аутсорсе с международной командой тебя ждёт выгорание, бессонные ночи и нулевой менторинг. Уровень стресса будет слишком высоким, чтобы чему-то качественно научиться. Безусловно опыт будет ценным и закалит тебя, но он не будет конвертируем толком для работы в компании где ты хочешь оказаться
В госконторе, несмотря на стабильность, ты скорее научишься формальному следованию регламентам, которые потом будет сложно «выбить» из головы. Реально ценные навыки здесь получить возможно, но только на конкретных проектах, которые людям с улицы не дают
Таким образом, несмотря на то, что каждый из вариантов по-своему хтоничен, именно второй вариант) даст тебе наиболее качественный, структурированный и разносторонний опыт
Задача на подумать для менеджера
Лучшим выбором для тебя будет именно «галера» (второй вариант), и вот почему
Во-первых, несмотря на кажущуюся жесть и бюрократический мрак, именно там ты увидишь, как выглядят хорошо структурированные и стандартизированные процессы управления проектами. Это ценно для старта: после такого опыта ты сможешь легко адаптироваться и перестроиться под любой хаос или неопределённость, уже зная, как бывает «по учебнику»
Во-вторых, галеры обычно работают с клиентами из самых разных отраслей и ниш. Это значит, что ты получишь опыт не одного-двух, а десятка разных проектов. За короткое время у тебя будет шанс набраться широкого кругозора, понять специфику множества областей и наработать универсальные менеджерские навыки
В-третьих, крупные аутсорс-галеры работают с серьёзными, долгосрочными и высокобюджетными проектами. Никто в здравом уме не поставит новичка рулить таким проектом в одиночку, без контроля. У тебя всегда будет более опытный менеджер, который будет за тобой присматривать, помогать с первыми шагами и корректировать ошибки. Именно он может стать тем самым отличным наставником, которого так не хватает в начале карьеры
В-четвёртых, несмотря на излишнюю формальность, работа на галере отлично научит тебя дисциплине, тайм-менеджменту, ведению документации и общению с клиентами на профессиональном уровне. Эти «базовые» навыки легко трансформируются в конкурентное преимущество при дальнейшей карьере
Почему не другие варианты?
В стартапе ты рискуешь остаться один на один с хаосом и отсутствием хоть какого-то понимания, правильно ты действуешь или нет. Такой опыт будет трудно переосмыслить и использовать в дальнейшем. Кажется ты уже достаточно получил боевого опыта, раз тебя готовы нанимать и ты уже выстроил позицию чего хочешь. Второй стартап тебе не даст ценности
В мутном аутсорсе с международной командой тебя ждёт выгорание, бессонные ночи и нулевой менторинг. Уровень стресса будет слишком высоким, чтобы чему-то качественно научиться. Безусловно опыт будет ценным и закалит тебя, но он не будет конвертируем толком для работы в компании где ты хочешь оказаться
В госконторе, несмотря на стабильность, ты скорее научишься формальному следованию регламентам, которые потом будет сложно «выбить» из головы. Реально ценные навыки здесь получить возможно, но только на конкретных проектах, которые людям с улицы не дают
Таким образом, несмотря на то, что каждый из вариантов по-своему хтоничен, именно второй вариант) даст тебе наиболее качественный, структурированный и разносторонний опыт
🔥13👍5
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты работаешь tech PM в компании, разрабатывающей платформу автоматизации документооборота и согласований для среднего и крупного бизнеса. Рынок у вас высококонкурентный, постоянно гонитесь за новыми фичами и удобством, стараясь опередить конкурентов. Внутренние процессы классический Scrum: двухнедельные спринты, регулярные ревью, еженедельные ретро и оживленные обсуждения задач на дейликах
Твоя команда небольшая, но сыгранная: два синьора-бэкендера, два фронтендера (мидл и синьор), два мидла Python-разработчика, тестировщик, аналитик, дизайнер и devops-инженер. Команда открытая, с живым общением и дружеской атмосферой
Около полугода назад к вам присоединился Python-разработчик уровня middle — Саша. Парень интересный, хоть и немного интровертный, увлекается шахматами, много рассказывает о походах в горы и любит философствовать на ретро, мол, «жизнь — это непредсказуемый алгоритм с хаотичными данными». Коллегам он понравился, однако рабочие моменты поначалу складывались сложно: на ревью его коммиты прилетали с опозданиями, код был неаккуратным и метался от camelCase к snake_case. Комментарии к задачам в Jira были очень скромные, приходилось вытягивать детали и постоянно напоминать ему о лучших практиках
Но вот уже месяц-другой ситуация кардинально изменилась. Саша внезапно стал практически образцовым сотрудником: коммиты появляются первыми, оформлены идеально, ревью кода проходит почти без нареканий, а комменты к задачам — чёткие, структурированные и заранее отвечающие на вопросы коллег. Сначала ты списывал это на его прогресс и адаптацию, но в какой-то момент закрались сомнения
Однажды ты обсуждал с Сашей задачу по внедрению фичи автоматического архивирования документов, и он на твой вопрос ответил настолько чётко и структурно, что это вызвало эффект дежавю. Через пару минут ты понял, откуда ноги растут: пару дней назад ты сам задавал очень похожий вопрос Claude и получил практически идентичный ответ
Сомнения начали усиливаться: возможно, Саша использует нейросетевых помощников (Claude, ChatGPT, Copilot) для написания кода и комментариев. Вроде формально придраться сложно — задачи делаются, команда ускорилась, заказчик счастлив. Но вопросы этики, конфиденциальности и внутренней политики безопасности данных никто не отменял, а вдруг бизнес-логика проекта уже где-то лежит на сторонних серверах?
Недавно проблемы с интернетом, на которые Саша постоянно ссылался, решились, и он стал активнее общаться голосом и иногда даже включать видео на созвонах. Казалось бы, всё наладилось, но тут появилось новое ощущение, ещё более жутковатое — тот самый эффект «зловещей долины». Ты замечаешь, что движения его лица и губ на видео как будто немного неестественны, иногда чуть запаздывают или опережают слова. Голос ровный и глубокий, но словно слишком «идеальный». Ты начинаешь подозревать, что дело дошло до использования AI не только в тексте, но и голосом и видео с помощью инструментов вроде Eleven Labs, Synthesia, HeyGen или DID. Возможно, перед тобой вовсе не Саша, а его дипфейк-аватар
Ты стоишь перед выбором: принять ситуацию или срочно действовать?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты работаешь tech PM в компании, разрабатывающей платформу автоматизации документооборота и согласований для среднего и крупного бизнеса. Рынок у вас высококонкурентный, постоянно гонитесь за новыми фичами и удобством, стараясь опередить конкурентов. Внутренние процессы классический Scrum: двухнедельные спринты, регулярные ревью, еженедельные ретро и оживленные обсуждения задач на дейликах
Твоя команда небольшая, но сыгранная: два синьора-бэкендера, два фронтендера (мидл и синьор), два мидла Python-разработчика, тестировщик, аналитик, дизайнер и devops-инженер. Команда открытая, с живым общением и дружеской атмосферой
Около полугода назад к вам присоединился Python-разработчик уровня middle — Саша. Парень интересный, хоть и немного интровертный, увлекается шахматами, много рассказывает о походах в горы и любит философствовать на ретро, мол, «жизнь — это непредсказуемый алгоритм с хаотичными данными». Коллегам он понравился, однако рабочие моменты поначалу складывались сложно: на ревью его коммиты прилетали с опозданиями, код был неаккуратным и метался от camelCase к snake_case. Комментарии к задачам в Jira были очень скромные, приходилось вытягивать детали и постоянно напоминать ему о лучших практиках
Но вот уже месяц-другой ситуация кардинально изменилась. Саша внезапно стал практически образцовым сотрудником: коммиты появляются первыми, оформлены идеально, ревью кода проходит почти без нареканий, а комменты к задачам — чёткие, структурированные и заранее отвечающие на вопросы коллег. Сначала ты списывал это на его прогресс и адаптацию, но в какой-то момент закрались сомнения
Однажды ты обсуждал с Сашей задачу по внедрению фичи автоматического архивирования документов, и он на твой вопрос ответил настолько чётко и структурно, что это вызвало эффект дежавю. Через пару минут ты понял, откуда ноги растут: пару дней назад ты сам задавал очень похожий вопрос Claude и получил практически идентичный ответ
Сомнения начали усиливаться: возможно, Саша использует нейросетевых помощников (Claude, ChatGPT, Copilot) для написания кода и комментариев. Вроде формально придраться сложно — задачи делаются, команда ускорилась, заказчик счастлив. Но вопросы этики, конфиденциальности и внутренней политики безопасности данных никто не отменял, а вдруг бизнес-логика проекта уже где-то лежит на сторонних серверах?
Недавно проблемы с интернетом, на которые Саша постоянно ссылался, решились, и он стал активнее общаться голосом и иногда даже включать видео на созвонах. Казалось бы, всё наладилось, но тут появилось новое ощущение, ещё более жутковатое — тот самый эффект «зловещей долины». Ты замечаешь, что движения его лица и губ на видео как будто немного неестественны, иногда чуть запаздывают или опережают слова. Голос ровный и глубокий, но словно слишком «идеальный». Ты начинаешь подозревать, что дело дошло до использования AI не только в тексте, но и голосом и видео с помощью инструментов вроде Eleven Labs, Synthesia, HeyGen или DID. Возможно, перед тобой вовсе не Саша, а его дипфейк-аватар
Ты стоишь перед выбором: принять ситуацию или срочно действовать?