Рубрика развивается при поддержке

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

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

В закладки

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

Что такое дискавери-фаза и зачем она нужна

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

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

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

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

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

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

Кто участвует

Роли

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

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

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

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

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

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

Как проходит

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

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

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

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

Mind Map

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

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

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

В центре карты — проект. Ветки — основные эпики проекта,крупные разделы и модули

User story

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

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

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

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

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

Диаграмма BPMN

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

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

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

Объединив user stories и BPMN получаем понятное представление процесса c точки зрения пользователя

Wireframes

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

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

Мы создаём Wireframe монохромными, так как на этом этапе «красота» не главное

Нефункциональные требования

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

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

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

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

Request-Response модель

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

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

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

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

Дизайн-концепт

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

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

Инвестигирование узких мест

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

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

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

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

Презентация

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

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

Кликабельный Invision-прототип

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

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

План проекта

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

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

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

Грубая оценка на разработку

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

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

Эффект

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

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

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

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

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

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

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Sergey Kolomenkin", "author_type": "self", "tags": [], "comments": 0, "likes": 15, "favorites": 19, "is_advertisement": false, "subsite_label": "dev", "id": 74412, "is_wide": true, "is_ugc": true, "date": "Tue, 09 Jul 2019 08:43:54 +0300", "is_special": false }
Выделенные серверы
Готовы к работе за 120 секунд
0
{ "id": 74412, "author_id": 66947, "diff_limit": 1000, "urls": {"diff":"\/comments\/74412\/get","add":"\/comments\/74412\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/74412"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 235819, "last_count_and_date": null }
Комментариев нет
Популярные
По порядку
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }