ответвление в истории развития продукта это

Развитие продукта: о стратегии, цикле и концепции

Стратегия развития продукта необходима для защиты предприятия от потери прибыли. Как же выглядит концепция развития продукта, ее фазы и циклы можно узнать в статье ниже.

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

Более того, для бизнеса важно диверсифицировать риски спроса на определенный продукт, чтобы уменьшить влияние конкурентной борьбы в отдельной категории. Это является драйвером для маркетинга расширения ассортимента, включая модификации товара. На современном рынке для компаний становится критичным фактор временного периода подготовки продукта к его запуску. Во многих технологичных сферах уже становится нормой, когда потребителям предлагается минимальный востребованный функционал, который получает развитие в процессе пользования.

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

Как строится стратегия развития продукта?

Стратегия развития продукта является его нулевым этапом жизни. Еще ничего не существует, но уже закладывается его будущее. Создание стратегии состоит из трех важных этапов:

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

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

О цикле развития продукта

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

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

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

Как выглядит концепция развития продукта?

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

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

В целом, ключевые направления концепции развития продукта могут иметь следующие решения:

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

Цели и важность построения стратегии

Более половины попыток компаний по разработке новых продуктов оказываются неудачными при выводе товаров на рынок. Они оказываются невостребованными или не оправдывают возложенных на них ожиданий по объему продаж и получаемой прибыли. Чтобы снизить риск подобных неудач, нужна стратегия развития продуктов. В ее существовании есть ряд важных для бизнеса моментов.

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

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

Разработка стратегии развития продукта невольно заставляет задумываться о перспективах. Ведь продукт должен быть актуальным и востребованным на протяжении всего его жизненного цикла. Такая проработка ведет к более пристальному планированию концепции развития продукта, включая формирование перспективного ассортимента модификаций. Фактически стратегия мотивирует мыслить с опережением и в долгосрочной перспективе.

Источник

Сторителлинг в проектировании интерфейсов и культура развития продукта через истории — Глава 2

Истории — это важнейший инструмент для сплочения участников команды продуктового дизайна вокруг общего видения продукта.

Дизайнер интерфейсов. Практик дизайн-мышления. Публикует материалы об UX/UI-дизайне. Активно осваивает HCD (Human-centered design).

Фев 20 · 13 мин читать

(Перед вами бесплатный курс от InVision Studio «Продуктовый дизайн». В курсе 7 глав. Если вы здесь впервые, то лучше начните сначала)

С помощью историй вы можете не только сообщить нечто важное, но и обеспечить команде возможность прочувствовать всю полноту ситуации, которую испытывают клиенты.

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

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

— Стэнли Вуд, Дизайн-директор Spotify

Основные этапы работы прописаны в дорожной карте продукта. Они показывают нам, что создавать и когда. Истории помогают всегда помнить для чего мы это делаем.

Люди не покупают то что вы делаете, они покупают зачем вы это делаете. А то что вы делаете, лишь доказывает то, что вы в это верите.

— «Начни с почему», Саймон Синек

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

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

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

Продуктовые истории объединяют наши идеи с людьми на тех же принципах что и тысячи лет назад. Есть много способов рассказать историю продукта, но начинать всегда надо с планирования.

Планирование продуктовой истории

Продуктовые истории это результат упорных исследований, а не чьей-то гениальности. Интервью с клиентом подсказывает нам важные моменты наполненные разочарованием, стремлением или триумфом. Все эти моменты можно использовать как отправные точки для создания истории. Студия Pixar использует простую структуру повествования, чтобы передать нам суть своих историй.

Повествовательная структура от Pixar:
Эта история случилась…
Каждый день они…
Но, однажды…
Благодаря этому…
После этого…
Пока, наконец не…

По этой схеме можно не только составить сюжет продуктовой истории, но и показать её важность. Давайте посмотрим на примере Airbnb.

Эта история случилась в Эшвилле, штат Северная Каролина с супружеской парой артистов, которые жили в милом домике с гостевым коттеджем позади. Каждый день они покидали выходили из дома, чтобы заработать деньжат на выплату ипотеки. Однажды они неплохо подзаработали сдавая в аренду гостевой коттедж. Благодаря этому они смогли быстрее выплатить ипотеку и немножко отложили на пенсию. После этого они меньше работали и больше времени проводили вместе. Пока наконец не вышли на пенсию и зажили так, как хотели.

История продукта это наука не про интерфейс, а про: кто и в каком контексте будет использовать ваш продукт. История продукта отвечает на высокоуровневый вопрос: как наш продукт впишется в жизнь человеков? А интерфейсы живут в мире прототипов и визуальных дизайнерских решений.

