Если время – это новая валюта, то скорость принятия решений и эффективность работы становятся ключевыми факторами успеха в IT. В аналитике же делегирование задач приобретает особую значимость. Однако простое распределение задач может привести к множеству проблем, если не учитывать специфику работы каждого специалиста и контекст проекта.
В статье бизнес-архитектор Nexign Егор Вершинин рассмотрит, как правильно подготовиться к этому процессу, особенно в условиях жестких сроков и параллельных задач. Его фреймворк поможет выстроить технологию дизайна под конкретный проект, учитывая уровень специалистов и временные рамки. Проверим подход на нескольких примерах по эффективному распределению задач между аналитиками. Надеемся, что этот инструмент станет полезен и вам для оптимизации рабочих процессов и повышения общей продуктивности команды.
Статья получилась большая, поэтому можно сразу сориентироваться по плану:
предпосылки и типичные проблемы в командах аналитиков;
подготовка к делегированию или масштабированию задач;
шаблоны для описания артефактов;
технология дизайна;
план внедрения технологии дизайна;
распределение артефактов по ролям в команде.
Предпосылки кейса: что и кому поручить?
Когда в команду приходит молодой специалист, важно соблюсти два правила:
задача должна быть интересной, чтобы сотрудник увлекся;
нужно минимизировать риски ошибок, которые повлияют на качество создаваемого решения.
Первая поучительная история
Мы разрабатывали продукт SFA (Sales Force Automation) для автоматизации продаж корпоративным клиентам. Вышли в продакшн, и поток требований сразу вырос. Поскольку у нас была небольшая команда, решили привлечь джуна. Поручили новобранцу формализовывать документацию, которая накопилась за долгое время. Все получилось отлично: быстро, качественно. Человек вовлекся и изучил предметную область.
Дали задачу посложнее: нужно было разработать постановку на процесс согласования нетиповых договоров. Здесь новому сотруднику текущих знаний и погружения в контекст не хватило, самостоятельно завершить задачу он не смог.
Вторая поучительная история
Наша команда создавала операционный инструмент для BSS-решения, разворачиваемого в «облаке». Данный инструмент на основании ключевых метрик «здоровья» и визуализации зависимостей микросервисов друг от друга позволял выявлять корневые проблемы в решении при возникновении эксплуатационных инцидентов.
Подключили мидл-аналитика и поручили ему описать Error Codes для внешнего API согласно принятому в компании гайду. Аналитик не смог справиться с задачей в указанный срок. Причина была в том, что он:
недостаточно хорошо разбирался в системном анализе и не смог сформировать общую картину;
не знал, каким образом возникают ошибки;
не смог их мэтчить с пользовательскими сценариями работы с инструментом;
не понимал, в каком формате все это описывать.
Третья поучительная история
В одном большом проекте внедрения постоянно плыли сроки. Работала команда из 30+ аналитиков и 10 архитекторов. Заказчик постоянно менял требования, что приводило к перепроектированию дизайна решения. Изменение одного требования могло влиять на несколько Use-кейсов в их текущей нарезке и связанных с ними функциональных и интеграционных спецификаций на реализацию.
Необходимо было изменить и формализовать процесс проектирования, чтобы минимизировать импакт от изменения требований и свести результат проектирования к конкретному набору согласуемых артефактов (с типовыми трудозатратами на подготовку и согласование каждого артефакта). Так появилась первая версия технологии дизайна и проектирования решения, про которую далее и расскажу.
Делегирование или масштабирование задач на несколько аналитиков: как подготовиться
Какой общий комментарий к ситуациям выше мог бы быть от сотрудников: много информации, не хватает опыта, много стресса.
Далее расскажу о конкретных шагах, которые помогут избеж��ть ошибок в постановке задач.
Первым делом необходимо декомпозировать вашу систему (CRM, ERP, HRM и т.п.) на слои и элементы, которые будем создавать или изменять при появлении новых требований. В общем случае автоматизируемую систему можно разделить на слои:
FrontEnd;
API;
BackEnd;
DataBase.
Каждый слой может быть представлен определенным набором элементов, на которые будут влиять новые требования. Например, FrontEnd описывается экранными формами, виджетами и т.д. Слой API может быть представлен в виде бизнес-объектов с их атрибутами и API-функциями, реализующими управление этими бизнес-объектами.
Каждый элемент системы описывается своим шаблоном или документом — спецификацией. Каждый новый бизнес-процесс или каждое новое требование реализуется через создание новых или доработку существующих элементов на слоях системы. Даже простое добавление одного нового текстового атрибута «Комментарий» для бизнес-объекта «Клиент» в CRM-системе будет декомпозироваться на:
изменения экранной формы на FrontEnd;
доработку API-функций, реализующих CRUD над бизнес-объектом «Клиент»;
доработку структур хранения в базе данных для значений нового атрибута.
Вторым шагом рекомендую создать шаблоны артефактов для элементов.
Чтобы зафиксировать все эти изменения, нам необходимо определиться, в каком формате мы описываем их и для какой группы заинтересованных лиц. В этом нам поможет понятие «артефакта» — описание экземпляра элемента системы, выполненное по конкретному шаблону и ориентированное на конкретную группу стейкхолдеров. Разберем детальнее на конкретных примерах:
По итогам анализа требований заказчика принято решение ввести в систему CRM новый бизнес-объект «Связанное лицо» для клиента. Его наличие позволит фиксировать в связи с клиентом иные лица: контактное лицо, доверенное лицо, руководитель клиента ЮЛ, информация о которых необходима сотруднику, ведущему продажу клиенту с использованием CRM-системы.
Если мы говорим с заказчиком, то обсуждать появление объекта «Связанное лицо» мы будем в формате: определение термина «Связанное лицо» (артефакт 1), примеры связанных лиц для конкретного клиента (артефакт 2), какие ключевые идентификационные атрибуты будут у экземпляра «Связанного лица». Все эти требования для заказчика могут быть оформлены в виде артефакта 3: «Модель предметной области».
При обсуждении с разработчиками системы нам понадобится другое представление бизнес-объекта системы: в виде логической модели или UML-диаграммы классов (артефакт 3), на базе которой будет спроектирована API-спецификация.
Другой пример — нужно представить UI-форму в виде различных артефактов. С одной стороны, у нас всегда есть бизнес-метрика (артефакт 1). Мы должны понимать, сколько времени у нас занимает поиск клиента, с какой вероятностью введенный критерий поиска позволяет ему найти нужный объект.
У нас есть типовой UX-паттерн или концепт (артефакт 2) того, как строится форма (в зависимости от задачи: одна строка поиска, либо набор предопределенных критериев поиска). Нам нужно показать конечному пользователю, как будет выглядеть поиск в виде перехода по макетам (артефакт 3 – Sketch-flow). А если мы говорим про разработчика, то ему нужны будут детальные макеты (артефакт 4) и UI-спецификации (артефакт 5), где будут четко описаны атрибуты, UI-формы, параметры входа/выхода API.
Шаблоны для описания артефактов: как сделать по уму
При создании шаблона необходимо учитывать:
степень неопределенности требования (задачи);
требуемую заинтересованному лицу степень детализации;
способ представления информации (текст, диаграмма, таблица, макет);
роль заинтересованного лица, являющегося потребителем документа с элементами системы (бизнес-заказчик, разработчик, тестировщик и т.д.).
Представьте, вы подготовили детальнейшую UI-спецификацию на 50 листов. Она дает разработчику четкое понимание, что надо сделать, чтобы доработать UI-формы CRM-системы по работе с бизнес-объектом «Клиент». Данный документ вы отдаете заказчику на согласование. Его первая реакция будет — «Уберите это подальше и оставьте мне для согласования только макеты, иллюстрирующие поведение системы».
Приступаем к наведению порядка:
1. Объединим артефакты в документы.
Нам нужно договориться, какие артефакты в какой документ объединяются, чтобы удовлетворить потребность заинтересованного лица на определенном этапе производственного процесса. UI-спецификация для разработчиков содержит один набор разделов, ориентированных уже на техническое описание UI-формы с маппингом на API-функции и логическую модель. Шаблон, в котором мы фиксируем бизнес-требования для автоматизируемого бизнес-сценария, напротив, чаще содержит картинки и диаграммы.
2. Выстроим цепочку создаваемых артефактов и документов.
Здесь замешаны различные архитектурные практики, в том числе TOGAF. Первое, что мы делаем, — разбиваем на слои систему, с которой работаем. Второе — мы должны определиться, с какими группами заинтересованных лиц будем работать (в контексте решаемого проекта).
Дальше определяем группы стейкхолдеров и каждый элемент системы декомпозируем на группы заинтересованных лиц: с кем предстоит взаимодействовать, чтобы согласовывать требования. Создаем спецификацию на реализацию для дальнейшего переиспользования. Результат данного упражнения визуализирован на картинке ниже. По горизонтали расположены слои системы, по вертикали — группы заинтересованных лиц, в ячейках — необходимые артефакты.
Теперь все новые требования, в том числе уровня «реализовать новый бизнес-процесс», можно декомпозировать с помощью фреймворка на необходимые для создания документы и артефакты:
3. Сформируем правила распределения артефактов между ролями.
Важно, что в нашей технологии дизайна подготовку различных артефактов мы поручаем сотрудникам с определенным уровнем квалификации. Представьте, что мы делаем большую бизнес-систему, у нас много бизнес- и системных аналитиков, и нам нужно распределить между ними задачи. Логика распределения артефактов: от максимальной неопределенности — к конкретным согласованным спецификациям. От сложных и комплексных активностей — к простым и детерминированным задачам. Например, диаграмму бизнес-сценария и модель его предметной области необходимо поручать senior-аналитикам, а младшему специалисту — зафиксировать реестр нотификаций, отправляемых в ходе исполнения сценария в системе.
Как использовать технологию дизайна?
Вариант первый: вы создаете новый продукт, вам нужно автоматизировать группу бизнес-процессов. На входе есть их список. Далее вы на примере одного бизнес-процесса с помощью технологии дизайна определяете, какие минимально необходимые артефакты вы создаете, в какие документы их агрегируете, чтобы согласовать с той или иной группой заинтересованных лиц. Важно при этом учитывать, какого уровня силы у вас сотрудники. Если у вас на начальном этапе проекта есть достаточное количество senior-специалистов, то можно пренебречь детализацией спецификаций на реализацию и, например, доверить проектирование API-спецификаций разработчикам.
Другой вариант: от концепций и абстракции — к конкретным элементам системы. Что это означает? Например, диаграмма и описание бизнес-процесса «Управление клиентом» в CRM задает фундамент. Через его моделирование можно определить, какие бизнес-объекты и операции по ним необходимо реализовать в системе. Например, автоматизировать работу по сущностям: клиент, продажа, заказ, продукт в заказе. Это уровень концепции и абстракции. Чем ниже спускаемся по слоям описания нашей системы, тем больше становится конкретики. Чтобы все заработало как надо, необходимо сконфигурировать в системе справочники: типы клиентов, с которыми мы работаем, типы каналов продаж, доступные продуктовые предложения и т.д.
Какая роль какой артефакт готовит
Чем выше уровень неопределенности, тем более высокая квалификация нужна, чтобы подготовить артефакт. При создании продукта на уровне бизнес-процессов, моделей, предметной области работают сеньоры. Они определяют, что конкретно мы будем делать, границы системы, интеграционные точки с другими внешними системами, в какой оптимальной последовательности необходимо реализовывать Use Cases, на которые мы нарезали автоматизируемые бизнес-процессы. Мидл по описанию Use Case и диаграмме бизнес-сценария сможет хорошо выделить перечень операций, которые нужно в системе добавить или изменить. Джун спокойно опишет справочники, внесет изменения в существующую функцию API.
Ниже реальный пример фреймворка проекта, который длился больше 3 лет, и над которым работали 30 аналитиков и 10 архитекторов только на стороне вендора решения. Единицей работ являлся бизнес-сценарий. Примерами таких сценариев были: согласование коммерческого предложения, работа с оборудованием при выполнении продажи, проведение регулярного биллинга и т.д.
По каждому бизнес-сценарию собирались бизнес-требования, готовился end-to-end flow в виде BPMN-диаграммы, варианты выполнения бизнес-сценария декомпозировались на Use Cases. Каждый Use Case, согласно своему описанию, визуализировался в виде скетчей. Далее все эти артефакты объединялись в документ уровня HLD (High Level Design) по каждому бизнес-сценарию, он согласовывался с представителями бизнеса и IT-заказчика, в нем ставились отметки о согласовании, и можно было уходить на детальное проектирование и реализацию.
После этого системные аналитики по каждому Use Case выполняли проектирование детальной спецификации на реализацию. В этот документ уровня LLD (Low Level Design) в отдельных артефактах фиксировали необходимые изменения в объектную модель, проектировали UI- и API- спецификации, описывали значения справочников. Все аналитики при проектировании HLD и LLD были распределены по четырем бизнес-доменам: продажи, обслуживание, биллинг и работа с продуктами и вели работы параллельно друг другу.
Когда аналитики разбиты по ролям, в зону неопределенности и взаимодействия с бизнес-заказчиком мы ставили бизнес-аналитиков. У них были максимально прокачанные коммуникационные навыки, они умели расположить к себе заказчика, скрупулезно зафиксировать его требования в режиме онлайн. Когда дизайн был подписан, системные аналитики декомпозировали все эти требования на конкретные изменения в элементах системы и контролировали, что разработка возьмет все в реализацию в нужную итерацию.
Если мы создаем новую продуктовую линейку, то концепцию решения по фреймворку должны создавать архитекторы. Им нужно зафиксировать набор архитектурных паттернов, как коллекцию «строительных блоков», из которых будет собираться система, чтобы их не изобретали в ходе дизайна и не дублировали функциональность.
Например, в Enterprise-решениях можно использовать паттерн «Единое окно». Ни один из backend-компонентов не имеет своего UI. В решении есть отдельный компонент, который реализует UI ко всем компонентам, в которые он «ходит» через композитное API. Или другой паттерн Catalog-Driven для BSS решений в телекоме. В таких решениях есть мастер-компонент, в который ты заводишь все справочники и все продуктовые предложения. При заведении и публикации нового справочника или продуктового предложения запускается процесс «разливки» его проекций по всем компонентам р��шения, и тем самым сокращается time-to-market на запуск новых продуктов у оператора связи.
Как внедрить технологию дизайна и проектирования решений за 5 шагов
В первую очередь нужно определить ответственного за данный подход. На практике это может быть главный архитектор или главный аналитик в больших командах.
Выбрать самый простой документ, ориентированный, например, на разработку, и определить минимальный перечень элементов системы, который вы в него положите. Начинать лучше с UI-спецификации.
В обязательном порядке разработать шаблоны артефактов документа с учетом требований стейкхолдеров.
Согласовать формат документа на конкретном примере с заинтересованными лицами.
Опробовать весь рабочий процесс на нескольких единицах работ (проектирование и реализация бизнес-требования) и уже затем масштабировать на всю команду.
Резюмируем кратко
Делите систему на элементы.
Используйте разные представления описания одного и того же элемента системы для разных заинтересованных лиц.
Разные представления — разные шаблоны артефактов.
Объединяйте артефакты в документы, выстраивайте оптимальную последовательность создания документов используя фреймворк технологии дизайна.
Распределяйте подготовку разных артефактов по разным ролям с необходимой квалификацией.
Как руководитель или сеньор-аналитик используйте фреймворк для масштабирования работ (разные сотрудники, роли, разные документы).
Вместо заключения
В моей практике с помощью этой технологии я развивал порядка 50 аналитиков в разных компаниях. И когда есть четкость, ясность и определенность, происходит быстрый карьерный рост от джунов до мидлов и сеньоров. Этот интервал с классических 5 лет сокращался до 2-3 лет.
Берите на заметку!
