Системний аналітик: все про професію, рівень зарплат та компетенції у 2024 році

Основа якісної розробки – адекватно складені вимоги. Потрібно врахувати побажання замовника та технічні умови. За це відповідає системний аналітик. Розкажемо все про цю професію в ІТ.

• Чим займається системний аналітик
• Скільки заробляють системні аналітики
• Системний чи бізнес-аналітик?
• Як працюють системні аналітики
  • Збір побажань
  • Отримання вимог
  • Розробка системних вимог
  • Обговорення ТЗ
  • Постановка завдань
  • Підсумкова перевірка
  • Основні технічні знання для системного аналітика
    • SQL
    • Бази даних та СУБД
    • Основи UX/UI
    • Інструменти опису API
    • Гнучкі методології
    • Опитування та анкетування
    • Нормативи та стандарти
    • Декомпозиція завдань
    • Конкурентний аналіз
    • Написання документації
    • Оцінка якості
    • Постійна підтримка від наставника та навчального центру
    • Допомога з працевлаштуванням
    • Готове портфоліо до кінця навчання
    • Практика з першого уроку

    Ви отримаєте саме ті інструменти та навички, які дозволять вам знайти роботу

    Чим займається системний аналітик

    Якщо спростити, цей співробітник є сполучною ланкою між замовником ПЗ і командою розробки. Його робота – отримати умови завдання, а потім коректно та технічно грамотно передати її іншим членам команди.

    Він перекладає побажання бізнесу на мову розробників та складає технічне завдання, яке потім ляже в основу проекту.

    На системному аналітиці лежить велика відповідальність. Саме він першим повинен зрозуміти, як працюватиме ПЗ та які завдання вирішувати. Також аналітики вивчають ринок та конкурентів, знаходять інформацію зі сторонніх джерел, а потім формують документацію для проекту.

    Уявіть, що вам потрібно розробити програму автоматизації на виробництві. Замовник знає, які результати вона має давати, але не розуміє, як їх можна досягти.

    За справу береться системний аналітик, який вникає в суть процесів, а потім вирішує, як можна їх реалізувати через ІТ-продукт. Він детально описує, як працюватиме програма, з яких модулів складатися, які кроки проходитиме користувач.

    Свої міркування він оформляє як технічного завдання. Зазвичай це текст і графіка: блок-схеми, діаграми, інколи ж навіть прототипи сторінок.

    Якщо дуже спростити роботу системного аналітика, вийде, що він збирає вимоги, та був пише інструкції для програмістів.

    Скільки заробляють системні аналітики

    На вересень 2024 року на hh.ru опублікували 5237 вакансії системних аналітиків в IT. Їх шукають компанії зі сфери фінтеху, промисловості, держсектора тощо.

    За даними «Хабр.Кар'єрі» за першу половину 2024 року, зарплати системних аналітиків становлять:

    • Мінімальна - 70 000 рублів.
    • Середня - 198 000 рублів.
    • Максимальна – 350 000 рублів.

    Фактично у цій сфері у системних аналітиків найвищі зарплати. Більше платять лише інженерам за даними.

    Системний чи бізнес-аналітик?

    У Росії її часто плутають ці вакансії або змушують одного співробітника виконувати функціонал обох посад. Але хорошим тоном вважають все ж таки розмежовувати ці спеціальності.

    Бізнес-аналітик працює над аналізом та покращенням бізнес-процесів. Він загалом може мати ніякого відношення до IT. Його експертиза побудована навколо специфіки діяльності компанії.

    Наприклад, бізнес-аналітик у будівельному тресті повинен розуміти в тому, як складають кошториси, з чого складається собівартість будівництва, скільки коштує маркетинг у сфері і так далі.

    А системний аналітик у тій же компанії стосуватиметься бізнес-процесів лише в тій частині, де їх потрібно оцифрувати для нового корпоративного програмного забезпечення або додатка.

    Якщо в компанії є обидва ці співробітники, то бізнес-аналітик при розробці сайту на основі вимог замовника продумуватиме клієнтський шлях. Тобто з'ясовує, що і як робитимуть відвідувачі і що їм потрібно.

    Коли це стає відомо, підключають системного аналітика, який продумує власні історії: які кроки можна буде робити на сайті і яким, виходячи з цього, буде інтерфейс і бекенд.

    Так, системний аналітик вирішуватиме, як повинна проходити авторизація і які у неї будуть варіанти, які характеристики мають бути у бази даних і як це відобразити у технічному завданні.

    Фактично, плід праці бізнес-аналітика – процеси компанії. А у системного аналітика якісно спроектовані функції IT-системи.

    Як працюють системні аналітики

    У роботі над проектом вони мають кілька стадій.

    Збір побажань

    Перший крок у роботі системного аналітика – збір інформації від замовника чи представників бізнесу. Ця стадія грає найважливішу роль, оскільки цьому етапі закладаються основи подальшої роботи над проектом. Основним способом отримання інформації є спілкування з ключовими зацікавленими сторонами.

    Системний аналітик проводить зустрічі з бізнес-користувачами, щоб зрозуміти, які процеси вони хочуть автоматизувати, покращити чи створити з нуля.На цьому етапі інформація може передаватися в усному вигляді, тому аналітик має вміти структурувати сказане та фіксувати ключові моменти.

    Наприклад, замовник може розповісти у тому, як відбувається обробка заявок отримання послуг, а аналітик записує кожен етап процесу, задаючи уточнюючі питання.

    Отримання вимог

    На цій стадії він взаємодіє із бізнес-аналітиками. Вони надають структуровані вимоги та описи бізнес-процесів. А системний аналітик вже на їх основі починає продумувати, які функції системи потрібно реалізувати, щоби підтримувати ці процеси.

    Наприклад, бізнес-аналітик передає, як у компанії обробляють замовлення. На цій основі системний аналітик створює функціонал: процес оформлення покупки, варіанти доставки, підтвердження, сповіщення користувачів. Все це має бути чітко прописано у вимогах до системи, щоб розробники могли розпочати реалізацію.

    Розробка системних вимог

    Тут необхідно розуміння архітектури системи та технічних процесів розробки. Потрібно деталізувати функціональні вимоги та продумати архітектуру програми.

    Системний аналітик вирішує, як взаємодіятимуть основні компоненти системи: фронтенд, бекенд та база даних.

    Також він обирає відповідні технології для реалізації проекту. Наприклад, для створення інтерфейсу (фронтенду) можуть вибирати серед сучасних фреймворків - React або Vue.js, для серверної частини (бекенда) - відповідні технології, такі як Node.js з швидкою продуктивністю або Java - для максимальної надійності, знаходять найбільш підходящі бази даних та СУБД.

    Аналітик також розробляє вимоги до REST API, визначаючи необхідні ендпоінти, методи HTTP, формати запитів та відповідей.На основі зібраних даних складають технічне завдання, що докладно описує всі аспекти системи.

    Обговорення ТЗ

    Готове технічне завдання обговорюють із командою. У нараді беруть участь усі співробітники: розробники, тестувальники, проектний менеджер, можливо, DevOps-інженери. Обговорення допомагає виявити потенційні ризики, розглянути можливі доопрацювання та покращення, а також уточнити технічні деталі.

    На цьому етапі системний аналітик може змінити вимоги, якщо команда знаходить, що якісь моменти можуть бути реалізовані простіше або, навпаки, потребують більш детального опрацювання.

    Постановка завдань

    Після узгодження вимог, системний аналітик (у деяких випадках проектний менеджер) створює завдання у планувальнику завдань, наприклад, у Jira. На цій стадії декомпозують проект. Кожну функцію системи розбивають окремі завдання для розробників, тестувальників та інших членів команди.

    В описі вказують усі необхідні вимоги та посилання на технічне завдання, щоб розробники могли відразу розпочати роботу.

    Підсумкова перевірка

    Після виконання завдань розробниками системний аналітик перевіряє результати. Він проводить тестування функціоналу відповідність вимогам технічного завдання. Якщо виявляються відхилення чи помилки, завдання повертається доопрацювання.

    Основні компетенції системного аналітика

    Щоб виконувати свою роль у команді розробки, системному аналітику необхідно мати тверді технічні знання та практичні навички.

    Основні технічні знання для системного аналітика

    Почнемо з технічного бекґраунду. Це загальні знання зі сфери IT, які мають бути вивчені системному аналітику.

    SQL

    SQL (Structured Query Language) — мова запитів до баз даних та один із ключових інструментів системного аналітика. Володіння SQL необхідно взаємодії з базами даних, вилучення даних та його аналізу.

    Наприклад, аналітик повинен вміти формувати прості запити для отримання інформації про користувачів системи або транзакції.

    Бази даних та СУБД

    Бази даних - основа будь-якої інформаційної системи, тому він повинен розбиратися в основних типах баз даних та системах управління (СУБД).

    Існує два основні види баз даних: реляційні та нереляційні. Реляційні бази даних, такі як MySQL та PostgreSQL, засновані на табличній структурі та дозволяють зберігати дані у вигляді пов'язаних таблиць. Нереляційні бази даних, такі як MongoDB, працюють із даними у вигляді документів, графів або ключ-значення.

    Аналітик повинен розуміти, коли застосовувати ту чи іншу СУБД, а також, як вони функціонують у рамках системи. Наприклад, для проекту, де потрібно обробляти велику кількість структурованих даних, краще підійдуть реляційні бази даних, а для систем, де дані мають складнішу структуру, перевагу можна надати нереляційним СУБД.

    Основи UX/UI

    Системному аналітику необхідне розуміння основ UX/UI (User Experience та User Interface) для проектування зручних та функціональних інтерфейсів. Не буде зайвим і володіння інструментами прототипування, наприклад Balsamiq. З їх допомогою створюють прості прототипи інтерфейсів, які використовують для попереднього обговорення із замовниками та командою розробки.

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

    Системний аналітик повинен вміти впроваджувати ці правила у розробці та оцінювати продукт за ними.

    Інструменти опису API

    Вони дозволяють організувати обмін даними між різними компонентами системи чи зовнішніми системами. Аналітик має розбиратися в їхній архітектурі.

    Йому необхідно вивчити методи роботи протоколів HTTP, REST та SOAP, які забезпечують механізми взаємодії з API. Також системний аналітик повинен мати уявлення про формати обміну даними XML та JSON. Це потрібно для коректної інтеграції різних систем.

    Йому потрібно розуміти структуру протоколів та форматів, щоб коректно описувати вимоги до API.

    Гнучкі методології

    Agile та Scrum - найпоширеніші методології розробки програмного забезпечення, орієнтовані на гнучке управління проектами. Системний аналітик повинен добре розуміти їхні принципи, щоб ефективно взаємодіяти з командою та адаптувати процес розробки до змінних умов.

    Йому важливо вміти створювати вимоги в рамках Agile, де документація має бути максимально гнучкою та адаптованою під зміни.

    Загальні навички для системного аналітика

    Тут йтиметься про практичні навички, на яких будується робота.

    Опитування та анкетування

    Як ми вже писали, перше завдання системного аналітика - збирання інформації від замовників та користувачів системи. Для цього він має вміти проводити інтерв'ю та правильно готувати питання. Вони повинні допомогти визначити ключові питання, які допомагають зрозуміти бізнес-процеси та проблеми.

    На практиці системний аналітик працює з анкетами та опитуваннями, аналізує та систематизує результати.

    Нормативи та стандарти

    Працюючи над проектами системний аналітик враховує нормативно-правові акти, регулюючі діяльність компанії чи галузі.Наприклад, при розробці банківських систем необхідно пам'ятати про вимоги законодавства щодо захисту персональних даних та фінансової інформації.

    Не менш важливо вміти аналізувати та приймати внутрішні регламенти компанії.

    Декомпозиція завдань

    Декомпозиція - процес розбиття складних завдань на прості елементи, які легше реалізувати. Системний аналітик повинен уміти розбирати вимоги та уточнювати їх, щоб команда розробників могла чітко розуміти, що саме потрібно зробити.

    Також він повинен вміти виявляти вузькі місця у поточних системах, які можуть уповільнювати їхню роботу або знижувати ефективність. Наприклад, якщо певний модуль обробляє запити надто повільно, аналітику потрібно виявити причину цього та запропонувати рішення.

    Конкурентний аналіз

    За допомогою аналізу конкурентів можна виявити оптимальні рішення на ринку та запропонувати їх для реалізації у своєму проекті. Системний аналітик повинен досліджувати, що застосовують у конкурентів, які технології використовують та які функції надають користувачам.

    Написання документації

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

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

    • Постійна підтримка від наставника та навчального центру
    • Допомога з працевлаштуванням
    • Готове портфоліо до кінця навчання
    • Практика з першого уроку

    Ви отримаєте саме ті інструменти та навички, які дозволять вам знайти роботу

    Оцінка якості

    Системний аналітик повинен вміти оцінювати, наскільки продукт відповідає вимогам, як він працює з погляду продуктивності, безпеки та зручності використання.

    Для цього аналітик спирається на працю фахівців QA-інженерів. Але найчастіше і самостійно перевіряє чи функції системи працюють коректно і чи немає помилок, які можуть негативно вплинути на кінцевий результат.

    Системний аналітик: що робить, скільки отримує і як ним стати

    Системний аналітик допомагає оптимізувати та автоматизувати роботу компанії та її підрозділів. Цей фахівець розуміється на менеджменті, економіці та інформаційних технологіях — допомагає скоординувати процес розробки програмного забезпечення так, щоб результат був максимально продуктивним.

    Розповідаємо, чим займається системний аналітик, що він повинен знати та вміти, скільки заробляє, як увійти до професії та які доступні кар'єрні можливості.

    Дякуємо за допомогу у підготовці матеріалу Ксенію Шипіну, системного аналітика Skyeng та викладача курсу «Системний аналітик» у Нетології.

    Ксенія Шипіна

    Системний аналітик Skyeng

    Системний аналітик – IT-професія широкого плану

    Системний аналітик — це фахівець, який вивчає бізнес та визначає, як можна зробити його ефективнішим за допомогою впровадження інформаційних систем.

    Його можна назвати посередником між замовником – керівництвом компанії – та виконавцем – розробником.

    Підсумок такої співпраці – програмний продукт.

    Таке визначення близьке до істини, але не універсальне. У проблеми трактування є кілька причин.

    Основна причина – відмінності у вимогах різних компаній до фахівця.

    Інша причина — різниця у розвитку IT-ринків у Росії та у світі.Вперше термін «системний аналіз» запровадила 1948 року некомерційна організація RAND, яка у 1956 році випустила книгу на цю тему. У 1959 році американські підприємці Рой Натт і Флетчер Джонс заснували першу компанію з розробки програмного забезпечення - Computer Sciences Corporation. І багато практик задумалися про те, що основи системного аналізу можна використовувати в розробці.

    Це дало свої плоди – попит на системний аналіз почав зростати. У 1976 році було розроблено технологію Waterfall, що дозволяє оптимізувати процес розробки ПЗ.

    У Росії її країнах ближнього зарубіжжя розвиток IT-ринку почався пізніше. Розробка перших програм для комерційного використання ЕОМ стартувала лише 1980 року. А індустрія інформаційних технологій почала розвиватися лише 1990-х — після поширення перших ПК.

    Протягом тривалого часу на російському ринку не було кузні кадрів. Системні аналітики почали з'являтися в Росії на початку 2000-х, а професійні стандарти з'явилися лише до 2014 року.

    Професія системного аналітика остаточно оформилася як самостійна і стала затребуваною з кількох причин:

    • При зародженні ІТ-ринку виділеної ролі аналітика не було, але потреба у системному аналізі була присутня завжди. Найчастіше аналіз виконував суміжний фахівець, але завжди успішно.
    • Зростання конкуренції на ринку ПЗ теж вплинув. З різних причин багато проектів завершувалися невдало: компанії вкладалися в незатребувані рішення через непорозуміння між замовником розробки та виконавцем.Так виникла потреба у фахівцях з хорошим технічним бекграундом та розвиненими soft skills, які можуть правильно зрозуміти біль бізнесу та оптимізувати процес розробки.
    • Ускладнення програм зіграло свою роль — для грамотної інтеграції програмного забезпечення потрібні вузькоспеціалізовані фахівці.

    Чим займається системний аналітик і що він має вміти

    Основне завдання системного аналітика – розробка інформаційної системи, яка відповідає потребам компанії та дозволяє налагодити бізнес-процеси. Він розробляє список завдань і доносить їх команді так, щоб у колег було чітке уявлення про цілі та методи їх досягнення.

    Що робить системний аналітик:

    • збирає та аналізує вимоги вихідних програм, проводить інтерв'ю із замовником;
    • погоджує вимоги та керує їх змінами, включаючи моніторинг змін вимог для запобігання протиріч;
    • складає проектну, технічну, користувальницьку документацію, фіксує потоки інформації, щоб уникнути плутанини;
    • презентує роботу замовнику;
    • синхронізує контекст команди та замовника: забезпечує якісну комунікацію, зводить до мінімуму конфлікти.

    Для виконання робочих завдань спеціаліст повинен володіти певними компетенціями:

    • розуміти базові засади розробки ПЗ;
    • вміти визначати межі систем та зони їхньої відповідальності - для аналізу можливостей та обмежень;
    • знати, як виділяти підсистеми та їх функції;
    • вміти знаходити явні та неявні вимоги – для пошуку рішень;
    • мати навички моделювання — для візуалізації процесів.

    Процес розробки – це постійний обмін інформацією. Щоб правильно запитувати та ясно доносити її, системному аналітику важливо розвивати і soft skills.

    У різних сферах висувають різні вимоги до системного аналітика.

    На прикладі вакансій розглянемо вимоги роботодавців у різних галузях.

    У банківській сфері системного аналітика знадобиться розуміння бухгалтерського обліку, економіки, а також знання інформаційної безпеки для аналізу додаткових вимог до банківського ПЗ.

    У рітейлі при автоматизації процесів часто використовують клієнт-серверні системи, тому системний аналітик повинен розуміти відповідні вимоги та архітектуру. Досвід розробки прототипів допоможе створювати інтерфейси для зручного спілкування користувача і програми.

    System Analyst Roadmap або що потрібно знати системному аналітику

    Вирішив і собі структурувати необхідні знання для читачів. Що ж взагалі необхідно знати системному аналітику у 2024 році. І хто це взагалі такий?

    Якщо коротко, Системний аналітик розробляє вимоги до програмного забезпечення.

    Етапи кар'єри системного аналітика

    1. Стажер аналітик
    2. Молодший системний аналітик (junior)
    3. Системний аналітик (middle)
    4. Старший системний аналітик (senior)
    5. Провідний системний аналітик (Lead)
    6. Керівник відділу системного аналізу
    7. Вихід із аналітики: системний архітектор, технічний керівник проектів, фріланс або створення своєї команди розробки.

    Для початку я вирішив подивитися, скільки взагалі вакансій на майданчиках розміщено. Для зручності опишу, що я побачив на hh.ru. Вакансій системного аналітика трохи більше ніж 5.000. Десь пишуть про гібрид системного та бізнес-аналітик, десь даних чи будь-який схожий франкенштейн із завдань ПМ та СА/БА, але опис +- схожий. Якщо розділяти ці 5к за роками досвіду роботи, то це виглядає наступним чином:

    • Від 3 до 6 років 2 507
    • Від 1 до 3 років 2 162
    • Немає досвіду 235
    • Понад 6 років 188

    Подивилися, подумали, давайте підемо далі, що пропонують аналітики у своїх ключових вміннях. Гістограма ключових навичок з резюме системних аналітиків на hh.ru виглядає так. Тобто. бачимо що в основному з найпопулярніших hard skills це sql і powerpoint і більшість впевнені, що вони хороші управлінці) Але складати собі якийсь план навчання або бігти тикати менш популярні вміння у своє резюме, щоб вас помітили, немає сенсу.

    Тому, подивимося все ж таки на карту навичок:

    Отже, ми з вами бачимо, що є основні гілки, які бажано (іноді обов'язково) знати аналітику, хоча б загалом, це:

    • архітектури ПЗ;
    • програмне забезпечення;
    • інструменти;
    • методології ведення розробки та роботи команди;
    • робота веб-додатків та їх інтерфейси;
    • стандарти ведення документації;
    • протоколи;
    • мови моделювання та проектування. Деякі пункти я вирішив докладніше розписати, це такі як: Архітектура ПЗ та її види, види інтеграції, методології управління проектами, а також мови моделювання/проектування. Якщо треба буде описати решту, допишемо!)
      1. Архітектура програмного забезпечення (ПЗ) - це структура та організація системи, яка визначає її компоненти, взаємодії між ними та їх відносини із зовнішнім середовищем. Також можна сказати, що Архітектура є основою для подальшої розробки ПЗ, визначає його функціональність, надійність, масштабованість, продуктивність та можливості розширення. Важливою частиною архітектури є вибір технологій для її реалізації. Існує безліч різних технологій, включаючи мови програмування, бази даних, фреймворки та бібліотеки.Вибір технологій повинен ґрунтуватися на конкретних вимогах додатку, його цілі та обмеженнях. _{📎 Розробка архітектури для чайників. Частина 1 (https://habr.com/ua/post/658145/) / Частина 2 (https://habr.com/ua/post/658151/)Архітектура ПЗ: різниця між архітектурою та проектуванням (https://medium.com/nuances-of-programming/архітектура-по-різниця-між-архітектурою-і-проктуванням-204f2e7aeff)}Мікросервісна архітектура це підхід, яким програма розділена на безліч невеликих сервісів, кожен з яких відповідає за певну функцію. Вона забезпечує гнучкість, відносну незалежність компонентів та масштабованість. Однак, така архітектура може вимагати додаткових зусиль у супроводі та управлінні сервісами. Монолітна архітектура – ​​це великопланувальна структура з єдиним кодом, який включає всі компоненти додатка. Вона забезпечує простоту в розробці та тестуванні, але часто має проблеми масштабування та залежності між компонентами. Клієнт-серверна архітектура – ​​це модель, у якій клієнти у своїх пристроях використовують віддалений сервер обмінюватись інформацією. Вона забезпечує хорошу масштабованість та безпеку, але може мати проблеми з продуктивністю через віддалений доступ. Клієнт-серверна та мікросервісна архітектура часто є найкращим вибором для великих проектів, які вимагають масштабованості та гнучкості. Монолітна архітектура добре підходить для невеликих проектів чи простих систем. _{📎Порівняння мікросервісної та монолітної архітектур (https://www.atlassian.com/ru/microservices/microservices-architecture/microservices-vs-monolith)Мікросервіси чи моноліт.Яку архітектуру вибрати при розробці складного додатку для великого бізнесу (https://www.itweek.ru/management/article/detail.php?ID=223826)Клієнт-серверна архітектура в картинках (https://habr.com/ua/post/495698/)}
         Так самоіснує кілька видів інтеграцій систем, у тому числі:
         1. Інтеграція API (Application Programming Interface) – це спосіб зв'язування різних програмних програм через їх програмні інтерфейси.
         2. Інтеграція через файлові формати – це спосіб інтеграції, що базується на конвертуванні файлів у різні формати для обміну інформацією між програмним забезпеченням.
         3. Інтеграція баз даних – це спосіб обміну інформацією між різними базами даних на основі протоколів обміну.
         4. Інтеграція за допомогою платформи – це спосіб зв'язування різних програм через одну платформу.

    Спосіб інтеграції залежить від вимог конкретного проекту, але важливо вибрати найбільш підходящий варіант для ефективної роботи програми в цілому.

    1. Методологія управління проектами - це стандарт ведення проектів від старту до завершення, який включає принципи роботи (способи оцінки термінів, постановки завдань і передача їх між співробітниками, збір вимог, способи узгоджень і т.д.)

    Найбільш поширені методології управління проектами:

    • Waterfall (Водоспадна модель)
    • Agile (Гнучка модель)
      • SCRUM
      • Kanban
      • Lean і тд.

      Методи управління проектами:

      • Critical part method / Метод критичного шляху
      • Critical chain project management / Метод критичного ланцюга
      • та ін.

      Етапи управління проектом:

      • Ініціація
      • Планування
      • Виконання/Розробка
      • Моніторинг/Тестування
      • Завершення

      Водоспадна чи каскадна модель розробки програмного забезпечення (waterfall, водоспад) - Це модель процесу розробки ПЗ, в якій процес розробки виглядає як потік, що послідовно проходить фази аналізу вимог, проектування, реалізації, тестування, інтеграції та підтримки.
      Водоспадна модель має на увазі, що перехід від однієї фази створення продукту до іншої відбувається тільки після повного завершення попередньої фази і переходів назад і перекриття фаз не відбувається.

      Методологія Agile – це гнучкий підхід до розробки програмного забезпечення, який допомагає командам швидше та з меншими проблемами постачати цінність клієнтам. Замість випускати весь продукт повністю, команда, яка дотримується принципів Agile, виконує роботу в рамках невеликих, але зручних інкрементів. Вимоги, плани та результати оцінюються безперервно, завдяки чому команди можуть швидко реагувати на зміни.
      Процес роботи з Agile ділиться на ітерації – короткі цикли два-три тижні. Кожен цикл розв'язує серію завдань.

      _{Зрозуміти в чому різниця між Agile та Waterfall допоможе стаття - Agile vs. Waterfall: суть та відмінності методологій розробки (https://web-academy.ua/blog/upravlenie/agile-vs-waterfall)}

      UML (Unified Modeling Language – уніфікована мова моделювання). Це графічна мова, яка за допомогою діаграм та схем описує різноманітні процеси та структури. Ця мова в основному використовується для розробки програмного забезпечення. Однак він також використовується для опису робочих ролей, організаційних функцій та бізнес-процесів.

      Типи UML-діаграм:

      • Діаграма розгортання
      • Діаграма пакетів
      • Діаграма профілів
      • Діаграма класів
      • Діаграма об'єктів
      • Діаграма компонентів
      • Діаграма композитивної структури
      • Діаграма діяльності
      • Діаграма варіантів використання
      • Діаграма станів
      • Діаграма взаємодій
      • Діаграма послідовності
      • Діаграма комунікації
      • Діаграма огляду взаємодії
      • Діаграма синхронізації

      BPMN (Business Process Modeling Notation - Нотація моделювання бізнес-процесів) - Це спосіб, що використовується для ілюстрації / описи бізнес-процесів, тобто BPMN - це графічне уявлення бізнес-процесів. Даний метод наочно відображає докладну послідовність бізнес-операцій та інформаційних потоків, необхідних для завершення процесу.

      Можна сказати, що BPMN є частиною двох найважливіших складових:

      • Business Process Management (BPM) – управління бізнес-процесами або процесне управління. Іншими словами, BPM – це концепція управління організацією, що представляє діяльність підприємства як сукупність процесів.
      • Business Process Modeling System (BPMS) – це інструменти для виконання створених вами моделей. Це може бути Bizagi, Camunda, ELMA та ін.

      У нотації BPMN виділяють п'ять основних категорій елементів:

      • елементи потоку (події, процеси та шлюзи);
      • дані/date (об'єкти даних та бази даних);
      • сполучні елементи (потоки управління, потоки повідомлень та асоціації);
      • зони відповідальності (пули та доріжки);
      • Artefact (артефакти/виноски).

      У висновку, хочу сказати, у аналітиків дивні завдання, нестабільне навантаження, рутинні будні та купа потрібних навичок, але завдяки roadmap можна хоча б зрозуміти що в роботі може знадобитися!)