Привет, Хабр!

Меня зовут Софья Петаева, я руковожу отделом системного анализа. Уже почти 10 лет в этой теме, и за это время я научилась не только смотреть на результат работы аналитиков, но и понимать, как они его добиваются. В последнее время мне часто приходится организовывать аналитиков и придумывать новые процессы. Это и помогло мне лучше понять их работу.

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

Введение

Для начала давайте определимся с основным понятием этой статьи. Что же такое я имею в виду, когда говорю “Discovery”? Вряд ли речь о телеканале.

Из всех определений мне ближе всего это:

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

Обобщим и структурируем:

Discovery-фаза — это этап, на котором:

• Формируется предложение по технической реализации

• Фиксируются границы проекта

• Дается оценка стоимости и сроков реализации

Эти три элемента — предложение, границы и оценка — являются ключевыми результатами discovery.

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

Опыт реализации discovery-фаз: уроки на ошибках

Discovery — это не волшебная таблетка. Это инструмент. И как любой инструмент, он работает только если:

а) вы знаете, как им пользоваться;

б) не пытаетесь забить гвозди микроскопом;

в) не отдаёте его в руки тому, кто впервые видит гвоздь.

Ниже — два кейса из моей практики.

Кейс 1: Маркетплейс для торгового центра

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

Что мы сделали хорошо:

• Собрали потребности и «боли» клиента;

• Постоянно общались с заказчиком, активно вовлекали его в работу;

• Сформировали сильную команда (2 аналитика (middle+senior), архитектор, UX-дизайнер)

• Заложили риски в оценку (180 часов — этого оказалось маловато, но об этом ниже)

Какие возникли проблемы:

• Команда не понимала, что такое discovery на практике — ведь мы никогда раньше с этим инструментом не сталкивались;

• На выходе ожидания заказчика не совсем совпали с результатами;

• Затрачено в 1,7 раз больше времени (300+ часов вместо 180).

Результат: Хорошо детализированные требования и чёткие границы продукта. Заказчик, несмотря на проблемы, продолжил сотрудничество с нами на фазе реализации.

Кейс 2: Приложение для настройки умного дома

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

Какие именно ошибки мы допустили:

• Не была выделена команда, на discovery работал только один  junior-аналитик;

• Ввиду того, что заказчик и аналитик говорили совершенно на разных языках, детализировать требования до нужного уровня так и не удалось;

• Совсем не проработали этапность реализации;

• Разработчики посмотрели на полученные артефакты и… не смогли дать оценку на их основе.

Результат: Потеря заказчика. Я бы на его месте тоже не осталась с таким подрядчиком.

Выводы и структуризация работы

Из полученного опыта сформировались ключевые принципы:

1. Один аналитик не справится с discovery-фазой — нужна командная работа экспертов.

2. Каждое решение должно фиксироваться и согласовываться с заказчиком. Просто поговорить — хорошо, но где окажутся эти договорённости в критический момент?

3. У каждого решения должен быть ответственный за его принятие и исполнение. Такая простая истина, казалось бы, но всё же — фиксируем.

4. Необходимо постоянное управление ожиданиями и рисками. Не “когда клюнет”, а заблаговременно.

5. Результат discovery должен быть четким и предсказуемым для всех участников. И заказчику, и команде должно быть понятно, куда и зачем мы идём.

Структура работ на discovery-фазе

Мы составили полный список артефактов, которые могут получиться на выходе из discovery-фазы. Часть из них — обязательны, формируются всегда. Таких — всего 3. Остальные артефакты зависят от различных факторов. Давайте разберёмся во всём по порядку.

Обязательные работы (для всех проектов):

1. Дебрифинг (Debriefing)

Включает в себя:

• Знакомство и общение с заказчиком;

• Погружение в предметную область;

• Сбор и первичный анализ бизнес-требований;

• Анализ бизнес-правил;

• Фиксация результатов (схемы, майндмэпы, презентации и что угодно ещё, способное отразить собранную информацию).

Пример результатов дебрифинга (здесь и далее большинство примеров носят исключительно характер визуальных иллюстраций, помогающих понять, как это может выглядеть):

2. Определение ролей и вариантов использования

Включает в себя:

• Определение ролевой модели (если есть);

• Выявление подсистем;

• Определение вариантов использования для каждой подсистемы;

• Определение прав доступа;

• Расстановка приоритетов;

• Определение этапности реализации на основе приоритетов..

Визуализация ролей и вариантов использования.

Пример описания ролевой модели:

3. Ограничения, допущения и риски

Включает в себя:

• Определение ограничивающих факторов;

• Выявление возможных рисков;

• Фиксация условий и допущений.

Пример описания ограничений:

Пример описания допущений:

Пример описания рисков:

Опциональные этапы:

4. User Story Mapping (USM)

Необходимо, если:

• Проект планируется развивать по гибкой методологии;

• Не предполагается работа по ГОСТу;

• Нет понимания границ каждого этапа;

• Нет определенности функциональных требований, слишком размытые “хотелки”.

Используется для:

• Определения эпиков;

