А какой вариант ответа выберете вы? 🤔

Команда GetAnalyst желает всем продуктивной недели! 💃

#GAhahaha

Вы уже знаете, что этап анализа требований перед их проектированием — один из самых важных и дорогостоящих во всём процессе разработки.

Если аналитик собрал требования некачественно или проектная команда интерпретировала их иначе, повышается риск спроектировать совсем не те возможности, которые запрашивал заказчик. А значит придётся снова тратить время и деньги, исправляя это недоразумение 🥲

Чтобы не играть в «сломанный телефон» с заказчиком и проектной командой, аналитик фиксирует требования в письменном виде и в удобном для всех участников формате. То есть создаёт ТЗ #hardGetAnalyst

ТЗ, Техническое задание (англ. requirements document) — документ, где описаны цель проекта, из каких частей он состоит, какие результаты ожидаются и каким способом их можно достичь.

ТЗ – это один из основных артефактов работы аналитика, а точнее – важный её результат.
Благодаря ТЗ все требования к проекту хранятся в одном месте и поддерживаются в актуальном состоянии.

Иногда техническое задание называют спецификацией требований (англ. Software Requirements Specification, SRS), но между этими документами есть отличия.
Спецификация, как и ТЗ, содержит информацию о требованиях к проекту, но:
⚡️требования детализированы до системного уровня;
⚡️структура документа более строгая;
⚡️объём документации больше.

Иностранные компании предпочитают работать именно со спецификациями, а в России больше распространены ТЗ, структура которых адаптируется под проект или компанию.
Тем не менее принято считать, что бизнес-аналитики больше работают именно с ТЗ, а системные – со спецификациями. Хотя и это не правило, а скорее некоторая закономерность.

Далее о том, из каких частей состоит ТЗ 🔜

🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐

Чаще всего ТЗ содержит следующие информационные блоки:

1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.

2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.

3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.

4️⃣ Основные требования
Список основных функций, возможности, ограничения и взаимодействие с другими системами, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.

5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.

6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.

7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.

8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.

9️⃣ Стадии и этапы разработки, а также сроки их выполнения.

🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.

Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.


🧐 ПРО СТАНДАРТЫ ТЗ 🧐

Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:

❣️Международные (ISO, IEEE)
❣️Российские (ГОСТ 19, ГОСТ 34)
❣️Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)

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

Техники сбора требований делятся на:

👥 Коллективные
Такие требования аналитик узнаёт у заинтересованных лиц (стейкхолдеров): заказчика, пользователей, владельцев бизнеса и так далее.

👤Независимые
Такие требования аналитик собирает самостоятельно, изучая документы и существующие процессы.


КОЛЛЕКТИВНЫЕ ТЕХНИКИ СБОРА ТРЕБОВАНИЙ

📝 Анкетирование
Анкетирование — это опрос заинтересованных лиц с помощью анкеты. Сама анкета может содержать как открытые, так и закрытые вопросы. Открытые вопросы требуют от респондента самостоятельно сформулировать ответ – то есть нет выбора готовых вариантов ответа. Закрытые вопросы подразумевают выбор одного из предложенных вариантов.

🙋‍♀️ Воркшоп
Воркшоп — это групповая работа над задачей. Как правило, на воркшопе есть модератор, который помогает участникам прийти к цели. В случае со сбором требований стейкхолдеры собираются для того, чтобы вместе составить их список. Он не финальный, но всё же такой результат ценен для аналитика. Ведь это уже не просто набор полезной информации, который получается, например, при групповом интервью. Кстати, об интервью.

🎤 Интервью
Интервью — это техника личного общения с респондентами. Интервью может быть как индивидуальным – когда аналитик и интервьюируемый на встрече одни, либо групповые – когда отвечающих в ходе интервью несколько.

🧠 Мозговой штурм
Мозговой штурм — это коллективное обсуждение с целью предложить как можно больше идей по задаче. Участники озвучивают любые, даже странные мысли. В конце собирают лучшие решения, чтобы рассмотреть их более детальнее.

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


Далее о независимых техниках, не переключаейтесь 😊