Когда говорят о требованиях, первое, что приходит в голову: «О, опять список хотелок!» На самом деле, это запросы, идеи и проблемы, которые стейкхолдеры (то есть все те, кого заденет ваш проект) выдают разработчикам, аналитикам и менеджерам. Это может быть как организация в целом, так и один несчастный человек: от директора до сотрудника, который просто хочет, чтобы его жизнь стала немного проще.
Например, директор хочет знать, чем занимались его сотрудники в месяц. Менеджеры хотят, чтобы у них был инструмент контроля, а пользователи хотят, чтобы этот инструмент не превратил их жизнь в бюрократический кошмар.
Когда говорят о требованиях, первое, что приходит в голову: «О, опять список хотел от клиента!» На самом деле, это запросы, идеи и проблемы, которые стейкхолдеры (то есть все те, кого заденет ваш проект) выдают разработчикам, аналитикам и менеджерам. Это может быть как организация в целом, так и выражение лица: от директора до сотрудника, который просто хочет, чтобы его жизнь стала немного проще.
Например, директор хочет знать, чем занимались его сотрудники в месяц. Менеджеры хотят, чтобы у них был инструмент контроля, а пользователи хотят, чтобы этот инструмент не превратил их жизнь в бюрократический кошмар.
Мы попросили нашего технического писателя рассказать, как он собирает данные и документирует их, когда вокруг суета, ноябрь и клиент приходит с новыми пожеланиями, а проджет-менеджер с релизами.
Игорь Н.
технический писатель
Требования классифицируются на три категории в зависимости от глубины проработки:
Бизнес-требования — это общие формулировки о цели и задачах, которые разъясняют, чего именно хочет заказчик и для чего. Например, директор может захотеть знать, чем конкретно занимались сотрудники в определенный период.
Требования заинтересованных сторон — более детализированные ожидания различных групп стейкхолдеров, описывающие конкретные нужды, чтобы достичь поставленных бизнес-целей. К примеру, для того чтобы руководитель понимал работу своих подчиненных, ему нужно, чтобы сотрудники предоставляли отчеты о текущих задачах и времени, затраченном на их выполнение.
Требования к решению — самая мелочная и детальная категория, сосредоточенная на реализации конкретных решений в системе или приложении, а не на общих бизнес-параметрах.
Процесс сбора требований
Охватывает выявление, документирование и управление нуждами стейкхолдеров с целью достижения задуманного результата. Основное преимущество этого процесса заключается в том, что он создает основу для разработки содержания проекта и продукта. Сбор требований может осуществляться как в рамках одной сессии, так и на определенных этапах проекта.
Анализ данных
Начинается сбор требований и вся работа, обычно, с чашки кофе и этого шага.
Анализ данных может включать:
Изучение технической и нормативной документации;
Взаимодействие с продуктом или приложением;
Анализ наборов данных (например, автоматизация отчетов в Excel): "Отчеты Excel? Прекрасно. О, а это что, дата 2038 года в прошлом месяце?.."
Изучение программного кода: "Не знаю, кто это написал, но явно с чувством юмора."
Анализ данных помогает увидеть, как реальность (бизнес-процессы) сталкивается с ожиданиями. Ведь нельзя просто внедрить новый инструмент и сломать всё, что работает.
Интервьюирование: метод, который решает 80% задач
Интервью — это не только про вопросы и ответы, но и про понимание того, что на самом деле волнует стейкхолдеров. На мой взгляд, это один из наиболее эффективных методов сбора требований. При качественном интервью можно ожидать, что 80% требований будет получено на основании собранной информации. Несмотря на устный формат, важно записывать и согласовывать результаты интервью.
Интервью можно классифицировать по стадии исследования:
Предварительное — на этом этапе знакомимся с проблемой и определяем список стейкхолдеров вместе со сроками основной стадии.
Основное — сосредотачиваемся на детализации требований и проблем, упомянутых в предварительном обсуждении с бизнесом. Важно подготовить правильные вопросы для основной сессии.
Контрольное — фиксируем результаты, сверяем ожидания с реальностью, собираем новые запросы и записываем все отклонения от исходных требований.
Совет:Всегда фиксируйте все, что обсуждалось, иначе вас обвинят в том, что обещали луну, а привезли лампочку.
По количеству участников интервью делится на:
Индивидуальное — беседа один на один, душевно и по делу.
Групповое — разделение на группы по интересам, важно избегать присутствия, например, бухгалтеров и маркетологов одновременно.
Массовое — опрос большого количества людей, часто с использованием анкет.
По уровню формализации выделяют:
Стандартизированное — с заранее подготовленными вариантами ответов.
Фокусированное — с открытыми и направляющими вопросами, акцентируя внимание на теме.
Ненаправленное — подходит для предварительного этапа, помогает выявить проблемы бизнеса и собрать нужные данные для дальнейшего анализа.
Анкетирование
Анкетирование включает в себя использование формализованного списка вопросов (с открытыми и/или закрытыми ответами). Этот метод идеально подходит для подтверждения или детализации существующих требований либо для выбора оптимального варианта реализации.
Полезные советы по проведению интервью:
Начинайте с менее значительных тем, чтобы собеседник расслабился.
Переходите от общего к конкретному, активно слушая и задавая уточняющие вопросы: "Вы сказали, что вам сложно работать с отчетами. Почему?"
Спрашивайте об альтернативных сценариях, например, "А что будет, если...".
Выясняйте глубинные бизнес-потребности, задавая вопрос "Зачем?"
Пример: «Вы хотите получать уведомления о сроках задач? Зачем? — Чтобы не пропускать дедлайны».По завершении интервью отправьте все собранные данные на отзыв стейкхолдерам. Иначе потом услышите: "А мы такого не говорили!"
Внедрение
Данный метод популярен в государственных учреждениях и на производстве, так как позволяет собирать данные непосредственно в реальных рабочих условиях. Цель заключается в том, чтобы зафиксировать процессы работы и избежать недопонимания, возникающего в ходе интервью.
Метод наблюдения подходит, если вы хотите увидеть реальную работу в процессе.
Пример:
Бухгалтер говорит: "У нас всё получилось".
Вы приходите и видите, как он вручную переносит данные из одного Excel в другой.
Мозговой штурм
Подходит для создания новых идей или нахождения креативных решений и проходит в два этапа:
Генерация идей — фиксируйте каждую идею, даже самую безумную. Честно говоря, иногда гениальные решения сначала выглядят как шутка.
Отбор идей — фильтрация, группировка, уточнение и расстановка приоритетов.
Среднее время, отведенное на генерирование идей, составляет около одного часа.
Практические рекомендации:
создайте онлайн-доску (например, в Miro или Trello) или используйте оффлайн-инструменты (стикеры, флипчарт). Видя идеи коллег, участники начнут предлагать что-то новое или улучшать существующее.
стимулируйте активность всех участников: объединяйте людей в пары, просите записать свои идеи или обсуждать требования по кругу.
сначала фокусируйтесь на текущем требовании, зафиксируйте достаточное количество идей, прежде чем переходить к следующему пункту.
ограничьте время для генерации идей, чтобы сохранить продуктивность и избежать выгорания.
Бенчмаркинг
Бенчмаркинг или эталонное оценивание — это процесс сравнительного анализа на базе эталонных показателей. Если проще — это когда вы смотрите на конкурентов, восхищаетесь своим продуктом и думаете: «Почему у нас так нельзя?» Но вместо того, чтобы жаловаться, вы анализируете их успех и адаптируете лучшие решения под свои задачи.
Включает в себя определение, понимание и адаптацию успешных примеров работы других компаний с целью улучшения собственных результатов.
Состоит из этапов:
Оценка.
Изучите, как работают конкуренты: что у них лучше, чем у вас?
Если проект касается банковского программного обеспечения, важно учитывать, что клиент имеет в виду термины «платёжное поручение» или «AML-система».: «У конкурента доставка за 1 день, а у нас — за 3. Как это изменить?»Сопоставление.
Сравните свои процессы и решения с эталонными. Например, у кого удобный интерфейс, более быстрая обратная связь или лучший UX-дизайн.
Обычно в качестве образцов берутся продукты или маркетинговые процессы конкурентов, действующих в аналогичной сфере. Это позволяет выявить пути улучшения собственных товаров и методов. Грубо говоря, мы берем существующие решения и стандарты, адаптируем их под свою компанию. Если после адаптации результаты улучшаются, стоит воспринять этот опыт. Данный метод помогает точно сформулировать требования, так как многие наработки уже существуют, и нужно учитывать только свои бизнес-процессы и нормативные документы.
Use Case
Use Case (возможности использования) способствует сбору и формулированию функциональных требований от имени участников проекта. Диаграммы вариантов использования определяют границы решения и его взаимодействие с внешними системами и участниками.
Этот подход отвечает на вопросы:
Кто взаимодействует с системой?
Как они это делают?
Какие внешние системы задействованы?
Пример:
Если ваш проект — это система бронирования отелей, Use Case может выглядеть так:
Актор (пользователь): клиент.
Цель: забронировать номер.
Основной сценарий: пользователь выбирает даты, фильтрует отели по критериям, вводит данные, подтверждает бронь.
Альтернативный сценарий: пользователь отменяет бронь через профиль.
Почему это важно?
Use Case позволяет детализировать требования с точки зрения конечных пользователей и способствует уточнению необходимого функционала.. Кроме того, он помогает визуально показать границы системы и взаимодействие с другими элементами (например, платежными системами).
Изучение документации
Еще один эффективный метод, когда в организации имеется документация, помогающая выявить потребности заказчика, например, регламенты, описания процессов, структурные схемы, спецификации продуктов и различные инструкции.
Воркшоп
Воркшоп — это формат рабочего совещания, посвященного сбору и обсуждению требований, с заранее подготовленной структурой. Здесь приглашаются представители заказчика и команды разработки. Цель состоит в выявлении скрытых требований, уточнении общего списка потребностей и разрешении противоречий. В итоге группа приходит к оптимальному решению для всех участников.
Практические советы:
Запланируйте регламент: воркшопы могут длиться долго, поэтому обязательно предусмотрите перерывы и, если необходимо, обеды.
Подготовьте программу совещания и раздайте ее всем участникам.
Назначьте фасилитатора, который будет следить за процессом и повесткой встречи.
Определите таймкипера для управления временем и секретаря для фиксирования всех высказываний, принятых решений и отложенных вопросов.
Подготовка к сбору требований: как не выглядеть растерянным на встрече
Теперь немного о подготовительных этапах работы.
Перед встречей со стейкхолдерами важно собрать и проанализировать информацию по теме, изучить предметную область. Если имелось предварительное обсуждение с заказчиком, пересмотрите заметки, чтобы освежить идеи (если их нет, то начинайте их делать, серьёзно).
Проанализируйте рынок: узнайте, какие решения предлагают аналогичные компании, ознакомьтесь с похожими товарами. Насколько уникален ваш клиент и как его бизнес представлен на рынке?
Пример:Если ваш клиент — интернет-магазин, посмотрите, как конкуренты реализуют автоматизацию доставки или программы лояльности.
Знание темы и предметной области поможет вам говорить с клиентом на одном языке, демонстрируя осведомленность и понимание его проблем.
Сформулируйте начальные термины и определения на основе данных с сайта клиента. Глоссарий будет полезен во время погружения новых участников проекта, поскольку общее понимание терминологии поможет стейкхолдерам и разработчикам быстрее включиться в рабочие процессы.
Что включить в глоссарий?
Ключевые термины из предметной области клиента.
Жаргон или слэнг, которые используют заказчики.
Технические понятия, если их необходимо объяснить.
Пример:Если проект касается банковского программного обеспечения, важно учитывать, что клиент имеет в виду термины «платёжное поручение» или «AML-система».
Совет: Глоссарий можно сделать доступным для всех участников проекта, чтобы минимизировать недопонимание.
Для интервью подготовьте список ключевых вопросов общего уровня, которые можно будет развивать в зависимости от ответов собеседника. Начинайте с общих вопросов, постепенно переходя к деталям, чтобы не упустить важные моменты.
Для воркшопа или мозгового штурма определите проблему или проблемы для обсуждения, составьте список участников и выберите фасилитатора.
Ну и напоследок я спою, несколько общих практических рекомендаций:
Понимание ролей — ключ к успешному сбору требований. Необходимо знать, кто принимает решения, а кто просто участвует. Существуют спонсоры, заказчики и пользователи, и важно осознать цели заказчика и ожидания от системы.
Совет: Всегда уточняйте цели и ожидания каждого из них. Спонсор будет волновать ROI (возврат инвестиций), а пользователю важно, чтобы система не подвисала.
Сотрудники могут помочь прояснить текущую систему (As-Is), но важно уточнить, какой конечный результат нужен заказчику (To-Be). Не следует полностью следовать требованиям сотрудников, поскольку они могут не иметь полного представления о целостности и выполнимости требований.
Регулярно задавайте вопросы «Зачем?» и «Почему?», вместо простых «Что?» и «Как?». Это углубит ваше понимание сути требований, а не просто следование представлению конечного продукта со стороны сотрудников.
Если вы хорошо подготовитесь, то сбор требований станет не бесконечной головоломкой, а четким и понятным процессом. А если нет... ну, тогда спасут только импровизацию и кофе. 😊
