«Якщо ви думаєте, що Jira лікує все, — ви помиляєтесь». Як Приватбанк за рік перевів тисячі розробників на нові рейки

Скільки коштує перевести 2000 IT-спеціалістів на нову систему за рік, чому техніка — це лише 20% успіху, і як один адміністратор тримає 3000 користувачів. Конспект виступу Сергія Чеканова, керівника IT PMO Приватбанку, на Strategic Project Conference 2026 — чесно, з граблями і без прикрас.

«Це буде вперше, коли у нас на конференції розповідають не про Microsoft, а про Jira»

Так виступ анонсував організатор. Історично конференція називалася Microsoft Project Conference — вендор був спонсором, а компанії-учасниці розповідали кейси зі свого стеку. Цього разу — інша історія: масштабна міграція одного з найбільших банків країни на продукт Atlassian.

Спікер — Сергій Чеканов, керівник IT PMO Приватбанку. 18 років в IT.

Одразу на старті він поставив залу два питання: хто очолював міграцію у своїй організації — і скільки разів. Один раз — багато рук. Двічі — менше. Тричі — одиниці. «Я думав, мене одного прокляли», — пожартував спікер. Саме третя міграція, за його словами, була найцікавішою і найскладнішою. Не тому, що Jira — унікальний чи надскладний продукт. А тому, що всієї гостроти додав масштаб.

Точка А: «Насправді ми й до Jira працювали нормально»

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

«Якщо ви думаєте, що Jira лікує все, — ви помиляєтесь».

До Jira робота трималася на двох системах: ОУП (офіс управління проєктами, де працювали проєктні менеджери й власники портфелів) і Privat Project (де сиділа вся команда IT). Плюс Confluence для документації й десятки інших банківських систем навколо — звітність, внутрішні контролі, ризики. Проблема була не в тому, що інструменти не працювали. Проблема була в тому, що інформація була розпорошена: аналітика в одному місці, ініціативи в іншому, айтішники в третьому, а замовники й спонсори бачили все лише в презентаціях і звітах.

До того ж дві системи були морально — не технічно, а саме морально — застарілими. Офіційний термін експлуатації однієї сягав одинадцяти років, іншої — дев’яти. А на горизонті вже стояла Agile-трансформація банку, під яку старі інструменти не адаптувалися. Наприкінці 2024 року рішення дозріло: змінюємось.

Масштаб виклику в цифрах

Щоб зрозуміти, чому «нічого унікального» перетворилося на серйозний виклик, достатньо подивитися на цифри:

• ~2000 IT-співробітників, для яких Jira планувалася основним і єдиним робочим інструментом.
• ~500 проєктів та ініціатив у середньому (сотня «живих» ініціатив і близько 400 проєктів у різних стадіях).
• ~100 команд.
• ~1300 технічних завдань щомісяця.

«Те, що ти робиш у компанії на 100 чи 2000 людей, — це не те саме, що зробити на 10 чи 20 тисяч. Це геть інша історія», — так організатор сформулював різницю ще до виступу. І весь кейс Сергія — ілюстрація цієї тези.

Масштаб виклику в цифрах: ~2000 IT-співробітників, ~500 проєктів та ініціатив, ~100 команд, ~1300 технічних завдань щомісяця. Слайд із презентації Сергія Чеканова.

Найскладніше питання звучало не «Що купити?», а «Як це організувати?»

Якщо вірити рекламі, Jira — універсальна система. Якщо вірити практиці — це конструктор. І саме в цьому головна проблема.

Логіка просторів вийшла така: окремий простір під портфоліо проєктів (усі офіційно ініційовані проєкти), окремий — під ініціативи (усі «забаганки бізнесу» через єдину форму, які опрацьовують BRM-менеджери й вирішують, помре ідея чи переродиться в проєкт), проєктні спейси (де ПМи будують дорожні карти) і тімспейси (де команди роблять безпосередню роботу). Усе — в одній системі, зі зв’язками, які дозволяють показати дорожню карту незалежно від того, де фізично лежать задачі.

«Універсальні схеми, що підійшли всім». Спойлер: не підійшли

Ідеться про чотири базові сутності, з якими стикається кожен, хто впроваджує Jira:

• Ієрархія задач — від картки проєкту нагорі до тем, майлстоунів, епіків, сторі й сабтасок унизу. ПМ здебільшого не працює з нижніми рівнями, але бачить і контролює їх завдяки зв’язкам.
• Типи задач — на момент виступу їх у банку 36. Чеканов поділив їх на чотири категорії: ієрархічні (виключно для структури), універсальні (сторі, таски, сабтаски — тут 90% усієї роботи), профільні (адмінські, інциденти, вразливості, дизайн) і процесні (approval-и релізів, патчів, ресурсів).
• Workflow — саме тут було найскладніше, бо це і є побудова правильного процесу розробки.
• Дозволи та доступи — з тисячами користувачів без контролю нікуди.

Окремо спікер зупинився на дозволах — і назвав цю частину найнесподіванішою.

Революція, яка виявилася психологічною, а не технічною

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

Jira цю логіку перевернула. Один зі стейкхолдерів наполіг зробити все прозорим:

«А чого ми ховаємося? Від кого? Ви що там, таємні справи робите у своїх просторах? Давайте будемо відкритими».

