Як я за місяць створив застосунок для оцінки ризиків задач у Jira, не знаючи JavaScript
Привіт! Мене звати Максим, і я — UX/UI дизайнер, який вирішив кинути виклик самому собі та зануритися у світ розробки. Після створення Type Switch для macOS (про що я розповідав у DOU раніше), мені захотілося ще більше не висипатися та спробувати щось нове.
Одного дня я подумав: «А чому б не зробити щось для Jira?» , тим більше кожного дня я стикаюсь з ним в своїй роботі. Так народилася ідея Risk Radar — інструменту, який допомагає оцінювати ризики виконання (або невиконання) задач у Jira.
Проблема була лише одна: я не знав JavaScript і майже нічого не розумів у документації Jira. Все, що я робив до цього, було пов’язано з платформою Apple та мовою програмування Swift. Але коли це когось зупиняло?
Як народилася ідея створення Risk Radar
Управління ризиками виконання завдання — критичний аспект будь-якого проєкту. Часто команди стикаються з проблемами через недооцінку або ігнорування ризиків під час створення задач (іssues), що може призвести до зриву дедлайнів або збільшення бюджету. Стандартні підходи до оцінки ризиків вимагають аналітики та часу, що не завжди зручно для динамічного середовища роботи та розробки.
Я часто стикався з тим, що в командах ризики проєктів оцінюються або «на око», або взагалі ігноруються. Зазвичай діалог виглядав так:
— Які ризики у цієї задачі?
— Ну, треба подивитися...
— Добре, а як оцінити ризик?
— Ну, якось відчути...
Що таке «якось відчути», мені було незрозуміло. Виявилося, що багатьом розробникам і менеджерам не вистачає простого й наочного способу оцінки ризиків задач. Так з’явилася ідея створити інструмент, який:
- Дозволяє швидко оцінити ризик задач за кількома критеріями.
- Інтегрується в Jira без зайвих налаштувань.
- Надає зрозумілий індикатор ризику.
А почалося все з гуглення. Багато гуглення. Спочатку я просто вивчав, як працюють сторонні застосунки для Jira, як вони інтегруються та як взагалі можна з ними працювати. Проаналізувавши все це, я вирішив створити щось максимально просте — інструмент, який буде розраховувати ризик задач за трьома параметрами.
Звучить просто? Та звісно, поки ти не починаєш реалізовувати все це кодом.
Розробка, де починається справжня магія... і баги
Перше, з чим я зіткнувся, — це розробка логіки оцінки ризиків та їх категорій. Я хотів зробити її не просто механічним підрахунком значень, а такою, що реально відображає ризики, з якими команди стикаються при створенні та оцінці задач у Jira. Було важливо, щоб оцінка ризику відповідала реальним сценаріям, а не була формальним підсумком цифр.
Вирішив зробити так:
- Кожен параметр оцінки ризику — ймовірність, вплив, складність (про них трохи далі) оцінюється за шкалою від «1» до «10».
- Кожен параметр має свою вагу та коригувальні коефіцієнти.
- Фінальний ризик розраховується за формулою, яка враховує всі ці показники.
Наступним викликом було налаштування збереження даних у Jira через API. Спочатку запити здавалися складними, оскільки вимагали розуміння структури та способу роботи API Jira. Проте з часом я розібрався з цим і зміг налаштувати збереження даних у властивостях задачі.
Розробка застосунків для Jira має два основні шляхи:
- Forge — хмарна платформа від Atlassian, яка обіцяє простоту та безпеку. Вона ідеально підходить для швидкої розробки без необхідності підтримувати власний сервер.
- Connect — більш гнучка платформа, яка вимагає власного серверного хостингу. Вона надає повний контроль над інфраструктурою, але вимагає більше зусиль для налаштування.
Я обрав Forge, оскільки Atlassian заявляли, що це «просто». Мій досвід показав, що це не зовсім так.
Спочатку я встановив Forge CLI, створив базовий застосунок і спробував вивести простий «Hello, world!». Це зайняло два дні — не тому, що я повільний, а тому, що документація Atlassian — це квест, особливо для повного новачка. Але з часом я розібрався і з цим.
У фіналі Risk Radar використовує такий стек технологій:
- Forge Kit UI для створення інтерфейсу.
- React для побудови UI.
- Forge Storage API для збереження оцінок ризиків.
Як це працює
Принцип роботи простий: під час створення або редагування задачі (issue в термінології Jira) застосунок додає інтерфейс із налаштуваннями. У ньому можна оцінити ризик задачі за трьома ключовими параметрами:
- Ймовірність проблеми — наскільки ймовірно, що задача викличе проблеми.
- Вплив на проєкт — який вплив матиме проблема на проєкт, якщо вона виникне.
- Складність виправлення — наскільки складно буде виправити проблему, якщо вона виникне.
Кожен параметр має три рівні: низький, середній або високий. Risk Radar бере ці оцінки, застосовує ваги та розраховує фінальний рівень ризику, який відображається у вигляді числового значення (від 1 до 10) та індикатора (низький, середній або високий ризик).
Крім того, застосунок зберігає оцінку у конкретній Jira issues, додає коментар до завдання з результатами розрахунку та дозволяє змінювати оцінки ризиків у будь-який момент. Це дає змогу адаптуватися до нестандартних ситуацій, якщо формула розрахунку потребує коригувань.
Формула розрахунку ризику
Risk Radar використовує формулу для розрахунку рівня ризику задачі та додаткові коригувальні коефіцієнти.
Вона враховує три фактори:
Ймовірність проблеми (Low = 1, Medium = 2, High = 3)
Вплив на проєкт (Low = 1, Medium = 2, High = 3)
Складність вирішення (Low = 1, Medium = 2, High = 3)
Основна формула:
ризик = (ймовірність * 1.5) + (вплив * 1.2) + (складність)
Коригувальні коефіцієнти:
Якщо складність = Low, ризик зменшується на 15% (×0.85).
Якщо вплив = High та складність ≠ Low, ризик збільшується на 15% (×1.15).
📌 Приклад розрахунку
Припустимо, що:
Ймовірність = High (3)
Вплив = Medium (2)
Складність = Low (1)
Розрахунок без коригувань:
ризик = (3 × 1.5) + (2 × 1.2) + (1 × 1) = 4.5 + 2.4 + 1 = 7.9
Коригування: оскільки складність = Low, множимо на 0.85:
ризик = 7.9 × 0.85 = 6.7
Таким чином, підсумковий ризик для цієї задачі — 6.7.
Ця формула допомагає швидко оцінити ризики задачі та ухвалити рішення:
✅ Низький ризик
⚠️ Середній ризик
🚨 Високий ризик
Я надав найбільшу вагу ймовірності та впливу (розрахунок їх коригувальних відсотків має свій алгоритм), оскільки саме ці параметри мають найбільший вплив на ризик. Складність виправлення також враховується, але менше, адже складне завдання не завжди означає високий ризик. Наприклад, якщо задача (issues) має низьку ймовірність і невеликий вплив, навіть висока складність виправлення не зробить її критичною.
Сподіваюся, тепер хоч щось зрозуміло!
Виклики під час розробки
Проблема № 1: дефіцит нормальних прикладів у документації Я хотів зробити кастомний UI, а в документації було написано майже буквально: «Використовуйте UI Kit».
Я використав. UI Kit дуже обмежений. Наприклад, я хотів створити кастомний компонент для вибору ризиків, але він не давав такої можливості, навіть мінімальних підналаштувань, принаймні «з коробки».
Після кількох днів боротьби я вирішив: «До біса, я зроблю все це на Custom UI!» Але... зробив на UI Kit, вирішивши йти шляхом найменшого спротиву.
Проблема № 2: неактуальна та розрізнена документація. Atlassian Forge є відносно новою платформою, і документація іноді буває неповною або неактуальною.
Я витратив кілька днів на з’ясування, що Forge API має три способи зберігання даних, і кожен має свої нюанси. Наприклад:
- Forge Storage API: для зберігання даних, пов’язаних із конкретним застосунком або користувачем.
- Jira Properties API: для зберігання даних у властивостях issue.
- External Storage: використання зовнішніх баз даних або сервісів (наприклад, AWS DynamoDB).
Кожен спосіб має свої обмеження (наприклад, обмеження на розмір даних або частоту запитів), і це не завжди чітко описано в документації.
Проблема № 3: неочевидні обмеження Forge. Forge має обмеження на доступ до глобальних змінних, і код потрібно писати з урахуванням цього. Довелося переробляти частину логіки, щоб дані правильно оновлювалися та не губилися після перезавантаження сторінки.
Обмеження на частоту запитів: Forge має обмеження на кількість запитів до API, що може вплинути на продуктивність застосунку.
Обмеження на розмір даних: Наприклад, Forge Storage API має обмеження на розмір збережених даних (до 32 КБ на запис).
Хоча тут скоріше навіть не в цьому проблема, а, як я вже зазначав, все це рознесено по різним документам та форумам, а не зібрано в одному місці.
Досвід публікації в Atlassian Marketplace
Хоч це й не винесено в заголовок, але хочу поділитися своїм досвідом публікації застосунку. Можливо, це буде корисно, особливо в порівнянні з розміщенням застосунків в Apple App Store.
В Apple App Store процес розгляду та затвердження застосунків зазвичай займає
З Atlassian Marketplace досвід був зовсім іншим. Розгляд та затвердження Risk Radar зайняли майже два тижні, що довше, ніж у Apple, але різниця в підході була колосальною. Оскільки це була моя перша публікація в Marketplace, багато чого було незрозумілим. Проте людина, яка робила рев’ю мого застосунку, виявила повну емпатію, залученість та реальне бажання допомогти. Вона детально пояснювала, що потрібно виправити, а не просто скидувала посилання на документацію.
І що мене приємно здивувало: коли застосунок нарешті відповідав усім стандартам Atlassian і був схвалений, мені надіслали повідомлення з привітаннями. І завершувалося воно словами: «Слава Україні!». Що дуже приємно.
Висновок
Перший реліз Risk Radar відбувся через півтора місяці після початку розробки. Він став для мене не просто застосунком, а досвідом, який показав, що, маючи впевненість, навіть з нульовим досвідом можливо досить швидко себе пробустити та створити щось нове та корисне.
Якщо ви маєте ідею, але не знаєте, з чого почати — просто почніть. Навіть якщо це означає кілька безсонних ночей та сотні прочитаних сторінок документації. У кінці кінців, це того варте.
Якщо у вас є ідеї для покращення, я завжди відкритий до нових пропозицій!
📥 Встановити Risk Radar
🎥 Подивитись демо
📖 Документація та інструкції
Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.
Klauss Manner
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів