Меня зовут Татьяна, ресурсный менеджер компании Programming Store.
В мои прямые обязанности входит грамотное распределение ресурсов компании, а именно разработчиков 1С и аналитиков 1С в зависимости от их компетенций. В данной статье делюсь своим опытом создания качественного технического задания (ТЗ) для разработчиков 1С.
Содержание:
1. Как родилась идея идеального ТЗ.
Как родилась идея идеального ТЗ
Свой первый трудовой опыт я получила в структурном подразделении Администрации Ижевска. Скажу вам честно: работа в бюджетной сфере накладывает определенный отпечаток на человека в целом и на его образ мыслей и поведение в частности. Ты становишься менее гибким, привыкаешь жить в рамках и не даешь себе свободу мыслей. Каждый твой день четко регламентирован, отступать влево, вправо нельзя.
В IT сферу я пришла в 2018 году. Моя одногруппница пригласила меня в фирму-франчайзи 1С. После собеседования мне предложили позицию руководителя отдела сопровождения. Подстроиться под ритм «айтишки» было непросто. Но меня захватила динамика: скорость принятия решений была максимальной. Каждый день я замечала, как рушатся рамки в моей голове, которые были сформированы за годы работы в бюджете. Параллельно руководству отделом я развивалась как аналитик 1С:ЗУП. Получила свой первый ПРОФ, затем специалиста-консультанта. И понеслось… Проекты, клиенты, дедлайны. Меня часто привлекали к участию на проектах внедрения, иногда приходилось подхватывать руководство проектом на разных этапах и очень часто писать технические задания (ТЗ) на доработку 1С:ЗУП.
Сейчас я принимаю участие в финальных интервью с разработчиками 1С. Всё чаще в последнее время я слышу от них фразу: «Я никогда не видел качественное ТЗ». В моей голове зрел вопрос: «Как так? Не видели? Давайте я вам покажу! Я пишу ТЗ, за которые не стыдно». В своей статье я опишу структуру технического задания, которое может взять любой человек и понять «что?», «для чего?» и «как?» было доработано. Ну что ж, давайте начнем.
Структура ТЗ
Важно помнить, что ТЗ — это в первую очередь документ. Любой документ должен иметь определенную структуру. Давайте разберем, из каких составных частей может состоять ТЗ, чтобы стать понятным и простым документом.
Название
Все мы знаем фразу: «Голова — всему начало». Название ТЗ — это его «голова», без него будет непонятно, о чем этот документ. Название должно содержать информацию о том, какой объект будет дорабатываться. Приведем примеры названий:
- Техническое задание на доработку отчета.
- Техническое задание по запросу (№ запроса из учетной системы и его краткая суть).
- Техническое задание на разработку инструмента для загрузки Табеля.
и т.д.
- Раздел «Общие сведения».
Это первый раздел «Технического задания», который содержит в себе несколько подразделов: используемые термины и сокращения, цели изменений системы, область применения, описание бизнес-процессов. Разберем, что включает каждый из них.
1.1 Используемые термины и сокращения.
Этот подраздел обычно содержит:
- определения ключевых терминов: пояснения специфических слов или фраз, используемых в документе, для единообразного понимания;
- список сокращений: перечень аббревиатур с расшифровкой (например, БД — база данных, РН- регистр накопления и т.д.).
Если расшифровать термины и сокращения, это поможет избежать путаницы и обеспечивает ясность для читателя.
-
- Цели изменений системы.
Этот подраздел обычно содержит:
- описание задач: конкретные цели, которые должны быть достигнуты в результате изменений (например, повышение производительности, оптимизация работы специалистов отдела);
- ожидаемые результаты: количественные или качественные показатели успеха (например, сокращение времени обработки данных на 20%).
Этот подраздел даёт чёткое понимание, зачем нужны изменения и какой эффект они принесут.
-
- Область применения.
Здесь необходимо перечислить, в каких информационных системах будет использоваться функционал. Например: 1С:ЗУП или 1C:ERP и т.д.
- Раздел «Описание бизнес-процесса».
В данном разделе необходимо структурированно описать текущий бизнес-процесс и логику работы инструмента на данном этапе. Необходимо, чтобы зафиксированная информация отвечала на вопросы: «кто?», как?», «когда?», «в какой последовательности?». Важно отразить текущую логику работы инструмента и что в ней не устраивает, чтобы понять смысл и назначение доработки, которая будет реализована по нашему ТЗ. Также в данном разделе можно зафиксировать проблемы, решаемые изменениями: указать текущие недостатки или ограничения системы, которые устраняются.
- Раздел «Требование к функционалу. Описание способа реализации».
Этот раздел по праву занимает свое центральное место в ТЗ, потому что в нем будет содержаться максимальное количество важной и полезной информации для разработчика. Здесь необходимо структурировано описать изменяемый функционал системы как на уровне бизнес-логики, так и на уровне объектов метаданных. Если аналитик детально изучит бизнес требования и сможет дать разработчику грамотную информацию о том, из какого регистра необходимо взять данные для отражения в конкретной ячейке отчета. Это будет являться залогом грамотной оценки трудозатрат и упростит разработку.
Если в документ необходимо добавить новый реквизит, то для грамотных аналитиков не составит труда описать подробно, какого типа он должен быть и для чего он создается.
Приведу пример, как можно зафиксировать это в ТЗ:
«В документ «Прием на работу» необходимо добавить признак «Реферальная программа», тип «булево». Данный признак устанавливается, если сотрудник приглашен к трудоустройству в рамках реферальной программы. Также необходимо добавить реквизит «Реферер», с возможностью выбора значения реквизита из справочника «Сотрудники». Данный реквизит должен быть доступен к заполнению только если заполнен реквизит «Реферальная программа», выбирается сотрудник, который пригласил к трудоустройству своего знакомого.
Необходимо разработать Регистр сведений «Реферальная программа» (подробно описываем структуру регистра).
Необходимо разработать отчет «Реферальная программа». Отчет будет состоять из четырех столбцов (подробно описываем, какими значениями заполняется каждый столбец отчета):
- № п/п,
- Реферал,
- Реферер,
- Дата трудоустройства.
- Раздел «Отчетность».
Данный раздел необходимо заполнить в том случае, если изменяемый функционал виляет на регламентированную или управленческую отчетность. Здесь важно ответить на вопросы: «Что будет меняться в формировании отчетов?» Важно зафиксировать все риски влияния доработки на отчетность, чтобы потом не было для пользователей «неприятных сюрпризов».
- Раздел «Требования к ролям».
В данном разделе мы зафиксируем, есть ли потребность в создании новых ролей, а также в какой профиль и группу доступа их необходимо добавить. Грамотный аналитик может зафиксировать четкое наименование роли с префиксом, который будет идентифицировать его причастность к тому или иному проекту/доработке. Если же создание новых ролей не требуется, этот факт тоже можно отметить в данном разделе.
- Раздел «Требование к интерфейсу».
Предлагаю фиксировать здесь подсистему, в которой будет располагаться новый инструмент. Если в рамках ТЗ дорабатывается существующий инструмент, то можно указать, что его оставим в прежней подсистеме, и поставить наименование последней. Если же мы создаем целую подсистему, то зафиксируем в этом разделе, как мы ее назовем и где она будет располагаться.
- Раздел «Порядок тестирования».
Если нет отдельного документа, такого, как ПиМИ (приёмы и методики испытаний), то в ТЗ будет очень правильно включить данный раздел. В данном разделе нужно разработать и описать сценарий тестирования:
- указать путь к базе, на которой необходимо проводить тестирование;
- указать пользователя с каким профилем/группой доступа, под которым мы будем испытывать нашу доработку;
- поэтапно описать действия пользователя, которые необходимо выполнить, чтобы проверить новый функционал на работоспособность;
- описать критерии успешности завершения тестирования (например, сформировался отчет, указать, какие данные он должен содержать).
Резюме
Чтобы ТЗ несло реальную ценность, аналитик должен подойти к его подготовке обстоятельно и развернуто заполнить каждый раздел. Если разделы будут заполнены «для галочки» одной-двумя стандартными фразами, практическую пользу оно не принесет.
И да, если написать ТЗ по такому шаблону, оно будет стоить дорого. Нужно понимать, для какого заказчика мы будем писать такой объемный документ, а кому и предлагать его не стоит. Обычно корпоративные заказчики приветствуют подготовку подробной документации. Несмотря на это, с любым клиентом можно и нужно работать в части продажи качественной проектной документации. Важно грамотно аргументировать плюсы написания подробного и четкого технического задания, донести до заказчика, что на некоторых вещах лучше не экономить. Все мы знаем, что «скупой платит дважды, тупой — трижды, дурак платит всегда». Считаю, что адекватный заказчик будет готов выслушать качественные доводы в пользу хорошего ТЗ и примет правильное решение по его подготовке на проекте.
Трудозатраты на написание подобного технического задания будут большими. Конечно же, и уровень аналитика должен быть соответствующий. Но зато это огромный вклад в будущее. Если у кого-то появится желание разобраться, для чего и как сделана та или иная доработка, такая структура и содержание документа дадут ответы на все возникшие вопросы. Этот формат ТЗ однозначно облегчит работу разработчику, потому что детальное, четкое описание текущей ситуации и требований к реализации являются залогом качественной и быстрой разработки. Также в предлагаемом мной шаблоне есть раздел, помогающий протестировать успешность выполнения доработки. Этот раздел поможет не только пользователям, но и самому разработчику для первичного тестирования нового функционала.
Буду очень рада, если моя статься окажется полезной и шаблон ТЗ кто-то сможет применить на практике.
