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