«Дискавери-фаза», или что делать, когда аналитика — это долго, дорого и неэффективно

В прошлой статье я рассказал, что мы в Magora Systems разделяем оценку проектов на два этапа. В этой статье — что происходит после этапа пресейла и с проектами, которые невозможно оценить, опираясь только на опыт.

Расскажу, что такое Discovery phase, которую для простоты буду называть «дискавери». Заодно приложу ссылки на нашу документацию.

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

Если оценке уделить мало внимания, то можно сильно пролететь с итоговой стоимостью работ. Если же сразу проводить детальную аналитику — придётся оплатить работу специалистов, которые будут задействованы.

Это означает, что сначала заказчика просят заплатить за стадию аналитики. Потом, скорее всего, доплатить ещё — работать в минус мало кто любит, а умеющих определять стоимость сразу и ещё меньше.

Затем, после этапа аналитики, ему сообщают стоимость разработки всего проекта. А дальше по известному сценарию: отрицание → гнев → торг → депрессия → принятие. Кто-то принимает ситуацию и ищет бюджет, а кто-то решал, что лучше вложиться в шиномонтажку.

Нас перестал устраивать такой подход и отношение к заказчикам. Решение, которое мы для себя нашли, — продавать по фиксированной и морально приемлемой стоимости ту часть аналитики, которую можем точно оценить, которая принесёт заказчику максимальную пользу за инвестированные деньги.

Руководитель проекта, аналитик, дизайнер, технический специалист и, конечно же, заказчик.

И чем активнее заказчик вовлекается, тем лучше получается смоделировать систему. Ежедневные созвоны на данном этапе — скорее требование, чем рекомендация.

Аналитик отвечает за выявление, анализ и фиксацию требований, проектирование логики системы и построение взаимосвязей. Переводит бизнес-цели в формат функциональных и нефункциональных требований.

На дизайнере — UX и UI.

Руководитель проекта — главный ответственный за проект. Организовывает работу команды, коммуникации с клиентом и еженедельную отчетность, бронирование ресурсов и поставку артефактов клиенту в сроки и с должным качеством.

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

Дискавери — поэтапная работа. Идём от глобальных бизнес-целей и задач до конкретных пользовательских действий в системе. После каждого этапа предоставляем отдельный артефакт с зафиксированными требованиями.

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

Первый артефакт — Mind Map, описывающий общий скоуп выявленных бизнес-целей и задач. Завершающий — оценка на разработку с детальной разбивкой на функции, учитывающая утвержденные нефункциональные требования, и почасовая оценка необходимых трудозатрат.

Подробнее об артефактах.

• Основная цель: зафиксировать роли, модули и интеграции.
• Часы на создание: 8–32.
  
• Участники: аналитик и заказчик.
  
• Необходимость: обязательный.
  

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

С ней проще разглядеть сразу незаметные задачи, построить взаимосвязи, отследить противоречия и дублирующиеся требования.

• Основная цель: определить, какую задачу решает каждая фича. Если для фичи нет задачи — скорее всего, фича не нужна.
• Часы на создание: 8–32.
• Участники: аналитик и заказчик.
• Необходимость: необязательный артефакт.

Чаще мы получаем от заказчиков общее видение системы, описание бизнес-целей и перечень «хотелок». Задача команды дискавери-фазы — «перевести» полученную информацию в пошаговый путь прохождения бизнес-кейса для каждой роли в системе.

Пользовательские истории — это первый инструмент, позволяющий трансформировать бизнес-требования в функциональные.

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

К примеру: Как <роль/персона>, я <могу сделать>, <с такой-то целью>.

Пример.

• Основная цель: определить и зафиксировать основные сценарии взаимодействия пользовательских ролей и системы — кто что делает в системе и как это взаимосвязано.
• Часов на создание: 8–40.
• Участники: аналитик и заказчик. Процесс модерируется руководителем проекта и проходит ревью у технического специалиста.
• Необходимость: обязательный артефакт.

BPMN-диаграмма — это ещё один уровень детализации требований. Формализация требований в таком виде помогает чётко понять взаимодействие пользователей друг с другом и увидеть возможные «белые пятна», которые в другом артефакте мы могли попросту не заметить.

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

• Основная цель: показать основные группы содержимого, информационную структуру и как пользователь взаимодействует с интерфейсом.
• Часы на создание: 16–40.
• Участники: дизайнер, аналитик, заказчик. Процесс модерируется руководителем проекта и проходит ревью у технического специалиста.
  
• Необходимость: необязательный артефакт. Делаем только если: прорабатываем определённый пользовательский сценарий и показываем, как пользователь приходит к ожидаемому результату; оцениваем дизайн уже в дискавери-фазе; создаём интерактивный Invision-прототип.
  

Wireframe даёт предварительное понимание будущей UI, UX инфраструктуры. И так как он, как правило, отображает ключевой бизнес-кейс, даёт понять, какие экраны необходимо включить в интерактивный прототип.

• Основная цель: приоритезировать бизнес-критичные нефункциональные требования и установить, как они влияют на сложность и стоимость разработки системы.
• Часы на создание: 2–4.
• Участники: аналитик и заказчик. Контролируется руководителем проекта, и согласовывается техническим специалистом.
• Необходимость: обязательный артефакт.

