IT-инфраструктура для бизнеса и творчества

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

В прошлой статье я рассказал, что мы в 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": 19, "favorites": 30, "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 }
(function () { let cdnUrl = `https://specialsf378ef5-a.akamaihd.net/SelectelBranding/images/` let previousArticleNumber = null let currentArticleNumber = 0 let platform = 'Desktop' let articles = [ // { // name: 'camera', // url: `${cdnUrl}CameraCat`, // text: 'умную камеру для\u00A0наблюдения за\u00A0котиками', // link: '1', // num: 3 // }, { name: 'chill', url: `${cdnUrl}ChillCat`, text: 'трекер, который подскажет, когда пора отдохнуть', link: 'https://vc.ru/promo/288561-eye-tracker', num: 1 }, { name: 'cloud', url: `${cdnUrl}CloudCat`, text: 'котика: даёшь ему «пять», а\u00A0он делает бэкап в облако', link: 'https://vc.ru/dev/294799-maneki-neko', num: 2 } ] let buttonCycle = document.querySelector('.button--cycle') let buttonChoose = document.querySelector('.button--choose') let buttonMobile = document.querySelector('.button--mobile') let textField = document.querySelector('.selectel-footer-subtitle') let imageAgent = document.querySelector('.image--agent') let banner = document.querySelector('.selectel-footer') buttonCycle.addEventListener('click', cycleClick) buttonChoose.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) buttonMobile.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) let media = window.matchMedia("(max-width: 570px)") media.addEventListener('change', matchMedia) function matchMedia() { if (media.matches) { platform = 'Mobile' } else { platform = 'Desktop' } update() } matchMedia() function cycleClick(event) { sendEvent(`Promo ${articles[currentArticleNumber].num} Right`, 'Click') if (event) { event.preventDefault() event.stopPropagation() } window.open('https://vc.ru/tag/selectelDIY', '_blank') //cycle(event) } function cycle(event) { // incrementArticleNumber() textField.innerHTML = generatedText() imageAgent.src = articles[currentArticleNumber].url + platform + '.svg?3' imageAgent.setAttribute("class", "") imageAgent.classList.add('image--agent', articles[currentArticleNumber].name) banner.href = articles[currentArticleNumber].link } function update() { banner.href = articles[currentArticleNumber].link imageAgent.src = articles[currentArticleNumber].url + platform + '.svg' textField.innerHTML = generatedText() } function incrementArticleNumber() { previousArticleNumber = currentArticleNumber if (currentArticleNumber >= articles.length - 1) { currentArticleNumber = 0 } else { currentArticleNumber++ } } const sendEvent = (label, action = 'Click') => { const value = `SelectelDIY — loc: Footer — ${label} — ${action}`; if (window.dataLayer !== undefined) { window.dataLayer.push({ event: 'data_event', data_description: value, }); } }; function generatedText() { let defaultText if (platform === 'Desktop') { defaultText = `Мы тут собрали %text%. Хотите научим?` } else { defaultText = `Мы тут собрали %text%.` } return defaultText.replace('%text%', articles[currentArticleNumber].text) } function getRandom(min, max) { min = Math.ceil(min) max = Math.floor(max) return Math.floor(Math.random() * (max - min + 1)) + min } (function create() { currentArticleNumber = getRandom(0, articles.length - 1) cycle() let page = document.querySelector('.page--entry') if (page) { function insertAfter() { let parents = page.querySelectorAll('[data-id="7"]') let referenceNode = parents[0] referenceNode.parentNode.insertBefore(banner, referenceNode.nextSibling); loaded() } setTimeout(() => insertAfter(), 0) } }()) function loaded() { banner.classList.add('loaded') } loadImages([ `${cdnUrl}CameraCatDesktop.svg`, `${cdnUrl}ChillCatDesktop.svg`, `${cdnUrl}CloudCatDesktop.svg`, `${cdnUrl}CameraCatMobile.svg`, `${cdnUrl}ChillCatMobile.svg`, `${cdnUrl}CloudCatMobile.svg?3`, ]) function loadImages(urls) { return Promise.all(urls.map(function (url) { return new Promise(function (resolve) { var img = document.createElement('img'); img.onload = resolve; img.onerror = resolve; img.src = url; }); })); } }())
0
0 комментариев
Популярные
По порядку
Читать все 0 комментариев
Как я умоляю Samsung уже два месяца взять мои 160 000 рублей

11 августа 2021 смотрю презентацию Samsung Galaxy Z Fold3 5G, после чего решаю что надо брать, ибо девайс интересный, а мне давно пора было поменять свой рабочий телефон. OMG, давно я так не ошибался…

1₽ на хорошее дело: как работает Добрая подписка от Альфа-Банка
Вице-премьер Татьяна Голикова предложила ввести нерабочие дни с 30 октября по 7 ноября Статьи редакции

В некоторых регионах — с 23 октября.

«СберАвто» запустил продажу электромобилей Tesla в Москве с доставкой в день заказа Статьи редакции

Электромобили будут стоит от 3,5 млн рублей.

До AI Journey осталось меньше месяца. Рассказываем, что будет на конференции

Совсем скоро стартует AI Journey — международная конференция по искусственному интеллекту и анализу данных. Её проводит Сбер, и в этом году она пройдёт в онлайн-формате. Зарегистрироваться можно уже сейчас, а мы пока расскажем, почему мероприятие будет интересно всем: от учёных до школьников.

«Что вы нам предлагаете. Это всё шарлатанство. Ничего не сработает». Как УБРиР меняет подход к технологиям изнутри
Hashbon Rocket — децентрализованная платформа кросс-блокчейн обмена токенов ERC-20 на BEP-20

История создания платформы Hashbon Rocket от начала запуска до покорения DeFi рынка

В Москве обязали компании перевести на удалёнку 30% сотрудников с 25 октября по 25 февраля Статьи редакции

И всех сотрудников старше 60 лет и страдающих хроническими заболеваниями.

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

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

Мини-автомат с содовой Toys Spirits
Защита интеллектуальной собственности – это защита инвестиций

На «Неделях российского бизнеса» прошел Форум по креативным индустриям и интеллектуальной собственности, где представители власти, бизнеса и институтов развития обсудили проблемы защиты интеллектуальной собственности в России, введения третейских судов и регулирования оборота продуктов, созданных искусственным интеллектом.

null