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

Но названное средство ещё не обязательно отвечает на другой вопрос: что именно человек хочет сделать возможным или изменить — и где сейчас находится препятствие этому изменению?

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

Только после этого имеет смысл решать, что именно делать, в каком объёме и сколько этого будет достаточно.

Сначала — что должно стать иначе

Иногда человек достаточно точно понимает, чего ему не хватает, но пока не знает, как это устроить.

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

В такой ситуации всё намерение может собраться в одном знакомом слове: «курс».

Но слово «курс» здесь ещё не обязательно означает, что уже определены формат, объём, платформа и способ работы с людьми. Иногда оно означает гораздо более общее: я хочу, чтобы моё знание стало доступно другим без моего постоянного физического присутствия, но пока не понимаю, как именно это сделать.

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

Этого мы пока не знаем.

Интереснее сначала посмотреть на существующую ситуацию.

Что сейчас происходит такого, что человек хочет изменить? Чего именно не хватает? Что он хочет получить вместо этого? Для кого изменение должно произойти? Где оно должно стать заметным?

Мне бывает полезен и более простой поворот: если бы сейчас можно было изменить в этой ситуации что угодно, но только одно — какое небольшое изменение уже имело бы значение?

Не какое решение нужно купить. А что стало бы иначе.

Например, материалами впервые можно было бы пользоваться без личного объяснения автора. Клиенту стало бы понятно, что именно ему предлагают. Важная часть работы перестала бы постоянно возвращаться к одному человеку. Разрозненные материалы начали бы выполнять какую-то функцию, а не просто храниться. Появилась бы возможность проверить интерес к идее до большого вложения в неё.

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

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

Задача должна помещаться в реальные обстоятельства

Даже понятное желаемое изменение ещё не определяет объём работы.

Следующий вопрос — что человек реально может сейчас осуществить.

Речь не только о бюджете.

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

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

Можно найти силы один раз запустить проект, но не хотеть каждую неделю его сопровождать.

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

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

Можно автоматизировать действия — и получить вместе с этим новые обязанности по сопровождению системы.

Поэтому для меня недостаточно вопроса «можем ли мы это сделать?».

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

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

Посильная задача — не урезанная цель.

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

Достаточно — относительно чего?

Отсюда появляется вопрос об объёме.

Слово «минимальный» легко понять как «самый дешёвый» или «сделанный попроще». Я имею в виду не это.

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

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

Но это верно только тогда, когда более простой вариант действительно делает то, ради чего всё началось.

Если из него убрано именно то, что должно было изменить ситуацию, это уже не минимально достаточное решение. Оно просто недостаточно.

Поэтому один из самых полезных вопросов здесь звучит для меня так:

что мы сознательно не делаем сейчас — и почему?

И такой же вопрос нужен к более полной реализации.

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

Или потому, что это просто технически возможно сделать?

Максимальная реализация тоже не является целью сама по себе.

Иногда достаточный результат гораздо меньше потенциального проекта.

Решение задачи и проверка предположения — разные вещи

Есть ещё одно различие, без которого разговор о «минимальном» легко становится неточным.

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

В одном случае он уже создаёт полезное изменение. Пусть не всё возможное, но достаточное на текущем этапе.

В другом случае его задача — пока только проверить существенное предположение.

Возьмём явно условный пример.

У человека есть сложная профессиональная услуга. Ему кажется, что потенциальным клиентам трудно понять её ценность.

Можно сразу переделать весь сайт, всю структуру предложения и весь путь до обращения.

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

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

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

Это была проверка предположения.

Она должна быть достаточно содержательной, чтобы после неё можно было принять следующее решение.

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

Обе вещи могут быть небольшими по объёму, но это разные виды результата.

Первый шаг не обязан быть уменьшенной копией большого проекта

Из-за этого первый разумный шаг не всегда выглядит как первые десять процентов будущей полной системы.

Иногда нужно собрать один работающий участок.

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

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

Иногда — решить конкретное затруднение и посмотреть, возникла ли после этого необходимость в следующем уровне.

А иногда уже на этом этапе становится понятно, что практическую часть имеет смысл выполнить мне самой.

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

В начале разбора мы ещё не знаем, какая практическая форма окажется подходящей.

