Как архитектура проекта влияет на работу PM-a и зачем она ему нужна

Как архитектура проекта влияет на работу PM-a и зачем она ему нужна

7 сентября 2023

  • Автор: Александр Кононенко

  • Сложность: Средне

  • Время: 6 мин

— Уверен, что выбрана подходящая архитектура IT-проекта?

— Да, учитывая бизнес-цели клиента и озвученные им желаемые сроки и бюджет проекта.

— Давай подумаем еще. Нужна максимальная оптимизация времени и ресурсов для разработки, а также сокращение рисков до минимума.

Это пример диалога между Solution Architect и PM-ом, который имеет техническое понимание проекта. Дальше обсуждают ключевые аспекты архитектуры будущего приложения, сравнивают различные варианты для поиска лучшего решения. Подробней о том, почему это важно и какая роль проектного менеджера в этом процессе, расскажем в статье. Начнем с базы — что такое software architecture и почему она важна.  

Роль архитектуры в IT

Представьте, что перед вами стоит задача построить дом. Вы можете его сделать в любом стиле и из разных материалов, но в основе будет лежать определенное архитектурное решение. Именно оно диктует, какие технологии применять, как и в какой последовательности выполнять те или иные работы. В разработке IT-решений происходит все тоже самое с поправкой на особенности сферы. При этом связь архитектуры и реализации проекта прослеживается на всех этапах: от оценки до релиза и последующей техподдержке.

Software architecture помогает:

  • определить базовую структуру приложения, основные и второстепенные элементы;
  • выстроить логику взаимодействия между разными компонентами архитектуры проекта;
  • учесть риски, найти способы предотвращения технических проблем в процессе разработки и при работе готового ПО;
  • продумать безопасность и потенциальную масштабируемость проекта;
  • создать единую систему для комфортной работы команды;
  • оценить сроки, стоимость и этапы разработки.

Список можно долго продолжать, но главное — software architecture диктует, как вы «пишите» приложение, как оно работает и какой существует потенциал для расширения функциональности в будущем. От этого во многом зависит процесс девелопмента и управление IT-проектом в целом, и влияние архитектуры на роль менеджера в частности.  

Виды software architecture

Виды software architecture

Любое приложение по своей сути — это различные компоненты проектной архитектуры, объединенные в одно целое. Другой вопрос, каким образом воедино соединены все системы, модули и интерфейсы, и как построено их взаимодействие. Это во многом зависит от вида архитектурного IT-решения:

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

Подробнее о каждом из решений вы сможете узнать на курсе для проектных менеджеров «Архитек» — ArchiTech. На нем эксперты IAMPM делятся собственным опытом и знаниями, которые помогут вам понять всю важность архитектуры в проектах и проработать технические скиллы для PM. Мы же рассмотрим основные плюсы и минусы каждого вида software architecture.

Монолит

монолит архитектура проекта
ПлюсыМинусы

Простота развертывания. Так как для монолита в основном существует только одна точка входа, развертывание происходит очень быстро и относительно просто.

Разработка. Обычно выполняется быстро — все компоненты и модули содержатся в единой кодовой базе и всегда находятся под рукой, что экономит время.

Отладка. Значительно упрощается, так как все элементы находятся рядом можно отследить все связи с выполнением кода.
Масштабирование. Можно расширять только целиком — если нагрузка растет на один модуль, масштабировать необходимо весь монолит.

Надежность и уязвимости IT-проекта. Если выходит из строя, то сразу все модули.

Изменение и апгрейд технологий. Очень сложно!

Гибкость. Монолит негибкий — изменение одного модуля практически всегда влияет на другие.

Микросервисы

микросервисы архитектура проекта
ПлюсыМинусы
Гибкость. Каждый сервис — отдельная система и любые изменения в ней не затрагивает другие части архитектуры, если в этом нет необходимости. 

Масштабирование. Можно масштабировать каждый модуль по отдельности.

Гибкость технологий. Любая подсистема может быть реализована собственным способом, отличным от остальных.

Надежность и безопасность IT-проекта. Обычная поломка какой-то подсистемы редко выводит из строя всю систему.
Процесс разработки. Обычно требует больше времени и ресурсов, чем при работе с монолитной структурой, так как нужно реализовывать и налаживать взаимодействие нескольких подсистем.

Отладка. Происходит сложнее, чем в монолите — необходимо определить сломанный сервис и причины его выхода из строя.

Развертывание. Каждое добавление нового сервиса требует настройки главных частей IT-проекта.

Серверлес

серверлес архитектура проекта
ПлюсыМинусы
Гибкость. Высокая за счет обособленности модулей друг от друга.

Абстракция от операционной системы. Cloud автоматически решает, какая операционная система и настройки необходимы.

Легкий порог входа. Обычно  у серверлесов обособленный простой код, с которым профильный специалист легко и быстро сможет разобраться.

Надежность. Сравнима с микросервесной структурой при правильном построении проекта.
Гибкость. Одновременно плюс и минус. Недостаток в том, что масштабирование зависит от возможностей и настроек облачного сервиса.

Отладка. Усложнена из-за взаимодействия между обособленными компонентами.

Зависимость от сервиса. Каждый Cloud имеет собственный алгоритм работы, поэтому безболезненный переход с одного «облака» на другое на практике сложно осуществим.

Каскадный отказ. При неправильной структуре и настройке отдельных модулей возможно их взаимное влияние друг на друга, что несет потенциальные риски выхода из строя всей системы.

