Пишем ТЗ через сценарии

Я буду рассказывать не про пользовательские сценарии, а про немного более широкое понимание сценариев в том виде, как их описывает Алистер Коберн в своей книге «Современные методы описания функциональных требований».

Это сценарии разных уровней. Я расскажу, как с помощью понимания разделения сценариев на уровни сделать хорошее ТЗ.

Идея доклада возникла у меня в 2016 году, когда я рассказывал про UML на конференции Инфостарта. Одна коллега обратилась ко мне с вопросом после доклада. Она сообщила, что работает в государственной компании, ей нужно писать техзадание по стандарту ГОСТ 34, и спросила, как ей совместить моделирование и техзадание. Мы с ней немного подискутировали, и по итогам обсуждения я решил агрегировать свой опыт системной работы и с моделями, и с заданиями и представить в виде доклада.

Сегодня мы:

• Во-первых, немного поговорим про то, зачем вообще нужно техзадание – отделим продуктовые этапы от процедуры управления проектом.
• Я расскажу, с чего я начинал. У меня опыт в нашей отрасли – 15 лет, шишек я набил много. Надеюсь, вы мои шишки учтете и повторять их не будете.
• Поговорим про методические основания разработки техзадания – про то, как подобрать хорошую структуру для техзадания. Какие разделы в него включать, какие не включать.
• Поговорим про моделирование – совместим структуру ТЗ с моделями и получим успешные подходы к разработке техзадания
• Я подготовил специально для вас несколько примеров в Enterprise Architect, покажу, как выглядит модель, которую я включаю в техническое задание.
• И покажу вам сами документы. Я знаю, что большинство слушателей Инфостарта – это специалисты, которые работают “in-house”, поэтому я специально подобрал такие примеры, которые хорошо подойдут для общения с внутренним заказчиком.

Зачем нужно ТЗ

Когда я больше 15 лет назад стал программистом 1С, на первом месте работы, в компании-франчайзи, у меня сложилось такое впечатление, что техническое задание нужно для того, чтобы прикрыться им в случае каких-то проблем.

Из текущего опыта скажу, что у меня были отличные проекты вообще без техзадания, когда техзадание даже не делалось. И были проекты абсолютно провальные, когда техзадание на 200 листов, расписанное во всех деталях, но все равно заказчик находил лазейки, апеллировал к договору и приходилось многое доделывать и переделывать. Важно понимать, что техническое задание относится к продуктовому этапу, а управление рисками проекта (тем, чтобы минимизировать доделки, доработки) относится к процедуре управления проектами. Так вот, техзадание – это абсолютно не про то, чтобы «прикрыться».

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

Мои «фейлы»

Для начала посмотрим на пару моих «фейлов».

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

Заказчик, конечно, под этим подписывается, потому что деваться ему некуда. Но, как я уже говорил, даже при наличии такого достаточно детального техзадания всегда могут быть проблемы. Поэтому это не сближало меня и понимание заказчика о том, что я делаю – не помогало нам договориться.

Далее у меня был опыт, когда я наоборот описывал слишком верхнеуровневые требования. Я подумал, что, может быть, не нужно писать техническое задание и изучал разные практики, методологии.

Мне очень понравился Rational Unified Process от IBM. Это очень интересная штука – одновременно и методология, и готовый продукт, где вы настраиваете свой процесс. Но как заказчику объяснить, что мы работаем по такой технологии. Здесь на начальной стадии у нас больше аналитики работают, меньше программисты и т.д.

Заходило очень сложно. К счастью, я тестировал это все на лояльных заказчиках. Но даже с ними было тяжело, потому что все эти модные слова вроде BRD (бизнес-требования) и т.д. заказчики не очень понимают.

Методические основания разработки ТЗ

Давайте посмотрим на то, как сформировать оптимальную структуру технического задания. Есть два госстандарта, которые описывают то, как можно разрабатывать техническое задание – это ГОСТ 19.201 и ГОСТ 34.602. Причем, оба стандарта на разработку техзадания. Разница этих государственных стандартов в том, что:

