Если хочется автоматизировать то, чего нет

Временами нам приходится сталкиваться с желанием заказчика сделать автоматизацию ради автоматизации – а процесса, который хочется автоматизировать, просто не существует. Либо он нарушен, например, в результате слияния или реорганизации. Заказчик предлагает использовать agile-подход: начнем с чего-нибудь, в процессе разберемся и запустим следующую итерацию, а там видно будет.

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

Если хотя бы на уровне целей верхнего порядка заказчик не понимает, чего хочет, – никакие agile, scrum или digital transformation не помогут. Agile-подход дает невероятные результаты, намного лучше, чем классический водопадный метод. Он позволяет существенно сократить расходы, ускорить процесс и повысить качество. Но он работает, если общая картина понятна, когда можно спланировать спринты на пути к цели.

Возьмем для примера процесс оценки: У вас будут цели или KPI? Или и цели, и KPI? Будете ли учитывать компетенции? Процедура будет квартальной, годовой или полугодовой? Даже если заказчик пока не представляет себе оценочные формы или как будет формироваться ИПР, на вопросы верхнего уровня нужно иметь ответы.

Допустим, уже известно, что процедура оценки будет состоять из трех больших блоков: постановка целей, промежуточная оценка и итоговая оценка. В первом спринте реализуется процедура постановки – и по итогам пилотного запуска формируются новые требования и дополнения. В следующем спринте заказчик получает обновленную версию. Она выкатывается на следующий пилот, и после этого, например, принимается решение масштабировать ее на всю компанию. Это нормальный, правильный подход.

Неправильный подход – это когда разработчик настраивает всю процедуру оценки, но за три дня до запуска заказчик решает поменять постановку целей. К примеру, была постановка целей с каскадированием сверху вниз, а теперь будет снизу вверх, и не цели, а KPI. Это не agile. Такой проект не сможет работать и не взлетит.

Еще одна проблема автоматизации, с которой мы сталкиваемся в контексте несуществующих процессов – избыточно сложные процедуры, в которых учтено слишком много гипотетических и частных случаев. Ответственный за автоматизацию может не понимать процесс полностью и в силу этого бояться что-то пропустить. Кажется, что подстраховать себя и предусмотреть разные варианты – вполне естественно. Но это полностью противоречит логике гибкой модели.

В гибкой модели главное – это:

1. Сделать то, что очевидно и понятно работает – решение, в котором есть то, что вам действительно нужно.
2. Добавлять новые возможности лишь по мере поступления обратной связи от пользователей и анализа реальных кейсов. – 3. Решение изменить что-то или добавить стоит принимать с помощью опроса пользователей.
4. При этом задачу действительно стоит автоматизировать, если она массовая – затронет сотни пользователей и тысячи реальных сценариев. Если задача описывает единичные случаи, стоит учесть ее в процессе, но не автоматизировать: в единичных случаях лучше искать простые решения.

В качестве итога – три главных тезиса:

– Если вы не знаете, что хотите получить – agile не поможет.
– Изменения на лету – зло, если они не реализуются в логике agile.
– Избыточно сложные процедуры – от непонимания процесса.