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