• ГОСТ 19.201 – это техническое задание на программный продукт, на программу.
• ГОСТ 34.602 – это техническое задание на создание и развитие автоматизированной системы.

Давайте немного детальнее разберемся со структурой этих госстандартов.

Основные разделы госстандарта 19.201 видны слева.

Самый главный раздел – это «Требования к программе или программному изделию». Там указываются:

• требования к функциональным характеристикам, перечисляются функции программы;
• в разделе «Требования к надежности» указывается, сколько программа должна устанавливаться без отказов и т.д.

В моей практике только один раз ГОСТ 19.201 подходил к заказу. У меня был интересный заказчик – он попросил сделать систему для расчета того, сколько материалов нужно для производства торта. Это смешно звучит, но, когда я вник в проблему, оказалось, что математически размер торта невозможно посчитать, исходя из его веса, потому что плотность этажей может быть разной. Там была типичная программа-калькулятор: вводишь тип изделия и его вес – получаешь размеры. В моей практике это, пожалуй, единственный случай, когда ГОСТ 19.201 подходил.

Дальше я покажу разницу между ГОСТ 19.201 и ГОСТ 34.602.

Если посмотреть на ГОСТ 34.602, здесь уже требования не к программе, а к системе.

В разделе «Требования к системе в целом» приводятся:

• требования к численности и квалификации персонала;
• требования к структуре и функционированию системы;

Это требования не только к тому, что вы делаете, это требования уже к предприятию заказчика, которое вы автоматизируете.

На этом слайде я попробовал вывести условную разницу между двумя ГОСТ-стандартами. Слева – стандарт ГОСТ 19.201, а справа – ГОСТ 34.602.

Обратите внимание, красным я выделил отличия, которые у нас есть только в стандарте ГОСТ 34.602. Это:

• характеристика объектов автоматизации, где вы можете привести схемы бизнес-процессов, общие для объектов автоматизации, ограничить скоуп проекта путем перечисления тех процессов, которые входят в контур автоматизации;
• состав и содержание работ по созданию системы;
• требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• требования к документированию и т.д.

Давайте все-таки разберемся, что мы делаем – программы или системы? Чем отличается подход к разработке автоматизированной системы от подхода к разработке программного продукта?

На экране формальное определение информационной системы, соответствующее стандарту ISO. На первый взгляд может показаться сложным.

Но я считаю, что, информационная системы – это очень простая и понятная штука. Когда меня дети спрашивают: «Чем ты, папа, занимаешься?», я отвечаю: «Я делаю три вещи: первое – программу, второе – инструкции по эксплуатации этой программы, и третье – учу людей эксплуатировать программу по этим инструкциям».

Вот эта совокупность людей и программного продукта и является системой. Поэтому, на мой взгляд, ГОСТ 19.201 не очень подходит для структуры ТЗ на автоматизированную систему, а ГОСТ 34.602 подходит отлично, потому что вы видели, там есть требования к персоналу, требования по документированию и т.д.

Поэтому, исходя из определения, используйте ГОСТ 34.602. Рекомендую.

Я знаю, что очень многие боятся ГОСТ-ов. Думают, что они уже давно устарели.

Но, обратите внимание, в обоих ГОСТ-стандартах указано, что это рекомендация, вы можете исключать, объединять разделы, какие-то подразделы добавлять. И если даже вы там оставите всего три раздела из ГОСТ 34.602, то все равно вы можете сказать, что у вас ТЗ написано по ГОСТ. Это очень хороший аргумент в переговорах с вашими коллегами из других подразделений или с заказчиками. Да, техзадание написано по ГОСТ. А почему в нем не все требования указаны? Потому что в ГОСТ-стандарте допускается указывать в техзадании не все требования, поэтому мы так сделали.

Модели и требования

Теперь немного поговорим про моделирование.

• Техзадание – это документ, который содержит требования.
• Требования – это характеристика будущей системы, описание того, как система должна действовать.
• Модель, в свою очередь – это упрощенное представление некоторого объекта.

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

А зачем вообще заниматься моделированием?

