Тонкощі релізу: Як майстерно розробляти продукт завдяки вдалій стратегії релізів?

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

Інкрементально-ітераційний підхід не працює без інкременту. В галузі інформаційних технологій (особливо в контексті Scrum) розробка продукту якраз вимагає створення інкременту, що передбачає його регулярні релізи — оприлюднення і демонстрацію нового функціоналу, розробленого за відповідний ітераційний період, нарешті — його фінальної версії, яку побачить світ.

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

Чимало фахівців зізнаються, що реліз у їхній ситуації — слабка ланка.

На мою думку, проблема полягає не стільки в нерозумінні розробниками ролі й місця релізу в ітераційно-інкрементальному підході, скільки у відсутності стратегії релізів. Під стратегією я маю на увазі осмислені, свідомі дії, скеровані на те, щоб забезпечити регулярні релізи продукту, всупереч спокусі занурюватися з головою в процесно-операційну діяльність.

Запорукою успішних релізів є а) усвідомлення продуктової мети і б) команда, здатна її досягати.

Так чи інакше, відсутність стратегії релізів — справді одна з найпроблемніших нині сфер у розробці продукту.

Проблема

Виявити міну сповільненої дії в розробці цифрового продукту зовсім нескладно.

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

Саме з цієї причини до релізу функціональної частини продукту природним чином “не доходять руки”!
Вочевидь, більшість програмістів не мислить категоріями презентацій, демонстрацій, “випусків продукту” чи комунікацією з кінцевим споживачем. Розробники навряд перейматимуться адміністративними питаннями щодо організації релізу — в який день, о котрій годині, у присутності яких осіб чи за яких обставин. Тестувальники, дизайнери й програмісти не вчилися на те, щоб організовувати заходи, присвячені релізам.

Проте відсутність стратегії релізів — бумеранг. Питання часу, коли він дасть про себе знати.

Провальний реліз Ілона Маска

Згадаймо випадок із Ілоном Маском, який поспішив здивувати світ наступною цікавинкою (нею мав стати електропікап Tesla Cybertruck).

Біля ракетного заводу Space X в Лос-Анджелесі відбулася презентація диво-автомобіля. Ідейний натхненник і засновник компанії Tesla неабияк хизувався його футуристичним дизайном, а особливо кузовом, виготовленим із тієї ж сталі, що й космічний корабель SpaceX Starship! Ілон навіть назвав її “прозорим металом”. Хто б сумнівався — вона витримає удар довбні!

Після випробування довбнею асистент Ілона Маска жбурнув у скло чималий сталевий підшипник і воно розбилося на очах зачарованої публіки. Жбурляти другий підшипник було зовсім не обов’язково, але настирливий помічник сумлінно виконав свій обов’язок — влучив у друге вікно. Тепер Cybertruck мав дві тріщини. Якби асистентові подали третю кульку — він безперечно влучив би у третє вікно! Ініціативу перехопив засновник компанії Tesla.

Ілон спробував викрутитися, знайти в розбитому електрокарі якийсь позитив, у той час як маркетологи заспокоювали його в тому, що випадок, мовляв, привернув увагу публіки. Хай би як майстерно прикривався фіговим листям великий мрійник, реліз було провалено.

Щось схоже відбувається і у сфері розробки програмних продуктів. Щоправда, релізи в ІТ не привертають стільки уваги й не мають стільки пафосу, як у виробників електрокарів. Можливо, ми просто не навчилися здіймати шум навколо інкрементів.

Висновок очевидний і простий: до релізу потрібно добре і заздалегідь готуватися.

Різновиди релізів

Існує розмаїття релізів:

• Великі/невеликі;
• Тестові релізи;
• Пілотні релізи;
• А/Б тестування;
• Масштабні;
• Проміжні релізи;
• Офіційні;
• Релізи за етапами/рівнями та ін.

Розгляньмо їх докладніше.

Великими чи невеликими можемо називати релізи з точки зору складності інкременту: ідеться про демонстрацію складного чи простого функціоналу?

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

Пілотні релізи. Реліз уже не на тестовому стенді, а в середовищі реальної продуктової інфраструктури. Інкремент демонструють невеликій групі користувачів — від п’яти до семи осіб.

А/Б тестування. Це важливий різновид релізу, актуальний за необхідності порівняти нову і стару версії продукту. Аудиторія ділиться навпіл, одна дає зворотний зв’язок щодо старої версії, друга — щодо нової. Мета — вчасно зібрати цінні відомості для наступної ітерації, удосконалень, оптимізації або інших цілей.

Запитання, що ставлять у процесі А/Б тестування, можуть бути такими: “Чи справді нова версія краща, ніж стара?” “Які нові відомості можемо зібрати для вдосконалення чи покращення нової версії?” “Який чином можемо оптимізувати нову версію (прибрати зайві або неважливі для користувача функції тощо)”?

Масштабний реліз — для великої аудиторії.

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

Офіційні — передбачають присутність офіційних осіб;

