Техническое задание на написание сценария

Сохраните этот документ у себя в удобном формате. Это бесплатно.

г. _______________ «__»_________ ____ г.

Срок сдачи первого варианта Произведения _____________________

Вознаграждение Исполнителю ___________________________________

Окончательный расчет производится не позднее трех дней после

Исполнитель не вправе претендовать на иные суммы, связанные с

созданием или использованием, а также передачей прав на

Произведение, указанное в задании.

Сохраните этот документ сейчас. Пригодится.

Техническое задание – документ, который многим кажется слишком дорогим удовольствием. Руководитель консалтингового направления ГК СофтБаланс Клавдия Макарова объяснила, почему нельзя на него смотреть только с этой точки зрения, и какую пользу он приносит команде и заказчику.

Тема моего доклада – техническое задание как обязательный атрибут в автоматизации. Мы разберем реальные кейсы из моей 16-летней проектной практики.

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

Для кого и для чего

Давайте разберемся, для кого и для чего нужно техническое задание, на чем оно базируется, на что нужно обратить внимание?

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

Мы делаем ТЗ, чтобы максимально снизить риски. Заказчику важны деньги – он должен понимать, за что он их платит, а мы все-таки продаем не шоколадные батончики, когда можно четко сказать, сколько это стоит.

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

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

Поэтому ТЗ – это инструмент управления рисками. И в принципе любая документация на проекте нужна для снижения рисков.

Остановимся на некоторых моментах подробнее.

Хочу начать с цитаты моего коллеги, технического руководителя Олега Олейниченко.

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

Получается, что аналитик – это некий «универсальный солдат»: ему нужно донести информацию и до заказчика, и до программиста, и дать оценку руководителю проекта.

А со своей стороны мы, руководители проектов, руководители направлений и отделов, должны обеспечивать аналитиков нужной информацией.

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

От того, насколько одинаково понимают ТЗ заказчик и исполнитель, зависит успех проекта. Включение моделей на UML и BPMN в состав ТЗ помогает упростить взаимопонимание с заказчиком и обеспечить минимум доработок за счет полного покрытия всех процессов функциональностью системы. О том, как грамотно составить ТЗ и увязать требования заказчика с детализированными моделями, на митапе Saint Petersburg.Online рассказал Сергей Наумов.

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

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

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

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

Не решайте за программиста

Посмотрим еще один кейс. Я всегда говорю: не решаете за программиста, как нужно делать ту или иную задачу технически. Это может быть оправдано, только если он – простой кодер или начинающий специалист.

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

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

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

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

Я помню свое негодование, когда программист сделал все не по моему ТЗ и, не спрашивая меня, перевел допреквизит во встроенный реквизит.

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

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

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

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

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

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

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

Другие статьи в нашем блоге

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В поисках универсального подхода

Вкратце расскажу про свой 16-летний опыт.

Начинала я как консультант горячей линии. Будучи по натуре аналитиком, я не могу не анализировать всю информацию, которая ко мне приходит. И все 16 лет я искала этот «философский камень» написания технического задания.

Мне удалось поработать с большим количеством программистов, и я убедилась, что подход к ТЗ у всех разный. Передо мной в свое время даже стояла задача – понять программистов, придумать, как работать с различными специалистами по каким-то одинаковым критериям. Оказалось, что это невозможно. Тогда я для себя придумала идею, что программист – это художник. Когда художник рисует, он может одну и ту же картину нарисовать абсолютно разными красками, абсолютно по-разному наложить слои. И когда я придумала себе такую ассоциацию, мне стало немного легче.

Когда я уже работала бизнес-архитектором, я знала всех программистов у нас в компании. У нас, как и во многих других франчайзи, есть пул абсолютно разных специалистов, каждого из которых я могла подключить на проект. Я знала их всех наизусть – знала все нюансы и подходы, знала, какого программиста надо 2-3 раза проверить, а кого проверять не надо и можно даже попросить ещё кое-что сделать. Это было очень забавно, как какая-то игра.

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

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

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

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

Когда ТЗ не нужно

Рассмотрим, в каких случаях техническое задание не нужно.

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

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

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

Второй случай – ТЗ не нужно, когда идет исправление ошибок. Бывают ситуации, когда разработчики уже реализовали решение по ТЗ, а потом появляются ошибки, и заказчик настаивает, чтобы в первичное ТЗ были внесены изменения.

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

Паспорт проекта можно вести в СППР – не все эту систему используют, но у всех, кто работает с 1С, к СППР есть доступ. Что бы ни говорили о сложности СППР, в ней, как минимум, можно фиксировать требования и вести паспорт проекта.

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

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

Еще ТЗ не нужно, когда важна скорость проверки гипотез. Здесь клиент просто не согласится на длительное согласование ТЗ, ему нужна скорость – нужно проверить одну, вторую, третью гипотезу.

В этой ситуации возникают большие риски, которые, конечно, должен проработать руководитель проекта. Он должен договориться с заказчиком, объяснить эти риски, объяснить, во сколько это обойдется. Он должен поработать с ценообразованием, создать атмосферу для аналитика и программиста, чтобы они могли безболезненно проверять гипотезы.

В этом случае правила игры должны быть проговорены на берегу, нельзя просто ограничиться подписанием договора.

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

Когда у вас уже есть каркас решения – например, в точках Т3 и Т4, время и стоимость могут кардинально увеличиться, а приращение качества и точность прогноза уже не достигаются. Поэтому было бы здорово, если бы вы понимали и чувствовали, когда нужно остановиться в улучшении технического задания.

Вам в этом плане поможет совокупность «техническое задание – система учета задач – паспорт проекта». Если эти три инструмента работают в связке, они вам дальше помогут.

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

Ключевые положения регламента по составлению ТЗ

Все требования, которые формирует аналитик, должны подчиняться трем ключевым правилам:

ТЗ – совместный труд аналитика и программиста

Давайте посмотрим еще один кейс, который доказывает, что ТЗ – это совместный труд аналитика и программиста.

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

Аналитик пишет техническое задание, базирует на этом документе отчет.

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

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

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

Поэтому ТЗ – это труд совместный. Нужно взаимодействовать.

Как работать с дизайнером над обложкой книги

Рассказываем, как составить техническое задание дизайнеру. Советы авторов и специалистов

Если вы еще не раскрученный писатель, то встречать вас будут именно по обложке. Ведь она создает первое и самое важное впечатление о произведении. Можно написать прекрасный текст, который так и не начнут читать, потому что человеку не понравилось оформление книги. Авторы Литрес в «Историях успеха» неоднократно рассказывали, что уделяли обложке особое внимание, потому что она помогает привлекать внимание людей, увеличивать продажи. Кстати, если вы будете заказывать рекламу романа или заниматься ей самостоятельно, хорошая обложка будет обязательным условием для успешности кампании.

В этой статье мы расскажем, как работать с дизайнером. Даже если у автора есть исходная картинка и он представляет, каким должен быть результат, все равно большинство идут к дизайнерам. Почему? Нужно правильно разместить изображение, подобрать стиль и размер шрифта, позаботиться о сочетании цветов, о композиции и не только. Рассказываем, как ставить техническое задание (ТЗ) дизайнеру, чтобы результат порадовал вас и читателей. Советы дают авторы и специалисты Литрес.

Авторы рассказывают, как работали с дизайнерами

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

• Я сразу знала чего хочу от обложки, поэтому искала художника, чей стиль лучше подошел бы к атмосфере истории. 1. Самым сложным в ТЗ было подобрать референсы подходящие под образы, которые мне хотелось увидеть на обложке. Фон (три пейзажа в разбитом стекле), внешность героев, их одежда, позы и настроение — я прописала все, и приложила к описаниям визуал, который нашла. Нужно оговориться, я точно знала чего хочу. Когда идея для обложки нечеткая или я в чем-то сомневаюсь, просто полагаюсь на художников.2. Самой важной была композиция. Я хотела, чтобы герои находились на переднем плане, как бы отделенные от фона. 3. Цвет и шрифт мы с художницей подбирали на этапе эскиза.4. О самой книге не рассказывала дизайнеру ничего. Только о характерах героев, чтобы лучше отразить их отношения на обложке.
• На обложке должны были быть ключевые персонажи: обаяшка-главгерой, умный ученый, храбрая девица. И должно было быть что-то, что характеризует историю. В моей книге есть фантастическое допущение о других планетах и защитном куполе для колонии людей. На обложке есть «мерцание» купола и два спутника, то есть сразу сообщаем читателю, что тут будет про космос. 1. Я скинула примеры обложек и стилей, которые мне понравились: постеры старых аниме-сериалов, обложки «Космоолухов» Ольги Громыко, обложки современных романов, которые мне понравились по стилистике.2. Расписала детально идею и добавила референсы на каждого персонажа. Нашла подходящие фото в сети, и прислала как пример с указанием «тут надо такой цвет волос и глаз, отсюда подходит подбородок, отсюда прическа». О книге рассказала в общих чертах, о персонажах подробно, чтобы у художницы возникло представление о том, как персонаж себя ведет, какие у него привычки и особенности. В общем, чем красочнее автор дизайнеру представит персонажа, тем лучше будет результат.3. Композицию мы обговорили сразу при обсуждении идеи. Цвета и шрифты я отдала на откуп дизайнеру. Единственное условие было использовать шрифты, которые пригодны для коммерческого использования, или отрисовать уникальные.

Советы от дизайнера Литрес

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

Дизайнер Литрес Ирина Кириллова работает с авторами и помогает довести идею обложки до ее реального воплощения. Она отлично знает, как правильно составлять техническое задание (ТЗ) на создание обложки. Рассказываем все секреты того, как дизайнеры работают над обложками и какую информацию им нужно предоставить, чтобы получилось красиво.

Что писать в техническом задании дизайнеру?

В ТЗ заказчик ставит конкретные запросы:

• кратко и емко описывает свое произведение;

• делится своим видением обложки;

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

• описывает нужные образы, рассказывает о характерах персонажей;

• прикрепляет материалы, которые стилистически близки тому, что хотелось бы получить (референсы).

Нажмите, чтобы увеличить изображение

Что мне нужно рассказать дизайнеру о своей книге? И как лучше это сделать?

Лучше всего кратко описать сюжет книги и его общую суть в небольшом абзаце. К сожалению, дизайнеры не имеют возможности прочесть и изучить все произведение. Поэтому выделите в тексте самое важное и расскажите об этом. То, что нужно дать дизайнеру, похоже на сжатый синопсис, или немного расширенную аннотацию

Что помимо моего текста поможет дизайнеру понять, что я хочу?

Я назову референсы: изображения лучше всего помогают исполнителю понять предпочтения заказчика. Например, в ТЗ автор описал свою героиню: платье прошлых веков, лиф с короткими рукавами, сапоги с застежками, цветочный головной убор и сложная прическа. Вполне подробное описание, не так ли? Однако, если бы оно было подкреплено визуальными примерами того же платья или прически, то дизайнер смог бы быстрее и точнее воплотить образ.

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

Референсы могут быть любые: примеры уже существующих обложек, художественные работы, фотографии — все, что визуально близко к видению автора. То же можно сказать и про общие цвета и шрифты, если у автора есть конкретные запросы, то стоит упомянуть их в ТЗ.

Зачем дизайнер спрашивает: «Какие эмоции должна вызывать обложка»?

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

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

А если я не знаю, как сочетать цвета или ничего не понимаю в шрифтах?

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

Правила заказа обложек в Литрес

Дизайнер чаще всего представляет заказчику 9 вариантов иллюстраций. Но есть нюансы, о который стоит упомянуть.

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

Работа проходит в 3 этапа:

1. Создание первых вариантов. Заказчик смотри и дает правки, на основе которых дизайнер подготавливает новые изображения.2. Дизайнер дорабатывает варианты и представляет уже новые обложки. После автор также может дать правки и уточнения, если они имеются. 3. Заказчику представляют финальные, доработанные на основе правок, варианты обложек, одну из которых автор должен утвердить и получить.

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

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

Была ли данная статья полезна для Вас?

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

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

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

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

Резюме

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

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

Кейсы №4, 5, 6. Описывайте реквизиты, визуализируйте диалоговые окна и печатные формы

В ТЗ рекомендую оформлять реквизиты в виде таблицы. Это очень важно.

Обязательно визуализируйте формы.

Это можно делать в Excel.

Или в 1С Maker.

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

Вопросы

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

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

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

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

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

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

Сценарии тестирования

И, наконец, сценарии тестирования. Это – то, что поможет программистам. Если у вас есть сценарии тестирования, программист сможет проверить, как с этим работать.

В сценариях тестирования нужно обязательно определять:

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

Сценариев тестирования может быть достаточно много.

На слайде показан маленький пример.

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

Я считаю, что сценарий нужен обязательно. Мы сейчас добавляем сценарии тестирования во все ТЗ, и нам это очень помогает.

Дополнительные рекомендации для работы со сценариями тестирования:

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

Дайте определение, что такое ТЗ с вашей точки зрения, и что такое паспорт проекта, о котором вы упоминали. Потому что разные люди вкладывают в эти понятия разные вещи.

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

А как соотносятся понятия «паспорт проекта» и «устав проекта»?

Давайте не путать устав проекта, с которым работают руководители, и паспорт проекта, с которым работают программисты. Для меня паспорт проекта – это не ключевые вводные по проекту и не оргструктура. Паспортом проекта я называю систему, с которой мы работаем, она так и называется «Паспорт проекта». В ней ведется именно технический проект, техническая информация, по каким требованиям какая реализация сделана.

Учитывается ли длина жизненного цикла информационной системы при определении нужности ТЗ? При добавлении одного реквизита или для систем с коротким жизненным циклом ТЗ действительно не нужно. А если жизненный цикл системы больше 20-40 лет, лучше писать ТЗ или вносить изменения в существующее ТЗ и вести историю изменений?

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

А если система уже работает, в нее уже заведена вся информация, и приходит поток требований на доработку, вы можете, конечно, сделать на эти требования ТЗ. Главное, чтобы через 40 лет компания смогла разобраться во всех этих ТЗ.

В любом случае, эффективна связка трех подходов: «ТЗ – система учета задач – паспорт проекта».

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

ТЗ для заказчика и для программиста – это два совершенно разных документа, два разных видения. Можно ли эти видения совместить в рамках одного документа? И хороша ли эта практика?

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

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

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

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

Есть ли какой-то стандарт по написанию ТЗ или «что хочу, то пишу, я руководитель проекта, мне виднее»?

Представители 1С знакомы и с технологией корпоративного внедрения, и с технологией быстрых результатов, и т.д. Загляните в Профкейс, если никогда этого не делали.

Я уверяю, что многие аналитики даже не знают, что такие материалы есть в Профкейсе, это то, что рекомендует сама фирма «1С» – вы как сотрудники фирмы-франчайзи имеете право на эти документы посмотреть.

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

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

Поэтому есть общие какие-то моменты, на что нужно обращать внимание, есть регламент системы менеджмента качества (СМК), который спускает вендор. А дальше уже все решают ваш опыт, творчество и умение творить чудеса.

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе «Сбор требований и составление ТЗ: современные подходы в управлении проектами». Больше статей можно прочитать здесь.

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

О себе

• Я руковожу консалтинговым направлением в группе компаний СофтБаланс.
• В проектной деятельности я более 16 лет.
• Начинала с московского франчайзи, потом работала в фирме «1С», в «Учебном центре №3», и даже проводила сертификацию преподавателей ЦСО по бухгалтерскому учету в 1С – принимала экзамены.
• В декабре 2020 года я запустила первую онлайн-школу бизнес-архитекторов, потому что на текущий момент, к сожалению, никто не дает для архитекторов 1С совокупных знаний, которые можно было бы освоить за 6 месяцев. Из-за этого, к сожалению (или к счастью), очень многие специалисты в сфере 1С вырастают «кустарным методом».
• Также я являюсь профессиональным корпоративным спикером.

Но в первую очередь, конечно, я руководитель отдела консалтингового направления в группе компаний СофтБаланс. В моей команде 25 человек, мы растем, и в ближайшее время я ожидаю пополнения своей команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

Хотя вначале заказчику кажется, что техническое задание – это неоправданно дорого, в итоге он видит, как сокращено время. И, если руководитель проекта умеет донести до заказчика ценность технического задания, то вам, аналитикам и программистам, будет удобно с этим работать.

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