Отдохнули, конечно, отлично, но надо и поработать. Поэтому первая серьезная тема, над которой я решил подумать по возвращении, это "Какой должна быть последовательность действий аналитика на IT проекте?" Про это сегодня и пойдет разговор.
Сразу оговорюсь, что я работаю в продуктовой компании. Заказчиков у нас нет, требования составляются в процессе поиска и анализа законодательных и нормативных актов, продуктов конкурентов + внедрение своих революционных фич и технологий :)
Первый шаг и самое главное - это собрать вводный митинг и обсудить поверхностно основные моменты (в том числе и политические, которые будут/не будут реализованы из-за амбиций, например Директора).
- Пригласить на этот митинг следует всех ключевых участников внутри проекта - PM, team leads, все аналитики проекта, остальная часть команды по желанию (разработчики, верстальщики, тестировщики, дизайнеры, копирайтеры).
- Обсудить проект, его бизнес цель, нюансы.
- Составить план работ и оценить время на ближайшие шаги.
Второй шаг - собрать и проанализировать результаты вводного митинга и, как результат, составить общую концепцию проекта. Концепция определяет что и зачем делается в проекте. В ней обязательно следует учесть:
- Цели и результаты;
- Допущения и ограничения;
- Ключевые участники и заинтересованные стороны (на этом этапе можно составить Stakeholder wheel, подробнее о нем с реальным примером моего проекта я расскажу позже);
- Выделенные ресурсы;
- Сроки;
- Критерии приемки;
- Список основного функционала;
- Роли и права доступа пользователей;
- Структура и общие элементы UI;
- Набросать sketch интерфейса.
Главная цель этого этапа: подтверждение и согласование единого видения конечной бизнес цели, задач и результатов всеми заинтересованными лицами.
- Согласование концепции внутри отдела Бизнес анализа;
- Согласование с заинтересованными сторонами из пункта №1 (PM, team leads).
* Здесь и далее после каждого согласования подразумевается доработка без повторного согласования.
Третий шаг - создание прототипа и спецификации. Путем сбора мнений знакомых БА и изучения опыта западных коллег была выработана следующая рекомендованная последовательность действий:
- Разработка списка функций, которые имеют наиболее высокий приоритет на первоначальном этапе;
- Разработка Use Case Diagrams;
- Нарисовать sketch (wireframe, структурную схему), где будет видно функционирование этих фич (не тратить много времени, все делается очень грубо);
- Согласовать sketch внутри отдела БА;
- Согласовать sketch с разработчиками, чтобы не было противоречий с технической точки зрения;
- Нарисовать прототип (если время позволяет, то надо нарисовать рабочий прототип);
- Согласовать прототип внутри отдела БА;
- Согласовать прототип с дизайнерами;
- Провести презентацию прототипа с заинтересованными сторонами (PM, team leads);
- Создание спецификации;
- Согласовать тексты (на страницах, кнопках, pop-ups, etc.) с копирайтерами;
- Согласовать спецификацию внутри отдела БА;
- Согласовать спецификацию с разработчиками.
- Проверить, что дизайн отвечает всем требованиям спецификации (самое частое - не прорисованы все возможные состояния полей);
- Составить чек лист по элементам дизайна;
- Утвердить дизайн.
Пятый шаг - согласование текстов, написанных копирайтерами.
- Проверить, что тексты на страницах отвечают всем требованиям спецификации;
- Утвердить тексты.
Шестой шаг - приемочное тестирование. Может проводиться параллельно с тестировщиками или уже после исправления багов.
- Проверить, что готовый сайт или приложение соответствует требованиям спецификации, дизайна и тексту копирайтеров.
