Портал №1 по управлению цифровыми
и информационными технологиями

От проектной к продуктовой поставке ПО. В чём суть?

Продуктовый подход поставки программного обеспечения

Пытаясь принять и использовать идею “продукта” в рамках ИТ-организации, иногда бывает трудно понять границы и зону ответственности продуктовой команды, как её деятельность связана с тем, что коллеги из бизнес-подразделений называют “продуктом”.

Чтобы помочь с пониманием концепции продуктовых ИТ-команд, воспользуемся моделью жизненного цикла продукта (Product life-cycle, PLC), поскольку он описывает этапы присутствия продуктов на рынке, используя соотношение между временем нахождения и объёмами продаж.

Жизненный цикл продукта

Каждый продукт, продаваемый сегодня на рынке потребительских товаров, имеет свой жизненный цикл – от момента создания до исчезновения. Хотя каждый продукт и имеет уникальный набор факторов, которые привели к его появлению на рынке и росту зрелости, фундаментально модель для понимания и распознавания этих этапов остается неизменной.

Жизненный цикл продукта состоит из четырех этапов:

  • Появление: продукт только-только появляется на рынке, он новый и не пользуется ещё большой популярностью.
  • Рост: продукт достигает переломного момента в конце первого этапа и может перейти в режим быстрого роста.
  • Зрелость: если рост состоялся, то на этом этапе продукта выходит на уровень своего максимального распространения и насыщения. Со временем продукт начинает показывать замедление роста и в конечном итоге признаки спада.
  • Исчезновение: признаки слабости, выявленные на предыдущем этапе, начинают проявляться всё ярче. Продукт теряет свою привлекательность и постепенно сходит со сцены.

Жизненный цикл программного продукта

Теперь, имея общее представление о жизненном цикле продукта, можно заметить несколько интересных вещей, связанных с продуктовыми командами разработки ПО и жизненным циклом продукта. Предположим, что на рынок выводится продукт ИТ. Заменим обозначение «Продажи» по оси Y на рисунке выше на «Ресурсы». Функциональные возможности продукта предоставляются клиентам, при этом ресурсы, необходимые для обеспечения этих возможностей, возрастают вплоть до точки падения эффективности. Ресурсами могут быть прямые затраты, трудочасы персонала, использование вычислительных мощностей (процессорное время / сети и каналы передачи данных / объёмы хранимых данных на СХД).

Что мы видим? Очевидно, что программные продукты не появляются волшебным образом из ниоткуда. Модель жизненного цикла продукта не учитывает ту деятельность, что необходима для появления и вывода продукта на рынок. На рисунке ниже поэтому добавлен раздел под названием «Создание». Эта часть жизненного цикла в большей степени соответствует проектному характеру деятельности от возникновения идеи до создания начального продукта.

Минимально жизнеспособный продукт

Чтобы продукт достиг порога жизнеспособности, мог быть выведен на рынок и представлен потребителям, нужно реализовать определённый объём возможностей, который стал бы восприниматься его потребителями как самостоятельная ценность. Разница в проектной и продуктовой моделях поставки программного обеспечения – реализация идеи минимально жизнеспособного продукта (minimum viable product, MVP).

Представьте, что вы строите дом. Чтобы дом воспринимался именно “домом”, а не кучей разнообразных строительных материалов и элементов отделки, необходимо наличие нескольких важнейших конструкционных и бытовых элементов: фундамент, пол, стены, крыша, утепление, водопровод, электричество, газ, санузлы, окна, двери и кухня.

Как поступает строительная компания, зная, что она может продать возводимый ею дом с определённым минимальным набором характеристик? Устанавливается стандартная ванная в санузле, на пол кладётся дешёвое напольное покрытие, на кухне гарнитур устанавливается без посудомоечной машины, а гаражные ворота без автоматического доводчика.

Аналогия с проектом – это идея построить дом, определив наименьшее количество функций, которые нужны для проживания в доме, и построив его. После того, как дом с минимальным набором функций будет построен и сдан, он выйдет из “проектной” стадии и перейдет в “продуктовую” фазу.

Аналогия с продуктом – это дальнейшее определение и реализация функций, которые необходимы, чтобы сделать дом более комфортным и удобным для проживания в соответствии с нашими постоянно меняющимися потребностями.

А теперь давайте расширим подобный подход к программным продуктам в целом. Чтобы получить выгоду от программной платформы, нам нужен базовый набор функций, которые нужны нашему клиенту для приобретения и использования платформы. Этот минимальный набор функций и есть наш минимально жизнеспособный продукт. Когда новая платформа ещё только придумывается, то для её реализации собирается команда – это команда проекта. Её задачей становится создание и вывод на рынок начального продукта.

От проекта к продукту

Проекты превращаются в продукты в тот момент, когда команда формирует минимально жизнеспособный продукт. После того, как он будет выпущен на рынок, начнётся измерение предоставляемой ценности. А команда станет постепенно добавлять новые функции или дорабатывать имеющиеся, чтобы добавить дополнительную ценность для клиентов или снизить риски по мере улучшения продукта. Такой подход требует как итеративного мышления, так и связанного денежного потока для обеспечения возможностей команды к итерациям.

От появления идеи, через создание и рост ценности до её уменьшения и окончательного исчезновения – жизненный цикл программного продукта показывает, как на этапе проекта создаётся базовый уровень минимально жизнеспособного продукта, способного приносить ценность и окупать начальные инвестиции. А затем, следуя фазам классического жизненного цикла продукта, к появлению новой идеи и, соответственно, нового продукта. Такая цепочка и есть эволюция от проекта к продукту.

Особенности проектной и продуктовой моделей

В приведенной ниже таблице более подробно показаны особенности каждой из моделей.

  Проектная Продуктовая
Бюджет Финансирование основных этапов (вех), определённых при оценке проекта. Новый бюджет – новый проект Финансирование потоков ценности, скорректированных в зависимости от результатов деятельности. Распределение нового бюджета в зависимости от спроса
Временные границы Срок реализации проекта (например, один год). Заданная дата окончания Жизненный цикл продукта (несколько лет). Включает в себя мероприятия по исправлению / улучшению
Мера успеха Подход “центра затрат”: вовремя и в рамках бюджета Подход центра прибыли: достижение бизнес-целей и результатов
Подход к работе с людьми Назначение людей для выполнения работы. Вовлечение в несколько разных проектов, частые переназначения Работа передаётся людям. Стабильные, постепенно корректируемые кросс-функциональные команды, привязанные к одному потоку создания ценности
Культура Централизованная организация: принцип «сверху вниз», соблюдение сроков, принятие решений Организация, наделённая полномочиями, нацеленная на сотрудничество и совместную работу, готовая экспериментировать и обучаться на ошибках и неудачах
Приоритеты Управление программами и портфелями проектов на основе плана проекта с упором на выполнение требований. Ориентация на “водопадную модель” разработки Управление на основе дорожной карты и проверки гипотез с акцентом на функциональность и ценность для бизнеса. Ориентация на Agile
Преимущества Распределение ресурсов и планирование строго определённой, заранее известной работы с низкой изменчивостью Быстрая обратная связь и обучение, высокая вариативность работы
     

Источник.

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;