Що треба врахувати бізнес-аналітику при розробці і впровадженні нового продукту на заміну існуючого

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт, мене звати Вікторія і вже 4 роки я працюю Бізнес-аналітиком, 2 з яких — в компанії ApexTech.

Сьогодні хочу поділись своїми думками та напрацюваннями стосовно впровадження програмного забезпечення (далі — продукт) в залежності від вихідних умов проєкту.

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

Тож поговорімо детальніше, що треба врахувати й про що треба пам’ятати при впровадженні продуктів.

Почнемо з того, як взагалі розробляються різні застосунки на різне програмне забезпечення. Є такий термін як SDLC (Software development lifecycle) — це процес, який використовується IT- індустрією для проєктування, розробки й тестування програмного забезпечення. SDLC націлений на розробку продукту, який відповідає очікуванням клієнтів або перевершує їх, в найкоротші терміни завершує роботу й оцінює витрати.

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

Фази SDLC

1. Планування системи. Фаза планування — найважливіший, на мій погляд, і критичний етап у створенні успішного продукту. На цьому етапі вирішується, що саме потрібно зробити, які проблеми вирішити, які потреби закрити, та визначаються ресурси: персонал і витрати.

Після аналізу цих даних буде три варіанти:

• розробити нову систему,
• покращити існуючу або
• залишити систему як є.

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

2. Аналіз системи. На стадії аналізу постає задача збору та документування вимог кінцевого користувача продукту та всіх інші типів вимог. Головним результатом цієї фази має бути єдине розуміння: в чому буде цінність рішення для користувача та як її досягнути.

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

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

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

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

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

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

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

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

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

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

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

Щоб зручніше було візуалізувати, що в нас вже є (AS IS) на момент планування змін та що потрібно побудувати (TO BE), можна використовувати тулзи по типу Miro або Figma. Головне тут якісно провести воркшоп по Event Storming та Value chain mapping.

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

Підготовка до процесу проектування і розробки

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

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

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

Наприклад: в наявному продукті є процес бронювання подорожі з можливістю додати Things to do (активності під час відпочинку) до цього бронювання. Змінити інформацію про Things to do можливо лише коли статус не дорівнює Approved. У новому продукті виник запит надати користувачу можливість змінювати дані в Things to do незалежно від статусу, з додатковим повідомленням для відповідального за клієнта менеджера.

Рішення: прибрати валідацію та створити новий тригер на нотифікацію менеджера в системі, що генерує повідомлення (підтвердити зміст та дизайн листа).

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

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

За наявності запиту на зміну інтеграції робота стає більш кропіткою:

• проаналізувати, який зараз процес для конкретного data flow;
• зібрати інформацію про залежності, як зміни вплинуть на інші, пов’язані з новим продуктом, системи;
• запропонувати варіанти рішень з урахуванням змін;
• презентувати відповідальним співробітникам з метою підтвердити рішення;
• створити документацію.

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

Це потребує розширення існуючого API, додавання валідацій, додаткового тестування.

3. Міграція/створення існуючих (нових) користувачів — це дуже важлива і нетривіальна задача, тому що треба врахувати, яке рішення буде використовуватись для авторизації.

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

Наприклад:

• В Auth0 можна використовувати lazy migration, коли налаштовується перевірка, що користувач вже існує в системі, де зберігаються користувачі й міграція відбувається автоматично. Це потребує нескладних налаштувань та не передбачає розробку інтеграцій.
• Також можливо налаштувати міграцію всіх користувачів в новий authorization tool і обробляти реєстрацію через Forgot password. Тобто в такому випадку треба розробити інтеграцію існуючих, а після — і нових користувачів.

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

Підсумовуємо загальними пунктами

Що треба мати у своєму чеклісті, коли заплануєте переробку наявного у вас продукту:

• організувати комунікацію — це, на мій погляд, ключове в будь-якому проєкті на кожному з етапів розробки та впровадження нового продукту;
• залучити експертів для максимальної якості та ефективності майбутнього рішення;
• пропрацювати інтеграції з усіма департаментами;
• чітко (наскільки це можливо) визначити об’єм задач для першого релізу, бо він все одно «попливе», але задля впровадження правильно розробленого продукту треба постійно тримати в голові головну мету проєкту.