Бот для HR-рутини команди
Відпустки, обміни змінами й розрахункові листи жили в робочих чатах і губились. Бот веде їх від заявки до підтвердження, а керівник керує всім зі звичної таблиці.
Результат
- Заявка проходить шлях від подачі до підтвердження без жодного чату
- Керівник керує ботом із Google Таблиці, не заходячи на сервер
- Обмін змінами неможливо провести без згоди другої сторони
- Накладку відпусток видно ще на заявці, а не в день, коли двоє не вийшли
- Роль
- Повний цикл: ТЗ, розробка, деплой
- Скільки зайняло
- 1 тиждень
Задача
Відпустки, вихідні й обміни змінами узгоджувались у робочих чатах. Хтось писав керівнику особисто, хтось у групу, хтось казав уголос. Наслідок передбачуваний: заявки губились, а накладки виявлялись у той день, коли двоє людей одночасно не вийшли.
Окрема історія це розрахункові листи. Їх треба роздати кожному персонально і знати, хто прочитав. Розсилка файлів у спільний чат не закриває ні першого, ні другого.
Що зробив
Бот веде повний цикл: заявка, підтвердження керівником, запис у журнал. Керівник отримує повідомлення з двома кнопками і вирішує з телефона. Розрахунковий лист приходить особисто, з кнопкою «Ознайомлений», тому видно, хто підтвердив.
Нагадування бот шле сам за розкладом, без ручних кнопок «оновити».
Коли підходить
- Відпустки й заміни узгоджуються в чатах. Хтось пише керівнику особисто, хтось у групу, і заявки губляться.
- Керівник не хоче заходити на сервер заради дрібного налаштування. Адмінка має бути такою, яку він і так відкриває щодня.
- Обмін змінами можна провести за чиєюсь спиною. Потрібне явне підтвердження другої сторони, а не мовчазна заміна.
Головне рішення: таблиця це адмінка, а не база
Керівник не має заходити на сервер, щоб змінити ліміт вихідних на місяць. Тому адмінка це Google Таблиця, яку він і так відкриває щодня.
Але важлива не сама таблиця, а напрямок руху даних. Першоджерело завжди всередині бота. Таблиця це або вхідна вкладка, яку заповнює людина, або вихідний журнал, який бот перезаписує повністю. Ніколи і те, і те одночасно: вкладка, яку редагують з двох боків, рано чи пізно дає дві різні версії правди, і жодна перевірка вже не скаже, котра справжня.
Що саме бот перезаписує сам, написано в ньому заздалегідь, а не з'ясовується в той день, коли чиясь ручна правка зникла.
Запобіжники
Дія однієї людини над чужим часом ніколи не виконується одразу. Обмін змінами це спершу запит, і аж після підтвердження другої сторони він стає фактом. Інакше графік можна переписати комусь за спиною.
Налаштування (ліміти, година нагадувань) живуть усередині бота, а не в конфігу на сервері. Те, що власник процесу має право міняти сам, не повинно вимагати розробника.
Спробуйте самі
За посиланням «Подивитись наживо» відкриється демо-бот. Після Start у вас буде власна вигадана команда з графіком на два тижні, і ви будете в ній водночас співробітником і керівником. Спробуйте взяти відпустку на день, коли вже відсутні двоє: бот відмовить сам. Або запропонуйте колезі обмін змінами і подивіться, як графік оновиться після його згоди.
У демо вигадані колеги відповідають самі, за кілька секунд, і немає Google Таблиці: все живе всередині бота. Ваші дії бачите лише ви, реальних даних тут немає.
Часті питання
Керівник може ненароком переписати чужі дані в таблиці? Ні. Напрямок руху даних фіксований: кожна вкладка це або вхід, який заповнює людина, або вихід, який бот перезаписує повністю, ніколи обидва одночасно.
Що як двоє співробітників попросять відпустку на ті самі дні? Керівник бачить це прямо на картці заявки: хто ще відсутній у ці дні і чия заявка ще очікує. Якщо задано ліміт одночасно відсутніх, бот сам відхилить заявку понад нього, а на кнопці «Погодити» перевірить ще раз, бо дві заявки могли прийти одночасно. Лікарняне ліміт не блокує, лише позначає.
Стек
- Python
- aiogram 3
- SQLite
- Google Sheets API
Схожа задача?
Опишіть її двома реченнями. Скажу, чи можна це автоматизувати і скільки приблизно коштуватиме.