Техническое задание (ТЗ) – это документ, от которого в значительной степени зависит результат всего проекта. На первый взгляд, это все понимают, но на практике техническому заданию зачастую уделяют недостаточно внимания. Сегодня мы подробно разбираемся в том, почему такой подход на серьёзном проекте недопустим.
К чему приводит низкий уровень качества ТЗ
Таким образом, подготовка ТЗ – это отдельная задача, от которой зависит успех всего проекта. На практике без хорошего ТЗ регулярно возникают следующие ситуации: невозможно создать пользовательские сценарии и требования к их выполнению;
крайне затруднительно определить критерии выполненных работ и ответственность подрядчика;
возникают затруднения при приёмке, потенциально спорные и конфликтные ситуации;
нет возможности проверить систему на 100% – убедиться в том, всё ли на самом деле сделано;
теряются нужные функции: нет четкой последовательности действий и понимания конечного результата;
становится менее прозрачным выполнение работ: график, этапы, бюджет;
усложняется использование продукта в будущем.
5 ошибок, которые совершают в ТЗ недобросовестные подрядчики по внедрению систем «1С»
Определить, что подрядчик не умеет формировать качественное ТЗ, очень просто: достаточно посмотреть на наличие самых распространённых ошибок при составлении ТЗ. В первую очередь следует обратить внимание на следующие моменты:
Теперь разберем каждый пункт подробнее, а в конце статьи расскажем о структуре качественного ТЗ. Также отправим шаблон технического задания по внедрению систем «1С», после заполнения формы.
Встречаются формулировки, которые можно трактовать неоднозначно. Например:
Неоднозначные формулировки Вопросы к формулировке:
Отчёт по клиенту (количество заявок, сумма выручки по определенному периоду)
Вопрос к формулировке:
Отсутствуют требования. Есть риск, что отчет будет реализован в виде картинки, без возможности настройки и без расшифровки его показателей. Таким отчётом нельзя будет пользоваться – нет перечня настроек и допустимых фильтров за период, за который строится отчет. Не хватает написанного макета отчета, а без него разработчик сделает его на свое усмотрение. Нет ясности, как структурировать данные. Все эти моменты должны быть чётко зафиксированы в ТЗ.
Задача менеджерам- логистам: все данные по грузу вносить в задачу. Логист берет задачу в работу, после одобрения ставит галку, и задача завершена. Оформитель делает заявку клиенту и, если необходимо, перевозчику.
Вопрос к формулировке:
Нет описания автоматизированного процесса: как логист должен увидеть задачу? Какие данные по грузу вносятся? Какой объект системы будет использоваться для постановки задачи? Как логист поймёт, что задача одобрена? Что делать, если логист, не выполнив работу, поставит галку? Бизнес-часть не расписана: кто такой оформитель? Какая у логиста роль в этой задаче? Кем одобрена? Какие объекты системы создавать, какие предусматривать поля для ввода данных, нужны ли статусы и их перечень? Не расписан маршрут согласования/одобрения. Не описано рабочее место. Нет ясности, какие права у пользователей на создание и чтение документа: нужно ли создавать роль или можно использовать типовые роли?
Возможность входа в заявку через ПП
Вопрос к формулировке:
Непонятно, что имеется в виду: возможно, речь идет о смежном продукте. Что понимается под ПП, в какую заявку, какой конкретно документ подразумевается? При реализации возникает множество вопросов, без ответов на которые программист не сможет приступить к выполнению данной задачи.