• Моделирование нужно для того, чтобы разобрать какой-то сложный объект на его составляющие. Упростить понимание этого объекта путем того, то вы представляете этот объект, как совокупность некоторых простых элементов.
• У меня в работе были кейсы, когда я не делал моделирования проекта. Причем, это была компания, которую я на тот момент знал пять лет, все процессы знакомы, систему сдаем, заказчику все нравится, и он спрашивает: «А этот процесс как сделать?» А я про этот процесс не слышал вообще ни разу. Вот такие незаметные штуки очень удобно выявлять с помощью модели, потому что схему бизнес-процесса мы все понимаем. Заказчик нормально поймет и скажет вам, что этот процесс не описали.
• И вообще, хорошие модели сокращают время при передаче информации между участниками проекта, потому что кто-то может заболеть, уволиться и т.д.

Поэтому к моделированию я призываю вас относиться очень внимательно, уделять этому время на проектах.

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

Вот, опять же, сказка о трех поросятах, только представленная уже в виде классов. У нас есть суперкласс «Животное», от которого свои свойства наследуют «Поросята» и «Волк». Они как-то между собой взаимодействуют, взаимодействуют с классом «Дом».

Согласитесь, все понятно.

Пару слов о том, что такое моделирование.

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

Если представлять совсем упрощенно, вы помните уроки труда в школе, когда вы какую-то деталь раскладываете на три проекции. Моделирование на наших проектах – это то же самое. Вы предприятие раскладываете по некоторым осям координат.

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

Бизнес-процесс – это последовательность действий. Последовательность действий, в свою очередь, является сценарием. У нее есть некоторые входные данные для этого сценария, порядок обработки этого сценария и какой-то результат. Поэтому для моделирования бизнес-процессов, на мой взгляд, очень подходит модель Use-Case языка UML.

Дальше – каждый сценарий мы детализируем на последовательность действий. Я применяю такую нотацию, как на экране:

• слева у нас объекты метаданных;
• посередине – деятельность;
• отмечаем исполнителя;
• и те правила, по которым он работает.

Эти дорожки я могу менять от проекта к проекту. Где-то я добавляю в правую колонку правила или регламенты, где-то – требования к системе: так очень удобно делать трассировку требований.

Вот реальный кейс, который мы делали для одного заказчика.

Сначала построили общую схему бизнес-процесса. Потом развернули конкретный процесс – получилось такое описание подпроцессов.

UML – это очень простая штука. Я надеюсь, вы сейчас увидели это на примере и убедились. Мы начали с того, что попробовали сказку смоделировать, а потом я UML применил к моделированию бизнес-процесса.

Я использую два уровня сценариев.

• Первый уровень сценария – это верхнеуровневые сценарии. Бизнес-процессы компании.
• И второй уровень – это поведение форм или обработок в рамках бизнес-процессов. Т.е сценарии взаимодействия пользователей с системой.

Когда я делаю техзадание:

• в качестве раздела верхнего уровня делаю бизнес-процессы;
• и раздел нижнего уровня – это объекты метаданных, которые в рамках этих бизнес-процессов задействованы или как-то использованы.

Коллеги, сразу хочу вас предупредить – когда будете знакомиться с UML, в российском интернете очень много трактовок, очень много холиваров. Не обращайте на это внимания ни в коем случае. На одном из сайтов люди написали FAQ, что UseCase-диаграммы не предназначены для моделирования функций. Я в свое время очень много времени потратил, пытаясь разобраться в этой информации, отделить зерна от плевел.

Эта ситуация связана с тем, что очень много разных переводов. Когда я знакомился с UML, я читал много книг. В разных книгах переводы могут немного отличаться. Из-за этого появляются эти разночтения. Поэтому если нужно вам использовать диаграмму вариантов использования для моделирования функций – используйте. Ничему это не противоречит. Функция – это некая последовательность действий, которую выполняет система, поэтому не обращайте внимание на эти холивары, используйте UseCase-диаграммы, как вам нужно. Еще раз подчеркну, UML – это язык, по которому вы можете строить свою нотацию. В этой нотации вы уже описываете модель.

Успешные подходы к разработке ТЗ

Как выглядит разработка техзадания по сценариям?

