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

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

Проще говоря, продукты низкого качества предлагают нам небольшое содержание по функционалу и ценностям, например "старый Б/У запорожец". А продукты высокого качества предлагают нам большой набор содержания - функционала, красоты, ценностей и т.д, например, "новая BMW".

Справедливо отметить, что понимание низкого или высокого качества - это дело относительное и субъективное. Однако сбор статистических данных и опросы позволяют отсортировать продукты по уровням качества по отраслям или типу, например:

1) продукт низкого качества - старая сухая немытая морковка;

2) продукт среднего качества - молодая немытая морковка;

3) продукт высокого качества - молодая мытая упакованная морковка.

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

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

Вариант №1. Простое ТЗ на типовое внедрение Битрикс24

Простое техническое задание, которое у нас включено в стоимость работ по внедрению Битрикс24

В него входит:

1. перечисление и описание функциональных требований – что надо настроить, какие разделы;

2. с чем необходимо интегрироваться и требования к интеграции;

3. перечислены направления и стадии сделок;

4. требования к пользовательским полям в карточке клиента;

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

6. указаны требования к прочим настройкам портала и обучению персонала.

Вариант №2. Усложненное ТЗ на автоматизацию, со схемами бизнес-процессов

Усложненное техническое задание описывает более подробно требования к автоматизации процессов, подходит для сложных проектов с бизнес-процессами, нестандартной автоматизацией в Сделках и Лидах, определяет архитектуру (структуру) настраиваемой информационной системы, представляет итоговый вид информационной системы (в т.ч. Битрикс24).

Стоимость такого технического задания рассчитывается индивидуально. Примерно составляет 30% от стоимости будущего проекта.

В него входит:

1. схемы АВТОМАТИЗИРУЕМЫХ бизнес-процессов по нотациям iDEF0, FlowChart или BPMN;
   

2. подробные таблицы с описанием полей в карточках отдельных сущностей системы (например, карточках клиента в Б24);

3. таблицы с описанием и демонстрацией структуры универсальных списков, разделов в списках и товарах;

4. частные технические задания на настройку уникальных бизнес-процессов в виде схем и описания требований;

5. и то же, что и в простом ТЗ (см. Вариант №1)

Вариант №3. По ГОСТ 34.602-89 (да ГОСТ старый, но рабочий)

Данный вариант включает в себя всё то же самое, что Вариант №2, плюс разделы по ГОСТ 34.602-89. Он есть в свободном доступе. Погуглите, скачайте образец.

Вариант №4. ТЗ на мобильное приложение, сайт или уникальную информационную систему

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

Может включать в себя:

1. результаты НИОКР и ОКР (или часть);

2. результаты маркетинговых исследований (или часть);

3. функциональные и нефункциональные требования;

4. архитектура будущего программного обеспечения (карта разделов/интерфейса);

5. требования к прототипу (если подразумевается);

6. интерактивная карта будущего ПО или программный прототип (демо-версия будущего продукта, но далеко НЕ MVP);

7. дорожную карту развития функционала и обновлений (по годам, по месяцам);

8. требования к MVP;

9. дизайн всех страниц и разделов, всех вариантов всплывающих уведомлений и т.д.;

10. постраничное описание функционала – что будет, если нажать на эту кнопку, на ту, на эту; сценарий работы пользователя с ПО;

11. системные требования;

12. требования к UI/UX;

13. требования к API;

14. список динамических и статических полей (подгружаемых с сервера и дополняемых вручную);

15. тест-кейсы (для тестирования и отладки готового ПО).

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

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

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

В остальных, в 98% случаев, ТЗ обязательно. А если нет ТЗ, то и результат - "СЗ" (сами знаете), что означает высокий риск увеличения затрат на проект и сроков его реализации. Причин масса: из-за появления дополнительных неучтенных работ, "переделок", исправлений ошибок, и в худшем случае - это рестарт проекта, когда следует внести изменения в базовую архитектуру проекта, т.е. нужно будет делать всё заново.

Поэтому рекомендуем всегда делать техническое задание, даже самое простенькое
Успехов вам!