Ф’южн-фабрика, або Як бізнес-розробники можуть розвантажити ІТ-відділ
Працівники ІТ-департаментів часом відчувають значний тиск з боку бізнесу. «Зробіть на вчора», «необхідно зробити вдвічі більше функціональності за половину часу», «коштів обмаль, але давайте значно підвищимо обсяг роботи», «у нас з’явилося декілька нових вимог», «в цьому кварталі необхідно зробити ще одну функцію» — це лише частина запитів, які можна почути в будь-якому ІТ-відділі чи не щодня.
Постійне збільшення команди не завжди є можливим чи виправданим. Що ж робити, коли бізнес наполягає, а людей і ресурсів на виконання всіх вимог обмаль? Сісти й плакати, постійно відмовляти чи погіршувати якість — не варіант. А чи не пробували ви навчити бізнес-користувачів розробляти застосунки та автоматизувати бізнес-процеси?
Так-так — «сам-собі-девелопер». Якщо ви одразу вважаєте цю ідею жахливою, розгляньмо її детальніше. Мене звати Даніїл Безлюднов, я менеджер розробки програмного забезпечення в EPAM Україна і маю понад 10 років досвіду у роботі з технологіями Microsoft, Power Platform, Dynamics 365 CRM, Azure та .NET. В цьому матеріалі поділюся новими трендами у світі автоматизації та розробки корпоративних застосунків.
Що таке ф’южн-фабрика і хто такі бізнес-розробники
Далі я буду оперувати певними термінами, тому надамо їм визначення на початку.
Ф’южн-фабрика (англ. fusion factory) — концепт, який пропонує поєднання роботи професійних розробників і тренованих бізнес-розробників задля підвищення продуктивності розробки корпоративних застосунків та автоматизації за допомогою засобів, які не потребують знання мов програмування. Саме про цей концепт і піде мова далі.
Бізнес-розробник (англ. citizen developer) — це бізнес-користувач, який пройшов додаткове навчання і використовує новітні інструменти, що надають можливість розробляти застосунки та автоматизувати за допомогою налаштувань, дуже високорівневого програмування і некодових інструментів.
Некодові інструменти (англ. no code) — набір застосунків, нотацій, формул і підходів до розробки, які дають змогу створювати рішення без знання професійних мов програмування, як-от Java, C#, Python, Javascript чи інших. Основні взаємодії компонентів будуються за допомогою Excel-подібних формул та перетягування й поєднання елементів на графічному інтерфейсі. Найпопулярніші технології в цьому сегменті — Microsoft Power Platform, Appian, Pega, OutSystems, AppSheet та інші.
Як це працює
Ф’южн-фабрика (малюнок 1) — це новий підхід, який повністю змінює формат взаємодії бізнесу та ІТ-департаменту всередині компанії. Він виводить нового гравця на поле розробки. Гравця, який дуже сильно відрізняється за рівнем знань, потребами та специфікою роботи від професійних інженерів.
Щоб запустити фабрику, спочатку треба сформувати і навчити команду бізнес-розробників. При цьому підході ІТ-відділ інвестує свій час і ресурси у навчання найздібніших бізнес-користувачів. Вкрай важливо, щоб керівництво компанії підтримувало цю ініціативу і надавало працівникам час для навчання. Варто починати з бізнес-користувачів, які досить вправні у роботі з комп’ютером, сайтами, вміють робити складні формули в Excel та, можливо, малювати блок-схеми, успішно використовують Office та проактивні в навчанні.
Саме бізнес-розробники є центром тяжіння цього підходу, адже вони й досі є частиною бізнесу, але вже мають певні основи ІТ-знань. Такі люди можуть бути першопроходцями, отримувати запити від інших бізнес-користувачів (по суті своїх колег) і деякі з них виконувати самостійно. Якщо задача занадто складна, вони віддають її ІТ-департаменту. При цьому ІТ-департамент займає позицію навчання, підтримки, консультацій і розробки складних рішень та некодових компонентів за допомогою професійних мов програмування.
Малюнок 1. Модель ф’южн-фабрики
Модель робочого процесу (малюнок 2) ІТ-команди при цьому залишається схожою, але доповнюється деякими додатковими кроками. Загалом процес виглядає таким чином.
Малюнок 2. Модель робочого процесу з допомогою ф’южн-фабрики
- Процес починається з ідеї (тут все як завжди), яку вносять бізнес-користувачі.
- Після цього бізнес-розробники за допомогою ІТ-коуча проводять всебічну оцінку (assessment) запиту. Вони обмірковують, чи варто його розробляти, чи можна щось перевикористати та, чи можна його виконати самостійно або ж знадобиться допомога ІТ-департаменту.
- Наступна стадія — дизайн, під час якого розробляються концепт бізнес-процесу та скетчі графічного інтерфейсу.
- На етапі розробки за допомогою некодових інструментів бізнес-розробники покривають 90% роботи й просять допомоги у професійних інженерів з 10% за складними, нетривіальними та комплексними компонентами.
- На етапі розгортання проводиться постачання рішення до кінцевих користувачів за допомогою підготовленої автоматизованої лінії постачання. Процес в найкращому випадку має робитися лише в декілька кліків.
- Після постачання готового рішення дуже важливо розповсюдити знання про розроблені застосунки, автоматизовані процеси, компоненти, які можна перевикористати. А також про те, де знайти пов’язану документацію тощо.
- Закінчується все передачею застосунку чи процесу в ІТ-відділ до стадії контролю (monitoring) з погляду технічних вимог та до бізнес-розробників на перевірку на потенційні майбутні покращення.
Які є ризики підходу
Цей підхід може бути застосований тільки за повної підтримки зі сторони бізнесу. У бізнесу має бути велика (чи навіть величезна) кількість нерозв’язаних задач, які ІТ-департамент не може обробити, і він має шукати будь-які способи задоволення своїх потреб. В такому контексті ф’южн-фабрика дає можливість бізнесу бодай трохи почати робити це самостійно. Цей підхід також допомагає перерозподілити бюджети між ІТ та бізнес-відділами, що позитивно впливає на обидві сторони.
Звичайно, ми не маємо очікувати, що бізнес-розробники зможуть проєктувати та розробляти такі ж якісні, описані, структуровані, зв’язні рішення, як і професійні інженери. Всі ІТ-знання не прийдуть до продавця, бухгалтера та маркетолога впродовж одного-шести тижнів. Водночас розробники також не стануть експертами в продажах, бухгалтерії та маркетингу за один-шість тижнів. В цьому і полягає ідея ф’южн-фабрики: те, що можна зробити просто і те, де дуже важливе знання бізнесу, роблять бізнес-розробники, а те, що складне і має високу ціну помилки, потребує залучення професіоналів в ІТ.
Хтось може сказати: «Так все ІТ — це про складне і не тривіальне». Дозвольте не погодитися. Наведу деякі приклади задач, які бізнес-розробники можуть зробити (і на моєму досвіді дійсно робили) менше ніж за один робочий день:
- Розпізнати в листі, який прийшов на загальну електронну пошту, рахунок на оплату в PDF-форматі і записати основні значення у внутрішню систему Х (не плутати з ex-Twitter 🙂).
- Зробити форму вводу персональних даних для планшета в реєстратурі.
- Зайти на сайт, відфільтрувати дані й звантажити звіт.
- Автоматизувати нотифікації при додаванні нових рядків в Excel-файл або нових людей в HR-систему.
Сьогодні вже не обов’язково знати, як працює процесор, як індексується пам’ять, та у чому різниця між чергою і стеком, щоб автоматизувати якийсь бізнес-процес. Так, без цих знань не обійтись на проєктах із запуску супутників на орбіту, автоматизації швидкості руху автомобіля в заторі, чи навіть розробки нової CRM або ERP-системи. Так, будь-які ускладнення потребуватимуть цих знань, але для найпростіших сценаріїв (а у бізнес-користувачів таких зазвичай десятки й сотні, як-от робота з MS Office взаємодія з наявними сайтами, реорганізація файлів і пошти тощо) вистачить базових навичок.
Плюси і мінуси ф’южн-фабрики
Позитивні і негативні сторони цього підходу дуже сильно залежать від погляду, з якої ви дивитеся на нього. Розглянемо декілька.
Професійний розробник
Плюси
Менше монотонної розробки однакових форм, створення того-самого-REST-API в тисячний раз і більше цікавих задач, пов’язаних зі складною бізнес-логікою.
Мінуси
Значне погіршення архітектури системи через зменшення зціпленності застосунків та використання неоптимальних і субоптимальних (не найгірших, але й не найкращих) рішень.
Збільшення задач з моніторингу та підтримки через різке зростання кількості застосунків та процесів.
ІТ-менеджмент
Плюси
Розвантаження ІТ-департаменту від безлічі незначних задач.
Збільшення сфокусованості ІТ-команд на стратегічних цілях.
Мінуси
Необхідність зміни підходів та погляду в автоматизації бізнес-процесів.
Потенційне збільшення залежностей через збільшення кількості місць збереження даних.
Потреба в покращенні процесів стандартизації дизайну та постачання.
Збільшення видатків на контроль і підтримку великої кількості застосунків, розроблених не професіоналами.
Необхідність налаштування якісного навчання для бізнес-розробників.
Збільшення ризиків, пов’язаних із безпекою.
Бізнес
Плюси
Можливість отримати автоматизацію процесів, «на яку так давно чекали», за допомогою наявних ресурсів всередині департаменту.
Можливість автоматизувати безліч рутинних, непріоритетних процесів, як-от: роботу з поштою і чатами, нагадування про події, архівацію файлів, просте розпізнавання картинок (візитівок, рахунків) тощо.
Зменшення залежності бізнес-відділів від ІТ-департаменту, що відкриває нові можливості для розвитку.
Покращення продуктивності завдяки збереженню великої частини часу за допомогою автоматизації мікропроцесів (наприклад, «прийшов електронний лист, перенаправ його Петру і зроби запис в Excel»), про які ІТ-відділу навіть не повідомляли через їхню низьку пріоритетність.
Мінуси
Треба вкластися в навчання співробітників і давати їм час на опанування нових навичок.
Частина роботи перетвориться на підтримку нових застосунків і автоматизованих процесів.
Застосування на практиці
Під час впровадження цього підходу для одного з великих клієнтів ЕРАМ, європейської фармакологічної компанії, ми як консультанти розбудовували ф’южн-фабрику, починаючи з одного бізнес-користувача. На старті в команду входили архітектор-консультант з нашого боку і проєктний менеджер від клієнта.
Початок роботи був присвячений розробці детального тренінгу на основі технологій Microsoft Power Platform та Microsoft Power Automate з використанням модулів ШІ. Фінальна версія тренінгу містила 10% теорії і 90% практики автоматизації, яку можна було пройти впродовж шести годин за один робочий день (з обідом і трьома перервами). Під час практики група мала автоматизувати деякі нескладні сценарії виростання програм MS Office та роботу з сайтами.
Після розробки тренінгу і першої сесії ми отримали десять нових бізнес-розробників. Після чого почали проводити цей тренінг для груп з
- Приблизно 40% учасників зайшли «просто повчитися».
- 30% пішли думати, що саме вони хочуть автоматизувати в їхньому робочому процесі.
- Ще 20% зробили одну мікроавтоматизацію для своєї рутинної роботи й пішли суперзадоволені.
- Останні 10% одразу повернулись до ІТ-департаменту і попросили допомоги зі складнішими сценаріями застосування й потребували подальшого менторингу.
Основні виклики з’явились, коли кількість бізнес-розробників перетнула позначку в 50 людей. На цьому етапі різко збільшується потреба в роботі служби контролю та координації бізнес-користувачів. Тільки уявіть: ви збільшили ІТ-департамент на
Таке рішення допомагає:
- більш комплексно подивитися на розробку бізнес-девелоперами;
- будувати звіти та підсвічувати місця, які потребують втручання експертів;
- видаляти старі застосунки й ті, якими не користуються;
- давати раду з пошуком процесів, які займають занадто багато ресурсів, визначенням великих розмірів баз даних тощо.
А також пропонує міріаду застосунків й процесів автоматизації процесу контролю.
Завдяки цьому досвіду, коли ми почали запроваджувати підхід поєднальної фабрики для гіганта роздрібної торгівлі, то одразу взяли до уваги, що в середньостроковій перспективі планується навчити більше тисячі бізнес-розробників. Тому запропонували нашому партнеру застосувати більш стратегічний підхід до моніторингу розроблених рішень і координації бізнес-розробників. Це допомогло уникнути деяких «пожеж» і легше пройти позначку в 50 таких спеціалістів.
Насамкінець
Ф’южн-фабрика — відносно новий підхід, який дає бізнесу та ІТ-відділу цікавий набір опцій з розділення обов’язків з розробки. Бізнес-розробники допомагають професійним інженерам розробляти найпростіші застосунки та дають можливість останнім займатися більш стратегічними й складними задачами. Водночас слід пам’ятати, що делегування частини роботи ІТ-відділу бізнес-користувачам навіть за умови спеціальної підготовки має ризики, пов’язані з погіршенням архітектури, потенційними безпековими моментами й зменшенням зв’язаності застосунків.
Більше інформації — за посиланнями:
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів