Как обеспечить стабильный Delivery процесс

Создание IT-продукта — это объединение творческой энергии и технических знаний команды с организационными скиллами менеджера. При этом от действий PM-а во многом зависит, насколько комфортно и эффективно пройдет Delivery процесс. В статье подробно расскажем о том, на каких этапах и на что именно Product Manager должен обратить максимум внимания.

Что собой представляет Delivery Process

Delivery Process — комплекс работ, в который входит разработка, отладка, тестирование и запуск продукта с последующим сопровождением и внесением изменений при необходимости. 

Предлагаем рассматривать процесс Delivery, состоящим из 5 этапов:

1. Definition of Requirements (Need Help);
2. Delivery Definition;
3. Development;
4. Delivery Event;
5. 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

Из таблицы видно, что продакт, проектный менеджер и бизнес-аналитик в идеале должны участвовать на всех этапах. На практике часто 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 — залог успешного запуска продукта, который имеет высокие шансы стать популярным на рынке. Главное в процессе — правильно определить бизнес-цели, требования к приложению и грамотно выстроить взаимодействие участников на всех этапах. Для этого важно подобрать подходящую команду специалистов, определить между ними роли и зоны ответственности, контролировать приоритетность задач и ход работы. Также помните, что повторяемость и соблюдение формальностей — ключ к высоким результатам.