Чтобы ответить на этот вопрос, задействуем следующие принципы:

Человечество мыслит образами. Перед тем как что-то понять, мы хотим это увидеть. Чтобы объяснить людям абстрактную идею продукта — покажите им образ который станет для них полярной звездой.

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

— Джеймс Бакхаус, Sequoia Capital

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

Связь между сторителлингом и дизайном означает, что вам нужно создать историю для людей которая поможет им понять, какое влияние [продукт] окажет на них.

— Кевин Ченг, Incredible Labs

Сюжетные карты: создаем продуктовую историю

История продукта может принять разную форму визуализации: карта путешествия, storyboard, видео и даже комиксы. Добавьте в историю небольшой развлекательный элемент и она станет интереснее и пользователям, и команде, и клиентам.

Создание карт пользовательских путешествий (journey maps)

Донна Личоу в своей книге «The User’s Journey» отмечает, что истории, как правило, развиваются по проверенной схеме. Мы знакомимся с персонажами, их целями и особенностями повествования истории. Вспыхивающий конфликт перерастает в кульминационное событие, после чего персонажи находят красивое решение своих проблем. Очень похоже на структуру от Pixar с которой мы познакомились выше.

Рисунок 1. Общая структура историй, из книги Донна Личоу «The User’s Journey».

Пользуясь подобной структурой мы создадим карту пользовательского маршрута. Она нужна чтобы исследовать бесчисленные способы взаимодействия пользователя с нашим продуктом или услугой. Карта показывает как это работает во времени и по разным каналам.

Рисунок 2. Донна Личоу использует сюжетную арку, чтобы изобразить маршрут пользователя, который открывает для себя Slack и начинает им пользоваться.

Карту пользовательского маршрута можно отображать разными способами, лучший из которых — простой скетч. Скетч как в книге «The User’s Journey» можно сделать быстро и он намного интереснее чем официальные документы.

Быстрые советы по построению карты пользовательского пути:

Вся команда рисует комиксы, не только я.

— Кевин Ченг, Incredible Labs

Сториборд (Storyboard) в продуктовом дизайне

Сториборд — это иллюстрации с короткими описаниями которые вовлекают в ключевые моменты истории. Этот инструмент часто используется для проработки концепции повествования на студиях анимации и кино. Первое применение сторибордов заметили в студии Уолта Диснея для постановки «Трех поросят» в 1933 году.

Рис. 3. Уолт Дисней с командой изучают сториборды для прорывной ленты «Белоснежка и семь гномов».

Так уж получилось, что сториборд удачно вписался в процесс разработки продукта. Нейт Блечарчик, соучредитель и технический директор Airbnb признался, что создание сторибордов стало «зажигательным событием для компании». Брайан Чески, генеральный директор Airbnb был вдохновлен тем, как Disney Studios построила повествование используя сториборд. Это позволило им сделать большой шаг и от коротких мультиков перейти к созданию первого полнометражного фильма «Белоснежка и семь гномов».

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

Нам удалось вовлечь в команду художника по сторибордам из Pixar, чтобы он помог воплотить опыт использования Airbnb во всей полноте.

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

Визуализация опыта как бы помещает вас и вашу команду на сцену, помогает испытать сочувствие по отношению к пользователям и разработать стратегию развития дальнейших дизайнерских решений. Работа над сторибордом помогла команде Airbnb сплотиться вокруг общего дела и разработать продукты, которые предоставляют их клиентам лучший в мире сервис.

Для создания объемной истории вам совершенно не обязательно нанимать иллюстраторов уровня Pixar и рисовать детальный сториборд как у Airbnb.

Советы по созданию сториборда (Storyboard) для дизайна продукта:

История продукта в формате видео

Если вы работаете над важным проектом и время вас не торопит, попробуйте создать видео-историю продукта. Такой подход поможет команде погрузиться в опыт клиентов.

Видео обладает способностью переносить нас в новые места и ощущать себя частью истории. Видео обладает эффектом погружения и формирует у нас долгосрочные воспоминания. Такой подход помогает сподвигать людей на общее дело.

Отснятым видео легко поделиться. Залейтие видео на Vimeo, скопируйте его адрес, и используйте в e-mail или Slack, чтобы все желающие могли смотреть и сохранять ссылку.

Одним из недостатков создания видео-истории являются временные затраты. Всё-таки надо создать сценарий, собрать актёров и возможно, арендовать какое-то видеооборудование.

