PM-у на заметку: архитектура, интеграция и безопасность проекта

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

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

Статья написана по материалам открытых лекций спикеров курса ArchiTech

Архитектура проекта и ее влияние на процесс

Как будет выглядеть дом? Как он будет функционировать? От этого зависит его архитектура. В случае с IT ситуация аналогичная. Клиент хочет разработать приложение или создать интернет-магазин? В любом случае придется учитывать архитектуру (software architecture) будущего проекта. Именно она решает: как все реализовать и как будет работать в итоге. Так что понимание software architecture и техническая экспертиза — must have не только для разработчиков, но и для PM. 

Вопрос в том, как разобраться в software architecture. Начинать советуем с понимания, как архитектура влияет на создание (написание) продукта в IT.

Архитектура диктует, как мы пишем приложение

Ровно, иногда коряво, реже идеально. Все это можно сказать о разработке любого приложения, но во всех случаях неизменно одно — работу строят по определенной модели проектирования. Базовых две: MVC и MVP

MVC (Model-View-Controller — «Модель-Вид-Контроллер»). В данном случае приложение разбито на отдельные модули или компоненты. Каждая составляющая имеет свой код и отвечает за свою часть общих функций системы:

• Model. Хранит данные и методы работы с ними. Этот модуль получает запрос на обновление данных от Controller, а затем передает View нужную информацию на вывод для юзера. По сути — это бизнес-логика приложения.
• View. Получает необходимую информацию от модели и отображает (представляет) ее пользователю. Если провести ассоциацию с правами доступа к документам, то вид\представление может только «читать» данные с Model.
• Controller. Отвечает за взаимодействие юзера с приложением. Получает от пользователя запрос, который перенаправляет потом в Model на обработку для дальнейшего показа нужного результата через View.

MVC характеризуется четкой иерархией и тем, что блок Model сам говорит View, какие данные нужно показать. Работу модели можно охарактеризовать следующей цепочкой: User → Controller → Model → View → User. 

MVP (Model-View-Presenter — «Модель-Вид-Представление»). Эта модель проектирования аналогично MVC также разбита на отдельные компоненты:

• Model. Здесь находятся данные, которые передаются на отображение пользователю по запросу от Presenter. Отличие данного блока от такого же в MVC в том, что в MVP его можно изменять.
• View. Взаимодействует с Presenter в двух направлениях: для отправки запроса от пользователя и для отображения юзеру необходимой информации, полученной от Model.
• Presenter. Взаимодействует с обеими функциональными частями модели. Через этот блок в Model передается запрос об изменении данных или о том, какую информацию нужно вывести для юзера. С компонентом View работа строится на отображении обновлений UI и получения действий пользователей.

Если сравнивать MVP с MVC, то главное отличие — это прослойка Presenter между View и Model, которая позволяет настроить более гибкое взаимодействие между модулями. Работу данной модели можно расписать следующей цепочкой: User → View ⇆ Presenter Model ⇆ Presenter ⇆ View → User. 

Обе модели проектирования показывают, что архитектура приложения в плане написания — это деление кода на логические компоненты, каждый из которых отвечает за свою часть работы конструкции. В идеале, если все модули независимы друг от друга. Это позволит изменить\заменить любой из них без вмешательства в другие, что сильно снижает стоимость возможного рефакторинга (переработку кода).

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

Знание этих моментов и влияния архитектуры на то, как работает приложение, помогает PM:

• Еще на этапе оценки проекта правильно закладывать время на разработку software architecture и refactoring. Почему важно учитывать возможную задачу по переработке кода? Всегда есть вероятность изменений бизнес-логики, внесения дополнений в проект и так далее. 
• При возникновении ошибок в работе приложения быть на одной волне с разработчиками, быстрее влиться в процесс решения проблемы.
• Проще и быстрее объяснить клиенту почему на создание продукта или же внесение изменений в существующий, нужно то или иное количество времени и денег.

Теперь давайте вместе разберемся, как software architecture влияет на работу приложения.

Архитектура диктует, как наше приложение работает

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

• Монолит (Monolith). В данной структуре проект находится в одной кодовой базе, то есть все функциональные блоки зависят друг от друга.
• Микросервисы (Microservices). В этом решении кодовая база состоит из отдельных микро-проектов, каждый из которых отвечает за свою часть общего функционала. Между собой модули взаимодействуют по программируемому алгоритму, образуя вместе единую систему.

Разница в структуре каждого из видов архитектуры диктует дальнейшую работу приложения, возможности по апгрейду и расширению функций системы. Для небольших задач, где присутствует простая бизнес-логика и четкая иерархия, подойдет вариант Monolith. Для масштабных проектов с разнообразными функциями, где каждое действие может зависеть от множества факторов, оптимально использовать Microservices.

Для лучшего понимания особенностей этих двух видов архитектуры, давайте сравним их между собой:

Нет правила, что монолит — это плохо, а микросервисы — хорошо. Любому проекту нужно найти свое подходящее решение. Это также важно понимать PM-у, как и то, что software architecture для него — один из маркеров квалификации. Чем этот скилл лучше, тем больше ценят такого специалиста. Аналогично обстоит ситуация с интеграцией проекта с внешними системами. Если project manager в этом разбирается, он явно сможет «потянуть» ведение серьезного проекта.

Интеграция с внешними системами

Внешняя система — специализированное программное обеспечение от стороннего сервиса.

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

Интеграция с внешними системами упрощает и ускоряет разработку любого приложения:

• Нужно организовать онлайн платежи? Существуют готовые решения от тех же Stripe, Braintree.
• Есть необходимость в указании местоположения? Google maps в помощь.
• Регистрация через соцсети? Facebook, Twitter API.

Иногда новички PM-ы по неопытности путают внешние системы с библиотеками. Как говорят в Одессе: «Это две большие разницы!» Одно дело взять кусок кода и встроить в свой, а другое — подключить совсем независимый модуль, который расположен на чужих серверах. Оба способа широко используют на практике, но помните об их принципиальных отличиях.

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

Перечисленное добавляет головной боли не только разработчикам, но и проектным менеджерам. PM-ам даже сложнее, ведь именно менеджеру придется «выруливать» перед клиентом в случае форс-мажора. Чтобы снизить риск появления проблем из-за интеграции со сторонним решением, важно системно подходить к его оценке. Начинать следует с изучения информации о работе внешней системы. 

Документация сторонних решений

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

При оценке возможного выбора в пользу интеграции с той или иной внешней системой, обязательно обращайте внимание: 

• Есть ли вообще документация и как давно обновлялась. Если ее нет, однозначно ищите другое решение. Аналогичная история с внесением изменений в работу внешнего модуля и их фиксацией. Нет смысла тратить время на то, что морально и технологически устарело.
• На какой площадке размещена документация и в каком виде. Информация изложена четко и понятно? К ней есть беспроблемный доступ? Это не файл txt, а что-то вроде Swagger или Postman Collections? С такой документацией работать можно. Текстовый файл лучше не рассматривать, потому что этот формат не так удобен для изучения информации, как другие.

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

Работа внешней системы

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

Исследование через status page может дать один из двух результатов: все хорошо или есть сбои. Если все хорошо, вопросов больше нет — делаем интеграцию. Если же появились сбои, советуем думать о резервных решениях или failover механизмах (аварийном переключении). Кстати, это также относится к безопасности работы приложения. А если добавятся возможные проблемы в менеджменте доступов — получите ту еще головную боль для проектного менеджера.

Менеджмент доступов

Представьте ситуацию: вы — project manager, и из команды уходит человек. Что вы делаете в первую очередь, чтобы обезопасить проект и компанию от возможной утечки информации? Меняете доступы на всех сервисах, верно? Хорошо, если у вас они упорядочены, но на практике обычно иначе:

