ТЗ на разработку отчета (рекомендации и шаблон)

Публикация № 1058419

Управление - Техническое задание

ТЗ ТТ техническое задание технические требования формализация отчет разработка риски

18
Если вы работаете специалистом в отделе сопровождения ПО 1С и сопровождаете уже внедренные решения 1С, то скорее всего вам частенько приходится разрабатывать различного рода отчеты. И хорошо, если ваши пользователи уже “воспитаны вами” и подают вам формализованные требования. А если нет?! Тогда вам срочно нужно повышать их “культуру” через формализованную подачу требований на разработку отчетов. В данной статье представлен разбор наиболее оптимальной (с авторской точки зрения) структуры ТЗ на разработку отчета и листа его согласования. На основании этих рекомендаций можно самостоятельно с учетом ваших корпоративных стандартов разработать свой шаблон ТЗ, а если это делать лень - шаблон можно скачать.

Итак, начнем.

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

Как описать требования к отчету или

коротко о структуре ТЗ на разработку отчета

1. Контактная информация инициатора работы

Тут все просто - разработчику нужна контактная информация для связи с заказчиком. Её содержание и объем определяется весьма индивидуально.

Нам достаточно следующих полей: Инициатор разработки, подразделение, должность, телефон, e-mail.

 

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

С точки зрения решения возможных спорных ситуаций в последующем достаточны следующие параметры:

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

Желаемый срок реализации - понятно, что всё все хотят в первую очередь или даже “еще вчера”. Тем не менее, нужно приучать пользователей мыслить в категориях, что ничего “по щелчку” не бывает.

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

 

3. Требования к отчету

Название отчета

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

Назначение отчета

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

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

Тут же можно использовать рекомендации agile-сообщества в части формирования user story:

Я как, <роль пользователя>, <хочу получить отчет>, <с такой-то целью> .


Источники данных

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

Логика работы отчета

Описание логики выборки данных, условий и формул расчета

Требования к настройкам отчета

Описание требований к пользовательским настройкам и интерфейсным решениям отчета

Визуальный макет

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

Внешний вид отчета прикладывается как приложение.

 

4. Порядок сдачи-приемки работ

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

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

 

5. Ограничения и гарантии

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

Перечень условий, при которых гарантируется работа отчета.

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


Теперь перейдем к согласованию требований и сдаче работ

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

при согласовании требований - от заказчика к исполнителю

при сдаче работ - обратно от исполнителя к заказчику.

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

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

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

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

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

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

Не все поданные пользователями заявки должны быть выполнены.

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

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

Поэтому первый пункт листа согласования:

Дата рассмотрения требования:

(принято/не принято + код причины отказа)

Определение плановой даты разработки отчета

Помните в начале мы говорили про “Требования к срокам реализации”. Так вот, их тоже нужно согласовать. То что заказчик отразил как желаемая дата реализации - это всего лишь желаемая дата реализации. Реальная календарная плановая дата разработки зависит от трех параметров:

  1. Трудоемкость разработки (оценка работ - большая отдельная тема)
  2. Приоритет работы (в корп секторе должна быть метода определения приоритетности работ)
  3. Процент времени специалиста, отведенного под разработку (особенно, если мы говорим про отделы сопровождения, у вашего отдела ведь тоже решение текущих вопросов (инцидентов) - это первоочередной тип работ?!)

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

К обоим этим понятиям я всегда добавляю слово “плановая”. Потому что инциденты и поручения от ТОП менеджмента - события весьма стихийные, особенно если нет наработанной статистики…

Резюме:

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

В первом описывается “хотелка” заказчика, во втором - её формализация. Первое понятно заказчику, второе - разработчику. Контрольный пример - приземляет первые две сущности.

Остается только работать по принципу: сделал - молодец, не сделал - не молодец. Как определить что сделал?

Контрольный пример.

Все остальное философия.

Вот и всё. Так просто и так сложно одновременно. Главное быть последовательным и все будет хорошо. Или как говорится “Нормально делай - нормально будет”.

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

18

Скачать файлы

Наименование Файл Версия Размер
Шаблон ТЗ на разработку отчета и лист согласования
.rar 24,38Kb
08.05.19
4
.rar 24,38Kb 4 Скачать

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. VmvLer 08.05.19 16:52 Сейчас в теме
такое бумагомарательство имеет смыл если степень доверия между исполнителем и
заказчиком низка, либо они "хороводят" по причине отсутствия взаимопонимания.
Такой "фарш" замыливает задачу, но отличный аргумент для нагибания сторон.

