Техническое задание для своего предприятия

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

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

1. Названия подразделений, отделов и служб предприятия

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

2. Специализированные термины и сокращения

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

1. Общие сведения

1.1. Полное наименование системы и ее условное обозначение

Полное наименование информационной системы

1.2. Шифр (номер) договора

Шифр и номер договора, в соответствие с которым были проведены работы по разработке технического данного задания.

1.3. Наименование предприятий разработчика и заказчика системы и их реквизиты

Разработчик:

Заказчик:

1.4. Сроки выполнения работ

Дата начала работ —
Дата окончания работ —

1.5. Сведения об источнике и порядке финансирования работ

Работы по разработке и внедрению информационной системы оплачиваются в соответствие с договором № ____ от » » ______________ г.

2. Назначение и цели создания системы

2.1. Цели создания системы

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

2.2. Назначение системы

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

3. Требования к системе

3.1. Структура информационной системы

Элементами системы являются:

1. Подсистема управления

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

Основными элементами подсистемы управления являются процедуры.

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

2. Автоматизированное рабочее место

Автоматизированное рабочее место (АРМ) — комплекс, предназначенный для автоматизации деятельности определенного вида.

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

3. средства

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

4. Организационные средства

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

• Процедуры;
• Инструкции пользователя;
• Правила опытной и промышленной эксплуатации;
• Прочие регламентные документы предприятия.

3.2. Требования к структуре и функционированию системы

Исходя из границ автоматизации, структура и функционирование автоматизированной системы управления определяются:

1. Требованиями к составу и свойствам и представлению выделяемых объектов автоматизации;
2. Требованиям к правилам обработки операций с объектами автоматизации;
3. Требованиями к способам и составу получаемой из автоматизированной системы информации;
4. Требованиями к способам и спецификой регистрации, хранения, обработки и получения информация из системы пользователями;
5. Требованиями к деятельности сотрудников и подразделений предприятия.

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

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

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

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

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

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

3.2.1. Границы автоматизации

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

Подразделение	(подсистема управления)	Процедура	Объект автоматизации

3.2.2. Требования к составу и свойствам выделяемых объектов автоматизации

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

Характеристика	Описание	Специфика

3.2.3. Требования к правилам обработки операций с объектами автоматизации

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

3.2.4. Требования к способам и составу получаемой из автоматизированной системы информации

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

Название получаемой информации	Описание	Детальность

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

3.2.5. Требования к способам и специфика регистрации, хранения, обработки и получения информация их системы пользователями

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

3.2.6. Требования к деятельности сотрудников и подразделений предприятия

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

Название АРМа	Количество	Процедура	Пользователь	Функциональность и права доступа

3.3. Требования к реализации системы

3.3.1. Требования к взаимодействию с другими информационными системами

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

3.3.2. Требования к защите информации

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

3.3.3. Требования к сохранности информации при авариях

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

3.3.4. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

3.3.5. Требования к техническому обеспечению информационной системы

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

3.3.6. Требования к численности и квалификации персонала системы и режиму его работы

В разделе приводятся требования к численности и квалификации пользователей системы и режиму его работы (возможно в разрезе АРМов)

4. Состав и содержание работ по созданию системы

Этап работ	Исполнитель	Ответственный	Дата начала	Дата окончания

5. Порядок контроля и приемки системы

5.1. Виды испытаний

В соответствии с составом и содержанием работ по разработке информационной системы должны быть предусмотрены следующие виды испытаний:

• Внутренние испытания при сдаче информационной системы в опытную эксплуатацию силами Исполнителя;
• Испытания информационной системы в ходе опытной эксплуатации силами Заказчика.

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

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

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

По результатам опытной эксплуатации оформляется «Протокол испытаний» с указанием всех недочетов, выявленных во время опытной эксплуатации модуля, который подписывается участниками Рабочей Группы с одной стороны и Менеджером проекта с другой. После доработки модуля Исполнителем составляется «Протокол доработки системы», который визируется Менеджером проекта и участниками Рабочей Группы.

При передачи системы в промышленную эксплуатацию оформляется «Акт передачи системы в промышленную эксплуатации», который визируется Менеджером проекта и участниками Рабочей Группы.

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

6. Требования к составу и содержанию работ по подготовке объектов автоматизации и подразделений предприятия к вводу системы в действие

Наименование мероприятия	Исполнитель	Ответственный	Начало этапа	Конец этапа

7. Требования к документированию

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

8. Источники разработки

