Одна з головних функцій менеджера на проєкті — правильно пояснювати та ставити завдання команді спеціалістів. Для цього Project або Product Manager повинен мати хоча б базове уявлення, як технічно реалізується IT-продукт, знати основні особливості кожного етапу розробки. Враховуючи високу важливість архітектури для будь-якого продукту, PM потрібно вміти правильно її обговорювати з девелоперами. Про це і поговоримо у статті, але для початку визначимо саме поняття software architecture.
Що таке архітектура ПЗ
Архітектура програмного забезпечення – скелет будь-якого IT-продукту, при побудові якого враховують усі його структури та елементи, їх взаємозв’язки між собою, поєднання з бізнес-процесами та бізнес-цілями. По суті, це креслення для ПЗ та процесу розробки — саме на його основі багато в чому визначають завдання для фахівців. Помилка на цьому етапі може викликати проблеми на всіх наступних кроках роботи над проєктом, а також при функціонуванні вже готового продукту.
В ідеальному світі в кожній команді є Software Architect, який створює майбутню структуру на основі бізнес-вимог та існуючих ресурсів без зайвого «головного болю» для менеджера. На практиці це не завжди здійснено, тому PM важливо знати, чим характеризується архітектура ПЗ, основні терміни — це допоможе зробити спілкування з розробниками конструктивним, полегшує постановку і контроль завдань.
Основні характеристики архітектури
| Наявність великої кількості стейкхолдерів | Кожен з них має своє бачення бізнес-процесів і бізнес-результатів, і завдання архітектури імплементувати всі ці потреби — так звані «драйвери архітектури». |
| Поділ інтересів/понять | Наявність “драйверів” призводить до появи різних уявлень архітектури з різних точок зору. Наприклад, ви розробляєте складну бізнес-платформу. Її побудову можна розглядати із боку сейлзів, техпідтримки, фінансового відділу. Відповідно під кожне бачення формують окремі архітектурні верстви, які в результаті взаємодіють між собою та об’єднуються в єдину систему. |
| Орієнтованість на якість | Цей пункт про нефункціональні вимоги до будь-якого продукту: захист від помилок, розширюваність, надійність, юзабіліті, розширюваність тощо. Архітектура без подібних якостей — це просто принципова схема, яка не може гарантувати виконання бізнес-вимог. |
| Рекористування | Ідея полягає в тому, що при створенні будь-якого артефакту закладається можливість повторного використання його складових вимог і технічних патернів різного рівня. Наприклад, якість “надійність” застосовується практично до всіх елементів архітектури ПЗ. |
| Концептуальна цілісність | Ця характеристика гарантує єдине об’єднувальне бачення майбутнього продукту всіх етапах розробки. Припустимо, стоїть завдання створити масштабний health care product, завдяки якому буде можливість зустрічатися з лікарями з відеозв’язку безпосередньо та вирішувати безліч медичних питань. Відразу створити таке складно, але поступово додавати нові фічі на різних кроках розробки – не проблема. Концептуальна цілісність гарантує наступність всіх елементів структури кожному етапі, що дозволяє їй без проблем зростати і адаптуватися під нові бізнес-потреби. |
| Когнітивне обмеження | Насправді це відтворення і повторення архітектурою поведінка реальних систем. Наприклад, Amazon на своїх складах використовує роботів для сортування товарів. Незважаючи на те, що вони автономно здійснюють певні операції, всі процеси засновані на поведінці людей з адаптацією під роботу машин. |
Терміни для конструктивного спілкування з девелоперами
Одна з найчастіших проблем новачків у проєктному та продуктовому менеджменті — відсутність знання та розуміння термінології, якими оперують розробники. У результаті PM і Developer можуть говорити про те саме, але не розуміти один одного. Щоб такого не відбувалося, є сенс вивчити основні поняття та жаргонізми, які використовують девелопери.
Терміни для полегшення спілкування з розробниками:
- Прототип, патерни, послуги.
- MVP, домени.
- NFR – нефункціональні вимоги.
- Roadmap.
- Frontend, backend.
- Метрики, логи, дебаг.
- DevOps, реліз, регресія, UAT.
- Інстанси.
- Git, бранчі, репозиторії, мерж.
- Docker, Kubernetes, скейлінг групи.
- Сервер, API, Swagger, апі-гейтвей.
- JSON, кукі, OAuth.
- Ключі, сертифікати, поліси.
- Юніт тести, and-to-end, моки.
Список можна продовжувати, але знання перерахованих термінів та їх значення у 90% випадках достатньо для взаєморозуміння з розробниками. Не соромтеся уточнювати якесь поняття у девелопера з команди або досвідченіших колег, наприклад, експертів курсу Delivery Mind — це значно спростить роботу над будь-яким проєктом. Також буде не зайвим знати основні види архітектури під різні типи додатків.
Варіанти архітектури для mobile, web, desktop
Схематично будь-який додаток є окремими блоками, які відповідають за певні процеси і взаємодіють один з одним безпосередньо або за допомогою додаткових інструментів. При цьому весь набір цих конструкцій об’єднані в єдину систему, архітектура якої створюється та реалізується залежно від типу програми та бізнес-завдань.
Архітектура для mobile
Типова архітектура мобільного додатка зазвичай складається з двох частин: внутрішньої та зовнішньої. У локальній є чотири великі блоки:
- Presentation — відповідає за візуальне подання для користувача та взаємодію з ним.
- Business — включає в себе бізнес-логіку програми.
- Data — зберігає локальні дані на пристрої
- Common — містить компоненти Configuration, Security, Communications.
Зовнішня частина програми складається з глобального зберігання ключових даних їхнього обміну з локальними, і навіть різних сервісів із можливістю синхронізації до виконання певних операцій. Все це забезпечується віддаленою інфраструктурою.
Якщо розглянути реалізацію архітектури (імплементацію), її можна подати у вигляді будинку. Перший поверх – це мобільна операційна система та «залізо», другий – нативний фреймворк, який пов’язує перший поверх з третім – web-блоком, де відображається основна інформація для користувача через HTML, CSS та JavaScript. Можлива варіація без використання поверху-прошарку, але тоді web-частина має складнішу реалізацію.
Найпопулярніші інструменти для написання програми: Flutter (Dart), Ionic (JS), React-native (JS), Xamarin (.NET), Kotlin (Swift).
Архітектура для web
Для web-додатків існує кілька основних видів архітектури: Server-Side HTML, JS generation Widget, Service-oriented single-page Web apps. Кожна має свої переваги, що дозволяє знайти оптимальне рішення навіть під специфічні завдання. Пропонуємо ознайомитись з базовими особливостями всіх трьох варіантів архітектури для web, а також таблицею основних характеристик.
Server-Side HTML
Server-Side HTML – найпростіша реалізація архітектури для web. Дозволяє генерувати сторінки на сервері. Умовно бекенд містить як бізнес-логіку, і формування думки для користувача. Головний мінус такого рішення — постійне звернення в backend при завантаженні кожної сторінки, що негативно впливає на швидкість роботи програми та user experience.
JS generation Widget
JS generation Widget – логічна еволюція попередньої архітектури. Основна особливість — не весь HTML генерується в бекенд і наявність вкраплення Javascript. JS при формуванні сторінки робить запит до бази даних, що знижує навантаження на Backend та прискорює процес завантаження. Добре це відображено при роботі фідів у соцмережах — користувачам буквально відразу відображається зовнішня оболонка HTML з якоюсь красивою заставкою або анімацією, хоча дані ще підвантажуються. У результаті user experience зростає. З мінусів подібного рішення — дуже низька тестованість, SEO та складності роботи офлайн.
Service-oriented single-page Web apps
Service-oriented single-page Web apps — архітектура, в якій вся візуальна логіка web-програми знаходиться в Javascript та HTML підпорядкований JS. У такому додатку зазвичай існують базові індекси HTML, які завантажують командні бандли, а вони вже займаються формуванням сторінки. Головні мінуси – можливі проблеми з безпекою, низькі показники SEO та Linkability.
Оцінка основних характеристик різних видів архітектур для web-додатків (від погано 0 до 5):
| Характеристика | Server-Side HTML | JS generation Widget | Service-oriented single-page Web apps |
| Responsiveness/Usability | 1 | 3 | 5 |
| Likability | 5 | 2 | 1 |
| SEO | 5 | 2 | 1 |
| Speed of development | 4 | 3 | 2 |
| Scalability | 3 | 4 | 5 |
| Performance | 3 | 4 | 5 |
| Testability | 4 | 1 | 3 |
| Security | 4 | 4 | 1 |
| Conversion: website — mobile or desktop application | 0 | 0 | 5 |
| Offline work | 2 | 1 | 5 |
Архітектура backend
Це приблизна архітектура backend, яка може мати складніший або спрощений вигляд. Основне завдання бекенда — виконувати «чорнові» завдання, спрямовані на підтримку стабільної швидкості, високої безпеки та надійності роботи програми.
Архітектура для desktop
Десктопна архітектура дуже схожа на мобільну з погляду компонентів, але з’являються особливості імплементації у трьох важливих моментах: UI Development Technology, Deployment Strategy та Installer. Якщо web-додаток просто завантажується в браузер, то для десктопу необхідні інструменти та механізми для написання та відображення інтерфейсу на різному залізі з урахуванням відмінностей існуючих операційних систем.
Основні інструменти імплементації архітектури на desktop:
- UI Development Technology – Electron, UWP, JavaFx/Swing/Kotlin, Qt.
- Deployment Strategy – Store, Squirrel, Chocolatey, Custom.
- Installer – Inno, Wix, InstallShield.
Якщо хочете більше вивчити технічну складову розробки для кращої взаємодії з командою, зверніть увагу на курс для PM Delivery Mind — практикуючі експерти з досвідом роботи у великих міжнародних компаніях максимально повно розкриють цю тему.
Як вибирати інструменти?
Менеджерам часто доводиться стикатися із ситуацією, коли для реалізації технічної частини проєкту перед командою стоїть вибір із кількох технологій чи інструментів. Оптимальне рішення – провести порівняння за основними критеріями.
Для зручності оцінювання можете вибрати шкалу значень від -5 до +5:
5 – супер фіча, яка дуже потрібна;
4 – велике поліпшення;
3 – трохи збільшує user experience;
2 – приємний бонус;
1 – нейтрально;
0 – ніяк не впливає до певної “червоної лінії”;
-1 – Мінімальне зниження можливостей;
-2 – прийнятне зниження можливостей;
-3 – злегка вплине на user experience (tech debt);
-4 – Потрібна компенсація або оптимізація в майбутньому.
-5 – Фіча, якої немає або блокує розробку.
Цю шкалу значень можна масштабувати, розширюючи діапазон. Основна ідея в тому, що кожен інструмент має позитивні та негативні сторони, і впровадження мінуса краще підкреслює цю різницю для сприйняття.
Як приклад давайте подивимося порівняння кількох HTML шаблонизаторів:
Враховуючи оцінки всіх критеріїв, в даному випадку оптимальний варіант для вибору HTML шаблонизатора Handlebars. Подібна таблиця наочно показує плюси та мінуси того чи іншого інструменту, що значно прискорює та спрощує вибір відповідного.
Як обговорювати та перевіряти архітектуру
Well-Architected Framework від Amazon — у певному сенсі це одна з найкращих збірок рекомендацій щодо оцінки та розробки архітектури для високотехнологічних продуктів. У WAF ви знайдете питання, які потрібно ставити собі та фахівцям-архітекторам.
Якщо коротко, Well-Architected Framework базується на п’яти ключових категоріях нефункціональних вимог: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization. Виконання перерахованого гарантує якість системи. Загалом у WAF добре показано, які патерни існують при проєктуванні різних навантажень та видів завдань, чому і коли потрібно використовувати певні рішення, як вони реалізуються на прикладі Amazon.
Для перевірки архітектури менеджер обов’язково має знайти відповіді на три запитання:
- Чи покриті всі частини життєвого циклу розробки програмного забезпечення – SDLC?
- Чи проведено cost-analysis, складено роадмап основних фаз розробки продукту: POC, MVP, Prod?
- Визначено та чи враховано NFR у дизайні?
Для зручності та систематизації створіть докладну таблицю з кожного питання. Як і у разі визначення потрібного інструменту, такий підхід значно полегшить перевірку архітектури.
В цілому, чим краще ви вивчите технічну складову розробку, тим простіше вам узгоджуватиме цей етап з командою. Хороші hard skills додадуть вам додаткові бали не тільки в очах технічних фахівців, а й керівництва. Тож не соромтеся ставити уточнюючі питання та інвестуйте свій час у нові знання – це підвищить вашу цінність як IT-менеджера.