Що робить інженер, який працює безпосередньо, та коли вам потрібен такий фахівець

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

Такий спосіб роботи підходить також для малих та середніх компаній, можливо, навіть краще. У малому бізнесі рідко буває внутрішня IT-команда, яка могла б перетворити нечітку ідею („Чи може ШІ читати наші сертифікати постачальників?“) на технічні вимоги. Тут потрібна людина, яка зможе провести дослідження, написати код та відповідати за результат.

Що насправді виконує ця посада

Більша частина роботи відбувається до та після написання коду. Типове проектування проходить через чотири етапи:

• Виявлення проблем. Інтерв’ю з людьми, які виконують роботу, ознайомлення з реальними документами, таблицями та системами, а також письмовий опис поточного процесу з його винятками. Саме винятки мають найвище значення, адже саме там автоматизація може зазнати невдачі.
• Прототипування. Робочий інструмент на зразку реальних даних протягом кількох днів, а не презентація. Він ще не досконалий, але люди можуть ним скористатися та вказати, що не так.
• Впровадження. Контроль доступу, обробка помилок, журналування, моніторинг, резервне копіювання, етап перевірки, під час якого людина схвалює сумнівні результати, та набір тестів, які показують, чи інструмент все ще працює після кожної зміни.

Передача та підтримка. Документація, коротке навчання для команди та узгоджений спосіб повідомлення про проблеми та подання запитів на зміни.

У чому він відрізняється від класичного проекту

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

Автоматизація з використанням ШІ рідко є добре зрозумілою на початковому етапі. Ніхто не знає, скільки рахунків мають дивну структуру, як часто постачальник надсилає скан замість PDF чи яке правило бухгалтер застосовує, не записуючи його. Інженер, який працює безпосередньо над проектом, з’ясовує це, працюючи з матеріалом, тож обсяг робіт визначається на основі доказів, а не припущень.

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

Коли малому бізнесу потрібен такий фахівець

Ця модель є доцільною, коли справджуються кілька з наступних умов:

• повторюваний процес забирає кілька годин щотижня: читання документів, копіювання даних між системами, перевірка термінів, відповіді на однакові запитання;
• дані знаходяться в багатьох місцях: ERP або 1C, файли Excel, вкладення електронної пошти, спільні папки, відскановані документи;
• хтось вже пробував чат-бота або прототип ChatGPT, і він працює під час демонстрації, але не у реальних ситуаціях;
• немає внутрішнього розробника, який добре розуміє як бізнес, так і технології.

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

Що очікувати протягом перших двох тижнів

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

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

Питання, які варто поставити перед тим, як найняти когось

• Чи буде інженер працювати з нашими справжніми даними з першого тижня, і як контролюється доступ?
• Як ми дізнаємося, що інструмент є правильним? Попросіть набір для тестування та показники ефективності, а не обіцянки. Наші нотатки про оцінювання та людський огляд описують, як це виглядає.
• Де виконуються моделі, і чи виходять наші дані за межі нашої інфраструктури? Щодо конфіденційних файлів дивіться локальний ШІ для конфіденційних документів.
• Що відбувається після передачі: хто це виправляє, якщо постачальник змінює формат рахунку-фактури?

Якщо відповіді будуть нечіткими, проект також буде нечітким. Якщо ви хочете обговорити конкретний процес, наша сторінка forward-deployed engineering описує, як ми виконуємо такі завдання, і ви можете відповісти нам через форму зворотного зв’язку.