ШІ у команді: з чого почати за тиждень

Типовий сценарій невдачі виглядає так. Команда вирішує «спробувати ШІ», обирає велику показову задачу, витрачає два місяці на підготовку даних, показує демонстрацію на нараді — і на цьому все закінчується, бо ніхто не може сказати, чи стало краще.

Проблема тут не в технології. Проблема в тому, що задачу обрали за видовищністю, а не за вимірюваністю.

Задача для першого тижня має мати чотири властивості.

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

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

Терпимість до помилки. Результат перевіряє людина перед використанням. Задачі, де помилка йде одразу клієнту, для першого тижня не годяться.

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

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

Задачі, які не проходять: «замінити першу лінію підтримки», «автоматизувати документообіг», «зробити чат-бота для сайту». Це не погані цілі — це просто не задачі для першого тижня.

День 1 — замір. Виберіть задачу. Попросіть двох-трьох людей, які її роблять, зафіксувати час на кожному виконанні протягом дня. Не оцінку, а фактичний час. Це ваша базова лінія, і без неї весь наступний тиждень не має сенсу.

Тоді ж зберіть п'ять реальних прикладів: вхідні матеріали й те, що вийшло на виході. Вони стануть перевіркою якості.

День 2 — перший прохід. Виконайте задачу з ШІ на тих п'яти прикладах. Не редагуйте промпт до досконалості — вам зараз потрібна не найкраща відповідь, а чесне уявлення про типову.

Зафіксуйте, що виявилося не так: бракує контексту, невірний тон, загублена структура, вигадані факти. Це різні поломки з різними виправленнями.

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

Випишіть це один раз як короткий набір правил і додавайте до кожного запиту. Зазвичай саме цей крок дає найбільший стрибок якості — більший, ніж будь-яка зміна формулювання.

День 4 — реальна робота. Ті самі люди роблять ту саму задачу, але з ШІ, і знову фіксують час. Разом із часом на перевірку й правки — це частина роботи, а не накладні витрати.

День 5 — рішення. Порівняйте час і якість. Порівнюйте не з ідеалом, а з тим, що було в понеділок.

Чотири типові підсумки й що з ними робити.

Швидше й якість не гірша. Найкращий випадок. Розширюйте на всю команду й беріть наступну задачу.

Швидше, але якість гірша. Дивіться, де саме втрачається якість. Найчастіше це брак контексту — поверніться до третього дня.

Не швидше, але якість краща. Теж результат, просто інший: виграш не в часі, а в стабільності. Вирішуйте, чи це цінно для вас.

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

Не будуйте інтеграцій. Не переносьте базу знань. Не пишіть регламент використання ШІ. Не вибирайте постачальника на три роки вперед. Усе це має сенс — але після того, як ви побачили реальний виграш хоча б на одній задачі.

І не робіть пілот силами тих, хто цю роботу не виконує. Оцінка людини, яка бачить задачу зсередини, вартує більше за будь-яку демонстрацію.