Сайт — один из возможных результатов, но не обязательный. То же касается автоматизации, приложения, структуры материалов или другого цифрового объекта.

Практическая часть определяется задачей, а не наоборот.

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

«Результат» — это не одно событие

Когда что-то уже сделано, возникает другая трудность: одним словом «результат» начинают называть несколько разных вещей.

Первый уровень — готовность самого объекта.

Сайт опубликован. Материалы собраны. Документ подготовлен. Система технически работает.

Это полноценный результат исполнения.

Но он отвечает только на один вопрос: сделали ли мы согласованную работу.

Следующий уровень — признаки движения.

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

Это уже говорит о связи между созданным объектом и реальной ситуацией.

Но и это ещё не всегда желаемое изменение.

Третий уровень — изменилось именно то, ради чего работа начиналась.

Если человек хотел сделать свои знания доступными без постоянного личного присутствия — действительно ли ими теперь можно пользоваться без него?

Если хотел уменьшить зависимость процесса от себя — стало ли его участие меньше?

Если хотел, чтобы предложение стало понятнее нужным людям, — изменилось ли именно их понимание?

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

Не только денежная.

Можно ли его обслуживать? Обновлять? Использовать без постоянного перенапряжения? Не появилось ли вокруг созданного столько новой работы, что исходная польза начинает исчезать?

Не обязательно превращать все эти вещи в цифровые показатели.

Некоторые изменения вполне проверяемы качественно.

Но полезно хотя бы не смешивать их между собой.

Созданный объект не доказывает автоматически движение.

Признаки движения ещё не доказывают полного желаемого изменения.

А желаемое изменение не отвечает само по себе на вопрос, жизнеспособна ли система дальше.

И что будет, если решение заработает?

Есть ещё один вопрос, который иногда стоит поставить раньше, чем кажется:

что произойдёт, если всё это действительно начнёт работать?

Он не означает, что любой проект нужно заранее строить «на масштаб».

Иногда масштабирование вообще не нужно.

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

Но если увеличение объёма является частью намерения, полезно заранее заметить, что вместе с ним будет расти.

Больше пользователей — это только хорошо или вместе с ними появляется поддержка?

Больше материалов — увеличивают ценность или создают необходимость постоянно поддерживать сложную библиотеку?

Больше автоматизации — действительно уменьшает человеческое участие или переносит его в другое место?

Больше клиентов — можно обслужить существующим способом или при определённом объёме сама модель работы должна измениться?

И главное: хочет ли человек вообще этого следующего масштаба?

Техническая возможность расширения ещё не является основанием его планировать.

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

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

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

Здесь снова нет универсального ответа. Есть связь между желаемым изменением, ресурсом и ценой дальнейшего существования выбранного способа.

Корректировать решение — не значит менять критерий задним числом

Работа почти никогда не развивается точно по первоначальной схеме.

Появляются новые обстоятельства. Что-то оказывается сложнее. Предположение не подтверждается. Возникает информация, которой раньше не было.

Тогда можно изменить способ.

Можно уменьшить или увеличить объём.

Добавить ресурс.

Отложить часть работы.

Привлечь человека с другой компетенцией.

Остановиться.

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

Это нормальная корректировка.

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

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

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

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

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

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

Тогда корректировка сохраняет связь с реальностью.

Подмена критерия эту связь уничтожает.

Иногда достаточный результат — понять, что больше делать не нужно

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

Прояснение не обязано закончиться большим проектом.

Иногда оказывается, что первоначально названное средство сейчас вообще не нужно.

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

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

Иногда ограниченного изменения уже достаточно.

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

Это не обязательно неудача.

Если исходный вопрос был «что действительно стоит делать?», ответ «сейчас этого достаточно» или даже «сейчас дальше не делать» может быть вполне практическим.

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

Можно прийти с происходящим сейчас. С тем, что хочется изменить. С идеей. С материалами. С ощущением нехватки чего-то, чему пока трудно дать название. Даже с уже названным решением, если пока непонятно, действительно ли оно нужно и в каком объёме.

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

А когда появляется достаточно определённая практическая задача, отдельно становится видно, какую её часть я могу взять на себя.

Если вы находитесь в такой ситуации, можно просто написать мне. Не нужно сначала самостоятельно превращать её в правильный brief.