Анализ требований в разрезе управления проектом
За всеми нюансами предпроектного анализа нельзя забывать про главное — решение проблемы клиента. Рассмотрим процесс проведения аналитики на примере успешного кейса.
09.12.2014 | Автор: Гузель Рахимова, Центр Высоких Технологий (Руководитель проектов) 
Для чего Для чего нужна аналитика на проекте? Чтобы в конце получился именно тот продукт, который задумывался в начале.
Предпроектная аналитика поможет составить образ конечного продукта, избавиться от неопределенности при реализации, снизить затраты на доработки и обслуживание.
Как договориться и сделать хороший продукт в срок и без лишних нервов? Как вносить ясность и раскладывать требования по полочкам? Как же понять, все ли мы делаем правильно на проекте? Как адекватно оценить разработку? Как обозначить зоны ответственности? Требования Довольно часто во время разработки всплывают все новые и новые требования. Еще печальнее, когда это происходит на этапе сдачи проекта, когда конечный продукт не соответствует ожиданиям заказчика. И в результате заказчик не доволен, он теряет деньги, исполнитель переделывает и несет убытки.
Почему же так происходит? Участники проекта не сошлись в формулировках и ожиданиях, не поняли друг друга.
Такого непонимания можно избежать, если вовремя:
конкретизировать требования упорядочить требования зафиксировать требования Конкретизация Весь пул пожеланий и ожиданий заказчика необходимо уточнить до состояния полной однозначности. Например, заказчик предъявляет такое требование «Интерфейс должен быть интуитивно понятным». Хорошее требование (спасибо Денису Бескову за отличный пример).
Но что оно значит? Кому должен быть интуитивно понятен интерфейс: заказчику, пользователю, разработчику, жене заказчика?
Что значит «интуитивно понятен»? Интерфейс позволяет пройти базовый сценарий на странице без подсказок? А если пользователь прошел базовый сценарий без подсказок, но потратил на это полчаса? Это много или мало? На все это должны быть ответы.
Требования должны быть однозначными, измеримыми, выполнимыми.
Конкретные требования к продукту позволяют задать границы разработки, обеспечить разработчиков однозначными тасками, определить критерии качества.
Упорядочение Собранные требования можно привести в порядок разными способами.
Например, требования можно разбить на смысловые группы по приоритетам, по функциям и т.д. Например, есть задача по созданию сервиса, на котором пользователи могут платно смотреть некоторые видео. В первую очередь необходимо реализовать функцию загрузки, хранения и просмотра видео. Далее уже настроить возможность оплатить просмотр, сделать интеграцию с платежными сервисами, настройку регистрации пользователей и т.д.
Фиксация Все собранные и обработанные требования обязательно должны быть зафиксированы документально и согласованы. Что не записано, значит, не было. Например, я фиксирую требования в таких документах как: рамки проекта, ТЗ, спецификация, художественное задание, контентная таблица, схемы и прототипы.
Решение проблемы За всеми этими нюансами и деталями очень важно не упустить главное. А главным является решение проблемы клиента. Конечный продукт не должен быть вещью-в-себе, он должен решать задачи и быть полезным. Необходимо прояснить, в чем дело. Не всегда то, что хочет заказчик, это то, что ему действительно нужно.
Например, заказчик хочет интернет-магазин, так как считает, что это поможет ему увеличить прибыль. Ок, у заказчика появился классный, красивый и удобный интернет-магазин. Заказов стало больше, а прибыль не растет. В чем же дело? Заказов стало больше, операторы на стороне заказчика не успевают все обработать, на складе путаница. Выходит, что внутренние системы заказчика не были готовы к такому объему работы. Сайт не помог, а только усугубил положение. Истинная проблема была в несовершенстве бизнес-процессов внутри компании заказчика. Это необходимо выяснить на этапе аналитики.
Как сделать
Как же сделать это? Задавать много вопросов.
Но главное здесь — это умение задавать правильные вопросы, даже пусть они будут неудобными. Важно поставить себя на место заказчика, на место конечного пользователя и попытаться представить, что и зачем я делаю.
К вам пришел проект. Не поленитесь, задайте вопросы «для кого, зачем, почему, как, что в итоге», представьте себя пользователем, узнайте ожидания заказчика. Ответы на эти вопросы, полученные в самом начале, сэкономят вам кучу нервов и крови в конце проекта.
Процесс Кейс Процесс проведения аналитики я хочу показать на примере одного успешного кейса.
Рассмотрим кейс разработки корпоративного сайта для агрохолдинга. Вроде звучит достаточно ясно, но дьявол кроется в деталях.
А детали такие:
1 место в регионе 16 компаний 6 типов производства 6 сегментов аудитории b2b и b2c Всего 1 сайт для представления Первый этап «Определение бизнес-задач и ожиданий» Процесс проведения аналитики необходимо начинать с изучения бизнес-сферы клиента, целей и задач проекта и продукта.
На этом этапе мы с командой выезжали к клиенту в офис, провели встречи со всеми заинтересованными отделами, получили документ с видением сайта. По итогам первого этапа мы получили в качестве артефакта документ с рамками проекта, в котором зафиксировали задачи сайта, задачи клиента, задачи нас как исполнителя, указали ограничения по информационной структуре и навигации. Это послужило основой для разработки ТЗ и интерактивных прототипов
Второй этап «Изучение целевой аудитории» Конечным продуктом будут пользоваться живые люди. Необходимо выяснить, кто они такие.
Далее мы изучили потенциальных посетителей сайта, их требований и задач. Сайт ориентирован одновременно и на b2b, и на b2c сегменты.
Нужно было учесть интересы партнеров, инвесторов, контролирующих органов, СМИ, соискателей, конечных потребителей продукции. По итогам был составлен документ с пользовательскими сценариями и описанием необходимых разделов.
Третий этап «Аудит конкурентов» Следующим этапом стал аудит сайтов конкурентов и анализ лучших практик в интерфейсах и дизайне. Было изучено 19 различных сайтов и составлен документ с выводами, что опять таки повлияло на разработку прототипов и дизайна.
Поговорив с маркетологами, мы определили наиболее серьезных конкурентов и изучили их сайты по нескольким критериям: наличие промо баннеров, разделение контента по аудитории, каталог продукции, формы связи и т.д.
Четвертый этап «Анализ контента» На четвертом этапоме мы собрали требования к контенту. Учитывая большой пул разнообразных задач сайта, обширную аудиторию и невероятное желание клиента рассказать о себе все, мы решили все зафиксировать. Мы с командой составили таблицу соответствия раздела и необходимого контента и отрядили специального человека собирать контент в офисе клиента.
Пятый этап «Определение функций и сценариев работы» На предыдущих этапах мы выявили цели и задачи проекта, заказчика и пользователей. Теперь же исходя из этих данных мы описали функциональные возможности разрабатываемого продукта.
Все собранные и проанализированные требования к функциональности, работоспособности продукта мы отразили в проектной документации. Написали подробнейшее ТЗ и создали интерактивные прототипы.
Конечный прототип содержит 44 уникальных страницы. Проработанный до мелочей прототип позволил выявить недочеты в интерфейсе, помог осознать взаимосвязь всех разделов. Немаловажную роль сыграло тестирование прототипов.
Артефакты В ходе анализа требований мы получили следующие артефакты:
Рамки проекта Информационная структура сайта Пользовательские сценарии ТЗ на разработку сайта Контентная таблица Аудит сайтов конкурентов Прототипы Инструкции для контент-менеджеров Юзабилити тесты и приемочные тесты Основными материалами, которыми мы руководствовались при разработке, были ТЗ и прототипы.
Итог Проведенная аналитика позволила:
Определить понимание конечного продукта Корректно оценить и спланировать разработку Избежать рисков, связанных с концептуальным изменением разделов, структуры сайта или подачи контента Сформулировать задачи команде Разработать сценарии тестирования Определить реальные сроки сдачи Написать инструкции Выполнить приемку работОсуществить поддержку проекта И в итоге:
Все знают, что делать Все знают, что должно получиться Клиент в курсе всего и доволен … ??? Profit!!! Продукт соответствует указанным требованиям, выполняет свою роль с первых же минут релиза.
Литература Могу порекомендовать литературу, которая поможет понять процесс аналитики:
Карл Вигерс «Разработка требований к программному обеспечению» А. Перерва, В. Иванова «Путь аналитика» К. Чандлер, Р. Уингер «UX дизайн. Практическое руководство по проектированию опыта взаимодействия» Алан Купер «Психбольница в руках пациентов» Хабрахабр Конечный результат http://www.komos.ru/
Полный текст статьи читайте на CMS Magazine
