Junior PM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@VoiceTextAI_bot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“

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

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

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

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

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

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

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

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

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

“

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