Однажды в MailChimp я готовил свою UX команду к большому редизайну приложения. Мы приготовили видеогайд по нашей концепции для 4-х месячного проекта. Во время наблюдений за клиентами исследовательская группа заметила, что все люди работают по-разному. Сотрудники работавшие через интернет на планшетах и телефонах делали это где угодно и когда угодно, но все они старались уклониться от выполнения маленьких задач. Появлялось ощущение, что отовсюду вырастают новые задачи. Людям перегруженным работой приходилось перекидывать её своим коллегам. Внимательно изучив эти поведенческие модели мы поняли что нам надо переосмыслить то, как MailChimp организует совместную работу на нескольких устройствах.

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

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

Советы по созданию видео:

Ответвления от истории продукта

Хорошо проработанный персонаж любую историю сделает красочнее. С помощью персонажей и Job stories мы можем преобразовать данные о клиентах в образы живых людей, для которых мы работаем. Это поможет нам повлиять на их поведенческие мотивы.

Персона (персонаж) пользователя

В чем суть метода персонажей? Персонажи — это архетипы собравшие в себя определенные сегменты пользователей. В отличии от абстрактных данных персонаж имеет имя и лицо. Он умеет вызывать сочувствие и помогает проектировать продукт.

Неважно в каком формате существует персонаж, хоть карманный хоть во всю стену, главное чтобы он был заметным. В MailChimp ребята из UX команды разработали серию рекламных плакатов для продвижения своего продукта. Изображения людей пользующихся их продуктом выглядывали из-за каждой кофемашины и даже в столовой не давали людям забыть о пользователях.

Рис. 3. Плакаты с персонами MailChimp помогают каждому в продуктовой команде чувствовать связь с клиентами.

Cоветы по созданию персонажей:

Job stories

Job stories пришли из концепции Jobs-to-Be-Done. Эту концепцию создал Клейтон Кристенсен, профессор Гарвардской школы бизнеса и автор известной книги «Дилемма инноватора». В основе теории Jobs-to-Be-Done лежит простая мысль — мы не покупаем продукты, а нанимаем их для выполнения определенной работы. Анализируя работу для которой нанимается продукт, можно лучше понять мотивацию пользователей.

Job stories основаны на интервью с клиентами, в которых используется специальная техника, которая возвращает клиента к моменту покупки с целью выявить ситуации (situations) и мотивы (motivations), которые привели к этому решению.

Job stories можно добыть только из интервью с клиентами. Обязательно пообщайтесь с реальными пользователями перед тем, как приступить к разработке новой функции или продукта. Вы откроете для себя все их страхи а также ситуации в которых может пригодиться ваш продукт (или продукт конкурента).

— Алан Клемент, Продуктовый дизайнер

Не путайте Job stories и персонажей — они про разное. Персонаж описывает определенный сегмент клиентов с общим набором характеристик, навыков и взглядов. Job stories показывают мотивацию клиента в определенном контексте.

Job stories представляет собой простую схему:

Совет от профессионала: Структура Job stories:

Когда ___________ я хочу ___________, так я смогу ___________.

Элементы истории по JTBD

Каждый раздел Job stories раскрывает определенную информацию:

Например:

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

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

Cоветы по созданию вашей Job stories:

Мы можем начинать с истории. во всем, что мы хотим создать.

— Liz Danzico, SVA MFA Interaction Design

Как вписаться в жизнь других

История вашего продукта важна и не имеет значения каким именно способом вы будете её рассказывать. Вам будет легче вовлечь команду в работу и сформировать нужное отношение к продукту, если перед стартом работ у вас будет история. Откажитесь от мышления на уровне “делать” и подумайте о том как ваш продукт впишется в жизнь других людей.

Очень важно каждый проект проработать до мельчайших деталей. Но только после того, как вы ясно увидите перед собой вашу собственную Полярную звезду, вы сможете заглянуть в будущее, которое можете создать. Первым делом — история (Story First) — простой принцип, который поможет вам и вашей команде браться сообща за большие идеи.

Источник

Записки отставного сиэмщика

Заметки о Software Configuration Management. Управление конфигурацией программного обеспечения.

2009-09-06

SCM // 2. Конфигурации и baselines

Продолжаем серию заметок про SCM. Сегодня речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.

Рабочие продукты и конфигурации

Что же будет являться рабочими продуктами в рамках проекта? Понятно, что для маркетинга и менеджмента продукт будет ровно один – тот, за который компания получит деньги. Ну, или несколько, по числу видов коробок, выдаваемых на рынок. Нас же интересует «нижний уровень» – то, чем будут оперировать постановщики задач, разработчики, тестеры и вообще каждый участник проекта. Задача CM – определить множество тех элементов, которые будут создаваться и изменяться командой. На этом этапе появляется понятие «configuration item» («элемент конфигурации») – это атомарный элемент, которым наиболее удобно управлять в рамках разработки. В дальнейшем будем называть его просто «CI».

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

