Создание IT-продукта — это объединение творческой энергии и технических знаний команды с организационными скиллами менеджера. При этом от действий PM-а во многом зависит, насколько комфортно и эффективно пройдет Delivery процесс. В статье подробно расскажем о том, на каких этапах и на что именно Product Manager должен обратить максимум внимания.
Что собой представляет Delivery Process
Delivery Process — комплекс работ, в который входит разработка, отладка, тестирование и запуск продукта с последующим сопровождением и внесением изменений при необходимости.
Предлагаем рассматривать процесс Delivery, состоящим из 5 этапов:
- Definition of Requirements (Need Help);
- Delivery Definition;
- Development;
- Delivery Event;
- Maintenance (Feedback and Support).
На практике Delivery Process может многократно повторяться, если продукт востребован на рынке. Для этого важно на этапе Definition of requirements и Delivery Definition правильно определить для кого, что и как делаем — то есть сформировать основные требования для IT-решения. Основные поставщики идей — пользователи и стейкхолдеры, команда разработки, отделы маркетинга и продаж.
Definition of requirements
В первую очередь необходимо найти ответ на вопрос: «Кто будет взаимодействовать с продуктом и какую пользу получит юзер от этого?» Например, приложение сможет улучшить бизнес-процессы, снизить затраты, ускорить работу. Правильное определение потенциальных пользователей и их потребностей — база для разработки плана по технической реализации проекта и стратегии дальнейшего продвижения. Особенно актуально для MVP.
Для существующего приложения формирование требований обычно начинается с анализа того, что можно улучшить в текущей версии IT-продукта: какие фичи добавить, а что оставить без изменений или вовсе убрать. Делается это все на основании данных, полученных после тестирования текущей версии и обратной связи юзеров. При поиске требований к IT-решению обязательно учитывайте мнение и рекомендации отделов сейлза и маркетинга — часто от этого зависит эффективность продвижения и скорость продаж продукта.
Delivery Definition
Когда определены потенциальные пользователи IT-решения и есть предварительное понимание, каким оно должно быть, стартует Delivery Definition. На этом этапе определяют, возможна ли реализация проекта в принципе. Solution Architect проверяет все запросы: есть ли подобное на рынке или это что-то новое, можно ли встроить в текущую версию приложения и так далее.
По сути на Delivery Definition анализируют потенциальную жизнеспособность продукта:
- уточняют основные функциональные требования и бизнес-цели;
- составляют предварительный план работ;
- рассчитывают примерную стоимость и сроки.
На практике часто встречаются ситуации, когда после Delivery Definition сдвигают старт разработки, полностью пересматривают концепцию или вовсе отказываются от проекта. Если все хорошо, идет плановый переход к Development.
Development
Процесс разработки у каждой команды строится индивидуально, но во многом зависит от используемой методологии и методики управления проектами. Например, Scrum диктует обязательное demo, что очень важно для Delivery. Если вы хотите, чтобы ваш продукт попал на рынок в нужном виде, обязательно подводите промежуточные итоги и при необходимости вносите коррективы в работу.
Старт Development обычно начинается с создания юзерстори. Затем составляют четкий план работ с обязательным указанием основных контрольных точек — milestones, которые относятся исключительно к процессу разработки. С этого момента начинается техническая реализация продукта с обязательными промежуточными demo и фидбеками по ним с последующим переходом к этапу Delivery Event.
Delivery Event
На этом шаге происходит создание финального demo, его презентация и тестирование для получения расширенного фидбека. Дело в том, что на этапе Development проверять продукт скорее всего будет небольшое количество лояльно настроенных пользователей. В таких условиях сложно получить объективную картинку, поэтому важно правильно провести Delivery Event.
В процессе отлично помогают видео-презентации, организация тренингов по использованию продукта, подсказки в самом приложении. Цель всех этих мероприятий — запустить максимально готовый продукт в виде MVP или обновленной версии существующего приложения для всех пользователей и перейти к этапу Maintenance.
Maintenance
На запуске продукта Delivery не заканчивается — идет постоянный процесс получения и анализа фидбека от юзеров, а также информации о дефектах. На основании этих данных вносятся коррективы в техническую часть продукта, стратегии маркетинга и продаж.
В целом правильный Delivery Process всегда включает в себя обработку обратной связи на всех этапах:
- При создании demo проверяйте идею и корректируйте идею при необходимости, чтобы получить наиболее точный результат на данный момент.
- Обязательно следите за перфомансом, чтобы Delivery не был «смазан», например, из-за проблем с сервером.
- Внимательно относитесь к фидбекам юзеров и тикетам об ошибках работы приложения, так как они могут натолкнуть на интересные идеи и выявить новых поставщиков требований.
На практике часто происходит ситуация, когда вовремя обработанная обратная связь позволяет определить критическую уязвимость или расширить потенциал приложения. Главное, чтобы в процессе Delivery все участники четко знали свои роли и понимали, что им нужно делать на каждом этапе.
Участники на Delivery
| Этапы | Участники |
| Definition of RequirementsDelivery Definition | Business AnalystProduct OwnerCTO / StakeholderSolution ArchitectProject Manager |
| Development | Product OwnerBusiness AnalystDevelopment Tech LeadProject Manager |
| Delivery Event | Project ManagerProduct OwnerBusiness AnalystSupport Lead |
| Maintenance | Support LeadProject ManagerProduct OwnerBusiness Analyst |
Из таблицы видно, что продакт, проектный менеджер и бизнес-аналитик в идеале должны участвовать на всех этапах. На практике часто Product и Project Manager — один и тот же человек, особенно на небольших проектах. Business Analyst основную роль играет при определении требований к продукту и в формировании технического задания команде разработчиков.
Stakeholder — база для сбора информации, а без Solution Architect сложно представить грамотную проработку физибилити на этапе Definition. Можно сколько угодно говорить о роли продакта, но процесс разработки во многом ложится «на плечи» Development Tech Lead. На этапе Delivery Event имеет смысл подключить Support Lead для ознакомления с функциональностью готового приложения и его бизнес-логикой — ему в дальнейшем это пригодится на Maintenance.
Если говорить о длительности и степени важности этапов, то сбор требований уверенно займет первое место. Вы вместе с командой можете создать идеальное приложение с точки зрения бизнес-логики и технической реализации, но ошибка при определении той же ЦА и ее болей может нивелировать все усилия — продукт просто не будет востребован. В итоге компания потеряет время, деньги и возможно понесет репутационные потери. Именно поэтому опытные Product Managers советуют уделить максимум внимания требованиям к будущему приложению.
Как наладить процесс Delivery
В Delivery Process по сути участвуют 2 команды — продуктовая и разработки. Условно они могут быть независимы друг от друга, но на практике часто пересекаются на этапе уточнения функциональных требований и разработки технического задания. Product и Project Managers — основные связующие звенья между ними, и организация рабочих процессов в их зоне ответственности.
Что учесть на старте проекта
- Оговорите формат взаимодействия между участниками, чтобы всем было удобно.
- Договоритесь о том, что должно получиться в результате работы, чтобы не было потом неприятных сюрпризов по типу «мы это не обсуждали», «этого не было в ТЗ».
- Обговорите показ ранних прототипов: в каком виде, как часто.
- Уточните терминологию и зоны ответственности, чтобы уменьшить хаос в работе.
- Лично познакомьтесь с реальными людьми по позициям и проговорите список обязательств с каждым при необходимости — это снизит процент недопонимания.
Что учесть на этапе выполнения
- Сформируйте список возможных рисков и действий по их устранению. Например, как не допустить срывы сроков.
- Организуйте раннее информирование участников по важным вопросам.
- Определите обязательные и необязательные активности, их приоритет и частоту.
Как соблюдать Delivery процесс
Допустим, вы наладили работу команды и взаимодействие со стейкхолдерами, прошли все этапы и успешно запустили проект. Отлично — теперь нужно это постоянно повторять. Такой подход позволит получать ожидаемые результаты, повысить качество выполняемых работ, снизить стоимость сопровождения процесса.
Очень важный момент для эффективной работы менеджера — соблюдение формальностей:
- Собирайте конкретные артефакты после окончания любого этапа, например, оформленные фичи.
- Планируйте все встречи/события.
- Будьте в курсе смены людей на позициях в проекте, немедленно проговаривайте список обязательств с пришедшими.
Список всегда можно расширить, но выполнение даже этих пунктов существенно упрощает работу PM-а и его взаимодействие с командой. Соблюдая формальности, вы избежите хаоса на проекте и снизите риски.
Вместо выводов
Стабильный Delivery Process — залог успешного запуска продукта, который имеет высокие шансы стать популярным на рынке. Главное в процессе — правильно определить бизнес-цели, требования к приложению и грамотно выстроить взаимодействие участников на всех этапах. Для этого важно подобрать подходящую команду специалистов, определить между ними роли и зоны ответственности, контролировать приоритетность задач и ход работы. Также помните, что повторяемость и соблюдение формальностей — ключ к высоким результатам.