В BABOK описано 50 техник бизнес-анализа, но сегодня я хочу сосредоточиться на техниках, которые полезны именно при написании технического задания (ТЗ). Причем давайте сразу условимся, что по общепринятому мнению ТЗ должен писать именно аналитик.
Согласно ГОСТ 34.602, техническое задание состоит из разделов:
-
Общие сведения
-
Требования
-
Условия эксплуатации
-
Приемка и испытание
-
Бизнес-обоснование
-
Ссылки на нормативные документы
Понятно, что основа ТЗ – это раздел «Требования», потому что именно требования описывают, что мы вообще хотим получить от нашей системы или планируемых доработок. А все остальное в ТЗ – просто обвязка вокруг требований.
И сегодня мы поговорим о том, как при формулировке требований применять техники BABOK.
Что такое BABOK и зачем он нам?
Когда мы в Telegram-группе аналитиков 1С проводили опрос «Применяете ли вы в работе техники BABOK?»:
-
13% ответили, что применяют;
-
31% – что не применяют;
-
И 56% вообще не знают, что такое BABOK.
Но вообще я на 99,9% уверен, что вы эти техники применяете – просто не знаете, что это техники BABOK. Потому что невозможно работать аналитиком и не применять эти техники.
BABOK – это аббревиатура от Business Analysis Body of Knowledge – «Свод знаний по бизнес-анализу». Этот свод знаний был разработан международным институтом бизнес-анализа IIBA в США. Иногда меня упрекают: «Как же так! Сейчас надо использовать все отечественное!» Ну нет отечественного аналога. Есть этот переведенный BABOK, и он, кстати, стоит немало – около 14 тысяч рублей. Я не призываю скачивать его нелегально, но в интернете он встречается, и аналитики умеют его находить.
Важно понимать, что IIBA не «изобрел» эти техники – многие из них существуют испокон веков. Например, сбор требований – это практика, существующая еще до появления информационных систем. Но институт систематизировал, описал и собрал все это в одну структуру.
Что вообще есть в BABOK:
-
Базовые понятия бизнес-анализа
-
Взаимодействие со стейкхолдерами
-
Работа с требованиями
-
Реализация стратегии бизнеса
-
Оценка решений
-
Компетенции бизнес-аналитика
-
Техники
Техники – наиболее применимый на практике раздел. Все остальное воспринимается довольно тяжело – как многословный текст, описывающий что-то системообразующее. Да и сами техники описаны довольно сухо – там много текста и очень мало примеров.
Поэтому сейчас мы углубимся в практические примеры, а сами описания техник вы сможете прочитать в BABOK – мы туда не будем уходить
Предполагаю, что многие не интересовались BABOK, потому что там много информации про бизнес-анализ, который может быть вообще не связан с ИТ. Т.е. чистые бизнес-аналитики могут вообще не разбираться в ИТ.
А у нас в 1С это довольно тонкий вопрос: «Кто мы – бизнес-аналитики, системные аналитики или просто аналитики 1С?» Я предпочитаю термин «аналитик 1С», причем такой аналитик в моем понимании обязательно должен знать 1С хотя бы на базовом уровне. И сейчас я буду пытаться вам донести – почему.
Техники для написания ТЗ
Изначально я планировал подробно рассказать про 12 перечисленных ниже техник:
-
10.09. Анализ бизнес-правил
-
10.11. Моделирование понятий
-
10.13. Диаграммы потоков данных
-
10.15. Моделирование данных
-
10.22. Функциональная декомпозиция
-
10.34. Анализ процессов
-
10.35. Процессное моделирование
-
10.36. Прототипирование
-
10.39. Матрица ролей
-
10.42. Диаграмма последовательности
-
10.44. Моделирование состояний
-
10.47. Варианты использования и сценарии
Расширенную презентацию с описанием всех техник из BABOK вы можете скачать из вложения к публикации.
Но здесь мы сейчас кратко коснемся только 6 самых неочевидных и интересных техник, которые выделены жирным, углубляясь больше в примеры их практического применения.
Тем более, что остальные техники – достаточно простые. «Анализ бизнес-правил» наиболее очевидная техника для сбора требований, «Моделирование понятий» – это фактически инструкция по составлению глоссария, «Диаграмму потоков данных», «Функциональную декомпозицию», «Анализ процессов» и «Матрицу ролей» я сейчас рассматривать не буду. Тем более, что «Матрицу ролей» вы вряд ли не знаете – она в 1С встроена в конфигуратор и используется в любой конфигурации. Странно было бы сказать: «Я не пользуюсь техниками BABOK» – тогда вы, наверное, не аналитик 1С и не работаете с 1С.
Начнем проходиться по техникам.
Техника 10.15. Моделирование данных
Мне очень нравится техника «Моделирование данных».
Строить модели данных можно в совершенно разных форматах. На слайде показаны два из них:
-
Первый формат моделирования называется Сущность-связь и также известен как «Вороньи лапки» – модель в этом формате показывает связи между сущностями, имеющими идентификаторы и наборы атрибутов. «Вороньи лапки» – потому что связь между сущностями типа «1 или больше» похожа на лапку. А связь «1 и только 1» выглядит как перевернутое «равно».
-
Второй формат – это UML-диаграмма классов. Этот формат очень похож на первый, просто здесь немного по-другому показаны стрелки и обозначения.
Рассмотрим, как в формате Сущность-связь выглядит процесс покупки билета в кинотеатр:
-
Один кассир продает множество билетов.
-
Один билет обеспечивает доступ на один показ.
-
Этот показ прокатывает один фильм.
-
Этот показ проходит в одном зале.
-
В этом зале содержится много рядов.
Эта техника очень удобна для того, чтобы показать в том же техническом задании, как будут устроены ваши данные и какая между ними будет взаимосвязь.
Обратите внимание, что у каждой сущности есть идентификатор и атрибуты. Если взять аналогию с 1С, то у любого объекта тоже есть идентификаторы и атрибуты, которые, например, в случае справочника называются «реквизиты», а в случае регистра это могут быть «измерения» или «ресурсы».
Кстати, постоянно ведется дискуссия – нужно ли аналитику хоть в какой-то степени знать конфигуратор? Представьте, что вы пишете ТЗ, и там нужно показать структуру данных и взаимосвязь между этими данными. И вам надо выбрать, например, использовать в этом случае справочник или регистр сведений. Я веду к тому, что, конечно, аналитик должен немного знать конфигуратор, иначе вы просто не напишете ТЗ. Или напишете некорректно, и программисту придется все взаимосвязи продумывать с нуля самому. Это неправильно.
Структуру данных можно представить через объектную модель:
-
Например, так, как она представлена в конфигураторе:
-
справочники;
-
документы;
-
регистры;
-
обработки и т.д.
-
-
Или показать структуру данных в технологической точки зрения, где у нас есть:
-
технологическая платформа 1С;
-
данные в СУБД MS SQL или PostgreSQL;
-
и прикладные решения, которые пользуются этими данными.
-
Также структуру данных можно представить в виде таблиц.
Например, любая взаимосвязь данных – это взаимосвязь двумерных таблиц. По-другому никак. Так устроены компьютеры, в них все данных – это двухмерные таблицы. Даже если мы думаем, что таблица трехмерная, она все равно двумерная, просто там еще есть дополнительные связи с другими таблицами.
Если вы посмотрите, как хранятся данные в любой реляционной СУБД – везде такие же таблицы. Это тоже относится к тому, как мы отображаем данные.
Еще структуры данных можно отображать в виде XML и JSON. Как правило, эти форматы применяются для описания обменов между конфигурациями или с внешними источниками / получателями. Структуры, описанные с помощью XML и JSON очень похожи, просто язык немного разный и применяется в разных ситуациях .
Вывод: моделировать данные можно по-разному, но для технических заданий удобнее всего использование модели в виде схем – в виде таблиц или XML-тегов вы вряд ли будете оформлять модели в ТЗ.
Техника 10.35. Процессное моделирование BPMN 2.0
Перейдем к следующей технике – это процессное моделирование.
Наверное, это самая применяемая техника, потому что странно представить аналитика, который не моделирует бизнес-процессы.
Самая популярная сейчас нотация для моделирования процессов – BPMN 2.0, в ней можно смоделировать любой бизнес-процесс.
А еще есть, например, нотация eEPC – она более старая, и к ней некоторые больше привыкли. В нотации eEPC акцент больше сделан на самом процессе. В отличие от BPMN, где в дорожках указано, кто и что делает, eEPC на этом не фокусируется. Его удобно использовать, когда вы хотите показать именно процесс от начала до конца, не размазывая его по разным дорожкам-исполнителям.
Есть и другие нотации, но я о них сейчас рассказывать не буду. BPMN и eEPC – это сейчас, наверное, самые распространенные.
Техника 10.36. Прототипирование
Следующая техника – прототипирование. Думаю, многие делают прототипы – на слайде показано, как создается прототип интерфейса в программе MAKER.
Есть, конечно, и другие решения, в том числе зарубежные, в которых можно нарисовать, как будет выглядеть будущий интерфейс. Но в MAKER можно сделать интерактивный прототип, в котором и кнопки нажимаются, и вкладки переключаются и т.д. – не только чтобы рисунок сделать в ТЗ.
Все вроде понимают, что прототипировать интерфейсы полезно. Но в очень редком ТЗ я видел, чтобы люди показывали прототип интерфейса. Понятно, что есть такие ТЗ, где взаимодействие с пользователями не предусмотрено – например, где нужно просто организовать обмен по расписанию. Но все-таки в большинстве технических заданий – если вы делаете отчеты, документы, справочники – интерфейсы нужны, и их прототип в ТЗ нужен.
Причем интересно то, что прототипирование – это не только про интерфейсы. Первая рабочая версия программы, у которой нет никаких дополнительных функций, тоже может быть прототипом. То есть прототип – это не только про картинки.
Техника 10.42. Диаграмма последовательности
Следующая техника – диаграмма последовательности.
В этой технике мы показываем последовательность тех или иных действий – кто, когда и с кем взаимодействует. Диаграмма читается сверху вниз, отражая шкалу времени. На ней:
-
Пунктирные вертикальные линии – это «линии жизни» объектов или участников процесса.
-
Прямоугольные блоки – это «блоки активации», показывающие, в какой момент объект активен и участвует во взаимодействии
-
А стрелки – это сообщения, передаваемые от одного участника к другому.
На слайде показан пример, как клиент заходит на сайт, чтобы найти объект недвижимости – то же самое, кстати, происходит и в 1С, когда человек что-то хочет найти.
-
Пользователь хочет перейти с главной страницы сайта в список недвижимости. На «линии жизни» главной страницы мы видим, сколько времени занял блок активации – это означает, что в данный момент главная страница взаимодействует с пользователем.
-
Он получил 20 записей. У него открылось новое окно – список объявлений. Пошел блок активации – пользователь какое-то время ждет этот список.
-
Идет запрос идет к базе данных, список объявлений формируется, а потом эти записи отображаются.
-
После этого человек ввел на странице списка какой-то фильтр, например на цену, и хочет видеть объекты недвижимости с указанной ценой.
-
Фильтр передается в базу данных, проверяется на существование таких объектов и выдается уже фильтрованный результат. Здесь опять идет взаимодействие.
-
Дальше человек выбрал какой-то объект недвижимости и хочет посмотреть о нем подробнее.
-
Опять идет взаимодействие с базой данных, и ему выдается полная информация об этом объекте, что и требовалось нашему заказчику.
На диаграмме последовательности хорошо видно, в какой момент происходит взаимодействие с тем или иным объектом: с главной страницей, списком объявлений и полной информацией по объявлению.
Причем обратите внимание – в одном случае имеется в виду список объявлений как база данных, а в другом имеется в виду список объявлений как отображение на экране.
Тоже очень удобная нотация.
Техника 10.44. Моделирование состояний
Техника «Моделирование состояний» – довольно редко используемый инструмент, но тоже в определенных случаях полезный.
В отличие от процессных моделей, здесь акцент сделан не на последовательности действий, а на изменении состояний (статусов) конкретного объекта на протяжении его «жизни» в системе. Например, у документа может быть несколько состояний – это может быть бумажный оригинал, скан-копия или электронный документ в разных статусах: «Создан», «Сохранен», «Проведен» и т.д.
Рассмотрим типичный пример:
-
Изначально бумажный документ находится у бухгалтера.
-
Затем его сканируют – он получает статус «Отсканирован».
-
Копия передается в архив – ее статус меняется на «Передан в архив».
-
А оригинал передается на хранение в группу регистрации и контроля для формирования книги покупок.
-
Если в результате проверки обнаруживаются ошибки, мы сканируем документ заново и получаем новый статус.
Техника не так часто используется, но, когда вам нужно понять, как работать со статусами, ее использовать очень удобно.
Техника 10.47. Варианты использования и сценарии
И последняя техника, которую я вам хочу показать – это варианты использования и сценарии.
Это тоже UML-диаграмма, только не про базы данных, а про то, как пользователи взаимодействуют с системой.
На схеме показано, как происходит процесс аутентификации для различных ролей в системе.
Дело в том, что каждому пользователю от системы нужно разное.
-
Менеджеру по работе с клиентами нужно работать с заказами.
-
Менеджеру по снабжению нужно управление информацией о поставщиках, управление информацией о комплектующих.
-
У каждого пользователя разные потребности от системы.
Когда проходит аутентификация, этот процесс включает (include) все эти варианты использования системы. Поэтому эта техника иногда еще называется диаграмма вариантов использования.
В действительности эту диаграмму удобно применять, когда, например, мы смотрим процесс AS IS – как есть. Мы рисуем, как пользователи в данный момент взаимодействуют с системой и что они получают. Но можно использовать и TO BE, показать, как мы можем в итоге это все переделать, если мы делаем какой-то реинжиниринг.
Заключение
Каждая из этих техник служит своей цели, но все они отлично дополняют друг друга в составе ТЗ, позволяя рассматривать требования с разных сторон:
-
Моделирование данных – с точки зрения, как будет устроена база данных.
-
Процессное моделирование – как будут устроены процессы взаимодействия пользователей, использования этих данных.
-
Прототипирование – при помощи каких интерфейсов будет происходить взаимодействие пользователя с системой.
-
Диаграмма последовательности – в какой момент по времени что будет происходить, и какие объекты будут задействованы.
-
Моделирование состояний – какое состояние будут приобретать те или иные сущности, объекты.
-
Варианты использования и сценарии – это больше отсылка к людям, которые взаимодействуют с системой – как они будут взаимодействовать, в какой последовательности, в какой взаимосвязи.
Надеюсь, вам теперь стало понятнее, что вы уже и так используете техники BABOK в своей работе. Но там еще много интересного – я показал только несколько инструментов, которые могут быть полезны в вашей работе.
Вопросы и ответы
Какую комбинацию этих диаграмм стоит использовать для написания ТЗ, с вашей точки зрения? Вы сейчас перечислили большой перечень, неужели весь этот перечень стоит отражать в ТЗ?
Это философско-риторический вопрос. В ТЗ нужно использовать такую комбинацию, которую вы считаете более уместной в данной ситуации.
Я не видел, чтобы в одном ТЗ были применены все техники хотя бы даже из тех шести, которые я перечислил, я не говорю про 12.
А техника, где мы пишем глоссарий, наверное, используется в любом ТЗ – наверное потому, что глоссарий требуется по ГОСТу.
Вы говорите, что ТЗ составляет аналитик – с этим сложно поспорить, это общепринятая практика. Но ведь часто бывает, что разработчики в итоге не используют это ТЗ, а пишут всё по-своему. Вы действительно считаете, что аналитику нужно настолько досконально погружаться во все это?
Все эти техники нужны просто для того, чтобы представление в ТЗ было более наглядным и понятным – как для заказчика, так и для программиста.
Можно ограничиться простым текстом, но лучше добавить таблицы и изображения.
Потому что как мы, например, текстом отобразим интерфейс? Это сложно, нарисовать проще.
Или как текстом отобразить бизнес-процесс? Не рисовать бизнес-процессы – это вообще странно.
Конечно, бывает, что ТЗ вообще не пишут, но мы же говорим о правильных внедрениях, а не о тех, где в результате получается «автоматизированный бардак».
До какой глубины, по вашему мнению, аналитик должен знать структуру конфигурации и уметь работать в конфигураторе, чтобы писать ТЗ?
Я считаю, что аналитик, чтобы написать ТЗ, должен:
-
Понимать, что такое конфигуратор.
-
Понимать, чем отличаются объекты – например, справочник от регистра сведений: в регистре сведений можно по совокупности измерений находить значения ресурсов, а справочник используется немного для другого. А документ похож на справочник, но там есть дата, номер, возможность проведения и так далее.
-
Хотя бы поверхностно уметь читать код. Если аналитик не понимает обычные условные конструкции или циклы, это странно. Хотя бы поверхностно он должен читать код.
-
Хотя бы поверхностно он должен понимать, как делаются запросы к тем же регистрам. Да, поначалу язык запросов может показаться слишком сложным. Но хотя бы поверхностно это надо понимать.
Чтобы написать ТЗ, нужно знать основы этого всего. Без этого аналитик не может быть аналитиком 1С. А необходимый уровень вашего знания вы определяете для себя сами. Я считаю, что чем глубже, тем лучше. Если аналитик еще и программист, то это вообще круто, но необязательно.
Какие инструменты, кроме Maker, вы используете для прототипирования?
Maker удобен тем, что он рисует «один в один», как в 1С.
Но вообще мы проводили опрос об инструментах для прототипирования, и там большинство ответило, что используют draw.io, Paint, Visio, а еще – самый популярный ответ – бумагу и ручку.
Нарисуйте форму – где какие поля должны быть, на что эти поля должны влиять. Если человек введет в отчете какой-то параметр, на что он должен повлиять? Из чего он должен выбирать этот параметр – из справочника, ограниченного списка или просто текстом его задать? Это тоже важно.
Поэтому как вариант – просто рисуйте на бумаге, как это должно выглядеть, это будет в 100 раз лучше, чем ничего.
Вы сказали, что основное предназначение используемых инструментов – сделать ТЗ более понятным разработчику и заказчику. Но, по-моему, вы упустили главное – это самоконтроль, что все требования отражены. Если мы возьмем sequence-диаграммы (диаграммы последовательности), у нас не должно быть подвешенных сообщений или инициируемых активностей без сообщений. Если мы берем BPMN, у нас не должно быть потоков данных и потоков исполнения, которые не заканчиваются результатом. Это же основное.
Действительно, одна из целей этих техник – чтобы все требования заказчика были отражены наиболее полно, чтобы их было проще согласовать, заранее проработать функциональность и избежать ошибок при реализации.
Например, мы показали диаграмму BPMN бизнес-процессов. Руководитель проекта или заказчик сказал: «Хорошо, а как интерфейс-то будет выглядеть?» Не договорились. Потом в итоге сделали, а ему не понравилось.
Когда я работала внедренцем, то часто сталкивалась с ситуацией: рисуешь схему – все красиво, логично. Приходишь к заказчику, а он: «Это что за кружочек? А как понять, что дальше?» Разработчику показываешь, он тоже не умеет ее читать. Насколько сейчас профессиональная среда уже готова к восприятию информации в таком виде без подробного разъяснения?
К сожалению, ситуация и сейчас не сильно изменилась. Если прототип интерфейса сразу понятен всем – и заказчикам, и исполнителям – то схемы бизнес-процессов в нотации BPMN, которые лично мне кажутся интуитивно понятными, заказчикам и исполнителям понятны далеко не всегда.
Наверное, человеку надо как-то дополнительно пояснить: «Пользователь делает вот это, потом происходит обращение к базе, потом информация отображается на экране». Просто сесть и показать последовательность, а он будет счастлив от того, что понял, что такое BPMN. Там же ничего сложного нет: вот действие, вот ветвление, вот шлюз. Все интуитивно понятно, просто это надо объяснить.
Бывают и более сложные случаи – например, попробуйте показать непосвященному функциональную диаграмму в IDEF0. Но с другой стороны, зачем ее показывать кому-нибудь ниже ИТ-директора? А если ИТ-директор не знает IDEF0, это вообще странно, потому что не понятно, как он тогда руководит ИТ-направлением.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