• Декомпозиции на фичи;

• Генерации идей (при необходимости);

• Расстановки приоритетов;

• Построения дорожной карты реализации.

Пример USM:

5. Моделирование бизнес-процессов

Необходимо, если:

• У заказчика уже реализованы процессы, в которые будет встроена система;

• Есть выраженные боли, нужно выявить потребность в автоматизации или / и интеграции;

• Необходимо точно определить роль системы в бизнес процессах заказчика;

• Большое количество ролей в рамках процесса; 

• Большое количество ограничений и бизнес-правил;

• Высокий уровень специфичности предметной области.

Используется для:

• Анализа существующих процессов;

• Выявления «узких» мест;

• Определения точек автоматизации;

• Определения места системы в бизнес-процессах.

Чаще всего фиксируется в виде BPMN.

6. Модель предметной области

Необходимо, если:

• Много специфичной терминологии;

• Сложные или не типичные связи между сущностями бизнес-системы.

Используется для:

• Семантического анализа предметной области;

• Выявления ключевых сущностей;

• Определения связей между сущностями;

• Построения ER-диаграмм.

Пример концептуальной ER-диаграммы для моделирования предметной области:

7. Карты экранов

Необходимо, если:

• Планируются сложные работы по дизайну (в качестве плана или чек-листа работ для дизайнера).

Используется для:

• Создания списка экранов/страниц;

• Определения иерархии;

• Составления списка обязательных элементов и функций;

• Прототипирования (у нас выполняется дизайнером, но в некоторых командах этим занимаются аналитики).

Пример карты экранов:

8. Концепт архитектуры

Необходимо, если:

• Предполагается создание продукта со сложной (SOA или микросервисной) архитектурой;

• Планируется миграция на SOA или микросервисы;

• Большое количество интеграций (более 5 разноплановых внешних сервисов).

Используется для:

• Определения списка подсистем / внешних систем;

• Определения связей между подсистемами / с внешними системами;

• Выбора сервисов для интеграции;

• Построения архитектурной модели.

Пример концепта архитектуры:

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

Необходимо, если:

• Проектируем высоконагруженную / международную / мультиязычную систему

• Есть существенные качественные ограничения со стороны законодательства / регламентов

Используется для:

• Сбора бизнес-правил

• Определения требований к:

  1. производительности

  2. серверной части

  3. безопасности

  4. локализации

Например:

10. Ключевые сценарии

Необходимо, если:

• Есть уникальные или / и неочевидные сценарии;

• Нужна максимально точная проработка рисков;

• Взаимодействуют более 3 систем и/или ролей в одном сценарии.

Используется для:

• Формализации пошагового выполнения сценариев;

• Описания базового потока;

• Фиксации альтернативных потоков и исключений.

Определяется список из 1-3 ключевых сценариев, которые необходимо описать.

У многих свои подходы и шаблоны к описанию сценариев, приведу кусочек нашего описания для примера.

Ретроспективный анализ

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

Пример для маркетплейса:

• Обязательные работы: 1-3

• Дополнительные: 

  • 5 — Моделирование бизнес-процессов (потому что у Заказчика уже есть готовый бизнес с налаженными бизнес-процессами, нужно понять — как в них будет встроена новая система).

  • 7 — Карта экранов (потому что Заказчик хотел уже на старте получить красивую картинку — это было очень важно для него).

  • 8 — Концепт архитектуры (в процессах было задействовано большое количество систем — здесь и складские системы, и несколько приожений (десктопных, браузерных, мобильных), и системы аналитики и статистики, ну и, конечно, старый добрый эквайринг.

  • 9 — Нефункциональные требования (система уже на старте обещает быть высоконагруженной, заказчик сам объяснял, что приложение, написанное “на коленке” для обкатки гипотезы, совсем не справлялось с нагрузкой — очень важно сразу предусмотреть высокие нагрузки).

• Оценка вышеуказанных работ: 312 человеко-часов

• По факту было затрачено: 311 человеко-часов

Пример для приложения умного дома:

• Обязательные работы: 1-3

• Дополнительные: 

  • 4 — User story mapping (заказчик очень хорошо понимал, по каким протоколам должно работать приложение, но ясной картины функциональности предоставить в первых беседах не смог)

  • 6 — Модель предметной области (большое количество специфической терминологии и неочевидных связей, модель предметной области помогла бы нам найти общий язык с заказчиком)

  • 9 — Нефункциональные требования (явно была озвучена потребность работы с определенными заказчиком технологиями, системами и протоколами, это также требует анализа).

• Оценка: 180 человеко-часов

• Фактически затратили 115 часов одного аналитика и получили нулевой результат.

Заключение

Для нас discovery-фаза перестала быть событием вида «терра инкогнита» и стала управляемым процессом с предсказуемым результатом. Еще раз вспомним ключевые факторы успеха:

1. Командная работа экспертов;

2. Строгая фиксация и отслеживание выполнения договоренностей;

3. Назначение ответственного за каждое решение;

4. Управление ожиданиями и рисками;

5. Четкий и понятный для всех результат этапа.

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

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

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