ПМ совет

На этой неделе мы обсуждали кейс Александра о заказчике, который ни в какую не делится информацией о продукте и планах больше чем на 3-4 месяца вперед, редко на 6. Собрали пару идей, как перевести отношения с клиентом на новый уровень и попробовать добиться открытости: 🤝 Личное знакомство с клиентом на его или вашей территории. Командировка к клиенту подойдет для крупных проектов, где вероятнее будет бюджет на поездку. Для небольших проектов прием дорогих гостей на своей территории будет выгоднее: клиент может совместить встречу с вами и другие бизнес трипы, и конечно, потусить с командой! 💼 Кейсы других проектов в том же домене из портфолио компании для демонстрации экспертизы и генерации гипотез для новых фичей. Если у клиента нет роадмапа по развитию продукта - можно взять инициативу и предложить свои идеи. В компании Александра нет других проектов из домена, и он предложил посетить тематическую конференцию: для поиска новых идей развития продукта, а также поиска новых клиентов в домене, где у них теперь есть экспертиза. —— Конспект о подходах к работе с закрытыми клиентам, а также запись этой и всех предыдущих встреч - доступны по подписке.

#129 Работа есть, цели нет Работать без целей непросто. Неважно, пиэмите ли вы в аутсорсе и ваш заказчик не делится с вами планами - как в кейсе. Или вы работаете в продукте и не в курсе целей компании и метрик успеха, в том числе финансового успеха. И вроде бы все хорошо, работа есть, релизы происходят - но ради чего все это неясно. А задачи ради задач пилить неинтересно, и вот уже и на работу как-то не хочется идти. На этой неделе обсудим кейс Александра: что делать, если стейкхолдеры не делятся планами и проблемами бизнеса, а погрязнуть в рутине не хочется. И стоит ли вообще что-то делать, ведь расслабиться и плыть по течению - это тоже вариант 🦭 📅 3 июля, среда, в 20.00 по Минску Участвовать по подписке или на триале

На этой неделе тренировались проводить 1-1 с программистами. Вывели правило, касающееся 1-1, посвященных проблеме или конфликту - начинать с точки зрения собеседника. Например, просить его своими словами описать, что произошло или что его беспокоит. 📍Мы разбирали кейс о “борьбе за власть” между текущим тим лидом и новым опытным разработчиком. 📍Наш подписчик Николай, который играл роль ПМ-а, задавал вопросы таким образом, чтобы раскрутить тим лида на его видение ситуации:

Как тебе кажется на этом этапе, вы уже сработались или нет? Чего не хватает, чтобы работать вместе вам было комфортно?

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

Ищем ребят, кто готов поделиться опытом Хотим разобрать в совете темы вот эти темы: 👉 метрики команды - технические, продуктовы, финансовые - какие собираете, где трекаете; 👉 работаете 7+ лет в одной компании - мотивация, плюсы, минусы; 👉 зп в виде акций / опционов - о чем помнить, чтоб не надурили; 👉 ушли из компании, чтобы работать напрямую с клиентом; 👉 Истории НЕуспеха: максимально большие факапы на проектах; 👉 Страхи и тревоги джуниор пм: вдруг не получится и уволят, страх осуждения опытных коллег, страх отказывать, любые другие тревоги. Приходите поделиться своими переживаниями и мы вместе подумаем как их преодолеть. Готов поделиться своим опытом по одной из тем? Напиши в бота @pmsovet_bot, и приходи на встречу ПМ сообщества (для экспертов без подписки).

#129 Делимся фишками 1-1 через симуляцию встречи ПМа и программиста В эту среду будем тренироваться проводить 1-1 между ПМом и девом, обе роли сыграют участники ПМ Совета (кто захочет). Контекст такой: 📖 Вводная → - К вам в команду присоединяется дев - тимлид его прессует, ПМ это видит и хочет пофиксить, пока ситуация не переросла в конфликт и в команде не начался раздрай. 👩‍💻 Тим лид → - Боится, что разработчик будет забирать его работу, т.к. тот раньше был лидом; - Во время онбординга нового дева подчеркивает свой статус в команде , отрицательно реагирует на любые инициативы и предложения нового дева, вступает в “перепалки” на общих командных митах; - Хорошо общается с заказчиком, имеет высокий кредит доверия; - Профессиональный, отлично справляется как с обязанностями лида, так и с деливери сложных фичей. 👨‍💻 ПМ → - Сильно полагается на тим лида во всем, что касается технический вопросов, не погружается в технические детали проекта; - Уже имел опыт работы с новым девом на другом проекте и знает, что он самостоятельный и профессиональный, также они дружат вне работы; - Отвечает также за саппорт активности на проекте, помимо управления командой, хочет, чтобы команда оставалась самостоятельной. 📅 3 июля, среда, в 20.00 по Минску Участвовать по подпискеили на триале

