«Директор небольшой брокерской фирмы Юрий сидел в офисе, который он арендовал в модном коворкинге вместе со своими немногочисленными сотрудниками. Компания последнее время показывала очень хорошие результаты. Престижное экономическое образование позволило самостоятельно построить успешную компанию, а вот как обезопасить основной капитал – базу клиентов – от участившихся хакерских атак собственными силами Юрий не знал. Своим сотрудникам Юрий доверял, но они часто работали из дома, из кафе, да и местный администратор Илья не вызывал доверия, наверное из-за бороды и черной футболки.

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

Секретарь Юля не только носила кофе боссу, но и выполняла самые ответственные поручения. Поэтому письмо Юрия о необходимости приобрести решение некой PrivateNet не вызвали удивления. Юля быстро нашла в интернете сайт компании и уверенно выбрала пакет для компании от 2 до 25 человек и оплатила пластиковой картой. Ввела адреса всех сотрудников (да, они все на mail.ru, но сервис вроде надежный и корпоративная почта получается бесплатно), телефоны, количество лицензий на каждый адрес и ввела сопроводительный текст от своего имени, чтобы письмо с ссылкой не попало в спам. Нажать кнопку «Уведомить сотрудников» и дело сделано. Ах да, проверить что все сработало. Юля проверила почту на своем MacBook Air и на iPhone. Все установилось без проблем, а в личном кабинете на портале PrivateNet красовалась зеленая цифра 2. Отлично, как будет 11, то можно будет сообщить Юре, что мы в безопасности.»

Что дает аналитику эта мини-история? Зачем вообще аналитик станет писать подобный текст? Ведь можно было обойтись обычным списком – на какой сегмент рынка рассчитан продукт, какие проблемы пользователя решает, кто принимает решение о покупке, кто является пользователем продукта, какой канал распространения, какие платформы поддерживаются, роли пользователей продукта, кому доверяем, а кто может быть нарушителем и многое другое.

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

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

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

И это еще не все. В отделе продаж всем будет понятно что именно они продают, и как лучше организовать продажи. Что стоит написать на билбордах, или билбордов вообще не будет? А что будет вместо них? Как лучше подтолкнуть Юрия к решению о покупке? Все коррективы сразу вносим в сценарий и проверяем как все складывается в непрерывную историю.

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

Названия компаний и имена людей выдуманы, все совпадения случайны.