Одним из первых шагов при написании ТЗ на разработку ИС является выявление будущих пользователей системы. Казалось бы: ничего сложного, но бывают нюансы.
Давайте начнем с теории. Согласно Карлу Вигерсу существует множество заинтересованных лиц:
«Заинтересованное лицо (stakeholder) — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.»
их подмножество — клиенты:
«Клиенты являются подмножеством заинтересованных лиц. Клиент (customer) — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта».
и их подмножество — пользователи:
«Требования пользователей определяют те, кто прямо или косвенно взаимодействуют с продуктом. Эти пользователи (часто их называют конечными пользователями) являются подмножеством клиентов. Прямые пользователи непосредственно работают с продуктом. Непрямые пользователи могут получать результаты работы системы, не входя в непосредственный контакт с ней.»
Все эти подмножества я представила кругами Эйлера на рисунке ниже.
Рис. 1. Заинтересованные в ИС лица и их подмножества.
При написании технического задания на информационную систему важно выделять именно пользователей будущей системы и не путать их с клиентами, не являющимися пользователями (на рисунке показаны желтым).
Приведу один курьезный случай из своей практики.
Нужно было реализовать и интегрировать в существующую информационную систему модуль по продаже лотерейных билетов. Стажер-аналитик присылает мне юзер стори, которая начинается словами «Я, как клиент компании, хочу купить лотерейный билет».
Это круто, конечно, для компании, что есть кто-то, кто хочет купить билет, но он абсолютно ни в каком виде не является пользователем ИС компании. В данном случае этот клиент компании входит в множество заинтересованных лиц, в подмножество клиентов, но не входит в подмножество пользователей ИС.
Одним из основных пользователей ИС в приведенном примере является оператор или кассир, непосредственно осуществляющий продажу билета и взаимодействующий для этого с модулем продажи билетов.
Я аналитикам-стажерам всегда советую перед тем, как начать писать ТЗ, представить себя компьютерной программой:
Кто первый коснется клавиатуры, чтобы запустить тебя?
Какую информацию тебе передаст этот кто-то?
Куда ты, как компьютерная программа, должен будешь передавать эту информацию?
Еще надо всегда помнить, что компьютерная программа туповата. Если ей чего-то не сказать, не передать, то сама она не догадается.
То есть сначала надо для себя написать или хотя бы проговорить «программ стори»:
«Я, как модуль продажи лотерейных билетов, …»
Ну и конечно, надо учитывать тот факт, что у продукта/сервиса/системы, как правило, много пользователей, каждый из которых будет выполнять свои задачи. Возвращаясь к модулю по продаже лотерейных билетов, можно сразу навскидку выделить еще несколько групп пользователей:
операционный директор, который хочет получать отчеты по объемам продаж билетов;
бухгалтерия, которая должна учесть продажи в 1С (здесь появляется задача по интеграции с 1С).
И для каждого из них надо, представив себя программой, пройти свой путь.
Кроме того, такой подход помогает в дальнейшем описывать архитектуру будущего модуля. Вы уже получаете представление о том, какие входные параметры необходимо передавать, как их обрабатывать и что получать на выходе.
В своей следующей статье я хочу рассказать, как перейти от описания юзер стори к написанию полноценного ТЗ на веб-сервис с описанием API, включающим определение ресурсов, конечных точек и методов.