в 99% случаев для разработки отчета достаточно подробного примера в эксель
с грамотными примечаниями и указаниями. Это наглядно и понятно любому без
полоскания простынь с терминами.
Bassgood; FesenkoA; klaus38; +3 Ответить
2. Serg O. 170 08.05.19 20:51 Сейчас в теме
(1) Иногда менеджеры и/или руководители под название "отчет" могут выдать целую новую подсистему... Эдакий мини-УПП в одном отчете... И материалы и продукция и затраты чтобы были, а ещё конечно тут же прибыль и продажи по регионам этой продукции конечно тоже надо...

Или понятие добавить галочку в отчет... Очень неоднозначно бывает.

Суп из топора тоже любят делать... Проблема часто в том, что менеджеры/руководители не могут даже сформулировать что именно хотят...да, так бывает... Отчет по регионам... Оказывется "имели ввиду" по региональным менеджерам, которые "конечно" продают клиентам во все регионы...

Писать такое приходится ЗА менеджера... Ибо... Что конкретно он имел ввиду... по 100 раз надо уточнять... Иначе 100 раз переделывать их же ТЗ придётся
4. gubsky 247 10.05.19 15:29 Сейчас в теме
(1)
Добрый день, коллега.
Я с вами соглашусь, если мы говорим про мини-компанию до 50 сотрудников и разработку "на коленке".
Тогда да, вы абсолютно правы: на пальцах друг с другом изъяснились по задаче и "после обеда" начали работу. Ну завтра в крайнем случае. К вечеру показали результат, если не понравилось переделали. Делов-то... [сарказм].
С таким подходом да, ТЗ - излишнее бумагомарательство, как вы выразились.
А когда вы работаете в крупной компании с сотнями пользователей и их бесконечным потоком, мягко говоря, неформализованных "хотелок", то без упорядочивания входящих обращений весьма и весьма сложно. И неэффективно. И это как раз о том, что коллега из (2) описал в последних двух абзацах своего комментария.
Так что... каждой ситуации свое решение. Универсальных пилюль не бывает.
КОРП - он такой корп =)
slavikss; +1 Ответить
5. VmvLer 13.05.19 09:05 Сейчас в теме
(4) я долго работал в организациях и с 50-ю сотрудников и с 300+ и 5000+
уточню, ваши терзания в пучине методичек на разработку как раз попадают в %1 - так показывает практика. Не надо путать их с методичками пользователей, когда продукт готов и на столе пользователя должны быть книги "рецептов".

Если % методичек на разработку больше, значит в организации "работу работают".
6. gubsky 247 13.05.19 12:12 Сейчас в теме
(5)
Про 1% диалог поддержать не могу, а вот про "работать работу" соглашусь. В КОРП секторе это встречается намного чаще, чем в более "коммерческих структурах" - там где мотивация (читай - ЗП) завязана на финрезе компании.

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

Если этого не делать, то могут "прилетать" задачи вроде "А сделайте мне отчет по неликвидам" или еще что-то в этом духе.
Так вот, с таким фильтром на входе можно достичь как минимум следующих результатов (по крайней мере эти два наиболее мне интересны):
1. Заставить инициатора заранее подумать над желаемым результатом работы отчета. Эффективность взаимодействия заказчика и разработчика при этом, как правило, возрастает (и это - главный мотив).
И вот тут мы можем наблюдать также интересный эффект:
2. Отсечь заявки на разработку без реальной в них потребности со стороны заказчика.
И это как раз из области ИБД: я бы подготовил отчет, но у меня нет исходных данных...
А нужен ли тогда вообще отчет?! И кому?!

В общем, я ни в коем случае не умаляю ваш практический опыт и, повторюсь, не претендую на истину.
Просто возможно кому-то это будет полезно на определенном этапе развития технологии корпоративного сопровождения и/или этапе развития компании в целом.
3. acanta 60 08.05.19 21:39 Сейчас в теме
А иногда программисты сами выдумывают себе работу, галочки, колонки, новые системы. Лишь бы не оказаться в других кругах общения.
Руководство здесь совершенно ни при чем, никаких заданий не было и быть не могло.
Все что есть - только этот шаблон ТЗ.
Вот только почему при этом должны страдать ни в чем неповинные пользователи?
Оставьте свое сообщение