Сузьте проблему

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

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

Другой пример — календарный вид из главы 1. Все знают, что такое календарный вид. Но стоило разобрать запрос, как обнаружилось множество неизвестных и решений, которые радикально влияли бы на объём работы. Если мы хотим потратить лишь шесть недель вместо шести месяцев на огромный календарь, как сузить задачу?

В таком случае мы переключаемся с вопроса «Что мы могли бы создать?» на вопрос «Что на самом деле идёт не так?». Конечно, календарь звучит заманчиво. Но что стоит за запросом? В какой именно момент привычный рабочий процесс человека перестаёт работать без того, о чём он просит?