Софья Петаева
Руководитель отдела системного анализа
Привет, Хабр!
Меня зовут Софья Петаева, я руковожу отделом системного анализа. Уже почти 10 лет в этой теме, и за это время я научилась не только смотреть на результат работы аналитиков, но и понимать, как они его добиваются. В последнее время мне часто приходится организовывать аналитиков и придумывать новые процессы. Это и помогло мне лучше понять их работу.
В этой статье я расскажу о Discovery-фазе, о том, какие ошибки мы сделали, на каких граблях потанцевали, и как эти уроки до сих пор влияют на нашу работу и принятие решений.
Введение
Для начала давайте определимся с основным понятием этой статьи. Что же такое я имею в виду, когда говорю “Discovery”? Вряд ли речь о телеканале.
Из всех определений мне ближе всего это:
Discovery-фаза — это первый обязательный этап разработки, на котором выявляются требования, анализируются бизнес-цели, формируется техническое предложение, фиксируются границы проекта и оценивается объем дальнейших работ.
Обобщим и структурируем:
Discovery-фаза — это этап, на котором:
Формируется предложение по технической реализации
Фиксируются границы проекта
Дается оценка стоимости и сроков реализации
Эти три элемента — предложение, границы и оценка — являются ключевыми результатами discovery.
В заказной разработке, где клиенты часто приходят лишь с общими идеями и проблемами, эта фаза становится критически важной для успеха проекта.
Опыт реализации discovery-фаз: уроки на ошибках
Discovery — это не волшебная таблетка. Это инструмент. И как любой инструмент, он работает только если:
а) вы знаете, как им пользоваться;
б) не пытаетесь забить гвозди микроскопом;
в) не отдаёте его в руки тому, кто впервые видит гвоздь.
Ниже — два кейса из моей практики.
Кейс 1: Маркетплейс для торгового центра
Обратился клиент с уже готовым бизнесом и даже с отработанной тестовой площадкой, где он уже убедился - потребность в цифровой платформе точно есть. Огромное количество идей, высокий уровень притязаний, уверенность в успехе - это то, как можно охарактеризовать настрой заказчика на этом этапе.
Что мы сделали хорошо:
Собрали потребности и "боли" клиента;
Постоянно общались с заказчиком, активно вовлекали его в работу;
Сформировали сильную команда (2 аналитика (middle+senior), архитектор, UX-дизайнер)
Заложили риски в оценку (180 часов - этого оказалось маловато, но об этом ниже)
Какие возникли проблемы:
Команда не понимала, что такое discovery на практике - ведь мы никогда раньше с этим инструментом не сталкивались;
На выходе ожидания заказчика не совсем совпали с результатами;
Затрачено в 1,7 раз больше времени (300+ часов вместо 180).
Результат: Хорошо детализированные требования и чёткие границы продукта. Заказчик, несмотря на проблемы, продолжил сотрудничество с нами на фазе реализации.
Кейс 2: Приложение для настройки умного дома
Технически грамотный заказчик с инженерным мышлением обратился за реализацией приложения. Он чётко понимал все технологии, протоколы и методологии - гораздо лучше, чем мы. Вполне ожидаемо, что мы провалились по всем фронтам. Вспоминать стыдно, но очень поучительно.
Какие именно ошибки мы допустили:
Не была выделена команда, на discovery работал только один junior-аналитик;
Ввиду того, что заказчик и аналитик говорили совершенно на разных языках, детализировать требования до нужного уровня так и не удалось;
Совсем не проработали этапность реализации;
Разработчики посмотрели на полученные артефакты и… не смогли дать оценку на их основе.
Результат: Потеря заказчика. Я бы на его месте тоже не осталась с таким подрядчиком.
Выводы и структуризация работы
Из полученного опыта сформировались ключевые принципы:
Один аналитик не справится с discovery-фазой — нужна командная работа экспертов.
Каждое решение должно фиксироваться и согласовываться с заказчиком. Просто поговорить - хорошо, но где окажутся эти договорённости в критический момент?
У каждого решения должен быть ответственный за его принятие и исполнение. Такая простая истина, казалось бы, но всё же - фиксируем.
Необходимо постоянное управление ожиданиями и рисками. Не “когда клюнет”, а заблаговременно.
Результат 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. Нефункциональные требования
Необходимо, если:
Проектируем высоконагруженную / международную / мультиязычную систему
Есть существенные качественные ограничения со стороны законодательства / регламентов
Используется для:
Сбора бизнес-правил
Определения требований к:
производительности
серверной части
безопасности
локализации
Например:
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-фаза перестала быть событием вида "терра инкогнита" и стала управляемым процессом с предсказуемым результатом. Еще раз вспомним ключевые факторы успеха:
Командная работа экспертов;
Строгая фиксация и отслеживание выполнения договоренностей;
Назначение ответственного за каждое решение;
Управление ожиданиями и рисками;
Четкий и понятный для всех результат этапа.
Такой подход позволяет уже на берегу разобраться в сроках и стоимости работ, отвечая на самый страшный вопрос заказчика: "Сколько это будет стоить и когда будет готово?".
Благодарю всех за внимание к теме. Надеюсь, эта статья поможет вам структурировать вашу работу и найти свои ответы на вопросы “как”, “когда” и “зачем”.
Больше полезного по системному анализу — в нашем ИТ-сообществе. Мы делимся экспертизой через бесплатные вебинары, организуем конференции, проводим опросы и создаем среду для профессионального общения. Подписывайтесь, чтобы быть в курсе всех событий и не упустить ничего важного. До встречи внутри!