1. Договор № от _______ г.

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

Источник

Разработка ТЗ: как составить качественное техническое задание — отвечают эксперты

Разработка ТЗ: как составить качественное техническое задание — отвечают эксперты

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

Алексей Пестерев

руководитель направления «Управление контентом и документооборот» в КРОК

Мое направление в департаменте разработки ПО занимается проектами автоматизации процессов документооборота. Мы разрабатываем и внедряем ECM, СЭД (вендорские решения и систему КСЭД 3.0, собственную разработку, которая включена в реестр российского ПО), электронные архивы, помогаем интегрировать эти системы с ERP, сервисами ЭДО, МЭДО, ССТУ и пр. И входим в пятерку ведущих российских игроков на рынке систем документооборота.

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

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

Иногда в руки попадают ТЗ на 2-3 страницы, и это может быть болью для потенциального исполнителя этого проекта, которому, например, нужно быстро принять решение о подаче заявки на тендер. Плюс при обсуждении такого ТЗ с заказчиком появляются крайне неудобные фразы типа: «Коллеги, мы же все описали в ТЗ, что вам непонятно?». При этом заказчик, который будет потом принимать работы по такому ТЗ, тоже будет в недоумении.

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

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

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

Аида Хакимуллина

менеджер по продукту IT-компании Maxima

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

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

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

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

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

При составлении ТЗ излагайте свои мысли от общего к частному, от проблемы к решению, от бизнес-требований к системным.

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

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

Не забывайте про оформление: структурированный текст — 50% успеха.

Яна Шапошникова

менеджер продукта компании-разработчика российского офисного ПО «МойОфис»

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

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

Типичные ошибки и подводные камни при составлении ТЗ:

• Не указана ЦА. Когда необходимо рассказать о пользователях продукта или какой-то отдельной его функциональности, заказчик часто углубляется в описание рабочих процессов, но никакой информации о ЦА или о том, какие ее проблемы необходимо решить, так и не обозначает.
• Нет конкретной цели. Из полученного ТЗ не всегда могут быть понятны приоритеты задач и назначение функций.
• Не определены ответственные с каждой из сторон. Очень важно, чтобы заказчик и исполнитель одинаково прозрачно понимали конечное ожидание от продукта или его функциональности. Для этого необходимо иметь возможность обратиться друг к другу с уточняющими вопросами. Чтобы этот процесс был структурирован, с каждой из сторон должны быть определены ответственные сотрудники.

Антон Макаров

руководитель диджитал-продакшена Creonit

Думаю, самая большая ошибка — это огромное подробное техническое задание.

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

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

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

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

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

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

Юлия Ершова

Project Manager в SEMrush

Многие думают, что ТЗ — это пережиток прошлого и атрибут излишней бюрократии в современном IT-мире с agile-подходом ко всему. Но по моему опыту, ТЗ по-прежнему неплохо работает как инструмент для повышения прозрачности на проекте и, кроме того, является неким страховым полисом для участников проекта. А страхует оно от неоправданных ожиданий Заказчика и неправильно трактуемых требований Исполнителем.

Правильное ТЗ должно быть прежде всего таким:

• Максимально подробным в отношении важных функций проекта.
• Однозначно трактуемым.

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

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

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

Вот основные пункты, которые точно должно содержать любое ТЗ:

• Цели и задачи, которые должны быть решены в проекте.
• Сроки.
• Рамки проекта (что должно быть сделано, а что не входит в проект).
• Подробное описание состава проекта и требований к нему.
• Требования к результату.
• Порядок сдачи/приемки проекта.

Ну и последнее, но немаловажное. Цель должна оправдывать средства, поэтому если проект небольшой (условно, сделать работу по нему будет быстрее, чем написать ТЗ), то скорее всего для такого проекта ТЗ будет избыточным. В таких кейсах можно использовать более лаконичные способы формулировки содержания проекта, например, Бриф или Устав.

Аветис Вартанов

руководитель отдела обучения QBF

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

Основная задача ТЗ – донести до разработчика идею заказчика. При этом важно, чтобы:

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

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

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

Несколько советов для заказчика:

