«Быстрее» и «проще» — не одно и то же

«Давайте сделаем это быстрее» и «давайте сделаем это проще» звучат как одна задача. Но. Это разные задачи, и путаница между ними стоит команде денег.

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

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

У нас в компании была похожая ситуация, только с другим уроком. Менеджерам регулярно нужно было редактировать документы задним числом — и каждый раз для этого требовался разработчик. Долго, неудобно, зависимость от чужого времени. Первая идея была очевидной: сделать это проще — дать менеджерам такую возможность прямо в системе, без разработчика. Уже начали прикидывать интерфейс. Но когда разобрались, почему вообще документы редактируют задним числом так часто, оказалось: дело не в неудобном процессе, а в том, что сам процесс был построен неправильно. Задним числом правили не потому, что это нормальная часть работы, а потому что где-то раньше терялись или неверно вносились данные — и редактирование постфактум было костылём, который чинил чужую ошибку.

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