Одним из первых шагов при написании ТЗ на разработку ИС является выявление будущих пользователей системы. Казалось бы: ничего сложного, но бывают нюансы.

Давайте начнем с теории. Согласно Карлу Вигерсу существует множество заинтересованных лиц:

«Заинтересованное лицо (stakeholder) — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.»

их подмножество — клиенты:

«Клиенты являются подмножеством заинтересованных лиц. Клиент (customer) — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта».

и их подмножество — пользователи:

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

Все эти подмножества я представила кругами Эйлера на рисунке ниже.

Рис. 1. Заинтересованные в ИС лица и их подмножества.

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

Приведу один курьезный случай из своей практики.

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

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

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

Я аналитикам-стажерам всегда советую перед тем, как начать писать ТЗ, представить себя компьютерной программой:

• Кто первый коснется клавиатуры, чтобы запустить тебя?

• Какую информацию тебе передаст этот кто-то?

• Куда ты, как компьютерная программа, должен будешь передавать эту информацию?

Еще надо всегда помнить, что компьютерная программа туповата. Если ей чего-то не сказать, не передать, то сама она не догадается.

То есть сначала надо для себя написать или хотя бы проговорить «программ стори»:

«Я, как модуль продажи лотерейных билетов, …»

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

• операционный директор, который хочет получать отчеты по объемам продаж билетов;

• бухгалтерия, которая должна учесть продажи в 1С (здесь появляется задача по интеграции с 1С).

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

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

В своей следующей статье я хочу рассказать, как перейти от описания юзер стори к написанию полноценного ТЗ на веб-сервис с описанием API, включающим определение ресурсов, конечных точек и методов.