Інші релізи — за етапами/рівнями тощо.

Хто відповідає за стратегію релізів

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

В сучасному скрамі за розробку стратегії релізів відповідає вся команда.

Вирішальну роль у цьому питанні відіграє скрам-майстер. Він не прийматиме кінцевого рішення, бо це прерогатива керівництва й команди. Проте він зробить усе для майстерної презентації релізів — забезпечить необхідну комунікацію між різними учасниками розробки, побудує “місточки порозуміння” (усуне непорозуміння, сприятиме досягненню консенсусу), створить умови для чесного вираження сумнівів, а також збагатить дискусію власним досвідом чи фаховими знаннями.

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

Також скрам-майстер має вжити заходів, щоб не допустити перекладання цієї функції на плечі однієї персони (зазвичай власника продукту або новостворених ролей на зразок “реліз-менеджера”).

Отже, за організацію релізів відповідає вся скрам-команда.

Приклади

Реєстр публічних осіб

Наведу приклад вдалого релізу. Нещодавно в Україні створено платформу реєстру національних публічних діячів (https://dataocean.us) — єдину базу даних публічних осіб.

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

На публічній презентації релізу DataOcean стейкхолдери запитали: “Чи може система здійснювати пошук за ідентифікаційним кодом?” Власник продукту відповів: “На разі ні, бо чинне законодавство не дозволяє. Але є інші шляхи для ідентифікації особи, тому в наступних релізах ми продемонструємо нову функціональність, додаткові критерії визначення особи. Зараз ми зібралися для того, щоб показати вам дві особливості продукту: пошук за деклараціями та аналіз суспільних зв’язків публічної особи”.

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

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

Як відомо, в усьому світі державні інституції мають доволі складну систему отримання даних, у багатьох випадках надто забюрократизовану.

Це створює незручності не тільки для пересічних громадян, а велику проблему для бізнесу, особливо у фінансовій сфері.

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

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

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

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

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

Якби плануванням релізів займалася одна особа (наприклад, власник продукту), годі було б розраховувати на щось путнє. Тільки командна взаємодія допомогла всім учасникам постійно пам’ятати про мету продукту й системно проводити релізи, завдяки чому було вчасно усунено зайве й додано справді корисне. Кінцевий продукт вийшов напрочуд успішним.

Як бачимо, реліз цифрових продуктів суттєво відрізняється від релізів автомобіля Ілона Маска. Розробка в галузі інформаційних технологій зазвичай передбачає розмаїття компонентів. Всі вони мають бути взаємоінтегрованими та пройти належне тестування, перш ніж говорити про демонстрацію стейкхолдерам. (У складних продуктах кожен компонент може взагалі може бути окремою платформою, що обслуговує окрему категорію користувачів!).

Рекомендації

Для того, щоб розробити успішну стратегію релізу продукту, необхідно:

1. Добре розуміти, що саме хоче бізнес.
2. Разом із командою вирішити, як саме адаптувати роботу, щоб врахувати потреби, вимоги й очікування з боку бізнесу.
3. Перший реліз варто зробити у невеликій пілотній групі (2-3 учасників). (Передчасна демонстрація ширшому колу осіб містить надто високі й навіть непередбачувані ризики).
   Наприклад, світовому виробнику автомобілів Volkswagen AG довелося відкликати з ринку США близько 500 тисяч автомобілів через певні дефекти, пов’язані в негативним впливом на екологію. Поспішили випустити “в термін”, з “виконанням технічного завдання в повному обсязі”, але не надали значення регулярному тестуванню й попереднім релізам з відповідними висновками. Фольцваген міг таке дозволити, та для більшості ІТ недбалість у тестуванні й попередніх релізах означали би самознищення компанії.
   Другий реліз можна презентувати більш широму колу (до 20 осіб).
4. Залучайте до планування релізів різних учасників команди, кого він може прямо стосуватися: ключові розробники, тестувальники, власники продукту, аналітики, фахівці з інформаційної безпеки, інші. При цьому не забувайте про мету командоутворення — синергія між усіма її учасниками задля кращої реалізації продуктової мети.
5. Планування. Щотижня виділяйте по одній годині на планування стратегії релізів, яка постійно переглядається і адаптовується. Щотижня з’являються нові результати, нові знання, нові ризики, нові можливості оптимізації та покращень. За тиждень стається чимало подій, що може вплинути певним чином на стратегію релізів. Це важливо враховувати і обговорювати на плануванні релізів.
6. Етапи. Врахуйте етапи планування.
   І рівень планування. Стосується інфраструктури, адекватної для першого рівня інтеграційного тестування. Головна мета — переконатися, що система працює коректно. Тут можемо тестувати її швидко.
   ІІ рівень. Тут ми заглиблюємося, і це дорого коштує. Тестування охоплює різні рівні. Нам потрібно переконатися, що система витримує навантаження. Інтеграція працює злагоджено і надійно.
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
• Підписатися на You-канал Agile.Live