Как не облажаться в начале и в конце проекта
Пожалуй, начну с самого начала. Почему несколько лет назад я решила заняться анализом требований к проектам? Потому что хотела уменьшить хаос и навести порядок. Для этого все средства хороши. Но милее всех сердцу моему — структурированный процесс. Именно об этом я рассказывала в далеком 2014 году в Смоленске на конференции Tabtabus.
Для чего
Для чего нужна аналитика на проекте? Чтобы в конце получилась желанная конфетка, то есть именно тот продукт, который задумывался в начале.
Аналитика поможет составить образ конечного продукта и ответить на вопросы:
- В какие сроки мы можем уложиться?
- Как вносить ясность и раскладывать требования по полочкам?
- Как же понять, все ли мы делаем правильно на проекте?
- Как адекватно оценить разработку?
- Как обозначить зоны ответственности?
Требования
Во время разработки постоянно всплывают все новые и новые требования. Проблемы возникают, когда это происходит на этапе сдачи проекта, когда конечный продукт не соответствует ожиданиям заказчика. И в результате заказчик не доволен, он теряет деньги, исполнитель переделывает и несет убытки.
Почему же так происходит? Участники проекта не сошлись в формулировках и ожиданиях, не поняли друг друга.
Такого непонимания можно избежать, если вовремя:
- конкретизировать требования
- упорядочить требования
- зафиксировать требования
Конкретизация
Весь пул пожеланий и ожиданий заказчика необходимо уточнить до состояния полной однозначности. Например, заказчик предъявляет такое требование “Интерфейс должен быть интуитивно понятным”.
Но что оно значит? Кому должен быть интуитивно понятен интерфейс: заказчику, пользователю, разработчику, жене заказчика?
Что значит “интуитивно понятен”? Интерфейс позволяет пройти базовый сценарий на странице без подсказок? А если пользователь прошел базовый сценарий без подсказок, но потратил на это полчаса? Это много или мало? На все это должны быть ответы.
Требования должны быть однозначными, измеримыми, выполнимыми.
Конкретные требования к продукту позволяют задать границы разработки, обеспечить разработчиков однозначными тасками, определить критерии качества.
Упорядочение
Собранные требования можно привести в порядок разными способами.
Например, требования можно разбить на смысловые группы по приоритетам, по функциям и т.д. Например, есть задача по созданию сервиса, на котором пользователи могут платно смотреть некоторые видео. В первую очередь необходимо реализовать функцию загрузки, хранения и просмотра видео. Далее уже настроить возможность оплатить просмотр, сделать интеграцию с платежными сервисами, настройку регистрации пользователей и т.д.
Фиксация
Все собранные и обработанные требования обязательно должны быть зафиксированы документально и согласованы. Что не записано, значит, не было. Например, я фиксирую требования в таких документах как: рамки проекта, ТЗ, спецификация, художественное задание, контентная таблица, схемы и прототипы.
Решение проблемы
За всеми этими нюансами и деталями очень важно не упустить главное. А главным является решение проблемы клиента. Конечный продукт не должен быть вещью-в-себе, он должен решать задачи и быть полезным. Необходимо прояснить, в чем дело. Не всегда то, что хочет заказчик, это то, что ему действительно нужно.
Например, заказчик хочет интернет-магазин, так как считает, что это поможет ему увеличить прибыль. Ок, у заказчика появился классный, красивый и удобный интернет-магазин. Заказов стало больше, а прибыль не растет. В чем же дело? Заказов стало больше, операторы на стороне заказчика не успевают все обработать, на складе путаница. Выходит, что внутренние системы заказчика не были готовы к такому объему работы. Сайт не помог, а только усугубил положение. Истинная проблема была в несовершенстве бизнес-процессов внутри компании заказчика. Это необходимо выяснить на этапе аналитики.
Как сделать
Как же сделать это? Задавать много вопросов.
Но главное здесь — это умение задавать правильные вопросы, даже пусть они будут неудобными. Важно поставить себя на место заказчика, на место конечного пользователя и попытаться представить, что и зачем я делаю.
К вам пришел проект. Не поленитесь, задайте вопросы “для кого, зачем, почему, как, что в итоге”, представьте себя пользователем, узнайте ожидания заказчика. Ответы на эти вопросы, полученные в самом начале, сэкономят вам кучу нервов и крови в конце проекта.
Процесс. Кейс
Процесс проведения аналитики я хочу показать на примере одного успешного кейса.
Рассмотрим кейс разработки корпоративного сайта для агрохолдинга. Вроде звучит достаточно ясно, но дьявол кроется в деталях.
А детали такие:
- 1 место в регионе
- 16 компаний внутри холдинга
- 6 типов производства
- 6 сегментов аудитории b2b и b2c
- Всего 1 сайт для представления
Первый этап “Определение бизнес-задач и ожиданий”
Процесс проведения аналитики необходимо начинать с изучения бизнес-сферы клиента, целей и задач проекта и продукта.
На этом этапе мы с командой выезжали к клиенту в офис, провели встречи со всеми заинтересованными отделами, получили документ с видением сайта. По итогам первого этапа мы получили в качестве артефакта документ с рамками проекта, в котором зафиксировали задачи сайта, задачи клиента, задачи нас как исполнителя, указали ограничения по информационной структуре и навигации. Это послужило основой для разработки ТЗ и интерактивных прототипов
Второй этап “Изучение целевой аудитории”
Конечным продуктом будут пользоваться живые люди. Необходимо выяснить, кто они такие.
Далее мы изучили потенциальных посетителей сайта, их требований и задач. Сайт ориентирован одновременно и на b2b, и на b2c сегменты.
Нужно было учесть интересы партнеров, инвесторов, контролирующих органов, СМИ, соискателей, конечных потребителей продукции. По итогам был составлен документ с пользовательскими сценариями и описанием необходимых разделов.
Третий этап “Аудит конкурентов”
Следующим этапом стал аудит сайтов конкурентов и анализ лучших практик в интерфейсах и дизайне. Было изучено около 20 различных сайтов и составлен документ с выводами, что опять таки повлияло на разработку прототипов и дизайна.
Поговорив с маркетологами, мы определили наиболее серьезных конкурентов и изучили их сайты по нескольким критериям: наличие промо баннеров, разделение контента по аудитории, каталог продукции, формы связи и т.д.
Четвертый этап “Анализ контента”
На четвертом этапе мы собрали требования к контенту. Учитывая большой пул разнообразных задач сайта, обширную аудиторию и невероятное желание клиента рассказать о себе все, мы решили все зафиксировать. Мы с командой составили таблицу соответствия раздела и необходимого контента и отрядили специального человека собирать контент в офисе клиента.
Пятый этап “Определение функций и сценариев работы”
На предыдущих этапах мы выявили цели и задачи проекта, заказчика и пользователей. Теперь же исходя из этих данных мы описали функциональные возможности разрабатываемого продукта.
Все собранные и проанализированные требования к функциональности, работоспособности продукта мы отразили в проектной документации. Написали подробнейшее ТЗ и создали интерактивные прототипы.
Конечный прототип содержит 44 уникальных страницы. Проработанный до мелочей прототип позволил выявить недочеты в интерфейсе, помог осознать взаимосвязь всех разделов. Немаловажную роль сыграло тестирование прототипов.
Артефакты
В ходе анализа требований мы получили следующие артефакты:
- Рамки проекта
- Информационная структура сайта
- Пользовательские сценарии
- ТЗ на разработку сайта
- Контентная таблица
- Аудит сайтов конкурентов
- Прототипы
- Инструкции для контент-менеджеров
- Юзабилити тесты и приемочные тесты
Основными материалами, которыми мы руководствовались при разработке, были ТЗ и прототипы.
Итог
Проведенная аналитика позволила:
- Определить понимание конечного продукта
- Корректно оценить и спланировать разработку
- Избежать рисков, связанных с концептуальным изменением разделов, структуры сайта или подачи контента
- Сформулировать задачи команде
- Разработать сценарии тестирования
- Определить реальные сроки сдачи
- Написать инструкции
- Выполнить приемку работ
- Осуществить поддержку проекта
И в итоге:
- Все знают, что делать
- Все знают, что должно получиться
- Клиент в курсе всего и доволен
- …
- ???
- Profit!!!
Продукт соответствует указанным требованиям, выполняет свою роль с первых же минут релиза.
Видеозапись выступления с конференции можно посмотреть тут.
С любовью, Гузель
P.S. Посты канала «Байки из проектного офиса»