Тепер за замовчуванням усі простори відкриті на перегляд: новий співробітник заходить у Jira й бачить, хто чим займається. Виняток — чутливі задачі на кшталт вразливостей інформаційних систем: для них узгодили окремий рівень security, коли задачу бачать лише керівник простору й виконавець. «Це була революція. Не технічна — психологічна», — підсумовує Сергій Чеканов.

Люди vs процеси: техніка — це лише 20%

Головна теза всього виступу винесена в окремий слайд: успіх міграції на 80% — це люди, і лише на 20% — техніка. «Більшість проєктів рушиться не з технічних причин, а саме з людських», — нагадує спікер відому статистику.

На слайді про впровадження Сергій показав три категорії людей:

Але головним промоутером був спонсор — CDTO банку. Його внесок Чеканов називає мінімальним за зусиллями й фантастичним за ефектом: із регулярністю в чат керівників IT він писав нагадування, що з 1 січня 2025 року всі працюють у Jira, і тегав відповідального за старі системи — мовляв, ці дві системи мають бути виключені саме тоді. Проста дія, яка тримала нейтралів у нейтральній зоні, а детракторів — у курсі, що відкату не буде.

Люди vs процеси: техніка — це лише 20%. Промоутери, нейтрали й детрактори — і робота з кожною групою. Слайд із презентації.

Jira — це LEGO. І в цьому проблема

Коли команда вирішила, що просто купить готовий курс з Jira, Сергій не заперечував — курси справді корисні. Але з нюансом: вони пояснюють Jira як конструктор.

«Jira — це LEGO. Висипав дитині — і думай, що з цим робити. Якщо ти не знаєш, що в ній робити, вона тобі нічим не допоможе. Якщо думаєте, що візьмете Jira і всі процеси злетять, — не злетять».

Звідси другий наскрізний меседж: процеси живуть не в Jira. Jira — лише інструмент візуалізації.

Навчання вибудували на трьох опорах. Перше — відеоблог: наприкінці дня, по 30 хвилин, для всіх охочих. У середньому приходило до сотні людей, загалом провели 12–14 таких зустрічей. Один новачок згодом упізнав спікера й подякував «за подкаст» — так відеоінструкції прижилися. Друге — письмові інструкції на Confluence, які структурували за ролями (окремо для ПМів, окремо для бізнес-аналітиків) на основі реальних питань користувачів. Третє — чат підтримки: у пік перших місяців він був «гарячим», зараз у ньому 300+ людей і робочі технічні питання щодня.

П’ять помилок, які команда більше не повторила б

Точка Б: що отримали через рік

Через рік «хмарка» зі старими системами зникла. Замість двох застарілих інструментів — Jira як єдине джерело даних про проєкти, ініціативи й усі роботи IT, і Confluence для документації.

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

Agile-трансформація теж рухалась: інструменти адаптували під скрам, спринти, OKR. Але — і це третій важливий акцент — проєктний менеджмент нікуди не зник:

«Проєкти є, їх багато, і вони будуть. Нікуди не зникнуть».

Jira дозволяє змішувати підходи в одному проєкті: одна команда працює за скрамом, інша за канбаном, третя сервісна — а проєктний менеджер збирає єдину дорожню карту, і йому неважливо, хто за яким підходом працює.

Точка Б: Jira як єдине джерело даних про проєкти, ініціативи й усі роботи IT; третина користувачів — не IT; інструмент адаптований під Agile-трансформацію. Слайд із презентації.

А де ж AI?

Слухаючи попередніх спікерів, які багато говорили про штучний інтелект, Сергій додав і свою ремарку. AI в Jira є — він називається Rovo. Найчастіше користувачі застосовують його як довідник: просто спитати, як із чимось працювати.

Але одиному кейсу спікер приділив особливу увагу. При створенні задачі була потреба заходити на певні сторінки Confluence і перевіряти, чи відповідають вони стандарту заповнення. Формалізувати таку перевірку класичними правилами важко — а AI впорався: він переходить за посиланням, звіряє структуру й пропускає або не пропускає задачу далі. «Маленький крок, але саме там, де важко чітко формалізувати перевірку, штучний інтелект дозволяє це зробити».

Що забрати з собою

Кейс Приватбанку цінний саме тим, що розказаний без глянцю. Кілька думок наостанок:

• Jira не лікує все. Це інструмент візуалізації, а не чарівна паличка. Процеси живуть не в системі.
• Jira — це конструктор. Без архітектури й розуміння, що ви будуєте, готовий курс не врятує.
• Техніка — це 20%. Решта — люди: промоутери, нейтрали, детрактори і робота з кожною групою.
• Спонсор вирішує. Проста регулярна підтримка згори тримає весь проєкт.
• Прозорість — це рішення, а не налаштування. Іноді головна революція — психологічна.
• Помилки будуть. Навіть у великій організації пілот можна профакапити — питання в тому, чи готові ви їх визнати й розгребти.

Дивіться повний виступ на YouTube

Про спікера

Сергій Чеканов — керівник IT Project Management Office Приватбанку. 18 років в IT. Пройшов шлях від експерта-криміналіста в секторі комп’ютерно-технічних досліджень через ролі бізнес-аналітика, проєктного менеджера та технічного директора. Освіта — аналітик інформаційних систем.