Если вы работаете специалистом в отделе сопровождения ПО 1С и сопровождаете уже внедренные решения 1С, то скорее всего вам частенько приходится разрабатывать различного рода отчеты. И хорошо, если ваши пользователи уже “воспитаны вами” и подают вам формализованные требования. А если нет?!
Тогда вам срочно нужно повышать их “культуру” через формализованную подачу требований на разработку отчетов. В данной статье представлен разбор наиболее оптимальной (с авторской точки зрения) структуры ТЗ на разработку отчета и листа его согласования. На основании этих рекомендаций можно самостоятельно с учетом ваших корпоративных стандартов разработать свой шаблон ТЗ, а если это делать лень — шаблон можно скачать.
В этой статье мы не будем останавливаться на методологических вопросах и вопросах знания функциональных возможностей конкретных ПП, а будем исходить из позиции, что типовым/существующим набором отчетов задачу решить нельзя, что означает, что пользователям понадобился новый отчет.
Техническое задание на проектирование — начало сметных работ
Как описать требования к отчету или
коротко о структуре ТЗ на разработку отчета
1. Контактная информация инициатора работы
Нам достаточно следующих полей: Инициатор разработки, подразделение, должность, телефон, e-mail.
2. Требования к срокам реализации
С точки зрения решения возможных спорных ситуаций в последующем достаточны следующие параметры:
Дата подачи требований — при этом нужно формализовывать и канал подачи требований исходя из установленных корпоративных стандартов. В частном случае это может почта или специализированная система учета заявок. Обычно этот момент регламентируется в положении о работе подразделения.
Желаемый срок реализации — понятно, что всё все хотят в первую очередь или даже “еще вчера”. Тем не менее, нужно приучать пользователей мыслить в категориях, что ничего “по щелчку” не бывает.
Приоритет работы — опять же сильно зависит от принятой корпоративной технологии работы. Поэтому в частном случае может принимать значения “низкий”, “средний”, “высокий”, либо быть представлен цифровым значением в разрезе конкретного подразделения, как это сделано у нас.
3. Требования к отчету
Название отчета
Особо без комментариев, с дополнением, что к наименованию отчета необходимо указать интерфейс и пункт меню, в котором должен быть расположен отчет.
Назначение отчета
Описываются задачи и ключевые вопросы, решаемые с помощью отчета: кто будет формировать отчет, кому передавать и для каких целей.
Описываются также роли пользователей, для которых разрабатывается отчет.
Тут же можно использовать рекомендации agile-сообщества в части формирования user story:
Источники данных
Указание информационной базы (баз) и описание набора данных, по которым должен строиться отчет.
Логика работы отчета
Описание логики выборки данных, условий и формул расчета
Требования к настройкам отчета
Описание требований к пользовательским настройкам и интерфейсным решениям отчета
Как составить ТЗ на проектирование
Визуальный макет
Требования к представлению, группировке и сортировке данных и их визуализации (таблица, диаграмма, списки, уведомления).
Внешний вид отчета прикладывается как приложение.
4. Порядок сдачи-приемки работ
Описывается контрольный пример, на базе которого будет осуществляться сдача работ: набор тестовых данных и результат работы отчета.
Работа сдается заказчику путем формирования отчетной формы на рабочей базе заказчика. При этом заказчиком проверяется соответствие внешнего вида отчетной формы и корректности её заполнения.
5. Ограничения и гарантии
Перечень условий, необходимых для корректного формирования отчета (расчет себестоимости и т.д.).
Перечень условий, при которых гарантируется работа отчета.
Сюда же помещаем все возможные риски. В частности, обход граблей с Олей и тому подобных вещей, описанных в статье решаются двумя фразами этого раздела (собственно фразы написаны в прилагаемом шаблоне). Ну а в остальном дело за последовательностью действий исполнителя.
Теперь перейдем к согласованию требований и сдаче работ
Фактически, это два ключевых момента в разработке, которые помимо всего прочего должны в том числе быть пунктами передачи ответственности, формализованными пунктами:
при согласовании требований — от заказчика к исполнителю
при сдаче работ — обратно от исполнителя к заказчику.
И если с первым в большинстве компаний и случаев как-то вопрос решается, то со вторым моментом вопросов гораздо больше — уж очень любят заказчики в корп секторе работу “как бы принять”, а потом вдруг если что — дорабатывать.
И этот момент нужно решать либо комплексно в регламенте работы отдела, либо в частном случае — в ТЗ. Пример фразы также в прилагаемом шаблоне. Ну и про последовательность не забываем.
Отдельно остановлюсь на мысли из единственной (до текущей) на сегодня на Инфостарте публикации по этой тематике.
Да, в частном случае так быть может. НО! Зависит это от корпоративной культуры компании в целом, принятой технологии разработки ПО и позиции руководителя отдела в частности.
Так вот, для тех, кто считает так же как и в выше озвученной мысли сейчас будет откровение.
Не все поданные пользователями заявки должны быть выполнены.
Для этого поданные требования нужно согласовывать на стороне отдела разработки/сопровождения и либо принимать их, либо отказывать. Но не безосновательно, а с указание причины отказа.
Так вот неполнота представления требований может являться одной из причин отказа в разработке. Список причин отказа также весьма индивидуален, в прилагаемом шаблоне представлен вполне исчерпывающий список причин отказа.
Поэтому первый пункт листа согласования:
Дата рассмотрения требования:
(принято/не принято + код причины отказа)
Определение плановой даты разработки отчета
Помните в начале мы говорили про “Требования к срокам реализации”. Так вот, их тоже нужно согласовать. То что заказчик отразил как желаемая дата реализации — это всего лишь желаемая дата реализации. Реальная календарная плановая дата разработки зависит от трех параметров:
- Трудоемкость разработки (оценка работ — большая отдельная тема)
- Приоритет работы (в корп секторе должна быть метода определения приоритетности работ)
- Процент времени специалиста, отведенного под разработку (особенно, если мы говорим про отделы сопровождения, у вашего отдела ведь тоже решение текущих вопросов (инцидентов) — это первоочередной тип работ?!)
То есть если трудоемкость разработки отчета 8 часов и заявлена она с самого утра, то это вовсе не значит, что вечером будет готово. Именно поэтому понятия трудоемкость и календарная дата реализации нужно разносить.
К обоим этим понятиям я всегда добавляю слово “плановая”. Потому что инциденты и поручения от ТОП менеджмента — события весьма стихийные, особенно если нет наработанной статистики…
Резюме:
Укрупненно в ТЗ имеем три раздела: описание назначения отчета, требования к нему и контрольный пример.
В первом описывается “хотелка” заказчика, во втором — её формализация. Первое понятно заказчику, второе — разработчику. Контрольный пример — приземляет первые две сущности.
Остается только работать по принципу: сделал — молодец, не сделал — не молодец. Как определить что сделал?
Все остальное философия.
Вот и всё. Так просто и так сложно одновременно. Главное быть последовательным и все будет хорошо. Или как говорится “Нормально делай — нормально будет”.
И напоследок, скажу, что я не претендую на истину в последней инстанции, а лишь выражаю свою точку зрения, основанную на собственном практическом опыте и с радостью готов обсудить в комментариях конструктивную критику по существу вопроса.
Источник: infostart.ru