Управління відпустками для команди в кількох країнах: свої правила для кожної локації

Як ми у Flatstudio придумали правило про 32 дні відпустки для команди у трьох країнах, чому Excel перестав його рахувати, і як з цього разом із партнерами з Push виріс продукт Teamtopia, яким зараз користуються 10+ компаній.

У 2023 році ми написали правило, яке досі діє у Flatstudio: кожна людина в команді має 32 дні відпустки на рік, незалежно від того, в якій країні вона живе. Правило зайняло два абзаци в документі. Рахувати його вручну для 18 людей у трьох країнах виявилось неможливо. Ця стаття про те, як ми дійшли до цього правила, чому таблиця перестала його витримувати, і чому агенція продуктового дизайну в результаті побудувала власну систему управління відпустками замість того, щоб купити готову.

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

TL;DR

• Flatstudio виросла з 12 до 18 людей, розкиданих між Лісабоном, Україною і містами, які змінюються щомісяця. Португальське законодавство про відпустки не працює для двох третин такої команди.
• Ми написали правило: 22 дні португальської відпустки плюс 10 днів на державні свята країни, де людина живе. Разом 32 дні, не більше 15 поспіль.
• Розібратись у таблиці після кожної зміни, переписати формули і вивести потрібні цифри займало від 30 хвилин до 2 годин у менеджера і у мене. І таблиця все одно не відповідала на головне питання: чи можна відпустити цю людину саме в ці дати без шкоди для проєкту.
• Разом із Push ми побудували Teamtopia. Перша версія працює з 2023 року, 10+ компаній, близько 250 людей. Зараз розробляємо другу версію, де менеджер обирає країну, а обов'язкові правила відпусток для неї підтягуються автоматично.

Одна компанія, три календарі

Коли у Flatstudio було 12 людей, правила про відпустки жили у голові. Хтось писав у чат «я наступного тижня відпочиваю», хтось відповідав «ок», і це працювало.

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

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

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

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

Як ми придумали правило про 32 дні

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

Рішення вийшло таким. За базу беремо 22 португальські дні відпустки. До них додаємо 10 днів, які людина сама розставляє по року на державні свята країни, де вона живе: українські, польські, будь-які. Якщо немає бажання прив'язувати їх до свят, це просто ще 10 днів відпустки. Разом 32 дні на рік.

Єдине обмеження: не більше 15 днів поспіль, щоб проєкт не залишався без людини на місяць.

Пізніше, коли Андрій моделював Teamtopia, це правило перетворилось на окрему сутність: локація під назвою Remote, без країни і без державних свят, з більшою кількістю днів. Але у 2022–2023 роках це був абзац у документі і колонка в Excel.

Коли Excel перестає працювати для обліку відпусток

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

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

Але справжня проблема була не в часі, витраченому на арифметику. Таблиця не вміла відповісти на питання, яке насправді ставив кожен запит: чи можемо ми відпустити саме цю людину саме в ці дати без шкоди для проєкту?

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

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

Чому ми не купили готову систему управління відпустками?

Ми тестували BambooHR і Vacation Tracker, WhosOff, LeaveBoard, Calamari. Жоден не підійшов, і причина була не в ціні і не в інтерфейсі.

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

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

Push мали той самий Excel

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

Дві невеликі компанії, одна проблема, одне рішення: будувати разом. Flatstudio взяла на себе продуктову логіку і дизайн, Push розробку. Пріоритети і продуктові рішення ми приймали разом, бо обидві команди були першими користувачами того, що будували.

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

Що змінилось у компанії після переходу з Excel

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

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

Для мене як для CEO змінилось інше. Я бачу компанію цілком: у яких командах бракує людей, якщо хтось піде у відпустку, хто на лікарняному, хто на day off, як це накладається на клієнтські проєкти. Раніше для цього треба було відкрити таблицю і скласти картину в голові. Зараз це один календар.

Кілька речей, які ми використовуємо щодня:

• Локації і команди з власними правилами. У Teamtopia локація називається «офіс», але це може бути що завгодно: лісабонська команда з португальським календарем, Remote з правилом про 32 дні, філія в іншій країні, ресторан або склад. Для кожної команди задано, скільки людей максимум може бути відсутніми одночасно.
• Календарі під конкретне питання. Можна зібрати календар однієї команди, усіх команд на конкретному проєкті, всієї компанії або однієї локації, і дати до нього доступ саме тим, кому він потрібен: менеджеру, дизайн-директору, тімліду.
• Календар для клієнта. Це функція, яку ми зробили на запит наших власних клієнтів. Клієнт отримує доступ до календаря своєї проєктної команди і бачить, хто над його продуктом працює, хто у відпустці, які святкові дні у людей з України, які у людей з Португалії, і навіть дні народження. Він розуміє не тільки що людини немає, а й чому. Прозорість всередині команди ми вважали обов'язковою з самого початку; прозорість перед клієнтом виявилась не менш важливою.
• Лікарняні, відгули, типи відпусток без паперів. Для кожної локації і команди можна створити свої типи відсутностей. Запит, погодження, оновлення балансу відбуваються без листування і без форм. Саме тому ми говоримо про управління відсутностями, а не тільки відпустками: лікарняні і day off проходять через ту саму систему.

Що ми додали за останні півтора року

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

• Розрахунок заробітної плати (березень 2025): облік відсутностей і понаднормових годин у вигляді, придатному для нарахування зарплати.
• Зовнішні апрувери (вересень 2025): можливість призначати погоджувальників, які не є частиною команди або локації, наприклад клієнта або зовнішнього менеджера.
• Holiday swap (вересень 2026): перенесення корпоративного свята на іншу дату, якщо стандартна не підходить команді.
• Інтеграції зі Slack, Google Calendar і Microsoft Teams.
• Статистика і групи навичок: хто з якою компетенцією доступний, і сигнали ризику вигорання на основі частоти і тривалості відпусток.

Станом на вересень 2026 року в Teamtopia заплановано понад 2 100 відпусток, зафіксовано понад 500 лікарняних і понад 1 600 годин понаднормової роботи.

Що далі: друга версія для більшої кількості країн

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

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

Модель для другої версії вже зібрана і прокликана як інтерактивний прототип у Figma Make. Прототип показав, що це enterprise-масштаб розробки, і саме тому ми знаємо це зараз, а не через півроку після старту.

Перша версія тим часом продовжує працювати. Вона відкрита для реєстрації: 3 місяці безкоштовно, далі $2 за користувача на місяць.

Що я виніс з цього як засновник агенції

Ми будуємо продукти для клієнтів з 2014 року. Teamtopia стала першим продуктом, де клієнтом були ми самі, і це змінило кут зору.

Коли ти сам відкриваєш таблицю і витрачаєш дві години на те, щоб знову зрозуміти власні формули, ти дуже точно знаєш, що саме має зробити продукт. Не «керувати відпустками», а відповісти на одне питання: чи можна цю людину відпустити в ці дати. Усе інше в Teamtopia виросло з цього питання.

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

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