При создании ИТ-продукта одновременно идут 3 процесса:
- Ответ на вопрос "Нужно делать вот это вот в таком порядке".
- Претворение этого в жизнь.
- Эксплуатация, использование и поддержка созданного.
Они идут и параллельно, и последовательно.
- Последовательно – с точки зрения жизненного цикла элемента, проходящего по конвейеру: идея, гипотеза, задача на реализацию, работающий функционал.
- Параллельно – в том смысле, что Владелец продукта, например, каждый день участвует во всех 3 процессах.
Эти же 3 процесса по-другому:
- Discovery – исследование, проверка гипотез.
- Delivery – development, реализация, разработка, поставка.
- Production – промышленная среда, реально работающий и используемый продукт.
![](https://static.tildacdn.com/tild3436-3335-4464-b032-353930616265/DBlinov-com_Discover.png)
Рассмотрим первые 2 процесса подробнее.
Процесс Discovery
Современный популярный тезис в сфере создания ИТ-продуктов звучит так:
Не создавайте всё то, что приходит в голову. Сначала исследуйте: оно нужно вообще?
Если быть точнее, то не просто "нужно ли оно", а
- нужно именно тем клиентам, для которых задумали,
- нужно именно в том объеме, в котором хотим: будут платить временем, вниманием, деньгами,
- нужно именно сейчас,
- нужно больше, чем другие наши задумки.
Для создаваемого продукта формируется группа Discovery.
- Из кого состоит? Из всех, кто необходим для принятия решений о том, что нужно сделать. В финансовой организации это могут быть: сам Владелец продукта, юристы, маркетологи, финансисты, любые другие необходимые сотрудники.
- Лучше поддерживать эту группу относительно небольшой – порядка 10 человек.
- От каждой необходимой компетенции нужно по 1 человеку. Не позволяйте участвовать "тройками", в которых 1 принимает решение и еще 2 на подхвате и рутине – коммуникации станут неэффективными, другие участники будут недовольными.
- Руководит работой группы Владелец продукта.
- Это не административный отдел компании, а собранная рабочая группа. Сотрудники по-прежнему штатно находятся в своих привычных отделах.
- Некоторые могут быть задействованы в работе группы на 100%, однако многие меньше.
![](https://static.tildacdn.com/tild3334-3564-4436-b039-326363343030/DBlinov-com_Discover.png)
Эта группа:
- Добавляет идеи в бэклог идей, описывает их, разделяет на меньшие. В бэклог попадают и просто идеи, пришедшие в головы, и результаты исследований рынка и конкурентов, и пожелания пользователей, и другие.
- Упорядочивает их = присваивает порядковые номера на основании выбранного метода. Обычно это скоринг по каким-либо показателям, например, ICE, RICE, WSJF и др. Все участники выражают мнение в рамках своей экспертизы, однако решающее слово за Владельцем продукта.
- Предсказывает потенциальную выгоду от реализации идеи: количество клиентов, доход, время и частота использования и др.
![](https://static.tildacdn.com/tild3731-6435-4565-a563-623535303835/DBlinov-com_Discover.png)
4. В ходе ежедневной работы эта группа проводит проверку идей-гипотез, в частности:
- организует или проводит опросы и интервью клиентов,
- выпускает прототипы,
- предлагает пробные версии продукта,
- создает посадочные страницы с описанием продукта,
![](https://static.tildacdn.com/tild3166-6464-4366-a366-396263633038/DBlinov-com_Discover.png)
Одобренные идеи попадают в бэклог на реализацию – бэклог команды Delivery. (На самом деле в этот бэклог попадают еще и некоторые задачи по проверке гипотез, но не сами идеи целиком.)
![](https://static.tildacdn.com/tild3262-3032-4034-b661-323036363765/DBlinov-com_Discover.png)
Процесс Discovery целиком изображен на схеме ниже. А далее мы перейдем к процессу Delivery.
![](https://static.tildacdn.com/tild3962-3862-4536-b065-653738383165/DBlinov-com_Discover.png)
Процесс Delivery
Для создаваемого продукта формируется команда Delivery, или несколько команд. Примером такой команды является и Scrum-команда.
- Из кого состоит? Из всех, кто необходим для превращения одобренных идей в инкременты – элементы продукта. Обычно такая команда состоит из Владельца продукта (если продукт создает одна команда) и ИТ-специалистов: системные аналитики, дизайнеры, разработчики, тестировщики. Скрам настаивает на том, чтобы все участники команды назывались просто Developers. (Также прочитайте о "T-людях".)
- Команда кросс-функциональна – члены команды все вместе обладают всеми компетенциями, чтобы превращать идею в фичу продукта.
- Лучше поддерживать эту команду относительно небольшой – порядка 10 человек.
- Руководит работой команды... По-разному. Если у вас Скрам, то команда самоорганизуется для выполнения работы, которую предоставляет Владелец продукта через бэклог. Если другой процесс, то руководить может тимлид.
- Это не рабочая группа, а команда. У этих людей есть общая цель – цель продукта; и более важных целей у команды нет.
- Команда стабильна – все члены занимаются только 1 продуктом или проектом. Сотрудники штатно могут находиться в любых подразделениях, однако задействованы в работе команды на 100%.
![](https://static.tildacdn.com/tild3439-3632-4230-b663-306234343032/DBlinov-com_Discover.png)
Эта команда:
- Добавляет элементы в бэклог, описывает их, разделяет на меньшие. Часть задач приходит из бэклога идей, часть генерится командой (ИТ-задачи, улучшения), часть приходит из промышленной среды (инциденты).
- Упорядочивает их = присваивает порядковые номера на основании выбранного метода. Все участники выражают мнение в рамках своей экспертизы, однако решающее слово за Владельцем продукта.
- Реализует элементы работы из бэклога – создает фичи, из которых формируются инкременты – новые версии продукта.
Бэклог на разработку:
- состоит из элементов разных видов: фичи, истории, функции, характеристики, улучшения, архитектурные задачи, технический долг, инциденты, дефекты и другие;
- обязательно упорядочен;
- постоянно изменяется.
![](https://static.tildacdn.com/tild6234-3533-4064-a336-326265393133/DBlinov-com_Discover.png)
Команда использует один из популярных процессов работы (Scrum, Канбан-метод) или использует свою вариацию. В конце спринта обязательно, а по желанию и в любой момент команда выпускает "готовый" результат – соответствующий выбранным командой и организацией критериям готовности (Definition of "Done"). Элемент бэклога не может быть "готов на 80%" или "на 99%" – он либо готов, либо нет. Согласно Скраму только такие результаты можно продемонстрировать стейкхолдерам на встрече по обзору спринта.
Не все "готовые" инкременты сразу же поставляются клиенту. Это решение принимает Владелец продукта.
![](https://static.tildacdn.com/tild6132-3562-4230-b832-363938396665/DBlinov-com_Discover.png)
Процесс Delivery целиком изображен на схеме ниже.
![](https://static.tildacdn.com/tild3264-3038-4331-b332-346133366239/DBlinov-com_Discover.png)
Production
Еще один слой – промышленная среда. Оставлю его детали за рамками этой статьи. Сейчас нам достаточно упомянуть 2 момента:
- появляющиеся при эксплуатации инциденты, которые нужно обязательно устранить, попадают на слой Delivery в бэклог на разработку;
- обращения пользователей, пожелания, статистика использования идут в слой Discovery в бэклог идей.
Все 3 слоя
А теперь объединим все 3 вида деятельностей в процесс создания продукта = Discovery + Delivery + Production.
![](https://static.tildacdn.com/tild3139-6338-4434-b031-346634306364/DBlinov-com_Discover.png)