Тонкости релиза: Как искусно разрабатывать продукт благодаря удачной стратегии релизов?

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

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

В официальном руководстве Scrum Guide сказано о фундаментальных принципах, философии, подходе, однако вы не найдете там инструкций или детализированных методик по самой разработке. Поэтому специалисты и компании обращаются к нам в Agile.Live за помощью, часто, чтобы спасать лодку, которая тонет, залатать на ходу дыры, или просто выяснить, что идет не так.

Многие специалисты признаются, что релиз в их ситуации – слабое звено.

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

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

Так или иначе, отсутствие стратегии релизов – действительно одна из самых проблемных ныне сфер в разработке продукта.

ПРОБЛЕМА

Определить мину замедленного действия в разработке цифрового продукта совсем несложно.

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

Именно по этой причине к релизу функциональной части продукта естественным образом “не доходят руки”!

Очевидно, большинство программистов не мыслит категориями презентаций, демонстраций, “выпусков продукта” или коммуникацией с конечным потребителем. Разработчики вряд заняты административными вопросами по организации релиза – в какой день, в котором часу, в присутствии каких или при каких обстоятельствах. Тестировщики, дизайнеры и программисты не учились на то, чтобы организовывать мероприятия, посвященные релизам.

Однако отсутствие стратегии релизов – бумеранг. Вопрос времени, когда он даст о себе знать.

Провальный релиз Илона Маска

Вспомним случай с Илоном Маском, который поспешил удивить мир следующей изюминкой (ею должен был стать электропикап Tesla Cybertruck).

Возле ракетного завода Space X в Лос-Анджелесе состоялась презентация чудо-автомобиля. Идейный вдохновитель и основатель компании Tesla изрядно красовался его футуристическим дизайном, особенно кузовом, изготовленным из той же стали, что и космический корабль SpaceX Starship! Илон даже назвал ее “прозрачным металлом”. Кто бы сомневался – она ​​выдержит удар молота!

После испытания молотом ассистент Илона Маска швырнул в стекло большой стальной подшипник, и оно разбилось на глазах очарованной публики. Швырять второй подшипник было совсем не обязательно, но назойливый помощник добросовестно выполнил свой долг – попал во второе окно. Теперь Cybertruck имел две трещины. Если бы ассистенту подали третью шарик – он определенно попал бы в третье окно! Инициативу перехватил основатель компании Tesla.

Илон попытался выкрутиться, найти в разбитом электрокаре какой-то позитив, в то время как маркетологи успокаивали его в том, что случай, мол, привлек внимание публики. Как бы искусно прикрывался фиговым листьями большой мечтатель, релиз был провален.

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

Вывод очевиден и прост: к релизу нужно хорошо и заранее готовиться.

Разновидности релизов

Существует разнообразие релизов:

• Большие / небольшие;
• Тестовые релизы;
• Пилотные релизы;
• А / Б тестирования;
• масштабные;
• Промежуточные релизы;
• Официальные;
• Релизы по этапам / уровнями и др.

Рассмотрим их подробнее.

Большими или небольшими можем называть релизы с точки зрения сложности инкремента: речь идет о демонстрации сложного или простого функционала?

Тестовые релизы. Здесь презентация релиза проходит в узком кругу самых тестировщиков. Такой релиз находится на тестовом стенде, который, кстати, можно максимально адаптировать к производственным реалиям.

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

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

Вопросы, которые задают в процессе А / Б тестирования, могут быть такими: “Действительно новая версия лучше, чем старая?” “Какие новые сведения можем собрать для совершенствования или улучшения новой версии?” “Какой образом можем оптимизировать новую версию (убрать лишние или неважные пользовательские функции и т.п.)”?

Масштабный релиз – для большой аудитории.

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

Официальные – предусматривают присутствие официальных лиц;

Другие релизы – по этапам / уровнями и тому подобное.

Кто отвечает за стратегию релизов

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

В современном Скраме за разработку стратегии релизов отвечает вся команда.

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

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

Также скрам-мастер должен принять меры, чтобы не допустить перекладывания этой функции на плечи одной персоны (обычно владельца продукта или новосозданных ролей вроде «релиз-менеджера»).

Итак, за организацию релизов отвечает вся скрам-команда.

Примеры

Реестр публичных лиц

