Автоматизация без фанатизма: что не надо трогать

Про то, что автоматизировать, написано много. Про то, что трогать не стоит, почти ничего — а именно этот список экономит бюджеты.

Дальше — пять признаков, при которых я советую не начинать, и один приём, который чаще автоматизации даёт результат.

Признак 1: правила меняются быстрее, чем окупается работа

Простая арифметика, которую почему-то редко проделывают до старта.

Пусть автоматизация экономит два часа в неделю и стоит сто часов разработки. Окупаемость — год. Если регламент, на котором она построена, переписывается раз в квартал, вы будете чинить её четыре раза за этот год, и каждая починка съест часть экономии.

Практический критерий: если период между изменениями правил меньше расчётного срока окупаемости — не начинайте. Вернитесь, когда правила устоятся, или сначала добейтесь, чтобы они устоялись.

Признак 2: объём ниже порога внимания

Пять заявок в неделю не нужно автоматизировать. Человек справится быстрее, чем вы опишете исключения.

Порог обычно проходит где-то около нескольких десятков однотипных операций в неделю, но точное число зависит не от объёма, а от того, сколько времени занимает одна операция и сколько в ней разнообразия. Полезнее считать не штуки, а часы: если суммарно на процесс уходит меньше рабочего дня в неделю, автоматизация почти наверняка не окупится.

Признак 3: дорогая ошибка при дорогой проверке

Опасное сочетание. Автоматизация даёт скорость, а скорость на дорогих ошибках — это ускоренное падение.

Порядок здесь обратный привычному: сначала сделать проверку дешёвой, потом автоматизировать. Иногда «сделать проверку дешёвой» и есть весь проект, а автоматизация после него оказывается не нужна.

Признак 4: нет владельца

Автоматизированный процесс без владельца — это система, которая молча ломается. Причём ломается она незаметно: пока результат кому-то нужен, поломку заметят; если результат никому не нужен, поломку не заметят никогда, и вы годами будете платить за поддержку контура, который выдаёт мусор.

Найдите человека или не начинайте.

Признак 5: процесс существует по инерции

Самый неудобный признак, потому что проверяется он неудобным вопросом: что случится, если этот процесс просто перестанет выполняться?

Ответ «ничего» встречается чаще, чем принято думать. Отчёт, который никто не открывает. Согласование, которое ни разу не закончилось отказом. Поле в форме, которое заполняют, потому что оно обязательное.

Автоматизировать такое — значит закрепить его навсегда. После автоматизации процесс становится дешёвым, а дешёвое не отменяют.

Приём, который чаще выигрывает

Прежде чем звать модель, попробуйте удалить работу.

Убрать шаг. Объединить две формы в одну. Отказаться от согласования, которое за год ни разу не привело к отказу. Заменить свободный текст выбором из списка — тогда половина обработки перестаёт быть нужной.

Это скучно, не выглядит инновационно и почти всегда даёт больше, чем интеграция. У приёма есть и побочный эффект: после упрощения оставшаяся работа становится настолько регулярной, что автоматизировать её — если она всё ещё нужна — уже легко.

Условие, при котором приём не работает: если шаг существует из-за внешнего требования — регулятор, контрагент, закон. Тогда удалять нечего, и надо автоматизировать как есть.

Подмена, которую легко не заметить

Есть отдельный класс проектов, где автоматизируют не тот процесс, о котором шла речь. Выглядит это так: команда не может договориться, каким должен быть результат, и вместо того чтобы договориться, начинает строить систему. Система откладывает спор, потому что пока она строится, спорить не о чем.

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

Разногласие автоматизировать нельзя. Оно всплывёт при приёмке, только дороже: теперь у него есть код, сроки и чьё-то авторство.

Лечится это до начала работ и стоит полдня: взять двадцать реальных случаев и попросить двух человек независимо записать, какой результат они считают правильным. Расхождения будут, и они и есть настоящая первая задача.

Что считать до начала

Минимальная смета, которую я прошу составить до первой строчки кода:

• разработка — часы;
• эксплуатация — сколько часов в месяц будет уходить на поддержку, включая разбор сбоев;
• изменения — сколько раз в год меняются правила и сколько стоит одна адаптация;
• проверка — сколько времени человек тратит на контроль результата, и не растёт ли эта величина вместе с объёмом.

Последний пункт пропускают чаще всего, и он же чаще всего убивает проект. Если проверка растёт линейно с объёмом, вы не автоматизировали процесс, а переложили его на другого человека.

Соотнесите сумму с экономией. Если разница меньше двух раз, я бы не брался: оценки на старте систематически оптимистичны, и двукратный запас — это не осторожность, а поправка на известную ошибку.

Где я сам ошибался в оценках

Систематически недооцениваю стоимость исключений. На старте видны три сценария, к запуску их оказывается двенадцать, и последние пять стоят дороже первых семи вместе взятых.

Помогает одно: не пытаться покрыть все исключения, а с самого начала проектировать очередь для необработанного. Контур, который честно откладывает пятнадцать процентов случаев в ручную обработку, запускается за недели. Контур, который обязан покрыть всё, не запускается никогда.

Открытый вопрос

Не знаю, как убедительно считать риск отложенной поломки. Автоматизация работает год, потом меняется формат данных на входе, и починка стоит дороже, чем всё, что было сэкономлено.

Формально это учитывается в статье «изменения», но на практике никто не закладывает туда редкое и крупное событие. Пока просто держу в голове, что любой контур переживает своих авторов и что документация к нему — часть стоимости, а не необязательное приложение.