Уявіть собі ситуацію. Зайшов новий проєкт. На пресейлі команда технарів запропонувала план робіт і передала його проєктному менеджеру. PM же, замість того, щоб підготувати пропозицію для клієнта, намагається розібратися в кількох питаннях. Звідки взялося стільки годин на розробку? Чому для впровадження конкретного продукту потрібен ще один девелопер? Як пояснити клієнту, що повна ідентифікація клієнтів – це не примха?
Відповіді на ці запитання лежать у розумінні проєктним менеджером (PM-ом) технічної складової розроблення проєктів: від архітектури та інтеграції із зовнішніми системами до безпеки продукту.
Архітектура проєкту та її вплив на процес
Який вигляд матиме будинок? Як він буде функціонувати? Від цього залежить його архітектура. У випадку з 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 ⇆ 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, і з команди йде людина. Що ви робите насамперед, щоб убезпечити проєкт і компанію від можливого витоку інформації? Змінюєте доступи на всіх сервісах, вірно? Добре, якщо у вас вони впорядковані, але на практиці зазвичай інакше:
- Паролі розкидані по особистих повідомленнях між фахівцями. На великих проєктах так і зовсім не факт, що потрібна інформація знаходиться тільки всередині вашої команди. Може ж бути ще й взаємодія з іншими фахівцями з компанії та сторонніми підрядниками.
- Для всіх робочих акаунтів використовується єдина пошта. Відповідно, коли хтось іде, виникає необхідність змінювати пароль до неї. Про те, що це величезний пролом у безпеці, промовчимо.
- Паролі зібрані в одному хмарному документі, наприклад confluence, до якого є доступ у всіх членів команди. З одного боку це зручно, але частіше в подібних документах твориться впорядкований хаос. Знайти там щось швидко, – часом зі сфери наукової фантастики.
- Часто використовуються сторонні сервіси для зберігання інформації, паролів тощо. Для зручності та економії зазвичай створюють один акаунт. Далі історія така сама, що й у випадку з єдиним email на всіх.
Напевно ви можете продовжити цей список прикладами зі своєї практики. Питання в тому, що з цим хаосом можна зробити? Пропонуємо такі рішення, які допоможуть вам, як PM-у, навести лад у менеджменті доступів:
- Створити окремі акаунти під кожен сервіс і нікому їх не давати. Важливі повідомлення можна форвардити на пошту. Спосіб підходить при роботі з невеликою кількістю акаунтів.
- Використовувати спеціальні сервіси, які допомагають передавати пароль одноразовим посиланням. Безпечно і зручно, особливо у випадку з віддаленою командою, яка розкидана по різних локаціях.
- Забути про те, щоб робити один акаунт на всіх. Навіть якщо ми вирішуємо зробити тестове ознайомлення якогось сервісу, створюємо окремий доступ. Ідея полягає в тому, що 1 акаунт = 1 людина. Це дає змогу легко заборонити доступ до будь-якого сервісу або бази даних компанії. Аналогічно з використанням особистих e-mail під час роботи над проєктом. Робимо тільки робочі, які в будь-який момент можна заблокувати.
- Підключити спеціальні системи контролю доступу. Наприклад: Dashlane, Keeper, RoboForm. Такий підхід відмінно себе показує у випадку з великою кількістю проєктів і учасників, коли команді стає складно з менеджментом доступів.
Правильне управління обліковими записами і паролями впливає не тільки на швидкість роботи команди фахівців, а й загалом на безпеку проєкту. Якщо говорити про взаємодію зі сторонніми сервісами, то невпорядкованість і нехлюйство в цьому питанні може істотно вдарити, зокрема, і по бюджету розробки.
Ціна та інтеграція із зовнішніми системами
За сервіс і комфорт потрібно платити. У випадку з підключенням сторонніх продуктів ситуація така сама. Якщо не говорити про повністю безкоштовні сервіси (таких багато, але не кожен надає необхідну якість взаємодії), у кожного платного свій тип монетизації:
- Умовно безкоштовно, коли на нульовому тарифі умови такі, що він підходить тільки для простих завдань або тестування сервісу. Надалі необхідно переходити на платні умови отримання послуг або шукати інші варіанти.
- Оплата за певний період. Часто є можливість заощадити, якщо відразу замовити послуги на рік і більш тривалий період.
- Оплата за кількість підключених акаунтів. За такого варіанту зазвичай тарифи ділять на індивідуальні, групові (для невеликих команд, проєктів) і корпоративні. Відповідно ціна також варіюється.
Є й інші типи монетизації, але перераховані зустрічаються найчастіше. Вибір зовнішніх сервісів і тарифів залежать від завдань і бюджету проєкту. Для додаткової економії розгляньте варіанти з семплюванням (актуально для аналітичних систем) або self-hosted.
При self-hosted зовнішню систему (наприклад, Jira) розгортають на власних потужностях компанії. Зазвичай це обходиться дешевше, ніж використання сторонніх ресурсів. З погляду стабільності роботи таке рішення теж іде в плюс. Контроль доступності сервісу та вирішення інфраструктурних питань не залежить від вендора (постачальника послуг). Водночас PM має розуміти, що безпека проєкту в цьому разі повністю «лягає» на його команду фахівців. Утім, про це варто пам’ятати на кожному етапі розроблення, оскільки проблеми в безпеці можуть серйозно вплинути на терміни і кінцеві результати.
Безпека проєкту
«За безпеку необхідно платити, а за її відсутність розплачуватися» – Вінстон Черчилль.
Це той рідкісний випадок, коли цитата на всі 100500 влучає в ціль. Якщо у вашому застосунку «дірки» в безпеці, ймовірність злому і крадіжки даних наближається до 100%. Наслідки подібного? Як мінімум, це вдарить по репутації компанії і призведе до фінансових втрат через відмову клієнтів користуватися ненадійним продуктом. Тож краще на самому початку розробки про це подумати і зробити все правильно.
Що важливо знати PM про безпеку? Про доступи говорили, коли обговорювали можливі проблеми з їх адмініструванням. Зараз зупинимося на двох ключових поняттях у безпеці роботи будь-якого застосунку: хешуванні та шифруванні. У фізичному плані перше – це одностороння функція (hash function), друге – двостороння. У кожної свої алгоритми роботи, але важливо пам’ятати таке: дані під час передавання шифрують, паролі в базі даних хешують.
Для кращого розуміння, навіщо все це потрібно, розглянемо кожну функцію окремо.
Хешування
Процес має такий вигляд:
- Є якийсь рядок, у якому можна представити будь-який об’єкт: текст, гру, картинку тощо.
- Передаємо його в hash function.
- На виході отримуємо невеликий рядок фіксованого розміру – хеш, який записуємо в базу даних (БД). Зворотне перетворення неможливе.
Отримана в такий спосіб інформація займає мало місця в БД, що часом критично на великих проєктах. Також важливим є те, що хеш одного і того ж рядка буде завжди однаковим, скільки б разів не відбувалося перетворення. Головна ж причина, чому при розробці додатків використовують хешовані дані, – їх складно зламати. Так, існують так звані «райдужні таблиці» з великою кількістю всіляких хешів, але на практиці їх застосування малоефективне.
Для прикладу розглянемо класичну схему. Під час реєстрації користувач створив пароль, який система записала в базу даних. Зберігатися там він буде у вигляді хеша. Наступного разу, коли користувач вводитиме свій пароль, він знову буде перетворений за допомогою hash function. Після цього відбувається порівняння отриманого хеша з тим, що знаходиться в базі. Якщо вони збігаються, значить усе гаразд.
Хешування – це просто знахідка для роботи з базами даних. Безпечно, економно і швидко. Майже як шифрування, але тільки в один бік. Утім, це чи не головна відмінність цих двох процесів.
Шифрування
Шифрування можна представити у вигляді такого ланцюжка дій:
- Вихідні дані шифруються за допомогою спеціальних алгоритмів.
- Шифр відправляється за призначенням.
- На виході дані дешифруються і прочитуються.
Вся ідея полягає в тому, що для прочитання вихідної інформації потрібно мати спеціальний ключ. Створюється він у процесі шифрування за допомогою алгоритму: симетричного або асиметричного. Обидва варіанти використовують під час роботи з додатками, але надійнішим вважається асиметричний алгоритм.
У разі симетричного алгоритму для розшифрування і дешифрування необхідний лише один ключ. Основна проблема в цьому процесі – безпечна передача як інформації, так і відмички до неї. «Перехоплення» всіх частин може статися в будь-який момент. В асиметричному алгоритмі з цим справи йдуть надійніше: для шифрування і дешифрування створюються окремі ключі. Наприклад, https і ssl працюють саме за такою схемою. Заволодіти чужими даними в цьому випадку значно складніше, ніж у першому варіанті.
Для максимальної безпеки проєктів обов’язково використовуйте хешування даних, а для їхньої передачі застосовуйте асиметричний алгоритм шифрування.
Кілька корисних порад:
- Забудьте про створення юзерів з ім’ям admin і паролем password (або подібними). Це може виявитися фатальним для вашого проєкту, оскільки ймовірність злому за такого підходу в рази вища, ніж за інших варіантів.
- Дозвольте інтеграцію систем моніторингу в проєкт, щоб розуміти, що відбувається в застосунку. Швидке реагування на нестандартну ситуацію часто запобігає серйозним проблемам надалі.
- Обов’язково вивчіть хмарні рішення для захисту, наприклад AWS Shield, у разі розростання проєкту. Вони не тільки можуть підвищити безпеку, а й полегшити життя проєктному менеджеру.
Головне, що має пам’ятати кожен PM, – не вставляти знайдені флешки в робочий або особистий комп і не «вестися» на фішинг! Ви можете бути дуже крутим спецом із нереальним досвідом, але від секундного помутніння розуму ніхто не застрахований. Тож будьте завжди уважні, щоб не було: «Як таке взагалі можливо? Та я ж ніколи! Та ну ні!»
Замість висновку
– Коли ми точно знатимемо, скільки часу займе проєкт?
– Коли його закінчимо!
Проза життя. Щоб наприкінці для проєкту був хеппі-енд, PM однозначно повинен:
- Розуміти, що таке software architecture.
- Знати, як правильно вибирати зовнішні системи для інтеграції.
- Пам’ятати про безпеку.
Це на додачу до його решти обов’язків: аналізу проєкту і планування робіт, створення команди фахівців, «розгрібання» форс-мажорів тощо. Утім, чим більше скілів і їхня якість, тим вища вартість послуг такого фахівця. Є, про що подумати!
Якщо хочете «доставляти» проєкти точно в строк і забути про переробки, приходьте вчитися на ArchiTech. Це не просто курс про архітектуру та управління технічною командою для менеджерів, а докладна програма про те, як вчасно і якісно постачати складні IT-проекти для всіх PM, BA і Product рівня Middle і вище! Зможете серйозно прокачати технічну експертизу, завдяки досвіду спікерів з RingCentral, Sprintera, Solar Digital, Ciklum, SoftServe, GlobalLogic і Цитрус.