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

08.05.19

Функциональные - Управление проектом (PMO, EPM)

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Шаблон ТЗ на разработку отчета и лист согласования
.rar 24,38Kb
59
59 Скачать (1 SM) Купить за 1 850 руб.

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме:

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

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

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

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

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

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

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

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

См. также

Управление проектом (PMO, EPM) Работа с интерфейсом Рабочее место ServiceDesk, HelpDesk Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Абонемент ($m)

Представляю вашему вниманию свою версию доски Канбан. Решение создано на управляемых формах в виде расширения. Я делал его максимально автономным, чтобы была возможность использования практически в любой конфигурации. Единственный объект, требующий сопряжения с основной конфигурацией – это справочник Пользователи. Эту разработку можно использовать как для отслеживания прогресса выполнения проектов, так и для учета текущих задач и времени их выполнения.

1 стартмани

28.08.2024    1248    11    umah    4    

7

Управление проектом (PMO, EPM) Руководитель проекта Платформа 1С v8.3 ИТ-компания Управленческий учет Абонемент ($m)

Полная трансформация в работе ваших команд. Цель публикации: Создание единого инструмента коммуникаций и ведения проекта по разработки ПО. Задачи, которые решает данная программа: Избавиться от большого и не интегрированного количества инструментов: excel, jira, wrike, redmine и т.д. Вся команда работает в одном окне. Кому полезна: Руководителям проектов по разработке ПО, Владельцам продуктов, Скрам мастерам, Участникам команды разработки.

1 стартмани

01.07.2024    1321    5    user1930767    2    

7

Управление проектом (PMO, EPM) Россия Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации с Хабра, VC, Инфостарта (и не только) и выбрали самые крутые и полезные. Читайте аннотации, сохраняйте и применяйте!

21.05.2024    855    Birby    1    

4

Документооборот и делопроизводство (СЭД) Управление проектом (PMO, EPM) Платформа 1С v8.3 1С:Документооборот Россия Абонемент ($m)

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

5 стартмани

10.07.2023    5535    59    Mattakushi    18    

9

Управление проектом (PMO, EPM) Бизнес-анализ Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

05.07.2023    2293    DenisErmolaev    7    

10

Управление проектом (PMO, EPM) Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Подсистема "Служба поддержки Redmine". Сделана на расширении. Позволяет отправлять заявку из 1С в сервис-деск Redmine. Использует Rest-API Redmine. Поддерживает полноценный редактор Markdown для оформления заявки.

1 стартмани

06.05.2023    3589    13    henr1ck    1    

12

Управление проектом (PMO, EPM) Бизнес-анализ Платформа 1С v8.3 1С:Управление торговлей 11 Оптовая торговля, дистрибуция, логистика Россия Управленческий учет Бесплатно (free)

Успешен ли бизнес, где его слабые места, а где — возможности для роста? Корректно отвечать на эти вопросы, опираясь на данные управленческой отчётности. О том, как мы внедрили «1С:УТ» и настроили качественный управленческий учёт, — в нашем кейсе.

26.04.2023    1660    ystetsenko    0    

0

Управление проектом (PMO, EPM) Пользователь Руководитель проекта Платформа 1С v8.3 Россия Управленческий учет Абонемент ($m)

Еще один трекер задач для 1С, но реализован на html + css + js. Успешно используется в собственной срм в повседневной работе. Конфигурация написана на базе БСП 3.1.5.306.

2 стартмани

24.04.2023    9490    97    andrybar    17    

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

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

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

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

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

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

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

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

В общем, я ни в коем случае не умаляю ваш практический опыт и, повторюсь, не претендую на истину.
Просто возможно кому-то это будет полезно на определенном этапе развития технологии корпоративного сопровождения и/или этапе развития компании в целом.
KhromovA; e.kogan; +2 Ответить
3. acanta 08.05.19 21:39 Сейчас в теме
А иногда программисты сами выдумывают себе работу, галочки, колонки, новые системы. Лишь бы не оказаться в других кругах общения.
Руководство здесь совершенно ни при чем, никаких заданий не было и быть не могло.
Все что есть - только этот шаблон ТЗ.
Вот только почему при этом должны страдать ни в чем неповинные пользователи?
7. user1323039 29.01.20 15:36 Сейчас в теме
Архив битый, что делать ?
8. user1323039 29.01.20 15:36 Сейчас в теме
9. gubsky 257 30.01.20 08:50 Сейчас в теме
(7) Я только что проверил - скачал архив, распаковал его, открыл оба вложенных файла - никаких проблем.
Может у вас с диском что-то не то или с архиватором?!
Попробуйте скачать на другой диск и разархивировать другим архиватором.
Если успешно разархивировать не получится, сообщите свой эл.адрес, я вам архив вышлю.

PS А минус публикации случаем не вы поставили?!
10. user1323039 30.01.20 16:16 Сейчас в теме
(9)Спасибо. Мне сразу в поддержке ответили, что все открывается и нужно другим архиватором открыть. 7zip сразу все открыл. Так что все получилось и всем доволен.
Минус не ставил, и, кстати, тоже не вижу, кто его поставил.
Оставьте свое сообщение