0

Анализ требований: как не облажаться в начале и в конце проекта

Гузель Рахимова
28 июля 2014 года

Для чего нужна аналитика на проекте? Чтобы в конце получился именно тот продукт, который задумывался в начале.


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

Требования

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

Такого непонимания можно избежать, если вовремя:

  • конкретизировать требования
  • упорядочить требования
  • зафиксировать требования

Весь пул пожеланий и ожиданий клиента необходимо уточнить до состояния полной однозначности. Например, клиент предъявляет такое требование: «Интерфейс должен быть интуитивно понятным». Хорошее требование. Но что оно значит? Кому должен быть интуитивно понятен интерфейс: клиенту, пользователю, разработчику, жене клиента? Что значит «интуитивно понятен»? Интерфейс позволяет пройти базовый сценарий на странице без подсказок? А если пользователь прошел базовый сценарий без подсказок, но потратил на это полчаса? Это много или мало?

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

Решение проблемы

Про требования все логично и понятно. Самым главным на этапе аналитики является поиск решения проблемы клиента наилучшим способом. Клиент приходит к нам не просто за сайтом или программой, а за решением. У него есть даже не проблема, а какая-то неудовлетворенность текущим положением. Необходимо прояснить, в чем дело. Не всегда то, что хочет клиент – это то, что ему действительно нужно.

Например, клиент хочет интернет-магазин, так как считает, что это поможет ему увеличить прибыль. Ок, у клиента появился классный, красивый и удобный интернет-магазин. Заказов стало больше, а прибыль не растет. В чем же дело? Заказов стало больше, операторы на стороне клиента не успевают все обработать, на складе путаница. Выходит, что внутренние системы клиента не были готовы к такому объему работы. Сайт не помог, а только усугубил положение. Истинная проблема была в несовершенстве бизнес-процессов внутри компании клиента. Это необходимо выяснять на этапе аналитики.

Как сделать

Как же сделать это? Конечно, задавать много вопросов — самых разных, а порой и неудобных. Лучше выяснить все мелочи до начала работы, чем страдать в конце.

Процесс

При проведении аналитики важно придерживаться такого процесса:

  1. Определение бизнес-задач и ожиданий
  2. Изучение пользователей
  3. Конкурентный анализ
  4. Определение функций и сценариев работы
  5. Разработка документации

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

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

Например, мы разрабатываем сайт доставки еды. Вот портрет одного из пользователей: Маша, 20 лет, студентка, увлекается фитнесом. Какой критерий окажется ключевым для Маши при выборе блюда на этом сайте? Девушка увлекается фитнесом, значит, следит за питанием. Ключевой критерий — калории. Что нам дает это знание? Это говорит о том, что на сайте должна быть возможность фильтровать блюда по количеству калорий. На сайте может быть даже калькулятор калорий, если можно собрать комплекс блюд. И еще это накладывает на заказчика обязанность подсчитать калории в своих блюдах. Таким образом, уже выявлены два функциональных требования и задача для заказчика.

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

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

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

Документация

Оформленный документ с зафиксированными требованиями позволит нам:

  • Согласовать состав работ
  • Сформулировать задачи команде
  • Разработать сценарии тестирования
  • Написать инструкции
  • Выполнить приемку работ

И в итоге:

  1. Все знают, что делать
  2. Все знают, что должно получиться
  3. Клиент в курсе всего и доволен
  4. ???
  5. Profit!!!!!111

Литература

Могу порекомендовать литературу, которая поможет понять процесс аналитики:

  • Вигерс К. «Разработка требований к программному обеспечению»
  • Перерва А., Иванова В. «Путь аналитика»
  • Чандлер К., Уингер Р. «UX дизайн. Практическое руководство по проектированию опыта взаимодействия»
  • Купер А. «Психбольница в руках пациентов»
  • Хабрахабр

Метки:

Оставить комментарий