Комментарии к вчерашней задачке
В варианте А предложены слишком жёсткие границы. Важно напомнить заказчику о согласованных ранее сроках реализации, но при этом не менее важно проявлять гибкость и предлагать другие варианты реализации.
Вариант B – допускается применять этот подход при очень сжатых сроках и отсутствии других вариантов, но единоразово. Иначе усталость команды будет накапливаться, а это может привести к ухудшению уровня разработки и выгоранию специалистов. Также стоит учитывать, что переработки должны оплачиваться, а это может повлечь за собой перерасход бюджета.
Вариант D – предложить помощь лишним не будет, но заказчик может в ней и не нуждаться. Знание причин подобных изменений – это ценная информация, которая поможет вам в управлении проектом. Необходимо будет предпринять дальнейшие шаги.
Самый оптимальный вариант в сложившейся ситуации – вариант С, так как он учитывает и необходимую функциональность, и изменившиеся сроки.

😱 Проект под угрозой – ушёл архитектор, у которого все знания были в голове. Что делать?

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

👉 Вводные данные: описание идеи в нескольких строчках и презентация кейса от консалтинговой компании на 2–3 слайдах. Сроки амбициозные – 1 месяц. Со стороны ПМа и команды возникли объективные вопросы:
– Что можно сделать за такое время?
– С чего начать?
– Какой алгоритм действий в данном случае выбрать?
– Какой подход к проектному управлению применить?

Шаг 1. Включаем критическое мышление
ПМ вместе с командой зафиксировали риски: проект без глубокой проработки, а сроки горящие. Для начала мы решили оценить идею нашей командой с точки зрения пользовательского опыта: насколько продукт интересен и мотивирует на покупку? Мнения разошлись – необходимо было проверить бизнес-гипотезу.
Шаг 2. Выбрать инструменты и проверить гипотезу
Из-за сжатых сроков для проверки гипотезы выбрали подход Lean Startup.
Также на старте важно было обеспечить единое видение системы у клиента и проектной команды. Для этого ПМ использовал некоторые инструменты из мира Agile:
▪️ Lean Canvas – для систематизированного описания и обсуждения бизнес-модели;
▪️ User Story Map – карта пользовательского пути, которая помогла выделить ценные функции будущего продукта и улучшить UX.
ПМ в этом проекте взял на себя роль scrum-мастера (писали об этом здесь). Было важно, чтобы команда думала не только о технической реализации задачи, но и о том, какую выгоду получит пользователь и какую бизнес-потребность закроет функциональность.
Шаг 3. Делаем конфетку на коленке
За неделю подготовили дизайн-макеты. После согласования визуальной части приступили к разработке. После анализа бизнес-требований отказались от бэкенд, сразу перешли к созданию логики визуальной части. Это сэкономило время и бюджет клиента.
Добавили анимацию и оптимизировали продукт с точки зрения быстродействия и отзывчивости. Сделали интеграцию с готовыми сервисами клиента для автогенерации лидов и сбора метрик.
Шаг 4. PIVOT – меняем вектор
Продукт был готов, но ПМ опасался, что он окажется нежизнеспособным, если не вызовет интереса у целевой аудитории. После мозгового штурма с командой сгенерировали новую концепцию:
▪️ она обеспечивала более широкий набор функций и вариативность,
▪️ а главное – позволяла бизнесу самостоятельно тестировать гипотезы, меняя тематику, целевую аудиторию и каналы распространения.
Это выходило за рамки первоначальных договорённостей, но отвечало бизнес-цели проекта. Единственный нюанс: ПМ проекта и команда были на аутсорсе, а заказчик – крупный холдинг с тяжеловесными процессами внутри.
🤔 Как грамотно преподнести предложение? Рецепт был такой: эффектная презентация с фокусом на ценности для бизнеса и масштабируемости, приправленная щепоткой гипотетических показателей, которых можно достичь после внедрения. Да, цифры не опирались на доказательную базу, поскольку за все время нам не предоставили какую-либо статистику и данные метрик. На пути к общей цели пришлось подключать весь багаж знаний команды.

Результат
Новому продукту – быть! ПМ вместе с командой проанализировали новый скоуп и выделили MVP-версию. Было принято решение начать с неё, а затем по итогам обратной связи от пользователей сформировать основной бэклог и улучшать продукт.

Стратегия ПМа принесла позитивные плоды:
✅ Сократили срок выхода продукта в продакшн: с полугода до 3 месяцев.
✅ Клиент быстрее стал получать обратную связь от пользователей, благодаря чему на ранних стадиях смог сделать продукт лучше и больше зарабатывать.
✅ Использование командой Agile-подходов позволило достичь дополнительной гибкости в разработке: чаще осуществлять релизы и быстро адаптироваться к изменениям.

Жмите🔥, если хотите узнать выводы ПМ из этого кейса :)