Нефункциональные требования — требования, описывающие работу системы, но не являющиеся в явном виде функциональными. Могут сильно повлиять на стоимость разработки, а если их не проработать, то и убить проект.

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

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

Пример.

• Основная цель: установить используемые форматы данных и требования к интеграциям.
• Часов на создание: 8–32.
  
• Участники: аналитик, разработчик и заказчик. Процесс контролируется руководителем проекта и согласовывается техническим специалистом.
  
• Необходимость: необязательный артефакт. Делаем только если в системе: есть нетривиальные интеграции; одна или более бизнес-критичная интеграция.
  

Это не описание API. Это документ, конкретизирующий требования к интеграции со сторонними системами и сервисами: что именно разрабатываемая нами система должна запросить у сервиса (какие поля) и что мы получим от него в ответ.

Это даёт понимание, какое решение справится с задачей наилучшим образом, выгодно для бизнеса и не вступит в конфликт с разрабатываемой системой.

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

Пример.

• Основная цель: согласовать основной стиль системы.
• Часы на создание: 16—24.
• Участники: аналитик, дизайнер и заказчик.
• Необходимость: необязательный артефакт. Обычно используется только в четырёх случаях: дизайн разрабатываем мы; поступил запрос на разработку интерактивного прототипа; готовится презентация идеи стейкхолдерам; заказчик обратился исключительно за дизайн-концептом.
  

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

• Основная цель: предложить обоснованные варианты решения проблемы клиенту.
• Часы на создание: 8–40.
• Участники: аналитик, технический специалист и клиент. Контролируется руководителем проекта и согласовывается техническим специалистом.
• Необходимость: необязательный артефакт. Используем если: в системе есть нетривиальные интеграции; в требованиях есть нестандартные аспекты, требующие отдельного внимания; для реализации требуется поиск и исследования возможных решений.
  

Любая бизнес-цель без изначально ясного решения или однозначного видения технической реализации — «узкое место». Инвестигирование — поиск узких мест и возможных решений.

Узкие места можно рассматривать в спектре от чисто бизнес-ориентированных до чисто технических. В особых случаях — симбиоз того и другого. Например, платежные системы.

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

Пример.

• Основная цель: рассказать про выгоды продукта для стейкхолдеров.
• Часы на создание: 12–52.
• Участники: аналитик, дизайнер и заказчик. Контролируется руководителем проекта, проходит один раунд обратной связи у заказчика.
• Необходимость: необязательный артефакт.

Делаем, чтобы помочь заказчику презентовать идею стейкхолдерам.

• Основная цель: протестировать способы взаимодействия и смоделировать пользовательский опыт.
• Часы на создание: 40–80.
• Участники: аналитик, дизайнер и клиент. Контролируется руководителем проекта и проходит раунд обратной связи у заказчика.
• Необходимость: необязательный артефакт. Делаем чтобы: помочь заказчику продемонстрировать идею стейкхолдерам; получить обратную связь от конечных пользователей или фокус-группы; протестировать реальный пользовательский опыт перед началом разработки.
  

Не путать с Wireframe. Invision-прототип может не выглядеть в точности как конечный продукт, но определённо не наброски в 50 оттенках серого. Взаимодействия аккуратно смоделированы и максимально похожи на то, что будет в конечном продукте.

• Основная цель: дать понимание требуемых разработческих ресурсов и транслировать сроки выполнения задач заказчику.
• Часы на создание: до 8.
• Участник: руководитель проекта.
• Необходимость: обязательный артефакт.

В зависимости от степени готовности аналитики и дизайна всех экранов приложения, план предоставляется:

• только на следующий этап — завершили первичную аналитику, есть оценка на полную аналитику;
• на весь проект — полностью готова аналитика и дизайн, выдана оценка разработки всего проекта.

• Основная цель: дать понимание, каких затрат потребует реализация текущего видения системы.
• Часы на создание: 8—16.
• Участники: аналитик и разработчики. Дизайнер и тестировщик при необходимости. Контролируется руководителем проекта и согласовывается техническим специалистом.
• Необходимость: обязательный артефакт.

Грубая оценка предполагает разбивку на технологии: бэкенд, фронтенд, мобилки, тестирование, аналитика, дизайн. Каждую технологию оценивает специалист по соответствующей технологии. Поэтому за оценку своей части отвечает соответствующий специалист.

Пример.

Может показаться, что дискавери увеличивает сложность и стоимость всего проекта. Но на самом деле — стало дешевле и проще, мы вынули часть работ по аналитике из разработки и перенесли их в дискавери.

Если смотреть на дискавери глазами заказчика, то дискавери помогает:

• заложить в требования ожидаемый срок и бюджет разработки, чтобы адаптировать проект под возможности заказчика;
• легче планировать бюджет и планы, потому что оценка разработки после проектирования опирается на факты, а не на фантазии отдела предпродажных работ;
• сформулировать замкнутый бизнес-процесс;
• сразу протестировать на конечных пользователях и собрать первый фидбек.

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

Наши показатели тоже изменились.

Положительные

• Повысили процент попадания в бюджет и ожидания заказчика.
• Подняли среднюю продолжительность проекта в три раза. Не в том смысле, что стали растягивать время, а начали смело брать проекты от 3000 часов. Дискавери отчасти ещё валидирует клиента на серьёзность намерений.
• Увеличили количество рекурентных клиентов.

«Не положительные»

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