Техническое задание на проектирование для чего нужно. Перечень вопросов по ТЗ
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.
ГОСТ 34
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
ГОСТ 19
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
IEEE STD 830-1998
Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
- 1. Назначение
- 2. Область действия
- 3. Определения, акронимы и сокращения
- 4. Ссылки
- 5. Краткий обзор
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
- 2. Функциональные требования
- 3. Требования к производительности
- 4. Проектные ограничения (и ссылки на стандарты)
- 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
- 6. Другие требования
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.
Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
- Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
- Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
- Правила составления Software requirements specification (читать вместе с комментариями)
- Примеры ТЗ и другой документации по разработке АС для МЭР
- ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
- Шаблоны документов для бизнес-аналитиков из
Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.
При наличии описания закупаемой продукции в КТРУ заказчик обязан:
- описывать объект закупки так, как это предусмотрено КТРУ;
- включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).
Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.
Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:
- указание на эквивалент;
- обоснованность регламентами или иными нормативными документами;
- наличие спецификаций, планов, чертежей, эскизов, изображений (при необходимости);
- новое состояние товара (если нет иной потребности у заказчика);
- требования в отношении , предоставлении гарантии.
Что указать в техническом задании
- общая информация;
- информация о закупаемом объекте;
- требования к поставщикам;
- условия ;
- приложения (допускается по усмотрению заказчика).
Этапы составления технического задания
1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.
2. Предоставить полную информацию о заказчике:
- наименование (официальное название организации с указанием организационно-правовой формы);
- адрес (организации или подразделения, которое отвечает за госзакупку);
- режим рабочего дня в соответствии с внутренним трудовым распорядком.
3. Предусмотреть в информации о закупке сведения:
- или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
- централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
- привлечение экспертов, порядок их работы.
4. Перечислить сведения о госзакупке:
- способ определения поставщика (ч. 1 ст. 24);
- обоснование выбранного способа определения поставщика (ч. 5 ст. 24).
5. Перечислить требования к участникам: деловая репутация, наличие у них производственных мощностей.
6. Указать исходные условия: справочная, производственная, опытная информация, которые оказывают влияние при исполнении контракта. Например, что обслуживать закупаемую технику возможно только в утренние часы.
7. Привести сведения об особенностях производственного процесса или архитектурного объекта заказчика, которые повлияют на процесс исполнения контракта. Например, при составлении технического задания на может понадобиться указать, что при доставке необходим подъем на третий этаж вручную из-за отсутствия лифта.
8. Указать точное местоположение объекта, а при необходимости — его полное описание. Это может потребоваться, например, для проектирования инженерных коммуникаций или для точного расчета стоимости ремонта.
9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).
10. Указать источник финансирования.
11. Установить для участников требование соблюдать определенную нормативно-правовую базу, в том числе относящуюся к предмету контракта, условиям исполнения, срокам, гарантийным обязательствам.
12. Определить условия госзакупки (ч. 1 ст. 19).
13. Указать наименование и обоснование объекта госзакупки.
14. Максимально точно и детально описать объект госзакупки (ст. 33).
15. Определить экологические особенности закупаемого объекта.
16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.
17. Определить гарантийный срок и объем предоставляемых гарантий.
18. Установить требования к упаковке, маркировке, какие условные и специальные обозначения должны быть на ней.
19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.
20. Определить расходы на эксплуатацию.
21. Определиться, нужны ли монтаж и наладка.
22. Установить порядок поставки и приемки.
23. Указать на необходимость провести испытания, обучение лиц, которые будут использовать закупаемый товар.
Образцы техзаданий для товаров, работ, услуг в 2019 году
Помните, что универсальный образец технического задания по ФЗ-44 не разработан к каждой закупке требуется индивидуальный подход. Только так можно учесть все потребности и особенности заказчика. В качестве ориентира вы можете использовать этот пример технического задания по 44-ФЗ (образец).
Ниже представлен образец технического задания на поставку товара по 44-ФЗ.
Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .
Вопрос «Нужно ли вообще составлять техническое задание (ТЗ)?» может возникать только у тех, кто никогда в жизни не заказывал разработку сайта, поскольку необходимость в нём возникает после первого же общения заказчика с исполнителем.
ТЗ - это документ, который описывает будущий проект детально и полностью. Чем детальней он будет, тем точнее будет реализована задумка и тем меньше конфликтов и спорных ситуаций в ходе выполнения проекта будет возникать, ведь абсолютно любую вещь можно сделать по-разному. На него можно ссылаться, если что-то не выполнено или выполнено не так или допущены другие ошибки. Перед началом работ заказчик обычно в тезисном виде описывает будущий проект или заполняет бриф, а исполнитель формализует все эти требования и пожелания, при необходимости, предлагает корректировки. При этом заказчику необходимо убедиться, что все его "хотелки" зафиксированы в тех задании.
Если с веб-студией или фрилансером будет заключаться договор на разработку сайта, то тех задание обычно идет, как приложение к нему. И в спорных ситуациях, руководствуются тем, что там написано.
Из чего состоит ТЗ?
Предположим, в рамках проекта требуется составить техническое задание на разработку сайта студии копирайтинга «Перо». Какие пункты оно должно содержать?
Общие сведения (описание)
Здесь указываются:
Сведения о компании . Общая информация о студии, чем она занимается. Не лишним будет привести список оказываемых услуг. Сюда же можно добавить адрес будущего сайта, контактные данные.
Этапы и сроки реализации проекта . Очень важный момент, как правило, календарный план по всем этапам работ составляют в самом конце. Эта часть даёт понимание, что и когда будет делаться. Например (с указанием дат):
- Подготовительный этап;
- Проработка концепции сайта;
- Проектирование;
- Создание дизайн-макета;
- Разработка дизайна страниц;
- Вёрстка;
- Программирование;
- Наполнение контентом;
- SEO-оптимизация;
- Тестирование;
- Запуск.
Каких-то этапов, например, SEO-продвижения может и не быть. Зависит от целей и задач заказчика и компетенций исполнителя.
Назначение и цели
Здесь формулируется, какие функции будет выполнять сайт и для кого он предназначен.
Назначение сайта . Каких целей созданием сайта необходимо достичь? Для чего он нужен, какие задачи решает?
- Реклама и привлечение новых клиентов;
- Поддержка заказчиков и партнёров;
- Демонстрация выполненных работ;
- Ознакомление со списком услуг;
- Создание и поддержание имиджа компании.
Возможно, некоторые пункты стоит расписать более подробно. Например, если перед сайтом стоит задача в том числе и информировать посетителей, то лучше пояснить, о чём именно.
Целевая аудитория . Кто будет пользоваться сайтом, для кого он создаётся?
- Веб-мастера, блогеры;
- Владельцы интернет-магазинов;
- Владельцы информационных порталов;
- Рекламные студии;
- Представители присутствующих в онлайн-пространстве фирм и компаний.
Требования
Большой и крайне важный раздел, в котором учитывается как можно больше моментов проектирования и разработки, потому как за неоговоренный в ТЗ функционал заказчику придётся доплачивать.
Тип . К какой категории принадлежит веб-ресурс?
- Посадочная страница;
- Сайт-визитка;
- Корпоративный сайт;
- Информационный портал;
- Интернет-магазин.
Требования к оформлению . Они могут быть следующего вида:
- Сайт должен быть минималистичным и при этом отражать род деятельности компании.
- Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
- В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
- Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).
Что касается требований к дизайну, то тут можно применять разные подходы. Если заказчик сам точно знает, что хочет получить, то описывает подробно свои пожелания, приводит примеры сайтов, которые ему нравятся и дает прочую конкретику. Но иногда бывает так, что и он сам точно не знает, как это все должно выглядеть, в этом случае обычно исходят из задач, которые должен решать дизайн. Исполнитель прорабатывает концепции, предлагает решения, защищает свою идею и корректирует его по замечаниям заказчика. Второй вариант стоит дороже и требует большей квалификации от подрядчика.
Языковые требования . Носители какого языка смогут посещать ресурс? Какие языковые версии сайта должны быть?
- Русский;
- Английский;
- Эсперанто.
Требования к совместимости . С каких устройств и какими браузерами сайт точно будет открываться корректно? В последнее время наметилась тенденция к адаптивной вёрстке, когда страница правильно отображается на любом устройстве с любым соотношением сторон и разрешением экрана. Здесь можно перечислить браузеры, с которыми однозначно должен быть совместим ресурс. Обычно на всех современных браузерах сайты отображаются одинаково, бывают только проблемы со старыми версиями Internet explorer.
Требования к CMS . Возможности администрирования сайта определяют, какие именно блоки можно редактировать и настраивать через панель управления, не вмешиваясь в код и не редактируя напрямую базу данных, а используя удобный визуальный интерфейс. Например, можно сформулировать так:
- Возможность изменения контента на страницах сайта;
- Возможность управления страницами (добавление, переименование, удаление и т. д.);
- Возможность редактирования структуры сайта и пунктов меню;
- Функции автоматической обработки графики (создание превью, трансформация под заданный размер и т. п.);
- Возможность прописывать уникальные Мета-теги;
Как и в других подразделов, нужно описывать все требования и пожелания.
Часто заказчик уже имеет опыт работы с одним из популярных CMS , тогда целесообразно искать порядчиков под конкретный движок. Также при выборе CMS лучше не соглашаться на самописные решения, т.к. в дальнейшем это поставит в зависимость от исполнителя. Самописные движки, на мой взгляд, оправданы только в очень крупных проектах, где требуется специфичный функционал или оптимизация больших нагрузок.
Структура и навигация . Какие разделы, подразделы и отдельные страницы будет содержать проект?
- Главная страница
- Услуги
- Копирайтинг
- Рерайтинг
- SEO-коперайтинг
- Корректура
- Транскрибация
- Контент-менеджмент
- Контент-маркетинг
- Портфолио
- О нас
- Контакты
Сделайте и краткое описание каждой страницы, дайте определения. Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?
Желательно контент или хотя бы его наброски приготовить еще до начала работ с подрядчиком. Это будет способствовать более эффективной коммуникации.
Дополнительные требования . Всё, что не вошло в другие пункты раздела.
Описание разделов сайта
В этом пункте - детали. Обычно расписывается содержание всех уникальных страниц: какие элементы там будут, как пользователь будет взаимодействовать с ними.
Главная страница . Формулировка задачи может быть в следующем виде.
Основная часть главной страницы должна быть выполнена в виде Landing Page . На ней сверху вниз должны располагаться следующие элементы:
- Шапка - логотип, название фирмы;
- Меню навигации;
- Информация об акциях и скидках;
- Кнопка заказа;
- Рекламный текст;
- Блок с пятью лучшими работами и ссылкой на раздел портфолио;
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки - выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Переводим на понятный язык
1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый - сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» - официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? - Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? - Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть - куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты - то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.
Многие компании не готовы привлекать подрядчиков на этап написания технического задания, полагая, что каждый подрядчик будет писать понятный только его сотрудникам документ, фактически гарантируя себе привилегированное положение на конкурсе\тендере.
Отчасти это действительно так, но связано подобное явление во многих случаях не столько с меркантильными интересами подрядчиков, сколько с различиями в подходе к реализации данного документа.
В определении технического задания на Википедии, в частности, говорится, что это «документ, содержащий требования заказчика к объекту закупки, определяющие условия и порядок ее проведения для обеспечения государственных или муниципальных нужд, в соответствии с которым осуществляются поставка товара, выполнение работ, оказание услуг и их приемка».
Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.
Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».
Одно время в отделе, где я работал, было принято следующее разделение: Техническим заданием назывался документ, описывающий требования к системе на понятном для бизнес-пользователей языке, а Техническим проектом – документ, составленный на основании Технического задания, более подробный, детально описывающий все функции, но уже на языке, понятном в основном разработчикам .
Мне данная характеристика, пусть и не являющаяся верной с формальной точки зрения, видится весьма справедливой для небольших компаний, у которых нет сверх бюджетов, но есть задачи, требующие срочного решения. Основным для них становится составление ТЗ силами своих сотрудников и его рассылка, к примеру, в несколько фирм-франчайзи. И естественно, что писать огромную простыню, содержащую неимоверное количество технической информации никто не будет.
Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?
Я не буду описывать основополагающие требования к структуре документа, такие как: в ТЗ должны быть описаны цели проекта, содержаться функциональные требования, должен присутствовать список сокращений и оглавление, написано все должно быть максимально простыми и короткими фразами и т.д. Считаю, это известно всем, кто хоть несколько раз читал технические задания.
Документы, с которыми мне приходилось сталкиваться, и на основании которых были получены максимально близкие к задумке результаты, обладали следующими свойствами:
1. ТЗ как инструкция . Документ по своей структуре напоминает инструкцию пользователя, где пошагово написано, в каком случае какие действия нужно выполнить пользователю, чтобы получить требуемый результат. Т.е. это были документы без сплошного перечня требуемых функций, но с логической разбивкой на отдельные процессы с описанием их специфики
2. Больше визуализации . Чем больше в документе содержится макетов\скриншотов\мокапов\блок-схем, тем меньше вероятность получить выполняющую вроде бы нужные функции, но обладающую совершенно иной логикой\оформлением\интерфейсом систему
3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.
4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.
5. Первичная обратная связь . Еще раз повторюсь - для успешной реализации ТЗ его не обязательно писать по ГОСТу. Не нужно писать документ, предназначенный только техническим специалистам. Техническое задание в первую очередь должно быть понятно коллегам его составителя, а потом и тем, кто будет его реализовывать. Крайне важно получить положительную обратную связь от коллег бизнес-пользователей, прежде чем направлять документ потенциальным подрядчикам или внутреннему отделу разработки. Документ, предельно ясный одному человеку, но не понятный даже ближайшему окружению не имеет шансов на успешную реализацию.
Безусловно, есть различные точки зрения на требования к составлению ТЗ. Однако в ситуации отсутствия должного количества времени, ресурсов и компетенций, именно написанное на максимально понятном для бизнес-пользователей языке техническое задание, обладающее указанными выше свойствами, будет иметь максимальные шансы на успешную реализацию.