Я не люблю начинать с готового решения

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

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

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

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

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

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

Я не считаю, что всё можно измерить идеально.

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

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

Даже простые данные могут сильно изменить понимание ситуации. Иногда они подтверждают интуицию. Иногда полностью её ломают. И это нормально: хороший вывод должен выдерживать встречу с фактами.

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

Личный опыт — сильный источник понимания. Через него появляются вопросы, наблюдения, интуиция и первые выводы.

Но опыт ограничен.

Один яркий случай не всегда показывает закономерность. То, что сработало в одной системе, может не сработать в другой. Поэтому я стараюсь не останавливаться на мысли: «У меня так было, значит так устроено всегда».

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

Так личный опыт остаётся источником наблюдений, но не превращается в набор необоснованных убеждений.

Техническое решение не существует отдельно от людей.

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

Поэтому при работе с системой важно смотреть не только на схему процесса, но и на людей внутри неё.

Кто будет пользоваться решением? Понимает ли человек, зачем это нужно? Не создаёт ли новый порядок лишнюю нагрузку или поведение, которого в реальности не будет?

Если решение игнорирует людей, оно может выглядеть логичным, но не прижиться.

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

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

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

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