У більшості ІТ-проєктів термін — предмет перемовин. Замовник хоче раніше, команда просить ще два тижні, хтось зсуває реліз на спринт — і нічого страшного не стається. Регуляторний проєкт влаштований інакше: дата набрання чинності записана в законі, а закон не переносять на дейлі.
Коли ми починали роботу над власним SaaS-продуктом для обов'язкового електронного інвойсингу, у нас була одна точка відліку, якої не міг зрушити ніхто. Графік польської системи KSeF було закріплено законом від 5 серпня 2025 року, підписаним Президентом 27 серпня 2025 року. З 1 лютого 2026 року обов'язок охопив великих платників податків, з 1 квітня 2026 року — решту компаній, а з 1 січня 2027 року охопить мікробізнес. Три дати. Нуль гнучкості.
Це процесний кейс, а не технологічний. Ми не розповідатимемо про вибір фреймворку. Розповімо про те, як ухвалювали рішення щодо скоупу, що свідомо викинули з MVP і як побудували продукт, який пережив зміну законодавства просто посеред власної розробки.
Чому регуляторний проєкт — це інший клас ризику
Класичний проєктний трикутник передбачає, що ви маневруєте трьома змінними: скоупом, часом і бюджетом. У проєкті під законодавчий дедлайн одна з них перетворюється на бетон. Лишаються дві — і по-справжньому гнучка тільки одна.
Масштаб ризику добре задокументовано. Дослідження McKinsey спільно з Оксфордським університетом, що охопило понад 5 400 великих ІТ-проєктів, показало: у середньому вони перевищують бюджет на 45%, графік — на 7% і дають на 56% менше цінності, ніж планувалося. У комерційному проєкті ці 7% затримки — незручність. У регуляторному — це момент, коли клієнти втрачають можливість легально виставляти рахунки.
Три типи термінів, і лише один справді твердий
Варто розрізняти, з яким саме терміном ви маєте справу, бо від цього залежить уся логіка планування:
Бізнесовий термін — хочемо вийти на ринок раніше за конкурентів. Пересувний, ціна — частка ринку.
Договірний термін — записаний в угоді з клієнтом. Пересувний, ціна — штраф або стосунки.
Законодавчий термін — записаний у нормативному акті. Непересувний, ціна — відповідність закону.
Тільки третій тип змушує перевернути стандартний процес планування. Ви не питаєте «скільки часу займе цей скоуп?», ви питаєте «який скоуп реально побудувати до цієї дати?». Здавалося б, косметична різниця — але вона перебудовує всю роботу команди.
Наслідок: скоуп стає єдиною змінною
Бюджет у продуктовому проєкті теж насправді жорсткий — ви не додасте на півдорозі ще стільки ж грошей і не подвоїте команду без втрати темпу. Закон Брукса працює незалежно від галузі: додавання людей до проєкту, що запізнюється, робить його ще повільнішим.
Отже, лишається скоуп. І саме він потребує найдисциплінованіших рішень у всьому проєкті. Не «що було б класно», а «без чого клієнт 1 квітня порушить закон».
Пріоритизація скоупу: що ввійшло в MVP, а що ми відклали
Standish Group роками показує у своїх дослідженнях, що переважна більшість функцій у бізнес-системах використовується рідко або взагалі ніколи — у класичному аналізі цієї організації близько 45% функціональності не використовували жодного разу. У проєкті без часового тиску це марнотратство. У проєкті під закон — екзистенційна загроза, бо кожна година, вкладена в необов'язкову функцію, відібрана в обов'язкової.
Ми ухвалили один головний критерій, який розв'язував будь-яку суперечку про пріоритет.
Критерій: «чи без цього клієнт порушує закон?»
Кожну пропозицію функції ми пропускали через трирівневий фільтр:
Блокує відповідність — без цього користувач не може виконати законодавчий обов'язок. Іде в MVP без обговорень.
Блокує операційно — формально обов'язок виконано, але процес настільки незручний, що на практиці непридатний. Іде, якщо вміщається у вікно.
Підвищує цінність — покращує досвід, економить час, вирізняє продукт. Не йде до дедлайну. Крапка.
Звучить банально, доки не доводиться застосувати це до функції, яку насправді дуже хочеться зробити. Дисципліна полягає в тому, щоб не переносити речі з третьої категорії в першу за допомогою креативної аргументації.
Що ввійшло в першу версію
Скоуп MVP замкнувся на кількох напрямах, і кожен із них прямо відповідав на обов'язок із нормативного акта:
Виставлення та надсилання структурованих рахунків у чинній схемі.
Приймання вхідних документів — адже з 1 лютого 2026 року всі платники ПДВ зобов'язані отримувати рахунки із системи незалежно від того, коли самі починають їх виставляти.
Керування автентифікацією та правами: хто в компанії має право діяти з рахунками.
Обробка коригувань, авансових і розрахункових рахунків — типів документів, без яких бухгалтерія не закриє місяць.
Отримання офіційного підтвердження та архівування доказів надсилання.
Базова спостережуваність: що пішло, що відхилено і чому.
Що ми свідомо відклали
Список відкладеного вийшов довшим за список зробленого — і це здоровий сигнал, а не провал:
Розгорнута аналітика та менеджерські дашборди.
Автоматична категоризація витрат на основі машинного навчання.
Глибокі двосторонні інтеграції з бухгалтерськими системами третіх сторін.
Складні багаторівневі workflow погодження.
Мобільний застосунок.
Кастомізація вигляду документів понад мінімум.
Ключове правило, якого ми трималися: відкладене не означає скасоване, але має бути записане. Кожна відсунута функція потрапляла в реєстр із обґрунтуванням і попередньою датою повернення. Завдяки цьому розмова зі стейкхолдерами звучала не «ми цього не робитимемо», а «ми зробимо це в другому кварталі після запуску, і ось чому не раніше».
Як ми говорили про скоуп зі стейкхолдерами
Найбільш недооцінена частина пріоритизації — це не ухвалення рішень, а їх комунікація. Людина, відповідальна за продажі, бачить у відкладеній функції втрачений аргумент у розмові з клієнтом. Людина з бухгалтерії бачить ризик, якого не бачить продуктова команда.
Замість того щоб захищати рішення, ми почали показувати його альтернативну вартість. Кожну пропозицію розширити скоуп ми оцінювали не в людино-годинах, а в тому, що мало б випасти з MVP заради неї. Розмова «що прибираємо, щоб це додати?» завершується зовсім інакше, ніж розмова «чи можна це докинути?».
Другим інструментом був щотижневий односторінковий статус з одним числом угорі: кількістю днів до законодавчої дати. Без графіків, без відсотка готовності. Це одне число впорядковувало пріоритети ефективніше за будь-який планувальний документ.
Перехідний період, або кілька версій реальності одночасно
Найскладніший елемент усього проєкту не мав нічого спільного із самим запуском. Річ у тім, що законодавець — і цілком слушно — не перемикає всю економіку одним рубильником. Поетапний графік означає, що протягом багатьох місяців в обігу паралельно існують різні правові стани.
На практиці наш продукт мусив одночасно обслуговувати: компанії, вже охоплені обов'язком; компанії, ще не охоплені, але зобов'язані приймати документи; і суб'єктів, що користуються перехідними винятками. Виняток для найменших платників стосувався операцій до 450 злотих за окремим рахунком і до 10 тис. злотих місячного продажу — а це означає, що система має знати контекст кожного клієнта, а не лише календар.
Версіонування схеми як функція продукту, а не техборг
Найбільша помилка в такому проєкті — вважати формат даних чимось сталим. Схема структурованого рахунка змінилася просто під час впровадження: нова версія замінила попередню й додала, зокрема, окремі поля для зв'язку розрахункового рахунка з авансовим.
Тому ми спроєктували підтримку кількох версій схеми як повноцінну функцію системи. Документ зберігається у внутрішній моделі, незалежній від офіційного формату, а трансляція в конкретну версію відбувається на виході — залежно від дати й контексту платника. Це одне архітектурне рішення окупилося кількаразово.
Дані мігрують повільніше за норми
Другий урок перехідного періоду стосується історичних документів. Рахунок, виставлений за старим режимом, має лишатися читабельним, придатним до коригування й заархівованим роками після зміни правил. Коригування до документа, створеного до зміни формату, — окремий і нетривіальний бізнес-кейс; податковий орган навіть видавав із цього приводу індивідуальні роз'яснення.
Висновок для будь-якої компанії, що планує подібне впровадження: сплануйте роботу з минулим раніше, ніж роботу з майбутнім. Міграція історичних даних — зазвичай найбільш недооцінений елемент графіка.
Коли норми змінюються просто під час розробки
Найповчальніший момент проєкту настав уже після запуску першої фази. 9 червня 2026 року в Міністерстві фінансів відбулися відкриті консультації після часткового впровадження системи, де представили пропозиції щодо її вдосконалення.
Одна з них стосувалася безпосередньо шару, який ми вже мали побудованим. Токени як метод автентифікації мали згасати до кінця 2026 року, але у відповідь на запити ринку міністерство запропонувало зберегти їх і після 31 грудня 2026 року. Обґрунтуванням стали інтерес користувачів до цього інструменту, безпека його застосування та зручність у щоденній роботі. У пропозиції також з'явилися строк дії токенів від 1 до 365 днів і механізм автоматичного поновлення за згодою власника.
Чому це була добра новина, яка могла стати катастрофою
Ми будували шар автентифікації з припущенням, що токени згорнуть, а сертифікати стануть цільовим методом. Якби цей шар був вплетений безпосередньо в бізнес-логіку, зміна курсу означала б переписування значної частини системи в розпал сезону.
Оскільки методи автентифікації від початку були взаємозамінними плагінами за спільним інтерфейсом, адаптація звелася до зміни конфігурації та додавання обробки життєвого циклу токена. Кілька днів роботи замість кількох тижнів.
Правило «проєктуй під напрям, а не під літеру»
З цього досвіду ми вивели правило, яке сьогодні застосовуємо в усіх регуляторних проєктах: реалізуй чинну літеру норми, але проєктуй структуру під напрям, у який норма може рушити. Якщо консультації показують, що щось можуть зберегти, розширити чи уточнити, ця невизначеність має бути видимою в архітектурі як точка гнучкості — а не схованою в коді як припущення.
Архітектура, стійка до зміни регулювання — чотири принципи
Регуляторна стійкість — це не властивість технології. Це спосіб розподілу відповідальності всередині системи. Чотири принципи, які спрацювали в нас:
1. Бізнес-правила відокремлені від коду застосунку
Порогові суми, дати набрання чинності, переліки винятків і умови застосування пільг — це конфігураційні дані, а не умовні конструкції, розсипані по застосунку. Зміна порога — це зміна запису, а не викочування нової версії.
2. Ізолювальний шар над API державної системи
Державні системи мають власний темп змін, власні ліміти й власні збої. Наш продукт спілкується з ними через окремий адаптаційний шар, який перекладає зовнішню модель у внутрішню. Це має й суто операційний вимір: ліміти запитів в інтерактивному режимі становлять 10 рахунків на секунду, 30 на хвилину і 180 на годину, а при завантаженні — відповідно 8, 16 і 64. Черги та контроль пропускної здатності треба закладати з першого дня, а не докручувати після першого сезонного піку.
3. Перемикачі функцій, прив'язані до дат набрання чинності
Кожен елемент скоупу, що залежить від норми, має власний feature flag і власний календар активації. Завдяки цьому код нового обов'язку потрапляє на продакшн заздалегідь, але «прокидається» лише в день набрання чинності — а якщо термін перенесуть, достатньо змінити дату.
4. Повна аудитованість замість перезапису
У регульованому середовищі історія змін — не розкіш, а доказ. Показово, що сам законодавець рухається в цей бік: серед запланованих змін — фіксація повної історії модифікацій даних у рахунках, бо сьогодні кожна наступна правка перезаписує попередню й простежити процес неможливо. Якщо держава доходить висновку, що їй потрібен повний аудиторський слід, то системі, яка має відповідати на запити перевірок, він потрібен тим паче.
Шість висновків для компаній перед власним законодавчим терміном
Масштаб того, що сталося, був цілком реальним: система обробила понад 340 млн рахунків, виставлених більш ніж 2,1 млн суб'єктів. Це показує, що за добре побудованого процесу вкластися в термін можна навіть у масштабах цілої економіки. Наші висновки:
Визначте дату, від якої рахуєте назад, і зробіть її недоторканною. Усі інші рішення — похідні від неї.
Сформулюйте один критерій пріоритизації і тримайтеся його механічно. Що менше простору для суб'єктивності, то менше суперечок у критичний момент.
Будуйте з розрахунку на перехідний період, а не на день Х. Співіснування версій триває довше, ніж саме перемикання.
Сприймайте регуляторну невизначеність як архітектурну вимогу. Там, де норма може змінитися, потрібна точка заміни.
Запускайтеся раніше, ніж мусите. Період без санкцій — це час навчитися процесу, а не привід зволікати: після його завершення санкції повертаються в повному обсязі.
Записуйте те, чого ви не побудували. Реєстр свідомих відмов — єдиний захист від питання «а чому цього немає?» через три місяці.
Підсумок
Проєкт під законодавчий дедлайн не складніший технічно за інші. Він складніший з погляду ухвалення рішень. Він вимагає згоди організації на те, що перша версія буде вужчою, ніж будь-хто хотів, і що частина хороших ідей зачекає.
По-справжньому вирішують три речі: безкомпромісна дисципліна скоупу, проєктування перехідного періоду як повноцінного стану системи та архітектура, яка припускає, що норми ще зміняться. Бо вони точно зміняться — питання лише в тому, чи застануть вас готовими.
Якщо ваша компанія стоїть перед власним регуляторним терміном — звітним обов'язком, галузевою вимогою чи зміною, яка змусить перебудувати процеси, — не починайте з питання про технологію. Почніть із питання про скоуп і про те, що готове бути відкладеним.
Якщо ви хочете створити систему, підлаштовану під процеси вашої компанії — зв'яжіться з нами. Наша команда допоможе перекласти бізнес-цілі на конкретні ІТ-рішення. Ми домовимося про безкоштовну консультацію, на якій проаналізуємо ваш графік, визначимо критичні для відповідності елементи й запропонуємо реалістичний план впровадження.