• Помните, если речь идет о творческой работе, ваши представления о чем-либо всегда отличаются от представлений другого человека. Поэтому формулируйте все фразы четко, без эмоций, с единственно возможной трактовкой.
• Если есть примеры работ, которые вам нравятся, передайте их исполнителю, так будет больше шансов на понимание. Визуально для творческих людей воспринять проще, чем текстом.
• Даже по идеально составленному ТЗ могут возникнуть вопросы. Не игнорируйте исполнителя. Некоторые гениальные и продающие идеи рождаются даже не в процессе механической работы, а в ходе обсуждения. Не лишайте себя шанса получить от исполнителя даже больше, чем вы описали в ТЗ.
• Для некоторых работ (IT-разработки, исследовательские изыскания) необходима документация. Без ее изучения не получится нужный результат. Не забудьте предоставить ее исполнителю или будьте готовы по его просьбе выдать нужные документы. Не всегда можно обойтись одним техническим заданием.

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

Екатерина Баукина

руководитель отдела ведения проектов DD Planet

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

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

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

Речь не идет о конкретных архитектурных решениях — как именно мы будем хранить данные. В ТЗ должны быть отражены вопросы такого плана: удаление или архивирование сущностей (пользователей, данных), логирование, статистика, администрирование контента и фильтры, сортировки по этому контенту в административном разделе. Использование коробочных систем, например 1С-Битрикс, много таких вопросов снимает. Но при кастомной разработке ничто не может «подразумеваться по умолчанию». Для разработчика не существует того, что не описано в ТЗ и договоре. Хорошо, если при вышеупомянутой оценке разработчик обратил внимание на отсутствие ряда функциональностей и в смету включил. Но на этапе тендера такие правильные детали могут сделать коммерческое предложение неконкурентным, а представитель заказчика, проводящий тендер, не всегда готов улавливать такие тонкости – у него иные критерии на этапе выбора подрядчика: цена, опыт в схожих проектах и тематике. А внимательность и техническая компетенция при оценке проекта будут далеко не первым критерием при оценке.

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

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

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

Примеры ошибок в ТЗ из нашей практики:

1. Не учтено логирование при большом количестве контент-менеджеров: невозможно найти, кто внес то или иное изменение. Здесь же обратный случай: не продуманы группы пользователей и их права, со стороны клиента все ходят в админку под одним логином администратора (и люди, отвечающие за добавление новостей, и seo-специалисты, и бухгалтеры).
2. Не продумано удаление и архивирование элементов и разделов: если на элементы завязана какая-то статистика или заказы и это где-то демонстрируется, надо продумать, оставляем ли мы архив и как мы решаем, что показывается. Это важно и для поискового индекса.
3. Не описан механизм нетиповой интеграции с 1С (endpoint, принципы, пр.) – согласование и выстраивание этой интеграции потребует плотных коммуникаций разработчиков и 1с-специалистов, времени и плотного контроля заказчика.
4. Нет выгрузки товарного каталога и описания хранимых данных в 1С по товарам – все они в итоге отдают одно свойство «характеристики», а в ТЗ предусмотрена фильтрация.
5. Не описана созависимость фильтров.
6. Упущены сортировки как таковые.
7. Административный раздел не описан полностью.
8. В административном разделе не описаны фильтры по заказам по дате, номеру, телефону, вообще какие-либо фильтры, которые будут необходимы администратору.
9. Управление мета-тегами забывают всегда: про то, откуда у страницы берется title – нигде не зафиксировано. Здесь же можно отметить весь пул SEO чек-листа (ЧПУ, 404, хлебные крошки, robots, коды счетчиков, редиректы и т.п.).
10. Не прописаны обязательные по законодательству ссылки в футере (например, СОУТ или «Политика конфиденциальности»).
11. Не описаны почтовые уведомления, которые вообще должны быть (о заказе, регистрации, отправленной форме и т.д.).
12. Не описано управление промо-баннерами. Описано все, но про сквозные картинки в дизайне и про слайдер – забыли.
13. Не продумана и, соответственно, не описана работа с заказами, оплатой и доставкой. Какие будут возможности оплатить заказ? Будет ли работа с юридическими лицами, можно ли им дать возможность сразу выставлять счет или работаем только через менеджера? Какие службы доставки используются, какие данные по заказу и товару нужны для расчета стоимости и сроков доставки? Какие статусы заказов, на каких этапах происходит оповещение пользователя о смене статуса и по каким каналам?
14. Клиент при написании ТЗ не продумал структуру контента, не определил разделы и подразделы. Необходимость вложенного меню с подуровнями может выясниться уже после завершения программирования при внесении контента.

Пишите и читайте ТЗ внимательно. Помните: любые неоплачиваемые доработки проекта вне ТЗ и договора съедают вашу маржинальность.

Источник