Приведу пример удачного релиза. Недавно в Украине создана платформа реестра национальных общественных деятелей (https://dataocean.us) – единую базу данных публичных лиц.

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

На публичной презентации релиза DataOcean стейкхолдеры спросили: “Может система осуществлять поиск по идентификационному коду?” Владелец продукта ответил: “На данный момент нет, потому что действующее законодательство не позволяет. Но есть другие пути для идентификации личности, поэтому в следующих релизах мы продемонстрируем новую функциональность, дополнительные критерии определения лица. Сейчас мы собрались для того, чтобы показать вам две особенности продукта: поиск по декларациям и анализ общественных связей публичного лица”.

Несомненно, разработчики DataOcean имели четкую стратегию релизов.

Автоматизация обработки данных в банке

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

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

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

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

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

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

Разработкой различных компонентов одновременно занимались разные команды. От этого процесс создания продукта не становился проще. Как в таком случае планировать релиз?

Если бы планированием релизов занималось одно лицо (например, владелец продукта), не стоило бы рассчитывать на что-то стоящее. Только командное взаимодействие помогло всем участникам постоянно помнить о цели продукта и системно проводить релизы, благодаря чему вовремя устранялось лишнее и добавлялось действительно полезное. Конечный продукт получился удивительно успешным.

Как видим, релиз цифровых продуктов существенно отличается от релизов автомобиля Илона Маска. Разработка в области информационных технологий обычно предполагает многообразие компонентов. Все они должны быть взаимоинтегрованными и пройти надлежащее тестирование, прежде чем говорить о демонстрации стейкхолдерам. (В сложных продуктах каждый компонент может быть отдельной платформой, обслуживающей отдельную категорию пользователей!).

РЕКОМЕНДАЦИИ

Для того чтобы разработать успешную стратегию релиза продукта, необходимо:

1. Хорошо понимать, чего именно хочет бизнес.
2. Вместе с командой решить, как адаптировать работу, чтобы учесть потребности, требования и ожидания со стороны бизнеса.
3. Первый релиз стоит сделать в небольшой пилотной группе (2-3 участникп). (Преждевременная демонстрация широкому кругу лиц содержит слишком высокие и даже непредсказуемые риски).
   Например, мировому производителю автомобилей Volkswagen AG пришлось отозвать с рынка США около 500 000 автомобилей через определенные дефекты, связанные в негативным влиянием на экологию. Поспешили выпустить “в срок”, с “выполнением технического задания в полном объеме”, но не придали значения регулярному тестированию и предыдущим релизам с соответствующими выводами. Фольцваген мог такое позволить, но для большинства IT небрежность в тестировании и предыдущих релизах означали бы самоуничтожения компании.
   Второй релиз можно представить более широкому кругу (до 20 человек).
4. Привлекайте к планированию релизов различных участников команды, кого он может прямо касаться: ключевые разработчики, тестировщики, владельцы продукта, аналитики, специалисты по информационной безопасности, другие. При этом не забывайте о цели командообразование – синергия между всеми ее участниками для лучшей реализации продуктовой цели.
5. Планирование. Еженедельно выделяйте по одному часу на планирование стратегии релизов, которая постоянно пересматривается и адаптируется. Еженедельно появляются новые результаты, новые знания, новые риски, новые возможности оптимизации и улучшений. За неделю происходит немало событий, которые могут повлиять определенным образом на стратегию релизов. Это важно учитывать и обсуждать на планировании релизов.
6. Этапы. Учтите этапы планирования.
   I уровень планирования. Касается инфраструктуры, адекватной для первого уровня интеграционного тестирования. Главная цель – убедиться, что система работает корректно. Здесь можно ее тестировать быстро.
   II уровень. Здесь мы углубляемся, и это дорого стоит. Тестирование охватывает разные уровни. Нам нужно убедиться, что система выдерживает нагрузки. Интеграция работает слаженно и надежно.
7. Стоит также организовать “антипутанницу” – сделать все для того, чтобы не запутаться в разработке сложного продукта, включающего 20 компонентов, у каждого из которых разные версии, разные взаимодействия с другими продуктами и тому подобное. Чем дальше продолжается разработка, тем больше запутанных взаимосвязей. Чем ранее мы обнаруживаем и отслеживаем их, тем быстрее и качественнее будет создан инкремент, время тестировщиков будет оптимизировано и больше внимания уделено релизам и усовершенствованиям.

Замечу, что в этом контексте мои советы – не постулаты или требованием скрам-подхода. Я делюсь собственным опытом, его применением в реальных ситуациях и практическими рекомендациями, которые, надеюсь, будут для вас ценными.

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

Слава Москаленко, сооснователь Agile.Live

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Master (PSM), Advanced Scrum Master with PSM II Certification, Professional Agile Leadership Essentials (PAL-E)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live