Я системный аналитик и хочу поделиться своим опытом в написании требований.

Входные условия: я работаю в небольшой команде, у нас нет жестких требований и обязательных шаблонов для технических заданий. В работе мы используем Jira и Confluence.

Когда я пришла на проект, в качестве единственного аналитика, а четких требований что же должно быть в постановке не было, возник вопрос: как мне их оформлять? Этот вопрос я декомпозировала на следующие пункты:

• где должны храниться требования к задачам: есть Confluence и есть Jira, надо ли дублировать требования в обеих системах?

• какие обязательные разделы включать в техническое задание, какую сделать структуру требований?

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

Конечно, идея прийти к разработчику или qa-специалисту и спросить, что они хотят видеть в требованиях была, но не виделась удачной. В итоге, от задачи к задаче я меняла структуру, дополняла постановки какими-то элементами и собирала обратную связь. Для такого подхода очень важна коммуникация внутри команды, честная и открытая. В этом моя команда оказалась просто находкой, ребята честно говорили, что им нравится, а где непонятно, где-то я объясняла что можно изменить, а что нет. Так накопился опыт и сформировались требования к аналитике на нашем проекте. В зависимости от задачи, ее масштабов и специфики структура технического задания меняется, но есть общие принципы, которыми я руководствуюсь (в дополнение к общепринятым требованиям).

Что же это за принципы и правила?

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

2. В Jira мы заводим задачи и даем ссылки на соответствующие страницы Confluence, а в постановках есть ссылки на конкретные таски, в которых была реализована функциональность.

3. В самих постановках (технических заданиях) присутствуют следующие элементы:

• описание ожидаемого результата - чек-лист и краткое описание того что получит пользователь или система (если задача сугубо техническая)

• краткий обзор предметной области - актуально, если внедряется новый процесс или иные глобальные фичи

• схемы, диаграммы или иные элементы визуализации - картинка всегда воспринимается лучше текста и позволяет всем членам команды лучше понять что требуется сделать. Если в реализации задействованы несколько микросервисов, то обязательно добавляется диаграмма последовательностей, при разработке нового микросервиса - диаграмма компонентов и т.д.

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

• ссылки на все связанные постановки и материалы. Если текущая постановка опирается на более раннюю, то информация не копируется, а просто дается ссылка

• техническое задание делается на на конкретную функциональность (user story) или процесс, например, для реализации новой фичи, разработка которой будет вестись в разных задачах и даже разными командами, аналитика пишется единым техническим заданием, внутри которого есть логическое деление на задачи и этапы, даны ссылки связанные таски

• негативные кейсы - обязательно делается описание возможных негативных сценариев и способов их обработки

• справочная информация - бывает, что пока задача дошла от аналитики до реализации или тестирования что-то поменялось во внешней среде, поэтому заметки и комментарии помогают в таких случаях восстановить картинку

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