Керівнику не потрібно вміти збирати автоматизацію власноруч, йому достатньо розуміти, з чого вона складається. Будь-який ланцюг має три частини: подію, яка його запускає, дії у відповідь і правило на випадок збою. Найчастіше ланцюги зупиняються саме на збоях: з'єднання прострочилося, поле у формі перейменували, дані в різних системах розійшлися, повтор спрацював двічі. Тому в технічному завданні підряднику треба описати і бажаний результат, і поведінку системи, коли щось пішло не так, кому приходить сповіщення про помилку і як ви приймете готову роботу.
Коротко
- Автоматизація складається з трьох частин: події, яка її запускає, дій у відповідь і правила на випадок збою.
- Сервіс автоматизації помічає подію або одразу, коли застосунок сам про неї повідомляє, або із затримкою, коли сервіс періодично перепитує застосунок.
- Більшість поломок трапляється на збоях: прострочене з'єднання, змінене поле, розбіжні дані, нескінченний цикл або дубль після повторної спроби.
- Технічне завдання описує подію, дії, поля даних, поведінку при збої, сповіщення, захист від дублів, доступи і спосіб приймання роботи.
- Роботу підрядника приймають тестовим прогоном усього ланцюга, перевіркою крайніх випадків і спільним переглядом журналу запусків.
З яких трьох частин складається будь-яка автоматизація?
Сервіс автоматизації працює як посередник між програмами компанії: сайтом, таблицею, поштою, системою обліку клієнтів. Сам зв'язок між ними тримається на програмних інтерфейсах, тобто на домовлених способах, якими одна програма передає дані іншій.
Перша частина називається тригером, і це подія, яка запускає ланцюг. Це може бути нова заявка з сайту, новий рядок у таблиці чи нова оплата. Сервіс дізнається про подію одним із двох способів. У першому випадку застосунок сам надсилає сигнал одразу, як тільки подія сталася, і ланцюг стартує практично миттєво. У другому випадку сервіс сам періодично опитує застосунок, чи з'явилося щось нове, і тоді реакція настає із затримкою від однієї до п'ятнадцяти хвилин залежно від тарифу. Спосіб визначає сам застосунок, змінити його налаштуваннями неможливо, тож для задач, де важлива швидкість, це варто з'ясувати заздалегідь.
Ще одна особливість тригера: ланцюг підхоплює лише нові записи, створені після його ввімкнення. Заявки, які надійшли вчора, до запуску автоматизації, він не обробить, і їх доведеться перенести окремо.
Друга частина складається з дій у відповідь: записати дані в таблицю, надіслати повідомлення, створити картку клієнта, відправити лист. Дії виконуються по черзі, і кожна спирається на дані попередніх кроків.
Третя частина найменш помітна і найважливіша: правило на випадок збою. Воно визначає, що робить ланцюг, коли якийсь крок не вдався, хто про це дізнається і як потім довести справу до кінця.
Як виглядає автоматизація заявки з форми на сайті?
Візьмімо типову ситуацію: інтернет-магазин або сервісна компанія приймає заявки через форму на сайті. Людина вводить ім'я, телефон, обирає послугу і залишає коментар. Після натискання кнопки форма передає ці дані сервісу автоматизації, і це подія, з якої все починається.
Далі йде перша дія: сервіс додає заявку новим рядком у таблицю. Кожне поле форми має потрапити у свій стовпчик, тому підрядник налаштовує відповідність між ними: поле [ім'я клієнта] йде в стовпчик з іменем, поле [телефон] у стовпчик з телефоном, поле [послуга] і поле [коментар] у свої стовпчики, а [час заявки] сервіс додає сам. Друга дія полягає в тому, що менеджер отримує повідомлення з коротким змістом заявки: ім'я, телефон і обрану послугу, щоб зателефонувати, не відкриваючи таблицю.
Правило на випадок збою тут відповідає на запитання: що станеться, якщо таблиця недоступна, хто дізнається, що повідомлення менеджеру не надіслалося, і як знайти заявки, загублені між кроками. Саме ці відповіді відрізняють робочий процес від демонстраційного.
Чому автоматизації між сервісами перестають працювати?
Ланцюг виглядає надійно, поки навколо нічого не змінюється. Хтось додав у форму нове поле або перейменував поле телефону, і сервіс більше не знаходить, звідки брати номер. Таблицю перемістили в іншу папку чи перейменували, і дія запису не має куди писати. Сервіс повідомлень відключився або в нього прострочилося з'єднання, і тоді запуски стоять у черзі, доки хтось не перепідключить обліковий запис.
Окрема група збоїв пов'язана з розбіжними даними. Типова схема: людина вказує в оплаті одну адресу пошти, а в заявці іншу, і система не розуміє, кому відкривати доступ або кому надсилати документи. Рішення тут організаційне: обрати одне головне джерело даних, отримувати повні дані про оплату одразу від платіжного сервісу і заздалегідь описати, що робити, коли дані не збігаються.
Буває і так, що сервіс упирається в ліміт запитів, тобто в обмеження, скільки звернень за певний час дозволяє інша програма. Ще небезпечніший нескінченний цикл: ланцюг пише в той самий ресурс, за яким стежить, або автоматичне повідомлення йде в той самий канал, звідки ланцюг бере події. Тоді кожен запуск породжує наступний, і ліміт витрачається дуже швидко.
Сервіси автоматизації вміють повторювати невдалий крок. В одного з них таких спроб буває до п'яти, з інтервалами, що зростають, а сповіщення про помилку надходить лише після останньої невдалої спроби. Збереження незавершених запусків для повтору в одного із сервісів за замовчуванням вимкнене, і це варто увімкнути свідомо. Тимчасові збої, як-от обрив з'єднання чи перевищений ліміт, можна повторити, решту доводиться виправляти вручну. Без налаштованої обробки збою ланцюг зупиняється, а якщо помилки повторюються майже щоразу, сервіс може сам його вимкнути.
Повтор має і зворотний бік: він не гарантує, що дія виконається рівно один раз. Якщо крок насправді спрацював, а сервіс вважав його невдалим, у таблиці з'явиться дубль рядка, а клієнт отримає лист двічі. Тому захист від дублів потрібен у кожному ланцюгу, де дія має наслідки.
Чим ці сервіси відрізняються для керівника?
Для керівника різниця між сервісами лежить у кількох площинах. Перша стосується місця роботи. Один варіант працює в хмарі постачальника, і за сервери відповідає він. Інший можна встановити на власний сервер компанії, і його безкоштовну версію можна запускати без ліміту запусків, але тоді сервер, оновлення, резервні копії і супровід стають відповідальністю компанії або підрядника.
Друга стосується способу оплати. Один із сервісів рахує кожну виконану дію. Інший нараховує кредити за кожну дію і за кожен запуск за розкладом, навіть якщо нових даних не було. Третій рахує завершені запуски цілого процесу незалежно від кількості кроків. Від цього залежить, яка схема буде вигіднішою саме для ваших обсягів, а актуальні тарифи варто перевірити в довідці обраного сервісу.
Третя стосується швидкості реакції на подію: миттєве спрацювання чи опитування із затримкою, і як це поєднується з вашими застосунками. Висновок для керівника такий: вибір сервісу підрядник має пояснити вам саме цими словами, через місце роботи, спосіб оплати, швидкість і відповідальність за супровід.
Що вписати в технічне завдання підряднику?
Технічне завдання спирається на опис процесу, який у компанії вже існує, і переводить його на мову ланцюга. Ось пункти, які варто охопити:
- Подія, що запускає ланцюг, і звідки вона береться: наприклад, нова заявка з форми [назва форми] на сайті.
- Кожна дія по порядку: що записується, куди надсилається, у якій послідовності.
- Перелік полів даних із прикладами у квадратних дужках: [ім'я клієнта], [телефон], [послуга], [коментар], [час заявки], і в який стовпчик чи поле кожне з них потрапляє.
- Поведінка при збої на кожному кроці: повторювати, зупинятися, відкладати або передавати на ручну обробку.
- Кому і куди приходить сповіщення про помилку, з яким змістом і як швидко хтось має відреагувати.
- Захист від дублів: за якою ознакою система розпізнає, що заявка чи оплата вже оброблена.
- На чиїх облікових записах компанії створюється автоматизація, хто має доступи і як їх передати при зміні підрядника.
- Спосіб приймання роботи: тестовий прогін, перелік крайніх випадків і хто підписує результат.
Краще поставити вузьку задачу з конкретними точками обміну даними і прикладами реальних файлів, ніж просити зробити інтеграцію з усім. Буває, що з боку облікової системи підряднику доручають підготувати лише дві точки обміну з описом, а першим перевіряють один зрозумілий випадок. Буває й так, що завдання генерують одним запитом до ШІ, отримують розмитий текст і повертаються до першої версії, доповнюючи її зауваженнями та прикладом реального файлу.
Чому не варто збирати робочу автоматизацію самому за відеоуроком?
За відеоуроком легко зібрати сценарій, який працює в ідеальному випадку: заповнили форму, рядок з'явився, повідомлення прийшло. Зазвичай у такому сценарії немає обробки збоїв, сповіщень про помилки і захисту від дублів. Зупиняється такий ланцюг тихо, і помічають це, коли клієнт поскаржився, що йому ніхто не передзвонив.
Власний прототип корисний для розуміння логіки подій і дій. Робочий процес, від якого залежать заявки й гроші, краще віддати тому, хто відповідатиме за його супровід. Під час вибору виконавця варто попросити тестове завдання з акцентом на журнали запусків, повторні спроби і захист від подвійного виконання.
Як прийняти роботу підрядника?
Приймання починається з тестового прогону, який ви проходите самі. Залиште тестову заявку на сайті, а якщо ланцюг пов'язаний з оплатою, створіть тестовий продукт за символічну ціну і оплатіть його. Перевірте рядок у таблиці, повідомлення менеджеру і розташування всіх полів.
Далі перевірте крайні випадки. Спробуйте інший спосіб оплати, бо саме там звірку часто ще не тестували і є ризик відкрити доступ не тим людям. Вкажіть у заявці й оплаті різні адреси пошти, залиште необов'язкове поле порожнім, надішліть ту саму заявку двічі. Кожен випадок має закінчитися результатом, описаним у завданні.
Перегляньте разом із підрядником журнал запусків, тобто історію, де видно кожне спрацювання ланцюга і результат кожного кроку. Попросіть показати, що станеться при збої: відключіть тестове з'єднання і подивіться, хто і яке сповіщення отримає. Наостанок домовтеся, хто супроводжує ланцюг після запуску і вносить зміни, коли форма чи таблиця зміниться.
Що робити далі
- Оберіть один повторюваний процес, наприклад обробку заявок із сайту, і запишіть для нього подію, дії і бажане правило на випадок збою.
- Складіть перелік полів даних цього процесу з прикладами у квадратних дужках і підготуйте реальний файл або знімок форми для підрядника.
- Визначте, хто в компанії отримуватиме сповіщення про помилки і на чиїх облікових записах буде створена автоматизація.
- Попросіть підрядника пояснити вибір сервісу через місце роботи, спосіб оплати, швидкість реакції і відповідальність за супровід.
- Підготуйте сценарій приймання: тестову заявку, тестову оплату за символічну ціну і перелік крайніх випадків, які ви перевірите разом.