Найняти ШІ-інженера чи навчити команду: як ухвалити рішення
Власник або технічний директор бачить, що ШІ потрібно вбудовувати в процеси, і стикається з першим кадровим питанням. Відкрити вакансію «інженер з ШІ» або «промпт-інженер»? Чи навчити аналітиків і програмістів, які вже знають бізнес?
Пряма відповідь: рішення залежить від характеру робіт, а не від модної назви посади. Якщо компанія використовує готовий ШІ-сервіс для текстів, зведень чи пошуку по документах, зазвичай вистачає власника процесу й навченої команди. Якщо потрібні інтеграції з CRM, робота з даними, оцінка якості відповідей, контроль доступів і щоденна експлуатація, потрібна інженерна компетенція. Вона може бути внутрішньою, зовнішньою або змішаною.
Головна умова: спершу опишіть портфель задач на найближчі місяці, а вже потім обирайте, кого шукати. Після статті ви зможете розкласти свої задачі на ролі, зрозуміти, які з них закриє наявна команда, і скласти практичне завдання для кандидата чи підрядника.
Яка робота насправді потрібна
Слова «впровадити ШІ» описують дуже різні обсяги роботи. Від того, що саме стоїть за ними у вашій компанії, залежить, кого шукати.
Налаштування готового сервісу. Компанія купує корпоративний доступ до чат-асистента чи ШІ-функцій в офісних програмах. Потрібно налаштувати акаунти, правила даних, шаблони задач і навчити людей. Програмування тут мінімальне або відсутнє.
Інтеграції. ШІ має отримувати дані з CRM, обліку, сервісу підтримки чи сайту і записувати результат назад. Тут з'являються API, авторизація, обробка помилок, черги, журнали.
База знань для відповідей. Асистент відповідає на запитання з урахуванням внутрішніх документів. Потрібно підготувати документи, налаштувати пошук, перевіряти, чи знаходиться правильний фрагмент і чи відповідь йому відповідає.
Оцінка якості. Будь-яка система з ШІ потребує набору контрольних прикладів, правил перевірки і регулярного вимірювання: скільки відповідей правильні, де модель помиляється, що змінилося після оновлення.
Розміщення на власній інфраструктурі. Якщо правила компанії не дозволяють передавати дані зовнішнім сервісам і потрібна власна модель, може знадобитися розгортання в контрольованому середовищі. Це вже робота з інфраструктурою, продуктивністю, оновленнями й безпекою.
Супровід. Після запуску хтось має реагувати на збої, оновлювати інструкції, слідкувати за змінами постачальника і за витратами.
Варто врахувати і складність архітектури. У робочому процесі модель та інструменти діють за заздалегідь визначеною послідовністю в коді. Агент натомість може сам обирати наступні кроки й інструменти. Починайте з найпростішого рішення й додавайте складність лише тоді, коли це покращує результат перевірки. Для кадрового плану різниця практична: схема з одним викликом моделі зазвичай потребує менше інженерної роботи, ніж автономна система з доступом до кількох сервісів.
Які ролі закривають ці задачі
Коли задачі описано, їх можна розкласти на ролі. Роль означає набір обов'язків, а не обов'язково окрему людину. В одній компанії аналітик і власник процесу можуть бути однією особою, в іншій інженер інтеграцій також відповідає за експлуатацію.
| Роль | Що робить | Хто часто може взяти на себе |
|---|---|---|
| Власник процесу | Визначає, яку задачу вирішуємо, приймає результат, відповідає за якість | Керівник відділу, де працює сценарій |
| Аналітик | Описує дані, правила, винятки, готує контрольні приклади | Бізнес-аналітик, досвідчений працівник відділу |
| Інженер інтеграцій | Підключає API, обробляє помилки, налаштовує журнали | Бекенд-розробник, інтегратор |
| Спеціаліст з даних | Готує й очищає дані, налаштовує пошук по документах, вимірює якість | Аналітик даних, інженер даних |
| Безпека й доступи | Визначає права, перевіряє, які дані куди передаються | IT-адміністратор, фахівець з безпеки |
| Експлуатація | Моніторинг, реакція на збої, оновлення, контроль витрат | DevOps, системний адміністратор, підрядник |
Ця матриця є редакційною моделлю відповідальності. Вона не означає, що для впровадження потрібно шість нових працівників. Вона допомагає побачити, які обов'язки ще ні за ким не закріплено.
Окремо розподіліть відповідальність за правила, оцінювання ризиків і реагування на проблеми. Одна людина, яка «добре пише промпти», не закриває всі ці ролі.
Навчальна матриця: тип задачі і потрібні компетенції
| Задача | Мінімальний склад ролей | Чи потрібен окремий інженер |
|---|---|---|
| Чернетки текстів і зведень у схваленому сервісі | Власник процесу, редактор, який перевіряє результат | Як правило, ні |
| Бот, що читає й оновлює дані в CRM | Інженер інтеграцій, власник продажів, аналітик для правил і винятків | Так, хоча б на етапі створення й супроводу |
| Асистент з відповідями по внутрішній базі знань | Власник змісту бази, спеціаліст з даних, інженер для пошуку й інтеграції | Залежить від того, готове це рішення чи власна розробка |
| Модель у закритому контурі з вимогами до доступності | Інженер інфраструктури, спеціаліст з даних, безпека, експлуатація | Так, і зазвичай не один фахівець |
Коли варто навчати наявну команду
Навчання поточних працівників має сенс, коли виконуються кілька умов.
Є предметне знання. Аналітик, який п'ять років працює з вашими продажами, знає винятки, сезонність і помилки в даних. Навчити його роботі з ШІ часто простіше, ніж навчити зовнішнього фахівця вашому бізнесу.
Обсяг змін обмежений. Ідеться про готові сервіси, шаблони, прості автоматизації без складної інфраструктури.
Є час на навчання. Людям потрібен виділений час у графіку, а не «між основними задачами». Інакше навчання формально відбудеться, а навичка не з'явиться.
Є наставник і відповідальність. Хтось має перевіряти перші результати, а за кожним сценарієм має бути закріплений власник.
Для багатьох працівників, чиї задачі змінює ШІ, потрібними стають нові управлінські, аналітичні й цифрові навички, але не обов’язково спеціалізація на машинному навчанні. Це не означає, що інженери не потрібні: ідеться про працівників, які користуються ШІ, а не про фахівців, що будують і супроводжують системи.
Коли наймання виправдане
Окрема посада має сенс, коли робота стає постійною, а не разовою.
Постійний портфель складних задач. Не один бот, а кілька інтеграцій, які розвиваються, плюс черга нових запитів від відділів.
Критичність сервісу. Якщо збій ШІ-системи зупиняє продажі чи підтримку клієнтів, потрібна людина, яка відповідає за її роботу і швидко реагує.
Регулярні зміни. Постачальники моделей оновлюють версії, змінюють умови й ціни. Хтось має перевіряти, чи не погіршилася якість після оновлення, і адаптувати систему.
Достатнє навантаження. Якщо на окремого фахівця є роботи лише на кілька годин на тиждень, повна ставка навряд чи окупиться. Краще поєднати роль з іншою або залучити зовнішню допомогу.
Ми не наводимо зарплат, строків пошуку чи універсальної чисельності команди: вони сильно залежать від ринку, рівня фахівця і задач. Розраховуйте їх на основі власного портфеля робіт і реальних пропозицій кандидатів.
Сигнали, що окрема роль уже потрібна
Часто компанія доходить до рішення про наймання не через план, а через накопичені проблеми. Ось ознаки, які варто помічати раніше:
- Черга запитів від відділів росте. Продажі, підтримка і фінанси просять нові сценарії, а їх ніхто не встигає оцінити, не те що реалізувати.
- Збої помічають клієнти, а не команда. Бот перестав записувати заявки в CRM, і про це дізналися зі скарги. Значить, ніхто не відповідає за моніторинг.
- Знання тримається на одній людині. Програміст, який «трохи займається ШІ», пішов у відпустку, і ніхто не може змінити навіть інструкцію асистента.
- Оновлення моделі стають сюрпризом. Постачальник змінив версію, відповіді стали іншими, а порівняти «до і після» нема на чому, бо контрольних прикладів немає.
- Витрати на сервіси ростуть без пояснення. Ніхто не стежить, які сценарії і скільки споживають.
Якщо ці проблеми повторюються, оцініть обсяг незакритої роботи й вирішіть, як закріпити відповідальність: за внутрішнім фахівцем, через перерозподіл обов'язків чи договором із підрядником.
Коли допомагає зовнішній партнер
Підрядник має сенс у кількох ситуаціях:
- Пілот. Потрібно швидко перевірити гіпотезу, а наймати людину до появи результату ризиковано.
- Рідкісна компетенція. Наприклад, розгортання моделі на власній інфраструктурі чи складна інтеграція з галузевою системою, яка знадобиться один раз.
- Прискорення старту. Внутрішня команда вчиться на першому проєкті разом з підрядником.
Головний ризик зовнішньої допомоги: знання і доступи лишаються в підрядника. Тому ще до старту домовтеся про передавання:
- документацію архітектури і логіки обробки даних;
- усі доступи, ключі й акаунти на ім'я компанії, а не підрядника;
- опис даних, полів і правил;
- набір контрольних прикладів і спосіб вимірювання якості;
- інструкції з експлуатації: що робити при збої, як оновлювати, де дивитися журнали;
- зрозумілі умови, на яких підтримка переходить до вашої команди.
Як обирати фахівця
Співбесіда, на якій кандидат демонструє «красиві промпти», мало говорить про здатність побудувати робочу систему. Краще дати практичне завдання, наближене до ваших реальних ризиків.
Навчальне практичне завдання для кандидата
Задача: спроєктувати обробку заявки з сайту, яку ШІ класифікує і записує в CRM.
Попросіть кандидата описати письмово або на зустрічі:
- Дубль. Що робить система, якщо та сама заявка прийшла двічі за п'ять хвилин?
- Таймаут. Що відбувається, якщо сервіс моделі не відповів за відведений час? Заявка не має загубитися.
- Невідоме поле. У формі з'явилося нове поле, якого немає в CRM. Як система реагує?
- Оцінка якості. Як перевірити, що класифікація правильна? Скільки контрольних прикладів потрібно і хто їх розмічає?
- Передавання супроводу. Що має отримати інша людина, щоб підтримувати систему без автора?
- Вартість супроводу. Від чого залежатимуть щомісячні витрати і як їх контролювати?
Хороша відповідь не обов'язково ідеальна, але показує, що кандидат думає про помилки, дані, вимірювання і про те, що буде після запуску. Це завдання підходить і для оцінки підрядника.
Як відрізнити сильну відповідь від слабкої:
| Питання | Слабка відповідь | Сильна відповідь |
|---|---|---|
| Дубль | «Модель сама зрозуміє, що це повтор» | Перевірка за ключем заявки або комбінацією полів до виклику моделі, запис у журнал |
| Таймаут | Не згадано | Повторна спроба з обмеженням, черга, сповіщення відповідальному, заявка не губиться |
| Невідоме поле | «Додамо, коли з'явиться» | Поле зберігається окремо, система повідомляє власника, CRM не ламається |
| Оцінка якості | «Подивимось, чи все працює» | Розмічений набір прикладів, метрика, повторне вимірювання після змін |
| Супровід | «Я завжди на зв'язку» | Документація, доступи компанії, інструкція для іншої людини |
Таблицю можна використати як шкалу оцінки на співбесіді. Для технічної оцінки відповідей залучіть інженера: сама наявність правильних слів про збої ще не підтверджує здатності реалізувати рішення.
Що зробити на своєму процесі
- Випишіть ШІ-задачі на найближчі місяці й позначте для кожної тип: готовий сервіс, інтеграція, база знань, власна інфраструктура.
- Для кожної задачі заповніть матрицю ролей і позначте, які обов'язки вже має хтось у команді.
- Оцініть, чи вистачить роботи на окрему посаду, чи роль краще поєднати з іншою або закрити зовнішньою допомогою.
- Для ролей, які закриє наявна команда, визначте наставника, власника сценарію і виділений час на навчання.
- Підготуйте практичне завдання з дублями, таймаутом, невідомим полем, оцінкою якості й передаванням супроводу.
- Якщо залучаєте підрядника, запишіть у договорі перелік документації й доступів, які компанія отримає.
Часті запитання
Не обов'язково. Спершу визначте задачі, постійне навантаження і інженерні компетенції, яких бракує. Уміння формулювати запити корисне, але в реальних системах більша частина роботи припадає на дані, інтеграції, оцінку якості й супровід. Якщо ці задачі вже закриває хтось у команді, окрема посада лише під промпти може виявитися зайвою.
Лише в межах його компетенцій і повноважень. Аналітик часто чудово описує дані, правила й контрольні приклади, може налаштувати роботу в готовому сервісі. Але експлуатація, керування доступами, складні інтеграції та робота з інфраструктурою можуть потребувати інженерів. Якщо аналітик береться за це без досвіду, ризики переходять у продакшн-систему.
Документацію архітектури й логіки, усі доступи й акаунти на ім'я компанії, опис даних і полів, набір контрольних прикладів із способом вимірювання якості, інструкції з експлуатації та зрозумілі умови передавання підтримки. Ці пункти варто погодити до старту робіт і записати в договорі, а не обговорювати наприкінці проєкту. Якщо ви вирішуєте, як розподілити ролі в першому ШІ-проєкті, фахівці BotLabs за 15 хвилин допоможуть розібрати один процес: які задачі закриє ваша команда, де потрібна інженерна робота і що врахувати для супроводу. Разом визначимо реалістичний наступний крок.
Консультація щодо ролей для ШІ-проєкту
За 15 хвилин із технічним фахівцем BotLabs обговоримо один процес, наявні компетенції й потребу в інтеграціях та супроводі. Визначимо незакриті обов’язки й задачі, які потрібно оцінити перед рішенням про навчання, найм або підрядника.
Задачі процесу
Потрібні ролі
15 хвилин із фахівцем: розкладемо один процес на ролі й окреслимо роботу перед кадровим рішенням.
