Как создать IT-решение за 1 месяц: история одного MVP

Начнем с того, что руководитель проекта (он же менеджер проекта, project manager, PM, ПМ) выступает в роли инициатора, формирует команду и фокусирует всех вокруг единой цели: 

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

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

Для команды ПМ является неким коучем, помогает развивать самоорганизацию и чувство ответственности, контролирует процесс разработки с точки зрения бизнесовых метрик, а также всеми возможными способами устраняет преграды и препятствия, чтобы специалисты могли вкладываться в работу на 100%. Другими словами, руководитель проекта сохраняет баланс между выполнением требований двух сторон и комфортной организацией процессов. Подробнее рассмотрим на примере.

Исходная ситуация

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

Вводные данные: описание идеи в нескольких строчках и презентация кейса от консалтинговой компании на 2-3 слайдах. Сроки амбициозные — 1 месяц. Со стороны ПМа и команды возникли объективные вопросы:

• Что можно сделать за такое время? 
• С чего начать? 
• Какой алгоритм действий в данном случае выбрать? 
• Какой подход к проектному управлению применить?

Шаг первый: включаем критическое мышление

ПМ и команда уже на старте отметили риски: сроки горят, а идея продукта не имеет глубокой проработки. Клиент также не был уверен, что приложение достигнет своей цели — привлечения новых клиентов. 

ПМу и команде проекта потребовалось «примерить на себя». Они оценили идею с точки зрения пользовательского опыта, насколько им самим был бы интересен продукт, мотивирует ли он на покупку. Мнения в команде разошлись. Стало очевидно, что эту бизнес-гипотезу необходимо проверить на большей аудитории. 

Шаг второй: выбрать инструменты и проверить гипотезу 

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

На старте важно было обеспечить единое видение системы у клиента и проектной команды. Для этого ПМ использовал некоторые инструменты из мира Agile: 

• Lean Canvas — для систематизированного описания и обсуждения бизнес-модели. 
• User Story Map — карта пользовательского пути, которая помогла выделить ценные функции будущего продукта и улучшить UX.

Кроме того, ПМу необходимо было выступить в роли scrum-мастера: донести философию Agile до каждого участника проектной команды, научить мыслить как бизнес. Важно было, чтобы они думали не только как реализовать задачу технически, но и что та или иная функциональность может дать клиенту, какую выгоду получит пользователь и какую бизнес-потребность закроет. Иными словами, необходимо было взрастить продуктовый подход в команде. 

Шаг третий: делаем конфетку на коленке 

Работа пошла активно. За неделю подготовили дизайн-макеты. После согласования визуальной части приступили к разработке.

Далее проанализировали бизнес-требования к продукту и решили отказаться от создания бэкенд-части. Специфика работы системы позволила сразу перейти к верстке и созданию логики визуальной части продукта. В результате удалось сэкономить время и бюджет клиента. 

Для повышения удобства использования добавили анимацию и оптимизировали продукт с точки зрения быстродействия и отзывчивости — важно было создать красивую обертку. Также сделали интеграцию с готовыми сервисами клиента для автогенерации лидов и сбора метрик. 

Шаг четвертый: в продакшн 

Продукт готов! Уложились в сроки и бюджет. Провели демонстрацию перед клиентом, согласовали загрузку на продакшн среду и стали ждать первых отзывов от пользователей.

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

Шаг пятый: PIVOT — меняем вектор 

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

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

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

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

Шаг шестой: новому продукту — быть!

В результате совместные усилия позволили продвинуть идею дальше по структуре компании-клиента и утвердить старт работ. 

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

Стратегия ПМа принесла позитивные плоды: 

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

Выводы и рекомендации

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

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

Собрали некоторые рекомендации по эффективному управлению процессом создания нового продукта: 

• Внедрите процесс ревью аналитики лидами от frontend-, backend-разработки и QA, а также ревью дизайна аналитиком, лидами frontend-разработки и QA. Это существенно увеличит качество документации и позволит на ранних этапах выявлять разрывы в интерпретации требований участниками команды. 
• В условиях сжатых сроков важно грамотно управлять изменениями. Перед внедрением новых фич оцените, насколько это повлияет на систему в целом. Например, контролируйте фичи-бантики (функционал, который не является базовым и создается с целью небольших улучшений системы) 
• Как можно раньше займитесь подготовкой стендов для разработки и определите workflow по деплою. 
• Если время позволяет, обсуждайте, как оптимизировать систему, генерируйте идеи по развитию продукта. 
• Создайте в команде такую атмосферу, чтобы каждый мог свободно высказывать мнение, и научитесь слушать. Мотивируйте сотрудников, оценивайте результаты и обязательно предоставляйте обратную связь. 
• Для достижения наилучшего результата, если ситуация того требует, выходите за рамки своих должностных обязанностей. Предлагайте идеи независимо от положения и не бойтесь дополнительной ответственности. При желании все получится! 

Всегда нужно помнить, что ПМ — это лидер, который интегрирует специалистов в единую команду и фокусирует ее на достижение целей проекта.