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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник.

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Все говорят: «Поток!». А ты построй поток
      «А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Мотивация разработчика В2В продукта
      Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT