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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник.

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

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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT