Автоматизация с помощью Make: самый мощный инструмент
Что Make на самом деле делает, если убрать маркетинг
Если убрать маркетинговые формулировки, Make - это инструмент, который умеет говорить «если в одной системе произошло X, сделай Y в другой системе» без единой строчки кода. Новая заявка попадает в форму, Make добавляет её в CRM, отправляет сообщение в Slack в канал продаж и записывает строку в таблицу для отчётности, всё из одного триггера. Для малого бизнеса, который работает на нескольких не связанных между собой инструментах, система бронирования, бухгалтерский сервис, CRM, платформа рассылок, одно это убирает заметную часть ручного копирования, которое съедает чью-то рабочую неделю.
Где он реально окупается
Самые понятные победы намеренно скучные: надёжная, повторяющаяся, чётко описанная передача данных между двумя-тремя системами, где данные уже чистые. Заказ подтверждён в магазине - счёт создан в бухгалтерском сервисе. Клиент подписал договор - создана папка на общем диске и отправлено приветственное письмо. Тикет поддержки закрыт - через три дня запущен опрос удовлетворённости. Ни один из этих сценариев не требует суждения, они требуют последовательности, а именно последовательность малый бизнес обычно и теряет, когда всё держится на том, что кто-то не забудет сделать одни и те же пять кликов каждый раз.
Ловушка попытки автоматизировать всё
Поскольку Make технически может связать почти любые два инструмента с API, возникает соблазн построить один гигантский сценарий, который пытается охватить все ветки процесса: обычные заказы, возвраты, частичные возвраты, нестандартные запросы, VIP-клиентов и все исключения, какие только можно придумать. Именно на этом этапе выгода обычно заканчивается. Сценарий с десятком ветвлений становится сложно читать, ещё сложнее отлаживать и по-настоящему рискованно менять, потому что правка одной ветки ради мелкого исправления может незаметно сломать другую, о которой в этот день никто не думал.
Что ломается тихо, и почему это важнее того, что ломается громко
Сценарий, который падает целиком, раздражает, но по крайней мере заметен: кто-то получает уведомление об ошибке и чинит её. Более дорогой сценарий поломки - это автоматизация, которая продолжает работать, но начинает делать не то: поле привязано не к той колонке после того, как исходное приложение поменяло структуру данных, лимит запросов тихо теряет записи вместо того, чтобы выдать ошибку, сценарий задваивает действие, потому что сработал повтор, которого никто не заметил. Ничего из этого не проявляется, пока кто-то реально не следит за историей выполнения автоматизации, а для многих небольших команд это значит, что сбои копятся месяцами, пока проблему не вскроет жалоба клиента.
Стоимость и сложность, которые нарастают со временем
Make берёт оплату за количество операций, и сценарий, который казался дешёвым при пяти подключённых приложениях и сотне запусков в месяц, заметно дорожает, когда вырастает до пятнадцати приложений и тысяч операций, особенно если он выполняет лишнюю работу вроде опроса системы каждые несколько минут вместо реакции на вебхук. Сложность добавляет издержки менее заметные, но, пожалуй, более серьёзные: после года правок от разных людей набор сценариев может превратиться в нечто, что реально понимает только один человек в компании, а это уже своя форма хрупкости.
Понимать, где проходит граница
Make - сильный выбор для соединения уже существующих инструментов и надёжной передачи данных между ними. Он куда слабее там, где нужно реальное суждение, тонкий разговор или обработка, которая заметно меняется от случая к случаю, это обычно должно оставаться за человеком или узкоспециализированной системой, а не за блок-схемой из шагов «если это, тогда то». Компании, которые получают от Make больше всего пользы, обычно относятся к нему как к соединительной ткани между уже проверенными инструментами, а не как к основной логике самого бизнеса. Хороший тест простой: если объяснить сценарий новому сотруднику занимает больше пяти минут, вероятно, стоит разделить его на части поменьше.
Как выглядят разросшийся и компактный сценарии рядом
Представьте две версии одного и того же сценария для небольшого интернет-магазина. Разросшаяся версия пытается провести все типы заказов через один поток: обычные заказы, заказы с промокодом, заказы, помеченные как подарок, международные заказы, которым нужна таможенная форма, и запросы на возврат - всё внутри одного сценария с десятком условных ветвлений. Когда через полгода магазин добавляет новый тип скидки, кто-то правит одну ветку, и совершенно не связанная с ней ветка, отвечающая за международные заказы, тихо перестаёт правильно заполнять таможенное поле, потому что обе ветки использовали общий шаг сопоставления данных, о связи которого никто не подозревал.
Компактная версия делит это на три-четыре отдельных, более простых сценария: один для подтверждения обычного заказа, один для возвратов, один для сравнительно редкого международного случая - каждый настолько простой, что новый сотрудник мог бы прочитать его за пару минут и понять, что именно он делает. На такое разделение уходит чуть больше времени на планирование заранее, но это несопоставимо облегчает исправление, расширение или передачу сценария другому человеку позже, а это важнее лишнего часа, потраченного на то, чтобы сделать это правильно с самого начала.