Компонентная разработка и продуктовые линейки

Как же эти элементы конфигурации, атомарные единицы учета, организуются внутри проекта?

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

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

Итак, создаем систему, строим её из кирпичиков-компонентов. И нередка ситуация, когда одна система поставляется сразу в нескольких вариантах. За примерами далеко ходить не надо, взгляните на варианты поставки «Висты». И зачастую всё отличие разных вариантов/версий/редакций продуктов – всего в одном или нескольких компонентах, а то и вовсе в настройках. Как быть? Для этого создается то, что для простоты дальнейшего изложения будем называть продуктовыми линейками. Продуктовая линейка – это ответвление в истории развития продукта, дающее возможность изменять часть компонент независимо от других подобных ответвлений. (Здесь понятие «продукт» употребляется с маркетинговой точки зрения.)

Всё по теории эволюции – одноклеточное остается одноклеточным, но в результате мутаций и цепи случайностей (или же по злому умыслу) дает жизнь многоклеточным. Была линейка человекообразных приматов – от неё отделилась линейка homo sapience, но начальная порода обезьян продолжила жить своей жизнью. «Компоненты» у каждой «линейки» – почти на 99% совпадают. И только несколько процентов (мозги и ещё кое-что по мелочи) разрабатываются эволюцией независимо от родительской линейки и отличают одни виды от других.

На схеме 1 образно показан компонентный состав продукта. 1-8 — это компоненты, 4 — это «суперкомпонент», включающий в себя компоненты 5 и 6. В рамках интеграции продукта работа с ним ведется, как с обычным компонентом.

На схеме 2 показано, как одни и те же компоненты могут быть использованы при работе с продуктовыми линейками. Например, имеется Продукт 1, состоящий из нескольких компонентов и суперкомпонента. На его основе производятся продукты 2 и 3.

Продукт 2 берет все те же компоненты, за исключением 1 и 6 — они исключаются из работы (или игнорированием соответствующих директорий, или выключением директив компиляции). В дополнение, изменяется компонент 3 — он становится 3′ (штрих не проглядите). Также в единственный суперкомпонент добавляется новый компонент за номером 9.

Продукт 3 также берет за основу кодовую базу Продукта 1, однако берет в себя ещё и изменения из Продукта 2 — компоненты 9 и 3′. Также изменениям подвергаются компоненты 7 и 8, которые теперь называются 7′ и 8′ соответственно (да, тоже со штрихами).

Что в итоге? В итоге имеем несколько компонентов, интегрируемых одновременно в два-три разных продукта. Возьмем, к примеру, номер 2 – он неизменен во всех трёх продуктах. Напрашивается вывод – выпустить его один раз и просто «вставить» везде, где потребуют. Так и делается – компонентная команда в лице CM-инженера стабилизирует работу и передает на дальнейшую интеграцию трём «продуктовым» командам. Аналогично поступает CM-команда компонента 3’ – после внесения изменений поверх «предка» 3, полученный релиз компонента 3’ отдается в два продукта.

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

В технической плоскости CM является связующим звеном между компонентами и линейками. В управленческой плоскости, где принимаются архитектурные решения, рулят менеджеры, тим-лиды, архитекторы, а всю техническую поддержку этого разделения возлагают на CM-инженеров. Именно они дают конечным разработчикам инструкции («политики») о том, в какие системы контроля складывать свой код, как именно его туда складывать, как регистрировать изменения в системах багтрекинга, каков порядок объединения компонент, что в каком виде давать тестерам и как выпускать продукт заказчику. Сами же продукты становятся новыми элементами конфигурации.

Основной вывод: CM помогает определить, из каких кирпичей мы будем складывать продукт и дает цементный раствор для их скрепления. Какими методами определяет и скрепляет – рассмотрим дальше.

Стабилизация результатов работы

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

С точки зрения CM’а это означает, что надо стабилизировать конфигурацию рабочих продуктов. Например, имея команду из 20 человек, нужно взять все наработанные разными людьми куски функциональности – документы, код и друге результаты – и свести их воедино.

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

Например, есть основная конфигурация – версия продукта 1.0. Есть промежуточная конфигурация – разработанная девелопером новая «фича». Есть также 2 другие конфигурации – поправленные ошибки от двух других разработчиков. Стабилизацией в данном случае будет объединение результатов работы всех трех разработчиков и создание из них новой конфигурации, т.е. набора CI, которые образуют готовый продукт.