При разработке 4-го раздела техзадания по ГОСТ 34.602 «Требования к системе в целом» мы разворачиваем требования в сценарии верхнего уровня – в бизнес-процессы, приводим диаграмму всех автоматизируемых бизнес-процессов.

А далее, в разделе «Требования в функциям (задачам)» мы уже приводим конкретный бизнес-процесс и каждый бизнес-процесс детализируем до объектов метаданных (как на правой картинке).

Идеальная структура техзадания с моей точки зрения выглядит таким образом:

• Требования к системе включают общую модель бизнес-процессов. Это можно включить в характеристику объектов автоматизации, а можно включить и в требования к системе. Это зависит от того, как вам больше понравится.
• В требованиях к функциям:
  • в каждом подпункте приводим схему бизнес-процесса;
  • после схемы бизнес-процесса приводим описание шагов бизнес-процесса.
  • дальше делаем еще один уровень – описываем каждый объект метаданных. В рамках объекта метаданных мы еще можем описать сценарий поведения этого объекта метаданных. Эти сценарии заказчики тоже очень хорошо понимают.

В такой структуре – даже если заказчик совершенно не знаком с 1С, и ему непонятно, что такое объекты метаданных, первые два уровня он точно поймет. Описание шагов бизнес-процесса ему будет понятно. А вот уже дальше, когда ему понятна большая часть – ему понятно практически 80% техзадания, даже если он не знает, что такое 1С, что такое объекты метаданных. И уже он охотнее пойдет к вам навстречу, охотнее будет выяснять, что же вы имели в виду в других пунктах, так как большую часть он понимает.

Бывает ситуация, когда или вы привлекаете заказчика на тендер или у вас какой-то проект большой, и вы хотите сначала описать те задачи, которые планируется решать в системе, то можно сделать такой двухэтапный подход.

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

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

Демонстрация реальных кейсов ТЗ

Давайте посмотрим несколько реальных кейсов. Как раз тот самый пример, который я показывал в рамках демонстрации.

Обратите внимание на структуру техзадания.

• У нас есть требования к автоматизированной системе (или требования к функциональности).
• Дальше идет процесс. Он содержит описание функций. И под описанием функций пошли уже требования к объектам метаданных.

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

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

Дальше – общая структура автоматизируемых бизнес-процессов.

Один самый сложный бизнес-процесс расшифрован до объектов метаданных.

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

И дальше идет описание разрабатываемых объектов – как они будут выглядеть и как будут использоваться.

Давайте посмотрим, какие приемы я использовал в Enterprise Architect для разработки состава сценариев, которые я потом включил в техническое задание.

Во-первых, я сюда из Excel экспортировал требования, которые заказчик писал в тех или иных протоколах.

Дальше – сделал трассировку требований. По каждому требованию связал бизнес-процесс и выявил объекты метаданных, которые с этим бизнес-процессом связаны.

Потом отдельно проработал функциональную структуру.

Дальше связал эти бизнес-процессы с пользователями, чтобы понять, какие роли будут в системе.

И самый сложный бизнес-процесс детализировал до первого уровня.

Этот проект был достаточно успешным, потому что он был хорошо спроектирован. Заказчик эту работу принял, и глобальных доработок не было.

Резюме

Подведу резюме.

• На мой взгляд, за основу техзадания всегда лучше всего брать ГОСТ.
• Техзадание нужно сделать заказчику понятным. Как я показывал, на примере группировки, чтобы как минимум 80% техзадания заказчик понимал, а остальное уже можно уточнить в рамках переговорного процесса.
• Мне очень нравится UML. По моему опыту, это отличная нотация, но я не отвергаю BPMN – он тоже хорошо заходит пользователям, особенно, если какая-то большая система, всегда можно взять верхний уровень сделать в IDEF0, и декомпозировать его в BPMN. Это тоже интересная модель, экспериментируйте, выбирайте лучшие для вас нотации.
• Формально, техзадание – это документ с требованиями. Но если в него включать модель, как я делал, это очень упрощает нахождение взаимопонимания с заказчиком, и, в принципе, это не противоречит ГОСТ-стандарту. Вы просто иллюстрируете требования, поэтому вас никто не будет упрекать в том, что у вас техзадание по ГОСТ-стандарту. По крайней мере, у меня за 15 лет практики такого ни разу в жизни не было, хотя я работал с государственными компаниями. Включение модели в техзадание идет проекту только на пользу – позволяет находить взаимопонимание с заказчиками. И, как я уже говорил, прямо в ГОСТ-стандарте написано, что он позволяет менять трактовку – можно удалять, добавлять разделы. Также рекомендую не обращать внимание на какие-то формальные правила применения UML, как их трактуют на разных ресурсах.
• Делайте так, чтобы было понятно заказчику, находите взаимопонимание с заказчиком. Главное – результат!

Я вам всем желаю успешных проектов! Спасибо за внимание!

Вопросы:

• Как применим такой подход формирования ТЗ и сбора требований для гибкого процесса ведения проектов по Agile?
• Если вы будете работать по так называемому Agile, совершенно не понимая, куда вы идете, то вы никуда не придете. Я не зря включил в доклад модель RUP (Rational Unified Process), потому что в рамках гибких практик очень удобно сделать общее техзадание, чтобы ограничить тот скоуп, куда мы идем. Дальше в рамках каждого спринта делаете частное техзадание, где описываете то, что вы будете делать. Причем в рамках RUP у нас процесс «Бизнес-моделирование» и «Управление требованиями» идет сквозь все этапы – даже находясь на N-нной итерации, вы планируете уточнение требований и архитектуры. Мне эта картинка очень нравится, потому что она реально отображает то, как идут проекты в жизни – не важно, вы работаете по «водопаду» или по Agile, все равно, какие-нибудь уточнения всегда будут. В целом, я считаю, что тот подход, который я презентовал вполне применим и для Agile.
• Вы говорили, что в процессе детализации требований и определения объектов метаданных переходите на контекст системы объектов метаданных. И разговариваете с заказчиком не в терминах бизнеса «Заказ», а в терминах «Заявка новая 4» и т.д. Не является ли это проблемой в будущем для проектов, которые направлены не на создание новой системы с нуля, а на модификацию существующего решения?
• Особенно, когда проекты на модификацию существующего решения, я всегда углубляюсь до объектов метаданных, потому что тогда люди понимают, что «Заказ покупателя» – это форма, в которую нужно добавить поля или изменить ее поведение. Заказчику это понятно. По моему опыту, проблема с непониманием на уровне объектов метаданных может возникнуть только тогда, когда мы внедряем систему там, где 1С еще не было, потому что тогда им менее понятно, что это такое. Но, так как техзадание сгруппировано так, что 80% они понимают, договориться про оставшиеся 20% уже не проблема. Опять же, как я рассказывал, я пытался уйти от техзадания и объектов метаданных, пытался делать бизнес-требования и т.д. У меня это был неудачный опыт. Возникало непонимание того, как система будет выглядеть. Поэтому все-таки я вернулся к тому, чтобы включать объекты метаданных в техзадание.

• При описании новой функциональности вы всегда делаете эскизы экранных форм?
• Покажу на готовом примере. У меня однажды заказчик попросил описать весь объем проекта – что будет использоваться. Мы описали в таком формате: существующий справочник, назначение, доработка – есть/нет. Если нет доработки – картинку не вставляем. Если доработка есть – она описывается.

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

• Как убедить заказчика оплачивать создание ТЗ?
• Не работайте с теми, кто не оплачивает создание ТЗ. Я тоже раньше думал, что ТЗ нужно только для того, чтобы прикрыться, и моя работа состоит только в том, чтобы дорабатывать или создавать какие-то объекты метаданных. Нет, мы создаем систему, которая состоит из программы, инструкции и обученного персонала по работе с этой системой. Это очень важно понимать. И если вам заказчик не готов оплачивать этапы по сбору требований, проектированию системы, по вводу ее в эксплуатацию - не работайте с этим заказчиком, потому что денег вы там точно не заработаете, получите только проблемы.
• ТЗ нужно создавать даже для маленьких задач?
• Я думаю, что да. Но каждое предприятие само для себя выбирает, где находится граница между обычной заявкой на техподдержку и проектной работой.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online.