Фреймворк проектиро- вания социо-технических систем

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

Примеры грамотно сформулированных бизнес-целей, с которыми можно начинать работу:

1. Увеличить чистую прибыль на 1 млн. рублей через 6 месяцев после запуска продукта.
2. В 2 раза увеличить индекс Удовлетворенности пользователей через год после запуска продукта.
3. Захватить 15% рынка партнёрских сетей через 4 месяца после запуска продукта.

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

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

Карта гипотез

Цели и стратегии описываются Картой гипотез. Результат выглядит как диаграмма связей. В корне карты — цели, ветки — пути достижения целей через субъекты и гипотезы:

Результаты этапа

Заказчик и разработчики:

1. понимают зачем создается IT-продукт;
2. принимают бизнес-цели и готовы взяться за их достижение;
3. понимают стратегию достижения результата и приоритеты;
4. понимают критерии успешности IT-продукта;

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

Карта процесса-опыта

  ·  ·  · Обозначение на схеме И  Примеры

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

Условия переходов из одного состояния в другое Пример: Подошел срок сдачи отчетности, поэтому нужно написать своему бухгалтеру задачу

Препятствия и барьеры, которые мешают пользователям Пример: Сall-центр не готов принимать звонки ночью, поэтому клиент остается без помощи до утра

Артефакты, которые образуются в результате взаимодействия с IT‑продуктом Пример: Cформированный файл, отправленное письмо

Результаты этапа

1. Целостное видение IT-продукта.
2. Точки входа, точки выхода и переходы пользователей.
3. Линии жизни действующих лиц и важнейшие точки их взаимодействия друг с другом.
4. «Зашнуровка» всех внутренних процессов в бесшовный внешний опыт в глазах потребителя.

Функции IT-продукта описываются деятельностными историями следующего формата:

Я как... <носитель действия: функциональная роль>
Когда <описание ситуации, контекста или проблемы>
Делаю <описание способа действия>
Чтобы <описание бизнес-ценности>

Например:

Я как корпоративный клиент
Не понимаю в каком состоянии счет и из-за этого ухожу в минус, поэтому
Когда баланс стал критично низким
Останавливаю работу,
Чтобы не терять деньги

или

Я как рекламодатель
Покупаю трафик конкретной тематики, а не всё подряд
Чтобы эффективно использовать бюджет, привлекая целевую аудиторию

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

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

Карта реализации историй

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

Истории на карте разложены по двум осям. Колонки слева направо ориентируют в логика последовательного разворачивания процесса. Слои сверху вниз разворачиваются от замысла к формам его реализации.

С помощью этой карты исполнитель вместе с заказчиком выбирают задачи для ближайшего релиза и оценивают объем работ.

Результаты этапа

1. Описание «чистых», без примесей реализации, функций системы
2. Описание деятельностных историй
3. Описание формы реализации историй
4. Список историй и форм их реализации, взятых на ближайший релиз

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

Для обеспечения гибкости, готовности к изменениям и скорости поставки, выделяем отдельные разрезы архитектуры:

Подбор инструментов ИТ-инфраструктуры

Информационные потоки

Оркестрация бизнес-процесса

Микросервисная архитектура решения

Дорожная карта встраивания архитектуры решения в текущий ландшафт архитектуры предприятия

Результаты этапа

1. Целостное наглядное представление того, как будет работать система и каких трудозатрат в реализации потребует.
   Достигается за счет:
   • спроектированных уровней программной и серверной (облачной) инфраструктуры,
   • верхнеуровневых наглядных схем автоматизируемых бизнес-процессов и информационных потоков,
   • компонентной структуры необходимых к разработке программных элементов и взаимосвязей между ними.
2. Техническое описание в виде схем готовых к передаче в работу ИТ-команде
3. Итерационный план постепенного движения к целевой архитектуре, включающий в себя запуск MVP и последующие релизы продукта

	Цели и стратегия их достижения ПДФ-документ с диаграммой связей по Карте гипотез с комментариями
	Путевая карта пользователя ПДФ-документ с Картой процесса-опыта с комментариями
	Карта реализации историй ПДФ-документ оформлен в виде изображения с комментариями
	ИТ-архитектура ПДФ-документ со схемами и комментариями

Набор из этих документов даёт стратегическое и тактическое понимание IT-продукта. На основе этих документов создается план проекта: цена, срок и объем работ.

Разница между классическим Техническим заданием, написанным заказчиком, и подходом Byndyusoft заключается в активном понимании исполнителем бизнес-целей заказчика.