Я системный аналитик и хочу поделиться своим опытом в написании требований.
Входные условия: я работаю в небольшой команде, у нас нет жестких требований и обязательных шаблонов для технических заданий. В работе мы используем Jira и Confluence.
Когда я пришла на проект, в качестве единственного аналитика, а четких требований что же должно быть в постановке не было, возник вопрос: как мне их оформлять? Этот вопрос я декомпозировала на следующие пункты:
где должны храниться требования к задачам: есть Confluence и есть Jira, надо ли дублировать требования в обеих системах?
какие обязательные разделы включать в техническое задание, какую сделать структуру требований?
У меня было четкое понимание, что хорошо для одного проекта, может быть неприемлемо для другого проекта и команды. Я осознала, что имею уникальную возможность выстроить аналитику на проекте. Основным мои принципом (помимо хрестоматийных требований к спецификациям): аналитик пишет требования не для себя любимого и созданные артефакты будут использоваться разработкой, тестированием, технической поддержкой, соседними командами и бизнесом. Следовательно, удобно и понятно должно быть именно потребителям информации.
Конечно, идея прийти к разработчику или qa-специалисту и спросить, что они хотят видеть в требованиях была, но не виделась удачной. В итоге, от задачи к задаче я меняла структуру, дополняла постановки какими-то элементами и собирала обратную связь. Для такого подхода очень важна коммуникация внутри команды, честная и открытая. В этом моя команда оказалась просто находкой, ребята честно говорили, что им нравится, а где непонятно, где-то я объясняла что можно изменить, а что нет. Так накопился опыт и сформировались требования к аналитике на нашем проекте. В зависимости от задачи, ее масштабов и специфики структура технического задания меняется, но есть общие принципы, которыми я руководствуюсь (в дополнение к общепринятым требованиям).
Что же это за принципы и правила?
1. Все постановки мы храним в Confluence, при этом проектная документация разложена в соответствии с тематикой, таким образом легко можно найти как должна работать та или иная функциональность.
2. В Jira мы заводим задачи и даем ссылки на соответствующие страницы Confluence, а в постановках есть ссылки на конкретные таски, в которых была реализована функциональность.
3. В самих постановках (технических заданиях) присутствуют следующие элементы:
описание ожидаемого результата - чек-лист и краткое описание того что получит пользователь или система (если задача сугубо техническая)
краткий обзор предметной области - актуально, если внедряется новый процесс или иные глобальные фичи
схемы, диаграммы или иные элементы визуализации - картинка всегда воспринимается лучше текста и позволяет всем членам команды лучше понять что требуется сделать. Если в реализации задействованы несколько микросервисов, то обязательно добавляется диаграмма последовательностей, при разработке нового микросервиса - диаграмма компонентов и т.д.
таблицы также помогают лучше структурировать текст, например, при описании сложного процесса взаимодействия микросервисов, все требования были пошагово описаны в таблице
Шаг | Микросервис 1 | Мискросервис 2 | … |
1 | Описание алгоритма | --- | |
2 | Описание алгоритма | ||
… |
ссылки на все связанные постановки и материалы. Если текущая постановка опирается на более раннюю, то информация не копируется, а просто дается ссылка
техническое задание делается на на конкретную функциональность (user story) или процесс, например, для реализации новой фичи, разработка которой будет вестись в разных задачах и даже разными командами, аналитика пишется единым техническим заданием, внутри которого есть логическое деление на задачи и этапы, даны ссылки связанные таски
негативные кейсы - обязательно делается описание возможных негативных сценариев и способов их обработки
справочная информация - бывает, что пока задача дошла от аналитики до реализации или тестирования что-то поменялось во внешней среде, поэтому заметки и комментарии помогают в таких случаях восстановить картинку
Отдельно хочу выделить, что текст должен быть максимально понятным. Хоть это и общепринятый принцип, но частенько мы про него можем забывать, стараясь сделать аналитику более качественной и профессиональной. Но максимально простые структура и язык изложения помогают всем быстро понять что требуется сделать, не тратить время на на уточняющие созвоны, а значит работа над продуктом становится приятнее.