1. Пароли раскиданы по личным сообщениям между специалистами. На больших проектах так и вовсе не факт, что нужная информация находится только внутри вашей команды. Может же быть еще и взаимодействие с другими специалистами из компании и сторонними подрядчиками.
2. Для всех рабочих аккаунтов используется единая почта. Соответственно, когда кто-то уходит, возникает необходимость менять пароль к ней. Про то, что это огромная брешь в безопасности, умолчим.
3. Пароли собраны в одном облачном документе, например confluence, в который есть доступ у всех членов команды. С одной стороны это удобно, но чаще в подобных документах творится упорядоченный хаос. Найти там что-то быстро, —  порой из области научной фантастики.
4. Часто используются сторонние сервисы для хранения информации, паролей и так далее. Для удобства и экономии обычно создают один аккаунт. Дальше история такая же, что и в случае с единым email на всех.

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

• Создать отдельные аккаунты под каждый сервис и никому их не давать. Важные уведомления можно форвардить на почту. Способ подходит при при работе с небольшим количеством аккаунтов.
• Использовать специальные сервисы, которые помогают передавать пароль одноразовой ссылкой. Безопасно и удобно, особенно в случае с удаленной командой, которая раскидана по разным локациям.
• Забыть про то, чтобы делать один аккаунт на всех. Даже если мы решаем сделать тестовое ознакомление какого-то сервиса, создаем отдельный доступ. Идея состоит в том, что 1 аккаунт = 1 человек. Это позволяет легко запретить доступ к любому сервису или базе данных компании. Аналогично с использованием личных e-mail при работе над проектом. Делаем только рабочие, которые в любой момент можно заблокировать.
• Подключить специальные системы контроля доступа. Например: Dashlane, Keeper, RoboForm. Такой подход отлично себя показывает в случае с большим количеством проектов и участников, когда команде становится сложно с менеджментом доступов.

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

Цена и интеграция с внешними системами

За сервис и комфорт нужно платить. В случае с подключением сторонних продуктов ситуация такая же. Если не говорить о полностью бесплатных сервисах (таких много, но не каждый предоставляет необходимое качество взаимодействия), у каждого платного свой тип монетизации:

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

Есть и другие типы монетизации, но перечисленные встречаются чаще всего. Выбор внешних сервисов и тарифов зависят от задач и бюджета проекта. Для дополнительной экономии рассмотрите варианты с сэмплированием (актуально для аналитических систем) или self-hosted.

При self-hosted внешнюю систему (например, Jira) разворачивают на собственных мощностях компании. Обычно это обходится дешевле, чем использование сторонних ресурсов. С точки зрения стабильности работы такое решение тоже идет в плюс. Контроль доступности сервиса и решение инфраструктурных вопросов не зависит от вендора (поставщика услуг). При этом PM должен понимать, что безопасность проекта в этом случае полностью «ложится» на его команду специалистов. Впрочем, об этом стоит помнить на каждом этапе разработки, так как проблемы в безопасности могут всерьез повлиять на сроки и конечные результаты.

Безопасность проекта

«За безопасность необходимо платить, а за ее отсутствие расплачиваться» — Уинстон Черчилль.

Это тот редкий случай, когда цитата на все 100500 попадает в цель. Если в вашем приложении «дыры» в безопасности, вероятность взлома и кражи данных стремится к 100%. Последствия подобного? Как минимум, это ударит по репутации компании и приведет к финансовым потерям из-за отказа клиентов пользоваться ненадежным продуктом. Так что лучше в самом начале разработки об этом подумать и сделать все правильно.

Что важно знать PM о безопасности? Про доступы говорили, когда обсуждали возможные проблемы с их администрированием. Сейчас остановимся на двух ключевых понятиях в безопасности работы любого приложения: хешировании и шифровании. В физическом плане первое — это односторонняя функция (hash function), второе — двусторонняя. У каждой свои алгоритмы работы, но важно помнить следующее: данные при передачи шифруют, пароли в базе данных хешируют.

Для лучшего понимания, зачем все это нужно, рассмотрим каждую функцию в отдельности.

Хэширование

Процесс выглядит следующим образом:

1. Есть какая-то строка, в которой можно представить любой объект: текст, игру, картинку и так далее.
2. Передаем ее в hash function.
3. На выходе получаем небольшую строку фиксированного размера — хеш, который записываем в базу данных (БД). Обратное преобразование невозможно.

Полученная таким образом информация занимает мало места в БД, что порой критично на больших проектах. Также важно то, что хеш одной и той же строки будет всегда одинаковым, сколько бы раз не происходило преобразование. Главная же причина, почему при разработке приложений используют хешированные данные, — их сложно взломать. Да, существуют так называемые «радужные таблицы» с большим количество всевозможных хешей, но на практике их применение малоэффективно.

Для примера рассмотрим классическую схему. При регистрации пользователь создал пароль, который система записала в базу данных. Храниться там он будет в виде хеша. В следующий раз, когда юзер будет вводить свой пароль, он снова будет преобразован с помощью hash function. После этого происходит сравнение полученного хеша с тем, что находится в базе. Если они совпадают, значит все в порядке.

Хеширование — это просто находка для работы с базами данных. Безопасно, экономно и быстро. Почти как шифрование, но только в одну сторону. Впрочем, это чуть ли не главное отличие этих двух процессов.

Шифрование

Шифрование можно представить в виде следующей цепочки действий:

1. Исходные данные шифруются с помощью специальных алгоритмов.
2. Шифр отправляется по назначению.
3. На выходе данные дешифруются и прочитываются.

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

В случае симметричного алгоритма для расшифровки и дешифровки необходим всего один ключ. Основная проблема в этом процессе — безопасная передача как информации, так и отмычки к ней. «Перехват» всех частей может произойти в любой момент. В асимметричном алгоритме с этим дело обстоит надежней: для шифрования и дешифрования создаются отдельные ключи. Например, https и ssl работают именно по такой схеме. Завладеть чужими данными в этом случае значительно сложнее, чем при первом варианте.

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

Несколько полезных советов:

• Забудьте про создание юзеров с именем admin и паролем password (или подобными). Это может оказаться фатальным для вашего проекта, так как вероятность взлома при таком подходе в разы выше, чем при других вариантах.
• Пушите интеграцию систем мониторинга в проект, чтобы понимать, что происходит в приложении. Быстрое реагирование на нестандартную ситуацию часто предотвращает серьезные проблемы в дальнейшем.
• Обязательно изучите облачные решения для защиты, например AWS Shield, в случае разрастания проекта. Они не только могут повысить безопасность, но и облегчить жизнь проектному менеджеру.

Главное, что должен помнить каждый PM, — не вставлять найденные флешки в рабочий или личный комп и не «вестись» на фишинг! Вы можете быть очень крутым спецом с нереальным опытом, но от секундного помутнения разума никто не застрахован. Так что будьте всегда внимательны, чтобы не было: «Как такое вообще возможно? Да я ж никогда! Да ну нет!»

Вместо вывода

— Когда мы точно будем знать, сколько времени займет проект?
— Когда его закончим!

Проза жизни. Чтобы в конце для проекта был хэппи-энд, PM однозначно должен:

1. Понимать, что такое software architecture.
2. Знать, как правильно выбирать внешние системы для интеграции.
3. Помнить о безопасности.

Это в довесок к его остальным обязанностям: анализу проекта и планированию работ, созданию команды специалистов, «разгребанию» форс-мажоров и так далее. Впрочем, чем больше скиллов и их качество, тем выше стоимость услуг такого специалиста. Есть, о чем подумать!

Если хотите «доставлять»  проекты точно в срок, и забыть о переделках, приходите учиться на ArchiTech. Это не просто курс об архитектуре и управлении технической командой для менеджеров, а подробная программа о том, как вовремя и качественно поставлять сложные IT-проекты для всех PM, BA и Product уровня Middle и выше! Сможете серьезно прокачать техническую экспертизу, благодаря опыту спикеров из RingCentral, Sprintera, Solar Digital, Ciklum, SoftServe и GlobalLogic.