Каким будет роль ПМ-а в мире, где AI забирает на себе часть задач по разработке и поставке цифровых продуктов - вопрос из области предсказаний. На этой неделе на ПМ Совете ребята поделились своими представлениями о роли ПМ-а в век AI: 🤓 ПМ - позиция, которая берет ответственность за результат и решает проблемы. 💻 AI повысит скорость поставки и возможно упразднит некоторые роли. 👥 Но человеческий фактор в каком-то виде все равно останется. А значит, останутся проблемы, риски, оценки и т.д., за которые нужно нести ответственность → нужен ПМ. Делаем утешительный вывод, что пока в разработке продуктов будет существовать неопределенность любого рода - ПМ будет необходим, чтобы ей управлять и ее сокращать. А как по вашему мнению изменится роль ПМ-а с распространением AI? —— Очень ждём ваших кейсов! Сейчас в беклоге пусто, пришлете новых? Писать сюда 👌

#128 Agile в век AI Недавно на ПМ Совете мы обсуждали ChatGPT и как ПМ-ы использует его в своей работе. Но кажется, что AI не просто облегчает ежедневные задачи для нас, а трансформирует то, как мы разрабатываем и выпускаем продукты. На этой неделе попробуем новый формат для ПМ Совета - обсуждение статьи. Для участия во встрече надо будет прочитать статью Agile in the age of AI (~ 15 минут).

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

На основе статьи мы обсудим: - Пора ли нам искать новую профессию и сможет ли AI заменить ПМ-а? - Как будут меняться текущие роли, принятые в Scrum, если AI заберет на себя часть задач? На какие навыки стоит делать ставку? - Команда из 2 разработчиков + AI коллеги, возможно ли это? И будут ли такие команды более продуктивным, чем классические кросс-функциональные тимы из 5-7 человек? 📅 26 июня, среда, в 20.00 по Минску Участвовать по подписке или на триале

На этой неделе на ПМ Совете обсуждали риски при оценке проекта. Вспомнили про оценку по 3-ем точкам - когда разработчики дают оптимистическую (OO), пессимистическую (ПО) и реалистичную (РО) оценки времени на реализацию задачи. Но что делать с этими оценками дальше? 1️⃣ Для расчета средней оценки по методу PERT используем формулу →

Оценка по PERT = (1*OO + 4*РО + 1*ПО)/6

Мы присваиваем наиболее вероятной оценке бОльший вес с помощью коэффициента 4 и снижаем влияние крайних оценок на результат. 2️⃣ Полезно посмотреть, как сильно отличаются крайние оценки. Разница между ними - это степень риска: если она маленькая - риска мало, и наоборот. Считается отклонение так →

Отклонение

= (ПО - ОО)/6

3️⃣ Оценка по PERT - это значение без учета отклонений. Если к Оценке по PERT добавим 1 Отклонение - вероятность попасть в сроки составит 68.2%, если добавим 2 - вырастет до 95,4%, а если 3 - до 99.7%. ——— Столкнулись со сложным пиэмским кейсом или топиком - напишите нам в ПМ совет.

На прошедшем ПМ Совете обсудили кто какие запасы закладывает на риски. Всегда есть базовый запас относительно оценки трудозатрат специалистов - 10-15%. И в зависимости от различных критериев его увеличивают: 1. Если используется не знакомый тех стек, например, до 30%. 2. В каждом продукте есть типы задач, на которые по опыту стоит закладывать больший запас, это могут быть платежи, карты и т. п. 3. Когда сложный заказчик долго согласовывает документы, придирчив на этапе приемки, в процессе реализации уточняет требования и т.п. 4. Если есть интеграции с внешними системами. 5. Если качество исходных требований низкое. 6. Если команда проекта не постоянная. На основе каких критериев вы увеличиваете базовый запас на риски? Делитесь в комментариях! --------- Полный конспект и запись этой встречи, а также всех предыдущих доступны, по подписке.

#126 Запасы на риски в проектах При подготовке оценки или календарного плана каждый проджект добавляет буфер - запас на непредвиденные ситуации. В каких-то случаях достаточно добавить 15%, а иногда надо х2. Как определить, сколько именно брать? На этой неделе посмотрим опыт сообщества и обсудим: - Какие буферы используете: по срокам, бюджету, ресурсам? - Какими принципами руководствуетесь для определения необходимости запасов на риски? - Какой размер и на основе каких критериев устанавливаете? - Показываете ли буферы клиентам? 📅 19 июня, среда, в 20.00 по Минску. Присоединяйтесь по подписке или на триале.