Полученная конфигурация проверяется на соответствие требованиям к составляющим её рабочим продуктам. Требования могут быть разнообразными, как правило, это количественные критерии качества. Скажем, в приведенном примере с 3 девелоперами, подобное требование к коду – это успешное прохождение 98% регрессионных тестов. Код от всех разработчиков интегрируется, конфигурация стабилизируется, продукт собирается (например, отстраивается) и отдается на тесты.

Для релиза также делаются release notes. На русский этот термин переводится как «заметки о выпуске» или «дополнительные сведения» – так этот термин звучит в глоссарии Microsoft. Также может быть использовано «описание выпуска».

Если конфигурация соответствует требованиям, предъявляемым к стабильным релизам, то конфигурация считается стабильной. Например, если процент пройденных регрессионных тестов – 98%. По выбору менеджмента или CM-инженера, она становится тем, что называется «baseline».

Базовая конфигурация

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

Если вернуться обратно к нашему примеру про трёх разработчиков, то там стабилизированная конфигурация прошла оценку качества. То же самое обязательно и при выпуске базовой конфигурации. Менеджмент (тим-лид или SQA) смотрит на показатели качества, а также на другие факторы – например, на результаты инспекций кода или что-то ещё, что может вызвать сомнения. После чего принимает решение о том, что релиз должен быть взят за основу для работы всех остальных разработчиков, быть базой для разработки. Далее CM-инженер выполняет разного рода действия (например, навешивает метку и отстраивает код продукта) и выбранная конфигурация становится базовой. При этом она (как минимум, в виде исходников) выкладывается в открытый для всей команды доступ.

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

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

Во многих командах результаты интеграционной работы (появляющиеся релизы и базовые конфигурации) выкладываются в специально отведенное место – область релизов, или release area. Организация этой области и поддержание её в актуальном виде – задача CM-инженеров.

На Схеме 3 показан небольшой пример появления конфигураций во времени. Начальное состояние проекта – конфигурация 1. Она же является первым базисом, от которого будет идти дальнейшая разработка. Предположим, проект на начальной стадии. Через какое-то время появляется обновленная конфигурация 2. Разработка только началась и мы выпустили релиз, чтобы выдать команде хоть какую-то основу для дальнейшей работы. В ходе проверки выяснилось, что базой для работы этот выпуск служить не может – есть непонятные и противоречивые места.

Для их устранения группы разработки делают доработки. В результате них появляются конфигурации 3 и 4 – оба они разработаны на основе 2, но друг с другом они пока не согласуются, поскольку не включают изменения друг от друга. CM-инженер создает итоговую конфигурацию 5, сделанную на основе 2, 3 и 4. После проверки менеджмент дает отмашку – базовой конфигурации быть! По этому сигналу CM-команда выпускает этот релиз как официальную базовую конфигурацию и разработчики берут уже её за основу.

Далее история повторяется – группа разработки вносит изменения – появляется конфигурация 6. Её, в свою очередь, интегрирует CM-инженер и она получает номер 7. Он также становится официальной базой для разработки.

Конфигурации при компонентной разработке

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

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

В частности, после интеграции всей системы нужно не просто пройти регрессионное тестирование каждого входящего компонента. Надо ещё прогнать системные тесты, проверяющие взаимодействие разных частей системы между собой – как правило, это не входит в область тестирования каждой отдельной подсистемы. Кроме того, от CM’ной команды всего продукта может потребоваться сбор дополнительных метрик. Всё это требует больших ресурсов и некоторой доработки политик CM-команды вышестоящего компонента.

Конфигурации продуктовых линеек

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

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

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

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

Отсюда следуют две возможные линии поведения компонентных команд:
1. Выпуск стольких линеек компонентов, сколько продуктов сейчас находится в работе и сопровождении. Накладный вариант с точки зрения отслеживания изменений и конфигураций, а также сложно с точки зрения интеграции одних и тех же изменений в разные компонентные линейки.
2. Поддержка всех продуктов и их наборов функциональности одновременно в одной линейке компонента. При этом надо организовать код таким образом, чтобы можно было гибко «включать» и «выключать» функциональность через настройки во время «отстройки» системы или во время её инсталляции и запуска в эксплуатацию. Также появляются накладные расходы для разработчиков, которые, ожидая каждого вносимого изменения, вынуждены учитывать, как это изменение повлияет на работу каждой из фич, затронутых измененным кодом.

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

Источник