Урок 2.1 · Как объяснить задачу программисту · Модуль 2. Кто будет пользоваться · Бесплатно
Цель урока: Научиться описывать, кто именно пользуется системой и что делает.
Зачем это нужно: Пока непонятно, кто именно пользуется системой, любая функция кажется нужной — и объём работы растёт вдвое. Проверить это нечем: спорить не с кем, потому что «пользователь» — это никто. Он не звонит, не путается и не уходит на середине. Поэтому в задаче появляются «личный кабинет», «уведомления» и «настройки», а потом выясняется, что клиенту нужно было одно поле и одна кнопка.
Как это работает: Опишите каждого пользователя отдельно: кто он, что делает и что получает. Кто он — не роль в системе, а человек с обстоятельствами: «клиент, который листает телефон в метро и одной рукой держится за поручень». Обстоятельства объясняют, почему одни шаги допустимы, а другие нет. Что делает — последовательность действий, а не экранов. Не «страница записи», а «открывает ссылку, выбирает услугу, выбирает время, оставляет имя и телефон, подтверждает». Экраны появятся позже, действия нужны сейчас. Что получает — чем заканчивается сценарий: подтверждение, запись в расписании, готовый документ. Если конца не видно, сценарий не дописан. Сценарий — это путь от начала до результата: вошёл, выбрал, подтвердил, получил. У него есть начало (откуда человек пришёл) и конец (что у него осталось на руках). Если пользователей несколько, у каждого свой сценарий, и они не должны мешать друг другу. Проверка простая: пройдите сценарий одного и спросите, что в этот момент происходит у другого.
Продолжим нашу парикмахерскую. Пользователей трое, и все трое разные. Клиент. Он в метро, в очереди или на ходу, телефон в одной руке. Сценарий: увидел ссылку в соцсети → открыл → выбрал услугу (стрижка или уход) → увидел свободные окна на неделю → выбрал субботу, 14:00 → оставил имя и телефон → получил подтверждение с адресом и схемой проезда → за день до визита пришло одно напоминание → пришёл. Две минуты и ни одной регистрации с паролем: если попросить пароль, половина уйдёт на этом шаге. Администратор. Она за стойкой, у неё в руках телефон и клиент перед ней. Сценарий: утром открывает расписание на неделю → видит, какие окна заняты → записывает тех, кто позвонил → отмечает пришедших → переносит запись, если клиент позвонил. Ей нужна одна картина на неделю, а не список заявок: если онлайн-запись не попадает в её расписание, мы снова получаем две записи на одно время — ровно то, с чего началась вся история. Мастер. Он в середине стрижки, руки заняты, смотреть в телефон некогда. Сценарий: утром смотрит расписание на день → видит, кто и во сколько → в течение дня замечает новую запись, но не отвечает на звонки. Ему нужно расписание, а не управление им: если дать мастеру право переносить записи, он и администратор снова начнут править одно и то же в двух местах.
Заметьте, что «удобно» у всех троих разное. Клиенту — меньше шагов и никаких паролей. Администратору — одна картина на неделю и запись, которая видна сразу. Мастеру — не отвлекаться. Одно слово «удобно» этого не описывает, а три сценария — описывают. И видно, где сценарии сталкиваются. Клиент записывается в полночь — это нормально, администратор спит. Администратор переносит запись — клиент должен узнать об этом сам, иначе придёт к занятому мастеру. Такие стыки и есть настоящие требования к задаче: их не придумывают заранее, их находят, проходя сценарии по очереди.
Правило работает не только с сайтами. Сдать документы в МФЦ: заявитель приходит с папкой бумаг и хочет уйти с распиской, сотрудник окна проверяет комплект и отправляет заявление дальше. Два сценария, и у каждого свой конец: у заявителя — расписка, у сотрудника — принятое заявление. Если описать «пользователь работает с документами», не будет ни того, ни другого.
Разбор: Клиент: заходит с телефона, выбирает свободное время, получает подтверждение — две минуты. Администратор: открывает расписание на неделю, видит занятые слоты, переносит запись. Это уже основа и для оценки сроков, и для проверки результата. Обратите внимание: у клиента пять шагов, у администратора четыре, у мастера один — и это нормально. Число шагов говорит не о важности человека, а о том, сколько ему нужно сделать. Сравнивать сценарии между собой бессмысленно: у них разные задачи. Ещё один признак, что сценарий написан правильно: в нём нет слова «система». «Система показывает расписание» — это про программу. «Администратор открывает расписание и видит, кто занят» — это про человека, и такую фразу можно проверить, посадив администратора перед экраном. И последнее: сценарий не обязан быть коротким, но обязан заканчиваться результатом. Если после последнего шага непонятно, что человек получил, — сценарий не дописан, и исполнитель придумает конец сам.
Частая ошибка: 1. Описывать систему «в целом». «Пользователь может делать всё» — так невозможно понять, с чего начинать. 2. Перечислять экраны вместо действий. «Страница записи», «личный кабинет», «раздел настроек» — это уже решения, а не сценарий; из них не видно, что человек делает и зачем. 3. Забыть того, кто следит за порядком. Сценарий клиента выглядит прекрасно, пока не выясняется, что администратор о нём не знает, а мастер узнаёт о записи от клиента на пороге.
Итог: Список пользователей и по одному сценарию для каждого. Проверка: пройдите сценарий вслух от начала до конца и на каждом шаге спросите — что человек делает, что видит и что получает в конце.
Клиент — в метро, с телефона: выбрал услугу и время, получил подтверждение со схемой проезда.
Администратор — за стойкой: видит расписание на неделю, записывает по телефону, переносит запись.
Мастер — в середине стрижки: смотрит расписание на день и не отвечает на звонки.Опишите двух пользователей своей задачи: кто они и что делают. Если своей задачи сейчас нет, возьмите парикмахерскую из уроков 1.1–1.3 или случай из «Корявых задач» — метод разбирается так же.
Критерий успеха: Для каждого пользователя указано, кто он и что делает.