Перечисленное хорошо показывает влияние software architecture на разработку IT-продуктов. Также важно понимать, что для mobile, web и desktop каждый вид архитектуры будет иметь свою специфику. Поэтому важно изначально учитывать все моменты: функциональность и безопасность проекта, возможности масштабирования и другие аспекты. В этом вопросе роль PM-а выходит на первый план.

Как архитектура проекта влияет на работу PM-a и зачем она ему нужна

Роль проектного менеджера в архитектуре IT-продукта

На идеальном проекте у менеджера в команде присутствует Solution Architect, который продумывает архитектуру приложения. Для этого ему нужно, как минимум, идея и хотя бы базовое техническое задание — ТЗ обычно дает Business Analyst или Project Manager. Дальше идет процесс продумывания архитектурного решения с учетом:

  • данных по бизнес-целям и потребностям клиента;
  • текущих ресурсов: уровня специалистов, желаемых дедлайнов, выделяемого бюджета;
  • риск-менеджмента и так далее.

При этом менеджер может и вовсе не участвовать в процессе — только осуществлять контроль результата с последующей оценкой и ведением проекта по созданной software architecture. На практике же часто встречается ситуация, когда на проекте отсутствует SA и даже BA — в этом случае Project Manager становится мастером-универсалом. 

Если до этого одна из задач PM-а заключалась в организации работы бизнес-аналитика по сбору данных и составлении техзадания для архитектора, то теперь это ложится на плечи самого менеджера. При этом разработкой software architecture занимается Project Manager самостоятельно, если техскиллы позволяют, или с кем-то из девелоперов — тот случай, когда управление проектом с техническими знаниями об архитектуре дается легче, чем без них. Впрочем, при общении с Solution Architect подобные навыки тоже будут в плюс для менеджера.

Преимущества глубокого понимания технической стороны проекта

Преимущества глубокого понимания технической стороны проекта

Правильно настроенная коммуникация и выстроенные процессы — один из важнейших аспектов успешной работы команды. Понимание, что такое software architecture, знание терминов и процесса разработки,необходимые технические навыки помогают проектным менеджерам:

  • проще находить «общий язык» с разработчиками — сокращает время на принятие решений и устранение возможных проблем;
  • правильно оценивать время и бюджет проекта, в том числе и на разработку software architecture и refactoring — всегда возможны дополнения к текущим бизнес-целям, изменения приложения и другое;
  • качественней планировать загрузку команды, описывать задачи и контролировать их выполнение — упрощает управлении рисками и проектом в целом, снижает процент технического долга и возникновение проблем в долгосрочной перспективе;
  • быстро и доступно преподносить клиенту информацию от специалистов, отстаивать собственное предложение по срокам и цене — руководство и заказчики такое точно оценят;
  • корректно вести документацию и четко расписывать функциональность для упрощения дальнейшего обслуживания приложения, внесения изменений — такой подход значительно оптимизирует общую работу над проектом.

Помимо перечисленного знания software architecture позволяют менеджеру находить и предлагать команде вместе с клиентом лучшие варианты. При этом учитывать различные факторы и риски: от безопасности до потенциального роста проекта. Безусловно, многое приходит с опытом, но получить актуальные знания и прокачать свои технические навыки вы можете на курсе по архитектуре IT-проекта ArchiTech. Советуем на него обратить внимание вне зависимости от вашего уровня — на рынке высоко ценятся PM-ы, которые хорошо разбираются в software architecture.

Примеры влияния выбора архитектуры на судьбу проектов

На старте разработки одна компания неверно сделала выбор архитектуры для масштабирования приложения — не учли возможность быстрого изменения функциональности под разные запросы пользователей. В итоге пришлось фактически с нуля делать новую версию продукта со всеми вытекающими последствиями. Опытный PM обязательно сказал бы клиенту и команде обратить внимание на масштабируемость.

Другой пример касается идентификации потенциальных уязвимостей и правильного выбора архитектурных решений для безопасности. Клиент заказал бизнес-приложение, которое собирало расширенные данные пользователей. Так как это потенциальный фактор риска, РМ предложил заказчику усилить защиту и выделить для этого дополнительный бюджет. Из-за «плавания» в технических моментах и слабой коммуникации, Project Manager не смог добиться согласия клиента. Как итог, после релиза приложение быстро взломали и украли пользовательские данные. С одной стороны, вины менеджера нет, но были бы у него высокие hard и soft skills, переговоры с заказчиком могли иметь другой результат.  

Бонус: как обсуждать и проверять архитектуру

как обсуждать и проверять архитектуру

Для конструктивного обсуждения software architecture с архитектором или разработчиками советуем обращаться к справочнику WAF — Well-Architected Framework от Amazon. Здесь вы найдете актуальные рекомендации по оценке IT-продуктов. Если кратко, WAF предлагает оценивать проект исходя из пяти категорий нефункциональных требований:

  1. Operational Excellence.
  2. Security.
  3. Reliability.
  4. Performance Efficiency.
  5. Cost Optimization.  

Если все перечисленное выполнено, то с вероятностью в 99.9% архитектура на проекте разработана правильно. 

Александр Кононенко

Копирайтер-маркетолог с техническим образованием, опытом в продажах и маркетинге. Всегда в поисках лучших решений для достижения поставленных целей, и считает, что создание текстов — это симбиоз искусства и науки.