Жизненный цикл продуктов в IT – какие фазы в него входят и почему
Как разработчики, мы нередко сталкиваемся с непониманием фаз жизненного цикла продуктов. Приходится опровергать представление о том, что после релиза проекта разработка завершена. По опыту знаем, что в первые месяцы жизни продукта может понадобиться допилить или переделать функционал, пофиксить баги.
Чтобы передать наше видение жизненного цикла разработки, мы поговорили с главными разработчиками Azoft и попросили поделиться представлениями об этом. Текст статьи будет полезен и для бизнеса, и для наших коллег.
Итак, разработка успешного продукта – сложный многоступенчатый процесс. Только в кино начинающие бизнесмены придумывают крутую идею, попивая кофе из Starbucks. По сюжету, они играючи находят инвестиции и выпускают приложение, которое захватывает мир. В реальности всё не так просто.
Создание и развитие любого продукта происходит постепенно, проходя ряд обязательных этапов, часть из которых может идти параллельно. Приложениям, которые вы любите, и на которые охотно тратите время, понадобился не один год, чтобы обрести текущий визуальный облик и наполнение. И едва ли их разработчики остановятся на достигнутом.
Жизненный цикл проекта в IT – непрерывный процесс, который заканчивается лишь, когда его решают закрыть. Если вы придумали идею продукта и обратились к команде разработчиков, приготовьтесь, впереди много работы. О Силиконовой долине помечтаем позже.: )
Что же входит в жизненный цикл продукта?
Жизненный цикл программного обеспечения (software development life cycle, SDLC) – условная схема, включающая фазы создания программного обеспечения. Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. На выходе должен получиться экономически выгодный продукт, отвечающий требованиям заказчика.
В структуру цикла разработки входят все этапы жизни программного обеспечения от его рождения в виде идеи до условной «смерти» (этапы до разработки, во время разработки и после неё).
Погружение команды в бизнес-контекст – важная фаза цикла разработки программного обеспечения, с которой начинается рабочий процесс. Клиент должен понимать, что он тратит время и ресурсы на этом этапе не просто так. Ему важно, чтобы команда проекта погрузилась в детали бизнеса и тщательнее разобралась, для какого рынка готовится продукт, как сделать его по-настоящему полезным. Это актуально для любой отрасли.
Сбор и анализ требований – одна из наиболее важных фаз SDLC. Она выполняется при участии клиентов, отдела продаж и отдела аналитики. На этом этапе важно максимально точно и однозначно определить требования к проекту и для команды проекта, и для бизнеса. Аналитики помогают определить конечные цели и задачи работы. Подробнее об этом этапе вы можете прочитать в нашей статье.
Дизайн. К этому этапу переходят, когда есть четкое понимание целей проекта, и достаточно подробно сформулированы его требования. На основании требований обычно предлагается несколько подходов к проектированию архитектуры продукта. Внутренний дизайн всех модулей архитектуры должен быть четко определен и описан в деталях.
Кодирование. Это этап непосредственной реализации системы – написание кода на выбранном с учётом стоящих задач языке программирования.
Тестирование. Система запускается в бой. Этот этап сопровождается проверкой работоспособности системы, выявлением, фиксацией и исправлением багов до тех пор, пока продукт не достигнет требуемых стандартов качества. В этот период обычно возникает много несостыковок, белых пятен, багов. Их нужно оперативно устранить.
Внедрение. Когда продукт протестирован и готов к развертыванию, его выпускают на рынке. Иногда развертывание продукта происходит последовательно в рамках бизнес-стратегии. Продукт может быть сначала выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, затем, основываясь на отзывах, выйти как есть либо с улучшениями.
Сопровождение. На этом этапе жизненного цикла обеспечивается периодическая техническая поддержка системы. Это позволяет убедиться, что система не устарела и отвечает современным стандартам и технологиям. Сюда входит постоянная оценка производительности и апдейты компонентов.
Помимо указанных фаз, мы выделяем и фазу маркетингового продвижения. Маркетинговая деятельность является сквозной и проводится на протяжении всего жизненного цикла проекта. Клиенту важно создать осведомленность о продукте среди его целевой аудитории, привлечь пользователей, наработать клиентскую базу.
Все процессы разработки типовые, но подходы к работе бывают разные. И в зависимости от подхода определяется то, какой длины будут этапы, будут ли они делаться последовательно или итеративно, и как их будут выполнять.
Мы не раз сталкивались с тем, когда клиенты, прежде всего, стартапы обращаются с предложением разработать продукт, но изначально не планируют его сопровождение. Они не закладывают время и бюджет на его развитие в ходе эксплуатации.
В результате бизнес может столкнуться с ситуацией, когда все средства потрачены на разработку, а на поддержку или пиар проекта нет средств, как и договоренностей с командой о дополнительных работах.
Рады отметить, что сейчас такие ситуации возникают реже. Как правило, клиенты знают, что нужно предусматривать и обсуждать с деловыми партнерами будущее проекта. Они понимают, что жизнь продукта начинается с его идеи, а эксплуатация является важной частью жизненного цикла. Продукт – это всегда шире, чем разработка.
Не всегда верные представления о жизненном цикле ПО имеют и разработчики. Некоторые из них думают: ну что ж, я написал код, выложился по максимуму, а что с продуктом будет дальше, уже не должно меня беспокоить. На самом деле, программисты всегда должны быть готовы к постоянному взаимодействию с клиентами – к поддержке и сопровождению созданных решений.
У Azoft сложился опыт долговременного партнерства со многими крупными компаниями. Например, мы успешно осуществляем поддержку персонального кабинета для программы лояльности «Спасибо от Сбербанка».
Постоянное сотрудничество выгодно и нам, и клиентам Azoft. При таком подходе мы постоянно находимся в контексте проектов, над которыми работаем. Клиенту не нужно погружать в процессы сторонних разработчиков, тратить дополнительные усилия. Мы уверены, что крепкие партнерские отношения важны на всех фазах работы, а не только на старте.
Хотите разработать качественный продукт, решающий задачи бизнеса? Почитайте полезные статьи о нашем опыте разработки и обращайтесь за бесплатной консультацией.
Жизненный цикл и фазы проекта
Промежуток времени между моментом появления проекта и моментом его ликвидации принято называть проектным циклом или жизненным циклом проекта. Для каждого проекта, вне зависимости от лежащего в его основе замысла, характерен жизненный цикл определённой продолжительности.
1. Жизненный цикл и фазы проекта
Жизненные циклы проекта понимаются как определенные фазы, через которые проходит тот или иной замысел в процессе своей реализации, а также функционирования. Такое разделение важно не только с теоретической, но также и с практической точки зрения, ведь оно дает возможность лучше контролировать процесс производства.
Определение термина Понятие жизненного цикла проекта подразумевает под собой определенную последовательность этапов по реализации той или иной идеи касательно производственного или управленческого процесса. Роль данного понятия может быть выражена в следующих утверждениях:
— определяет продолжительность проекта, четко обозначая даты его начала и завершения; позволяет детализировать процесс реализации замысла, разбивая его на конкретные фазы;
— дает возможность четко определить количество задействованного персонала, а также необходимые ресурсы;
— облегчает процедуру контроля.
Стадии жизненного цикла проекта
В процессе реализации того или иного замысла касательно производственного процесса или прочих мероприятий на предприятии можно выделить несколько последовательных моментов. Так, принято выделять следующие этапы жизненного цикла проекта:
- Инициация — происходит выдвижение идеи, а также подготовка проектных документов. Производится детальное обоснование, а также маркетинговые исследования, которые послужат подспорьем для реализации последующих стадий.
- Планирование — определение сроков реализации замысла, разделение данных процессов на конкретные этапы, а также назначение исполнителей и ответственных лиц.
- Исполнение — начинается сразу же после того, как были утверждены планы. Подразумевает реализацию в полном объеме всех намеченных действий.
- Завершение — анализ полученных данных и контроль на предмет соответствия их запланированным. Данная обязанность в большинстве случаев возлагается на руководство.
Стоит отметить, что данное деление на этапы жизненного цикла проекта весьма условное. Каждая организация вправе самостоятельно детализировать этот процесс и разбивать его на стадии.
Можно выделить четыре основные фазы жизненного цикла проекта, а именно:
- исследования, предшествующие инвестированию — это выбор наилучшего варианта проекта, проведение переговоров с заинтересованными лицами, а также эмиссия ценных бумаг, посредством которых будет привлекаться капитал;
- непосредственно инвестирование, когда посредством продажи акций или других финансовых инструментов в организацию поступают средства, необходимые для реализации замысла;
- эксплуатация проекта — это полномасштабный производственный процесс, который проводится согласно заранее разработанному плану;
- послеинвестиционное исследование заключается в оценке эффективности деятельности, а также в определении соответствия полученных результатов предполагаемым.
Особенности жизненного цикла проекта
Жизненные циклы проекта, как уже было сказано выше, могут быть выстроены индивидуально с учетом специфики того или иного предприятия. Тем не менее, все они имеют некоторые общие особенности, а именно:
— Наибольшим количество затрат и персонала, задействованного в реализации проекта, является в середине цикла. Начало и конец данного процесса характеризуются невысокими показателями.
— На первом этапе наблюдается наибольший уровень риска, а также неуверенности и сомнений по поводу успешного исхода деятельности.
— В начале жизненного цикла проекта участники имеют огромные возможности касательно внесения изменений и совершенствования методик достижения целей.
С течением времени это становится сделать все сложнее.
Каскадная модель жизненного цикла проекта
Несмотря на то что жизненные циклы для каждого отдельно взятого проекта или организации могут существенно отличаться, существуют некоторые общепринятые модели, которые могут послужить базовой основой. Одной из самых распространенных является водопадная, которая подразумевает последовательное выполнение каждого запланированного действия и характеризуется следующими особенностями:
составление четкого плана действий по достижению поставленных целей;
по каждому действию определяется определенный перечень задач, а также обязательных к исполнению работ;
внедрение промежуточных (контрольных) этапов, на которых будет проводиться контроль за соблюдением ранее разработанного плана.
Спиральная модель
Жизненные циклы проекта, которые отличаются цикличностью, разрабатываются согласно спиральной модели. На каждом витке определяется эффективность разработки в соответствии с ее стоимостью. Эта модель отличается тем, что при ее разработке одна из ключевых позиций отводится рисковой составляющей, которая чаще всего включает в себя следующие пункты:
— недостаток квалифицированных и опытных кадров;
— возможность выйти за рамки бюджета или же не уложиться в заданные сроки;
— потеря актуальности разработки за время ее реализации;
— необходимость вносить изменения в процессе производства;
— риски, связанные с внешними факторами (перебои с поставками, изменение рыночной ситуации и так далее);
— несоответствие производственной мощности необходимому уровню;
— противоречия в работе различных подразделений.
Инкрементная модель
Жизненные циклы проекта могут быть рассмотрены с точки зрения инкрементной модели. Наиболее актуальным и обоснованным ее использование будет в том случае, когда предполагается сложная и масштабная работа с большим количеством участников. В данном случае объемный проект расчленяется на множество мелких составляющих, которые, реализуясь по частям, впоследствии складываются в масштабный проект. Инкрементная модель не требует единовременного вложения всей необходимой суммы средств. Можно постепенно вносить небольшие суммы, покрывающие каждый из этапов. А поскольку весь проект разбит на небольшие составляющие, то он является достаточно гибким и позволяет в любое время вносить соответствующие изменения. И одним из самых важных моментов является минимизация рисков, которые равномерно распределяются между фазами (инкрементами).
Принципы жизненного цикла проекта
Жизненные циклы проекта характеризуются рядом принципов, а именно:
наличие детального плана, в котором четко прописаны все временные периоды, сроки, участники, а также показатели в цифровом выражении, которые должны быть достигнуты по итогам работы;
должна быть разработана система отчетности, в соответствии с которой по завершении каждой стадии будет проводиться мониторинг соответствия достигнутых результатов заявленным;
наличие системы анализа, в соответствии с которой может быть спрогнозирована будущая ситуация, с целью внесения коррективов;
в организации должна быть налажена система реагирования на непредвиденные ситуации, чтобы работа могла быть направлена в нужное русло на любом из этапов жизненного цикла.
Адаптация модели жизненного цикла проекта
В данном учебном пособии по управлению ИТ-проектами в качестве концептуальной основы используется модель жизненного цикла информационных систем (ЖЦ ИС), описанная в стандарте ГОСТ Р ИСО/МЭК 15288. В соответствии с данным стандартом запуск каждого нового проекта подразумевает создание (или адаптацию уже имеющейся) модели ЖЦ, состоящей из стадий.
Процесс создания (или адаптации уже имеющейся) модели ЖЦ начинается с определения целей и результатов каждой из стадий, образующих структуру работ для детализированного моделирования процессов реализации ИТ. [10]
Исходя из допущений базового стандарта, а также типовых этапов ЖЦ ИТ и принятой последовательности их реализации, авторами предлагается следующая модель ЖЦ ИТ, определяющая последовательность изложения материала в книге.
1. Планирование проекта
3. Разработка и внедрение
4. Эксплуатация и поддержка
5. Утилизация и обновление
В таблице ниже представлены цели каждой из выделенных стадий ЖЦ (см. табл. 1.1).
| Таблица 1.1. Цели этапов жизненного цикла информационной системы | ||
| Этап (ГОСТ Р ИСО/ МЭК 15288) | Этап (адаптированный) | Цель этапа |
| Замысел | Планирование проекта | Оценка новых возможностей в деловой сфере, разработка предварительных системных требований и проверка их осуществимости. Концептуальное планирование всего ЖЦ ИС |
| Разработка | Проектирование | Создание проекта системы, которая удовлетворяет требованиям приобретающей стороны и может быть реализована, испытана, оценена, применена по назначению, поддержана при применении, в последующем списана и/или обновлена |
| Производство | Разработка и внедрение | Разработка (настройка) системы в соответствии с требованиями приобретающей стороны, тестирование системы, реализация соответствующих организационно-технических мероприятий и развертывание поддерживающих систем, направленных на обеспечение корректной эксплуатации внедренного продукта |
| Применение Поддержка применения | Эксплуатация и поддержка | Использование внедренного продукта в заданных условиях функционирования и обеспечение продолжительной результативности. Осуществление в процессе эксплуатации материально-технического снабжения, технического обслуживания и текущего ремонта, которые обеспечивают непрерывное функционирование рассматриваемой системы и устойчивое предоставление услуг, поддерживающих ее применение |
| Изъятие и списание | Утилизация и обновление | Обеспечение удаления рассматриваемой системы и связанных с нею обслуживающих и поддерживающих организационно-технологических подсистем. Поддержка планирования перехода на новую версию текущей или на абсолютно новую систему |
Приведенные этапы есть стадии жизненного цикла информационной системы и не тождественны жизненному циклу проекта. Жизненный цикл продукта отражает, что нужно сделать для создания, эксплуатации, поддержки и утилизации данного продукта, а жизненный цикл проекта — как нужно организовывать и управлять работой.Фаза ЖЦ продукта может включать в себя все этапы ЖЦ проекта (см. рис. 1.1 (а, б)), и, в соответствии со стандартом ГОСТ Р ИСО/МЭК 15288 [10], предусматривает наличие этапов планирования, оценки и контроля, а также процесса принятия решения — шлюза (см. рис. 1.1. (а)), через который происходит переход на следующий этап ЖЦ ИС и который является точкой мониторинга качества и точкой принятия решения о целесообразности продолжения проекта [10]. Необходимо отметить, что планирование, оценка и контроль характерны для любого цикла управления (например, цикл Деминга). Таким образом, использование их, в том числе на этапе "Эксплуатация и поддержка", носящем выраженный операционный (не проектный) характер, вполне обосновано.
Рассмотрение каждой стадии ЖЦ ИТ в качестве отдельного проекта позволяет (по сути, делает единственно возможным) применять метод планирования по принципу набегающей волны, который значительно понижает рискованность проекта и повышает шансы на успех [9].
Рис. 1.1.(а,б) Примеры соотношения жизненного цикла информационной системы и жизненного цикла проекта
В то же время процессы, выполняемые в рамках одной стадии ЖЦ ИТ, могут иметь взаимосвязи как в рамках данной стадии, так и с процессами других стадий. Очевидно, что для успешного достижения целей проекта необходимо не только управлять каждым процессом в отдельности, но и обеспечить комплексный подход к управлению с учетом взаимосвязей, взаимозависимостей как отдельных процессов, так и групп процессов.
С целью структурирования процессы управления проектом принято делить на области знаний. Ниже перечислены области знаний, составляющие процессы проектного управления. Предложенный перечень сформирован на основе рекомендаций лучших мировых практик и содержится в стандарте управления проектами [1,10, 23].
1. Управление интеграцией
2. Управление содержанием
3. Управление сроками
4. Управление стоимостью
5. Управление качеством
6. Управление рисками
7. Управление человеческими ресурсами
8. Управление коммуникациями
9. Управление конфигурацией
Описание содержания каждой из перечисленных выше областей знаний и соответствующих им процессов приводится в табл. 1.2.
| Таблица 1.2. Области знаний проектного управления | ||
| Область знаний | Описание | Процессы |
| Управление интеграцией | Управление интеграцией включает в себя процессы и действия, необходимые для определения, уточнения, комбинирования, объединения и координирования различных процессов и действий по управлению проектом в рамках групп процессов управления проектом. Таким образом, цель данного процесса состоит в достижении эффективного взаимодействия процессов управления проектами, обеспечивающих достижение целей проекта. Эффективное взаимодействие на стадии планирования заключается в формировании базовой линии проекта 1 (project baseline), на стадии оценки — в сравнении с базовой линией и корректировке в соответствии с ней на стадии контроля | 1. Разработка ТЭО проекта. 2. Разработка устава проекта. 3. Разработка плана управления проектом. 4. Руководство и управление исполнением проекта. 5. Осуществление интегрированного управления изменениями. 6. Оценка альтернатив развития проекта. 7. Планирование закрытия проекта и перехода в стадию эксплуатации. 8. Завершение проекта. |
| Управление содержанием | Управление содержанием включает в себя процессы и действия, обеспечивающие включение в проект всех тех и только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением и контролем того, что включено или не включено в проект [1,23] | 1. Формирование требований проекта. 2. Формирование ИСР. 3. Определение содержания проекта. 4. Определение результатов всех стадий жц ис. 5. Оценка реализуемости требований проекта. 6. Подтверждение содержания проекта. 7. Определение уточненных системных требований. 8. Мониторинг содержания и объема проекта. 9. Оценка готовности пользователей к работе в системе. 10. Планирование обучения конечных пользователей |
| Управление сроками | Управление сроками проекта включает в себя процессы, обеспечивающие своевременное завершение проекта [23] | 1. Формирование списка работ проекта. 2. Определение последовательности работ проекта. 3. Оценка трудоемкости и продолжительности работ. 4. Разработка базового расписания проекта. 5. Контроль и управление расписанием проекта |
| Управление стоимостью | Управление стоимостью проекта объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контролирования затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета [23] | 1. Оценка стоимости проекта. 2. Разработка сметы проекта. 3. Разработка базового плана по стоимости. 4. Управление стоимостью проекта |
| Управление качеством | Процессы управления качеством проекта объединяют все осуществляющиеся в исполняющей организации операции, определяющие политику, цели и распределение ответственности в области качества таким образом, чтобы проект удовлетворял тем нуждам, для которых он был предпринят. Управление качеством осуществляется посредством системы управления, предусматривающей определенные правила, процедуры и процессы по планированию качества, обеспечению качества и контролю качества, а также операции по их совершенствованию | 1. Формирование программы качества проекта. 2. Формирование базовой линии требований проекта. 3. Управление требованиями проекта. 4. Осуществление обеспечения качества. 5. Тестирование. 6. Приемка результатов |
| Управление риском | Процесс управления рисками тесно связан с общим жизненным циклом проекта. На ранних этапах преобладают риски, связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. На стадии реализации доминируют технологические риски, далее возрастает роль рисков, связанных с поддержкой и сопровождением системы. На протяжении всего жизненного цикла проекта возникают новые риски, что требует проведения дополнительных операций анализа и планирования. Согласно ГОСТ Р ИСО/ МЭК 152888-2005 [10] цель процесса управления рисками заключается в снижении последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков или ухудшения технических характеристик. В ходе данного процесса проводятся определение, оценка, обработка и мониторинг рисков, возникающих в течение полного жизненного цикла, а также вырабатывается реакция на каждый риск в терминах реализации соответствующих мер противодействия риску или его принятия | 1. Планирование управления рисками. 2. Идентификация рисков. 3. Качественный анализ рисков. 4. Количественный анализ рисков. 5. Планирование реагирования на риски. 6. Мониторинг и управление рисками |
| Управление человеческими ресурсами | Управление человеческими ресурсами проекта — это процесс обеспечения эффективного использования человеческих ресурсов проекта, к которым относятся все участники проекта (спонсоры, заказчики, команда проекта, субподрядчики, подразделения компании и другие участники проекта [13,17]) | 1. Планирование человеческих ресурсов. 2. Набор команды проекта. 3. Оценка доступности. 4. Развитие и оценка команды проекта. 5. Организация инфраструктуры проекта |
| Управление коммуникациями | Управление коммуникациями проекта — это процесс идентификации и эффективного обеспечения всех участников проекта информацией о проекте, а также создания единого образа проекта внутри организации | 1. Идентификация участников проекта. 2. Формирование стратегии и плана коммуникаций. 3. Реализация плана коммуникаций и сбор обратной связи |
| Управление конфигурацией | Управление конфигурацией — процесс управления аппаратными средствами, программным обеспечением, данными, а также документацией в ходе разработки, тестирования и использования информационных систем.Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны. Задачи управления конфигурацией проекта: 1. определение стратегии управления конфигурацией, включающей следующие вопросы: o — определение полномочий на запрет или разрешение доступа, реализацию и контроль изменений элементов конфигурации; o определение места и условий хранения элементов конфигурации, включая требования к окружающей среде, а в случае информации — требования к хранению носителей информации в соответствии с назначенными уровнями целостности, защищенности и безопасности; o определение критериев или событий, соответствующих началу контроля конфигурации и сопровождения базовых линий в процессе эволюции конфигураций; o определение стратегии аудита и ответственности за гарантии непрерывной целостности и защищенности информации, описывающей конфигурацию; 2. идентификация элементов, которые необходимо контролировать в процессе управления конфигурацией; 3. поддержка информации о конфигурации на приемлемом уровне целостности и защищенности. Для этого рекомендуется: o поддерживать записи о конфигурации в течение всего жизненного цикла и архивировать их в соответствии с соглашениями, законодательством или передовым производственным опытом; o описывать конфигурацию в соответствии с производственным или технологическим стандартами там, где это возможно. o регистрировать обоснования для изменений базовой линии конфигурации и связанные с этим данные о соответствующих разрешениях; 4. гарантирование того, что изменения базовой линии конфигурации соответствующим образом идентифицируются, записываются, оцениваются, утверждаются, проводятся и верифицируются. Для этого рекомендуется: o регистрировать этапы конфигурации; o управлять выполнением записей, изменениями и утверждениями текущего статуса конфигурации и статуса всех предыдущих конфигураций для подтверждения корректности, своевременности, целостности и защищенности информации; o проводить аудит для проверки соответствия базовой линии УК требованиям к результатам проекта | 1. Идентификация объектов управления конфигурацией. 2. Планирование инфраструктуры стадии разработки. 3. Установление базовой линии конфигурации проекта. 4. Оценка соответствия базовой линии конфигурации. 5. Контроль конфигурации выделенных элементов проекта. 6. Обеспечение целостности элементов конфигурации. 7. Реконфигурация инфраструктуры проекта |
Каждый из этапов ЖЦ ИТ и ЖЦ проекта предусматривает совокупность задач, с полной матрицей которых можно ознакомиться в Приложении 1.
В рамках конкретных проектов предложенные этапы ЖЦ ИТ, а также и отдельно взятые процессы ЖЦ ИТ могут быть индивидуально отобраны, идентифицированы и, при необходимости, модифицированы для достижения измененных целей и результатов соответствующих стадий.
Сделанные изменения должны быть задокументированы. Общие требования к процедуре модификации таковы: любой новый процесс жизненного цикла определяется и документируется в терминах его назначения, целей и результатов. Ответственным за такого рода модификации является, как правило, руководитель соответствующего проекта. В то же время утверждение адаптированной, сокращенной или дополненной модели ЖЦ ИС обычно производит офис управления проектами или иная организационная единица, в круг обязанностей которой входит поддержание целостности и актуальности корпоративной методологии управления проектами [8].
Приведенная процедура и шаблон документирования модификации ЖЦ ИТ являются одним из возможных вариантов оформления соответствующих действий над ЖЦ ИТ.
От проектной к продуктовой поставке ПО. В чём суть?
Пытаясь принять и использовать идею «продукта» в рамках ИТ-организации, иногда бывает трудно понять границы и зону ответственности продуктовой команды, как её деятельность связана с тем, что коллеги из бизнес-подразделений называют «продуктом».
Чтобы помочь с пониманием концепции продуктовых ИТ-команд, воспользуемся моделью жизненного цикла продукта (Product life-cycle, PLC), поскольку он описывает этапы присутствия продуктов на рынке, используя соотношение между временем нахождения и объёмами продаж.
Жизненный цикл продукта
Каждый продукт, продаваемый сегодня на рынке потребительских товаров, имеет свой жизненный цикл — от момента создания до исчезновения. Хотя каждый продукт и имеет уникальный набор факторов, которые привели к его появлению на рынке и росту зрелости, фундаментально модель для понимания и распознавания этих этапов остается неизменной.
Жизненный цикл продукта состоит из четырех этапов:
- Появление: продукт только-только появляется на рынке, он новый и не пользуется ещё большой популярностью.
- Рост: продукт достигает переломного момента в конце первого этапа и может перейти в режим быстрого роста.
- Зрелость: если рост состоялся, то на этом этапе продукта выходит на уровень своего максимального распространения и насыщения. Со временем продукт начинает показывать замедление роста и в конечном итоге признаки спада.
- Исчезновение: признаки слабости, выявленные на предыдущем этапе, начинают проявляться всё ярче. Продукт теряет свою привлекательность и постепенно сходит со сцены.
Жизненный цикл программного продукта
Теперь, имея общее представление о жизненном цикле продукта, можно заметить несколько интересных вещей, связанных с продуктовыми командами разработки ПО и жизненным циклом продукта. Предположим, что на рынок выводится продукт ИТ. Заменим обозначение «Продажи» по оси Y на рисунке выше на «Ресурсы». Функциональные возможности продукта предоставляются клиентам, при этом ресурсы, необходимые для обеспечения этих возможностей, возрастают вплоть до точки падения эффективности. Ресурсами могут быть прямые затраты, трудочасы персонала, использование вычислительных мощностей (процессорное время / сети и каналы передачи данных / объёмы хранимых данных на СХД).
Что мы видим? Очевидно, что программные продукты не появляются волшебным образом из ниоткуда. Модель жизненного цикла продукта не учитывает ту деятельность, что необходима для появления и вывода продукта на рынок. На рисунке ниже поэтому добавлен раздел под названием «Создание». Эта часть жизненного цикла в большей степени соответствует проектному характеру деятельности от возникновения идеи до создания начального продукта.
Минимально жизнеспособный продукт
Чтобы продукт достиг порога жизнеспособности, мог быть выведен на рынок и представлен потребителям, нужно реализовать определённый объём возможностей, который стал бы восприниматься его потребителями как самостоятельная ценность. Разница в проектной и продуктовой моделях поставки программного обеспечения — реализация идеи минимально жизнеспособного продукта (minimum viable product, MVP).
Представьте, что вы строите дом. Чтобы дом воспринимался именно «домом», а не кучей разнообразных строительных материалов и элементов отделки, необходимо наличие нескольких важнейших конструкционных и бытовых элементов: фундамент, пол, стены, крыша, утепление, водопровод, электричество, газ, санузлы, окна, двери и кухня.
Как поступает строительная компания, зная, что она может продать возводимый ею дом с определённым минимальным набором характеристик? Устанавливается стандартная ванная в санузле, на пол кладётся дешёвое напольное покрытие, на кухне гарнитур устанавливается без посудомоечной машины, а гаражные ворота без автоматического доводчика.
Аналогия с проектом — это идея построить дом, определив наименьшее количество функций, которые нужны для проживания в доме, и построив его. После того, как дом с минимальным набором функций будет построен и сдан, он выйдет из «проектной» стадии и перейдет в «продуктовую» фазу.
Аналогия с продуктом — это дальнейшее определение и реализация функций, которые необходимы, чтобы сделать дом более комфортным и удобным для проживания в соответствии с нашими постоянно меняющимися потребностями.
А теперь давайте расширим подобный подход к программным продуктам в целом. Чтобы получить выгоду от программной платформы, нам нужен базовый набор функций, которые нужны нашему клиенту для приобретения и использования платформы. Этот минимальный набор функций и есть наш минимально жизнеспособный продукт. Когда новая платформа ещё только придумывается, то для её реализации собирается команда — это команда проекта. Её задачей становится создание и вывод на рынок начального продукта.
От проекта к продукту
Проекты превращаются в продукты в тот момент, когда команда формирует минимально жизнеспособный продукт. После того, как он будет выпущен на рынок, начнётся измерение предоставляемой ценности. А команда станет постепенно добавлять новые функции или дорабатывать имеющиеся, чтобы добавить дополнительную ценность для клиентов или снизить риски по мере улучшения продукта. Такой подход требует как итеративного мышления, так и связанного денежного потока для обеспечения возможностей команды к итерациям.
От появления идеи, через создание и рост ценности до её уменьшения и окончательного исчезновения — жизненный цикл программного продукта показывает, как на этапе проекта создаётся базовый уровень минимально жизнеспособного продукта, способного приносить ценность и окупать начальные инвестиции. А затем, следуя фазам классического жизненного цикла продукта, к появлению новой идеи и, соответственно, нового продукта. Такая цепочка и есть эволюция от проекта к продукту.
Особенности проектной и продуктовой моделей
В приведенной ниже таблице более подробно показаны особенности каждой из моделей.