Crassa ignorantia
Заказчики уже более-менее приняли необходимость фазы аналитики, когда специалист-аналитик собирает, анализирует, фиксирует, согласует требования для того, чтобы разрабатываемый продукт соответствовал ожиданиям заказчика.
А что, если сами ожидания не определены? Заказчик что-то хочет, у него есть деньги, но представление о будущем продукте у него слишком размытое. Что предлагаете, не вписываться в такие проекты, чтобы минимизировать риски? Есть решение лучше — дискавери-фаза.
Дискавери-фаза — нулевой этап проекта, на котором выявляются верхнеуровневые требования и анализируются поставленные бизнес-цели, чтобы сделать предложение по технической реализации, зафиксировать границы проекта и оценить стоимость разработки.
Идея в том, чтобы сначала уменьшить неопределённость и только потом оценивать проект. Иногда это может быть сложно, например, с госами, там это требует целой отдельной процедуры.
Предпроектное обследование позволяет понять возможности заказчика и его айти-ландшафт. Какое ПО уже внедрено, какие сотрудники уже есть в штате.
Да и в целом, дискавери-фаза позволяет понять реальные проблемы, которые хочет решить заказчик и его верхнеуровневые приоритеты. А также его возможности и ограничения.
Команда для проведения предпроектного обследования
Руководитель проекта, аналитик, дизайнер, технический специалист и, конечно же, заказчик.
Вовлечение заказчика на этапе дискавери-фазы критически важно. Если заказчик не готов встречаться со специалистами каждый день, лучше вообще, не браться.
Аналитик отвечает за сферу требований. Выявление верхнеуровневых требований, их фиксация. Дискавери-фаза не подменяет этап аналитики, но в неё можно вынести часть аналитических работ.
Дизайнер — логика UX и UI, генерация вайрфреймов.
Руководитель проекта — организует весь процесс, назначает встречи с заказчиком, следит, чтобы все на них ходили. Консультирует всех участников, собирает итоговый отчёт.
Технический специалист — разработчик. Исследует айти-ландшафт, внедрённые решения, отвечает за то, чтобы всё, что мы напроектируем, было реализуемо.
Краткая методика предпроектного обследования
Дискавери-фаза предваряет проект и часто является довольно трудоёмким мероприятием, включающим в себя:
- Изучение процессов, касающихся проекта. Чаще всего, путём чтения доков.
- Интервьюирование заинтересованных и участвующих лиц.
- Личное посещение производства, если требуется.
Бизнес-консультант или аналитик, нанятый для проведения дискавери-фазы самостоятельно анализирует ландшафт, бизнес-процессы, оценивает общую эффективность работы, ищет точки роста. Часто к предпроектному обследованию привлекают и технических специалистов.
Специалист должен оценить, какими путями можно решить задачи, которые заказчик озвучил в брифе на проект. Выделить возможные проблемы, предложить варианты решения.
На дискавери-фазе не готовят техзадание. На нём готовят отчёт с описанием окружения, проблематики, текущей ситуации в стане заказчика. В отчёте может быть верхнеуровневый вариант реализации, решающий обозначенные проблемы. То есть, грубо говоря, что есть на входе, что должно быть на выходе и как мы этого добьёмся. Крайне желательно — и сколько это будет стоить.
Объём отчёта по предпроектному исследованию может быть разный, от 2-3 страниц до 50-60, более обширно делать не стоит. Детали можно будет доуточнить уже в техзадании.
В отчёте должно быть всё, что нужно заказчику для принятия информированного решения о старте проекта с оценкой рисков.
Артефакты дискавери-фазы
Mind Map
- Основная цель: зафиксировать верхнеуровневые аспекты проекта.
- Часы на создание: 8–32.
- Участники: аналитик и заказчик.
- Необходимость: обязательный.
Майндмап — лучший способ визуализировать сложную структуру, чтобы осознать масштаб проекта. Поместите на майндмап эпики и объекты интеграций, чтобы определить границы будущего проекта.
При помощи этого инструмента можно выделить малозаметные задачи, увидеть связи, отловить противоречия и дублирующиеся функции.
User story
- Основная цель: чётко и внятно разбить проект на фичи. Определить, какую задачу решает каждая фича.
- Часы на создание: 8–32.
- Участники: аналитик и заказчик.
- Необходимость: необязательный артефакт.
Это как раз, тот момент, в котором мы перекладываем на дискавери часть аналитических работ. Заказчик чаще всего даёт описание системы в очень общем виде, тут мы его структурируем.
Юзерстори позволяют трансформировать бизнес-требования в функциональные.
Текст пользовательской истории объясняет роль, действия пользователя в системе, его потребность и профит, который он получит, когда история случится.
Я, как <роль>, хочу иметь возможность делать <операцию>, для того, чтобы достигнуть <цель>.
Диаграмма BPMN
- Основная цель: понять, какие роли какие вещи будут делать в системе и как эти процессы взаимосвязаны.
- Часов на создание: 8–40.
- Участники: аналитик и заказчик. Пиэм курирует, разраб визирует.
- Необходимость: обязательный артефакт.
BPMN-диаграмма — это ещё один уровень детализации требований. В таком виде можно очень хорошо визуализировать систему, обнаружив «слепые пятна» в процессах и логике.
При составлении этого артефакта важно разобрать и поместить на схему инфу, как именно система работает, откуда берутся какие данные, входы и выходы процессов, пути достижения пользователем цели.
Wireframes
- Основная цель: показать верхнеуровневую логику интерфейса.
- Часы на создание: 16–40.
- Участники: дизайнер, аналитик, заказчик. Пиэм курирует, разраб визирует.
- Необходимость: необязательный артефакт. Делаем только если: прорабатываем определённый пользовательский сценарий и показываем, как пользователь приходит к ожидаемому результату; оцениваем дизайн уже в дискавери-фазе; создаём интерактивный Invision-прототип.
Не нужно пытаться в дискавери-фазе нарисовать весь интерфейс. Но набросать чёрно-белые вайрфреймы ключевых сценариев было бы очень здорово.
Кликабельный прототип
- Основная цель: дать возможность реальным пользователям ознакомиться с интерфейсом будущего продукта и собрать ОС.
- Часы на создание: 40–80.
- Участники: аналитик, дизайнер и клиент. Контролируется руководителем проекта и проходит раунд обратной связи у заказчика.
- Необходимость: необязательный артефакт. Делаем чтобы: помочь заказчику продемонстрировать идею стейкхолдерам; получить обратную связь от конечных пользователей или фокус-группы; протестировать реальный пользовательский опыт перед началом разработки.
Не путать с Wireframe. Прототип уже более детализирован с точки зрения дизайна, но всё ещё может не выглядеть как конечный продукт. Однако логика интерфейса основных потоков в нём уже должна быть проработана.
Практика показывает, что кликанье интерактивного прототипа намного лучше включает у заказчика абстрактное мышление, нежели статичные картинки. Этап необязателен, но очень полезен.
Нефункциональные требования
- Основная цель: выявить и приоритизировать нефункциональные вещи, которые могут повлиять на бюджет проекта.
- Часы на создание: 2–4.
- Участники: аналитик и заказчик. Пиэм курирует, разраб визирует.
- Необходимость: обязательный артефакт.
Почитайте мою статью о том, что такое нефункциональные требования.
В международных проектах можно влететь, не учтя необходимость локализации на редкий язык.
В целом, нефункциональные требования помогут лучше понять ограничения, накладываемые на систему.
Презентация
- Основная цель: рассказать про выгоды продукта для стейкхолдеров.
- Часы на создание: 12–52.
- Участники: аналитик, дизайнер и заказчик. Пиэм контролирует, проводится один раунд обратной связи у заказчика.
- Необходимость: необязательный артефакт.
Делаем, чтобы помочь заказчику презентовать идею стейкхолдерам и добиться положительного решения о старте проекта.
План проекта
- Основная цель: дать заказчику понимание количества требуемых ресурсов и верхнеуровневых сроков.
- Часы на создание: до 8.
- Участник: руководитель проекта.
- Необходимость: обязательный артефакт.
Большого смысла точно планировать на этапе дискавери-фазы нет. Очень примерный план с вехами. Может быть, даже не на весь проект, а только на первую итерацию.
Грубая оценка на разработку
- Основная цель: ответить на самый важный вопрос — сколько это всё будет стоить, хотя бы примерно?
- Часы на создание: 8—16.
- Участники: аналитик и разработчики. Дизайнер и тестировщик при необходимости. Пиэм курирует, разраб визирует.
- Необходимость: обязательный артефакт.
После того, как у нас готов общий план, можно попробовать примерно оценить трудозатраты и стоимость проекта. Можно с разбивкой на компоненты — бэк, фронт, мобилка, тестирование и так далее. Желательно, чтобы каждый компонент оценивал лид этого компонента.
Заключение
На первый взгляд, может показаться, что добавление в и так сложную проектную схему этапа дискавери, его усложняет. На деле, она сильно уменьшает неопределённость, снижая стоимость последующих работ.
Если смотреть на дискавери глазами заказчика, то дискавери помогает:
- Понять сроки и бюджет, чтобы для владельца компании они не стали неожиданностью.
- Облегчить последующее бюджетирование и планирование. После дискавери-фазы будет меньше фантазий и больше конкретики.
- Разобраться с бизнес-процессом, сделать его/их логичными и без дыр.
Ну и, конечно, если вы построите работу во время предпроектного обследования грамотно, вы наладите взаимодействие с заказчиком, что облегчит работу уже на самом проекте.
Ещё, из плюсов, наладив процесс дискавери, вы перестанете бояться проектов на большое количество часов. Кроме того, заказчики, не готовые платить, будут отваливаться после дискавери, а не после аналитики, экономя ваши деньги.
