Як ми волонтерили на проєкті «Дiя» та які висновки з цього зробили – кейс EPAM

У своїй статті Senior Business Analysis Manager в EPAM Роман Сахаров розповідає, як його команд працювала над додатком «Дія».

Мене звати Роман Сахаров, з EPAM я співпрацюю як Senior Business Analysis Manager/Delivery Manager. А ще я — один із лідерів команди волонтерів, яка брала участь у розробці мобільного застосунку Дія».

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

Комплектація команди

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

• 5 React Native front-end спеціалістів,
• 5 спеціалістів з back-end,
• 5 тестувальників,
• 3 бізнес-аналітика,
• 3 інженера з безпеки,
• 2 архітектори.

Моя власна роль — Project Manager/Scrum Master, тобто я відповідав за виконання завдань, дотримання термінів, комунікацію з командою Міністерства. Усього з боку EPAM у різний час було залучено близько 35 спеціалістів, які, окрім основних проектів, регулярно працювали над Дія.

Як поставили робочий процес

Для побудови робочого процесу обрали Scrum, як найбільш попурярну адаптацію Agile — останній практично не мав альтернатив, так як багато вимог з боку «замовника» формувалися в процесі розробки.

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

Інструментом для управлінням проектом стала Jira з плагіном Structure, який дозволив структурувати вимоги в рамках Jira та трохи полегшити життя бізнес-аналітикам.

Роботу допомогли налагодити щоденні онлайн Scrum-мітинги з учасниками команди EPAM (волонтери працювали одразу з кількох локацій), щоденні sync-up з представниками Мінцифри, в тому числі з Михайлом Федоровим, який був у курсі практично всіх дрібниць.

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

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

(Не)очікувані складнощі

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

Тривалі Scrum-мітинги (стендапи). Оскільки спеціалісти долучалися до проекту на волонтерських засадах, це викликало певні складнощі у побудові ефективної комунікації. Постійно потрібно було вводити новачків або тих, хто на певний час вибув, у контекст та деталі
проекту. Це призводило до того, що іноді стендапи могли тривати до 60 хвилин. Та згодом ситуація стабілізувалася: у нас утворився сталий кістяк команди, який володів контекстом та час від часу проводив точкові брифінги для нових колег.

«Плаваюча» продуктивність. Інший виклик, який є наслідком нестабільного складу команди — «плаваюча» продуктивність. Це характерно для будь-якого волонтерського проекту. Волонтери можуть часто змінюватися з різних причин, а головним пріоритетом для них є основна робота, за яку вони отримують гроші.

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

Як цього можна уникнути? Практично ніяк, але можна спробувати мінімізувати вплив відтоку добровольців: вести регулярну комунікацію з поточними учасниками команди, аби розуміти
настрій.

Діючий рецепт: постійно шукати додатковий «резерв» волонтерів в процесі роботи над проектом. Окрім цього, рекомендую не нехтувати створенням якісної проектної документації: адекватно заповнена Jira та структуровані дані у ній (згадуємо плагін Structure),
наявність актуальних мокапів (наша команда використовувала Figma), детально прописані user story, acceptance-критерії.

Усе це допомогло нам створити основи для навігації нових членів команди проектом та заощадити час на занурення у розробку.

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

І так як над UI/UX працювала інша компанія, ми не могли робити зміни у ньому так само швидко, коли б, наприклад, самі відповідали за цей напрям.

Усе це не критично, але висновок такий — намагайтесь мати максимально готовий дизайн перед початком розробки та підтримуйте постійну комунікацію з дизайн-командою. Це значно
пришвидшить роботу.

Мінімальний вплив на контент, з яким працює додаток. Під час тестувань було виявлено проблему, на яку ми, на жаль, не маємо прямого впливу. Це — якість даних у реєстрах МВС. Переважна більшість «баг репортів» від бета-тестерів стосувалась неповної видачі інформації про документи: частіше за все, посвідчення не мало фотографію громадянина, тому його електронна форма вважался недійсною. Для повноцінної роботи додатку релевантними є записи, створені після 2013 року.

Ситуацію вдалося частково вирішити співпрацею з МВС, які допомогли з «підтягуванням» до е-посвідчення фото із закордонного біометричного паспорту. Для всіх інших ситуацій шлях
вирішення проблеми лише один: або верифікація даних, або ж візит до відповідних служб та органів для оновлення персональної інформації у реєстрі.

Надвимоги до тестування та швидкий вихід у продакшн. Реліз «Дія» був певним викликом для нас з кількох причин. На етапі релізу ми зіштовхнулися з обмеженнями у AppStore. За правилами майданчику, застосунок, перш ніж потрапити у публічний доступ, має бути перевірено фахівцями Apple. Але через особливості авторизації у «Дія» (через клієнти українських банків або BankID), отримати «ОК» від них було проблематично. Для вирішення питання ми скооперувалися з банками, послугами яких могли користуватися тестувальники AppStore.

Але найголовніша вимога: тут практично немає права на жодну помилку.

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

Ми впровадили кілька рівнів тестування різними групами користувачів: альфа-версія для учасників команди та близького кола осіб; бета-версія для перших ентузіастів, які не мали стосунку до додатку та могли надати різносторонній фідбек. Звичайно, застосунок пройшов кілька рівнів тестування на стійкість до навантажень, pentest.

Результати тестів на навантаження були очевидними, застосунок міг впоратися з навалою запитів, а ось для реєстру це було вже занадто. На щастя, команда МВС швидко відреагувала на цю проблему — потужності реєстру отримали нове «залізо».

Окремо слід згадати про залучення EPAM Security Competency Center в рамках якого відбувалося додаткове тестування застосунку на всі можливі «дірки» в безпеці — перевірка проходила за стандартами міжнародного рівня, якими користуємось ми та наші клієнти.

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

• Збираючу команду волонтерів, переконайтесь, що всі вони достатньо вмотивовані. Часто жага роботи, притаманна на старті, з часом згасає, і замість цінного члена команди ви отримаєте практично неефективного колегу. Згодом це може «аукнутись» суттєво зірваними дедлайнами.
• Перш ніж почати, складіть для своєї команди детальний план робіт. Продумайте усі ключові етапи від старту до останньго релізу, визначте чіткі ролі та зони відповідальності.
• Ви маєте чітко усвідомлювати кінцеву мету проекту — ті зміни, які реально впровадити у невеликі терміни та побачити чіткий результат.
• Не забувайте про заохочення. Волонтери можуть мати власну потужну мотивацію, але час від час її необхідно «підкріплювати». Для волонтерського проекту таким «підкріпленням» може стати визнання. Аби підтримати командний дух, ми час від часу проводили неформальні зустрічі, випускали матеріали про учасників команди на внутрішньому порталі ЕРАМ, за успіхи дарували один одному «бейджи-ачівки» в HR- системі. Це дрібниці, але такі заохочення є важливим для волонтерського проекту.

Що у результаті

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

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

Автор: Роман Сахаров, Senior Business Analysis Manager в EPAM