Эта тема подробно обсуждается на курсе Основы Agile и Scrum.
При создании ИТ-продукта одновременно идут 3 процесса:
- Ответ на вопрос "Нужно делать вот это вот в таком порядке".
- Претворение этого в жизнь.
- Эксплуатация, использование и поддержка созданного.
Они идут и параллельно, и последовательно.
- Последовательно – с точки зрения жизненного цикла элемента, проходящего по конвейеру: идея, гипотеза, задача на реализацию, работающий функционал.
- Параллельно – в том смысле, что Владелец продукта, например, каждый день участвует во всех 3 процессах.
Прочитайте также о приоритизации гипотез.
Эти же 3 процесса по-другому:
- Discovery – исследование, проверка гипотез.
- Delivery – development, реализация, разработка, поставка.
- Production – промышленная среда, реально работающий и используемый продукт.
Рассмотрим первые 2 процесса подробнее.
Процесс Discovery
Современный популярный тезис в сфере создания ИТ-продуктов звучит так:
Не создавайте всё то, что приходит в голову. Сначала исследуйте: оно нужно вообще?
Если быть точнее, то не просто "нужно ли оно", а
- нужно именно тем клиентам, для которых задумали,
- нужно именно в том объеме, в котором хотим: будут платить временем, вниманием, деньгами,
- нужно именно сейчас,
- нужно больше, чем другие наши задумки.
Для создаваемого продукта формируется группа Discovery.
- Из кого состоит? Из всех, кто необходим для принятия решений о том, что нужно сделать. В финансовой организации это могут быть: сам Владелец продукта, юристы, маркетологи, финансисты, любые другие необходимые сотрудники.
- Лучше поддерживать эту группу относительно небольшой – порядка 10 человек.
- От каждой необходимой компетенции нужно по 1 человеку. Не позволяйте участвовать "тройками", в которых 1 принимает решение и еще 2 на подхвате и рутине – коммуникации станут неэффективными, другие участники будут недовольными.
- Руководит работой группы Владелец продукта.
- Это не административный отдел компании, а собранная рабочая группа. Сотрудники по-прежнему штатно находятся в своих привычных отделах.
- Некоторые могут быть задействованы в работе группы на 100%, однако многие меньше.
Эта группа:
- Добавляет идеи в бэклог идей, описывает их, разделяет на меньшие. В бэклог попадают и просто идеи, пришедшие в головы, и результаты исследований рынка и конкурентов, и пожелания пользователей, и другие.
- Упорядочивает их = присваивает порядковые номера на основании выбранного метода. Обычно это скоринг по каким-либо показателям, например, ICE, RICE, WSJF и др. Все участники выражают мнение в рамках своей экспертизы, однако решающее слово за Владельцем продукта.
- Предсказывает потенциальную выгоду от реализации идеи: количество клиентов, доход, время и частота использования и др.
4. В ходе ежедневной работы эта группа проводит проверку идей-гипотез, в частности:
- организует или проводит опросы и интервью клиентов,
- выпускает прототипы,
- предлагает пробные версии продукта,
- создает посадочные страницы с описанием продукта,
Одобренные идеи попадают в бэклог на реализацию – бэклог команды Delivery. (На самом деле в этот бэклог попадают еще и некоторые задачи по проверке гипотез, но не сами идеи целиком.)
Процесс Discovery целиком изображен на схеме ниже. А далее мы перейдем к процессу Delivery.
Процесс Delivery
Для создаваемого продукта формируется команда Delivery, или несколько команд. Примером такой команды является и Scrum-команда.
- Из кого состоит? Из всех, кто необходим для превращения одобренных идей в инкременты – элементы продукта. Обычно такая команда состоит из Владельца продукта (если продукт создает одна команда) и ИТ-специалистов: системные аналитики, дизайнеры, разработчики, тестировщики. Скрам настаивает на том, чтобы все участники команды назывались просто Developers. (Также прочитайте о "T-людях".)
- Команда кросс-функциональна – члены команды все вместе обладают всеми компетенциями, чтобы превращать идею в фичу продукта.
- Лучше поддерживать эту команду относительно небольшой – порядка 10 человек.
- Руководит работой команды... По-разному. Если у вас Скрам, то команда самоорганизуется для выполнения работы, которую предоставляет Владелец продукта через бэклог. Если другой процесс, то руководить может тимлид.
- Это не рабочая группа, а команда. У этих людей есть общая цель – цель продукта; и более важных целей у команды нет.
- Команда стабильна – все члены занимаются только 1 продуктом или проектом. Сотрудники штатно могут находиться в любых подразделениях, однако задействованы в работе команды на 100%.
Эта команда:
- Добавляет элементы в бэклог, описывает их, разделяет на меньшие. Часть задач приходит из бэклога идей, часть генерится командой (ИТ-задачи, улучшения), часть приходит из промышленной среды (инциденты).
- Упорядочивает их = присваивает порядковые номера на основании выбранного метода. Все участники выражают мнение в рамках своей экспертизы, однако решающее слово за Владельцем продукта.
- Реализует элементы работы из бэклога – создает фичи, из которых формируются инкременты – новые версии продукта.
Бэклог на разработку:
- состоит из элементов разных видов: фичи, истории, функции, характеристики, улучшения, архитектурные задачи, технический долг, инциденты, дефекты и другие;
- обязательно упорядочен;
- постоянно изменяется.
Команда использует один из популярных процессов работы (Scrum, Канбан-метод) или использует свою вариацию. В конце спринта обязательно, а по желанию и в любой момент команда выпускает "готовый" результат – соответствующий выбранным командой и организацией критериям готовности (Definition of "Done"). Элемент бэклога не может быть "готов на 80%" или "на 99%" – он либо готов, либо нет. Согласно Скраму только такие результаты можно продемонстрировать стейкхолдерам на встрече по обзору спринта.
Не все "готовые" инкременты сразу же поставляются клиенту. Это решение принимает Владелец продукта.
Процесс Delivery целиком изображен на схеме ниже.
Production
Еще один слой – промышленная среда. Оставлю его детали за рамками этой статьи. Сейчас нам достаточно упомянуть 2 момента:
- появляющиеся при эксплуатации инциденты, которые нужно обязательно устранить, попадают на слой Delivery в бэклог на разработку;
- обращения пользователей, пожелания, статистика использования идут в слой Discovery в бэклог идей.
Все 3 слоя
А теперь объединим все 3 вида деятельностей в процесс создания продукта = Discovery + Delivery + Production.
