Відкриті питання

Здебільшого не вирішено · востаннє переглянуто 2 жовтня 2026

Щодо Shiffty вирішено кілька речей — галузь, форму застосунку та інструменти, на яких його буде побудовано, зокрема розв'язувач для першої версії; усе інше — питання, на які треба відповісти, перш ніж щось будувати.

Що вже вирішено

• Лише рітейл (25 вересня 2026). Жодних ресторанів, складів чи універсального планування персоналу. Див. Огляд.
• Один застосунок для керівників і працівників, на телефонах — поки що через Capacitor (2 жовтня 2026). Див. Архітектуру.
• API на NestJS і застосунок на Nuxt, організовані за CleanSlice — на цих інструментах побудовано інші наші продукти (2 жовтня 2026). Див. Архітектуру.
• YALPS як розв'язувач для першої версії (2 жовтня 2026). Згодом, найімовірніше, Google OR-Tools окремим сервісом у Kubernetes — це намір, а не рішення. Див. Агент і розв'язувач.

Жодне з цих рішень не реалізовано.

Ринок

• Чому ми, а не Deputy чи схожі інструменти? Див. огляд ринку, конкурентне середовище та Deputy і наш підхід. Автоматичне складання графіків — уже стандарт, а великі постачальники вже заявляють обмін змінами природною мовою з погодженням керівника. Нам потрібна причина, зрозуміла керівникові магазину, а не перелік функцій, і знайти її треба раніше, ніж Deputy чи схожий інструмент додасть чат для працівників.
• З якого сегмента рітейлу почати? Галузь вирішено: лише рітейл. Відкрито інше: окремі магазини чи невеликі мережі, продуктові чи інші формати.
• З якої країни почати? З огляду на наш досвід природні кандидати — Україна та її сусіди, і, як показує конкурентне середовище, розмовного інструмента для графіків там поки немає. Трудові правила та звички щодо месенджерів у різних країнах різні, тож цей вибір визначить першу версію.
• Хто платить і скільки? Ціну ще не визначено. Інструменти для малого бізнесу коштують $2–9 за користувача на місяць або $30–120 за точку, тож ціну доведеться обґрунтовувати зекономленими годинами керівника.

Перевірка проблеми

• Скільки часу керівники зараз витрачають на складання графіків?
• Як часто графік змінюється після публікації і хто цим займається?
• Скільки коштує типовому магазину надлишок і нестача персоналу?

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

Продукт

• Агент чи розв'язувач. Наше робоче припущення: агент перетворює запити на обмеження, а розв'язувач складає графік. Див. Складання графіка та Агент і розв'язувач. Це треба підтвердити прототипом.
• Месенджер як другий канал. Перший канал — наш власний застосунок. Чи зможуть працівники писати ще й із Telegram, Viber або WhatsApp, не вирішено. Див. Асистент для працівників.
• Усе технічне, крім інструментів. База даних, хостинг, мовна модель, сповіщення. Див. Архітектуру.
• Затвердження. У демо кожну зміну затверджує керівник. Чи влаштує це керівників, ще треба з’ясувати; автоматичне затвердження до плану не входить.
• Дані про відвідуваність. Які джерела насправді є в магазинів. Див. Вхідні дані.

Ризики

• Трудове законодавство. Правила різняться залежно від країни та договору. Хто відповідає, якщо згенерований графік якесь із них порушить?
• Дані працівників. Доступність, відсутності та особисті причини — чутлива інформація. Де зберігаються дані і хто їх бачить, треба визначити ще до будь-якого пілоту.
• Довіра. Керівник, який не розуміє, чому агент обрав саме таку зміну, переробить усе вручну.

Наступний крок

Наступний крок — двотижневий план демо: MVP лише в браузері до 18 жовтня 2026 на заздалегідь заповнених даних одного вигаданого магазину. Кожну зміну затверджував би керівник. Це замінює найближчу пропозицію почати з реальних даних магазину; перевірка з реальним магазином залишається подальшою роботою, а не наявним пілотом.