Одна из главных функций менеджера на проекте — правильно объяснять и ставить задачи команде специалистов. Для этого 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-менеджера.