Исследование компании / процесса / продукта …
Обратил внимание, что на эту тему очень мало материалов в сети и решил в общих чертах поделиться, как мы проводим комплексное исследование под задачи заказчика.
Для чего проводить исследование?
Существует несколько сценариев, в которых вам может потребоваться исследование текущего состояния:
- Сложный запрос на изменения, например продуктовая трансформация большого периметра;
- Отсутствие четкого запроса на изменения, например все медленно, но почему — непонятно;
- Вы пришли в новую для себя компанию, и вам нужно быстро разобраться, как там все устроено;
- Нужно сформировать карту обучения сотрудников и для этого определить, каких компетенций и навыков сейчас не хватает;
- Произошло поглощение компании, и нужно разобраться, как интегрировать разнородные процессы и системы двух компаний;
- Необходимо подготовить бизнес к продаже, а для этого разобраться, в каких процессах следует навести порядок, чтобы поднять его стоимость и обеспечить возможность передачи покупателю;
- Необходимо максимально раскрыть неопределенность перед грядущими изменениями для всех сотрудников компании, чтобы снизить уровень сопротивления;
- Посмотреть на компанию или команду под новым углом и найти точки роста.
Общая структура исследования
Общая минимальная структура состоит из следующих этапов:
- Подготовительная работа;
- Сбор информации;
- Анализ собранной информации;
- Подготовка результатов;
- Презентация результатов;
- Сбор обратной связи.
Разберем каждый из этапов подробнее.
Подготовительная работа
На этой стадии закладывается основной фундамент будущего успешного исследования. Шаги этого этапа включают в себя, но не ограничиваются следующим набором:
- Сбор информации о клиенте;
- Согласование условий исследования;
- Формализация отношений;
- Формирование команды исследования;
- Запрос документов у заказчика;
- Формирование календарного плана проведения исследования.
Каждый из шагов включает в себя ряд задач, большинство из которых выполняются последовательно.
Сбор информации о клиенте
На первую встречу с клиентом нужно приходить подготовленным, а значит, вам потребуется как минимум:
- Определить сферу деятельности компании;
- Получить описание продукта или сервиса;
- Ознакомиться с публичной информацией о компании;
- Определить технологический стек, используемый в компании (если потребуется исследовать технологическую составляющую);
- Договориться с клиентом, какую информацию он может предоставить до начала исследования, например:
- Текущие проблемы / боли, которые видит клиент;
- Реальная и формальная структура;
- Архитектура;
- Структура бэклога;
- Жизненный цикл процесса;
- Стратегия компании;
- HR-стратегия.
- Посмотреть отзывы о продукте компании в appstore/…;
- Поискать информацию на сайтах отзывов.
На этом этапе уже можно сформулировать первые гипотезы о триггерах к изменениям, чтобы понять реальные потребности бизнеса.
Согласование условий исследования
Если удалось собрать достаточно данные, то первая встреча должна пройти продуктивно. Вы сможете сравнить собранную информацию с тем, что рассказывает клиент и сразу задать вопросы для проверки базовых гипотез.
Основные задачи этого этапа:
- Определить цели исследований и связать их с целями компании;
- Договориться о целях изменений;
- Установить границы исследования, причем не только в рамках скоупа, но и за его пределами;
- Определить критерии успеха исследования;
- Провести интервью с целью формулировки изначальных гипотез совместно с заказчиком;
- Договориться об итогах исследования.
Пример критериев успеха одного из исследований:
— Определены пробелы в архитектуре приложения
— Проведена функциональная декомпозиция приложения
— Определена стратегия повторного использования функциональных блоков
— Определены существующие функциональные блоки, от использования которых можно отказаться
— Зафиксирован выявленный в процессе исследования технический долг
— Отрисованы потоки данных на схеме, которую можно впоследствии дополнять
— Определены и описаны несоответствия бизнес-требований бизнес-модели
— Зафиксированы расхождения бизнес-модели и реализованных модулей
— Сформированы рекомендации по целевому процессу работы стрима разработки
— Сформированы рекомендации по текущей команде и предполагаемому составу стрима разработки
— Составлен план реализации/исправления модулей на ближайшие 6 месяцев
Результатом этого этапа будет сформированный общий контекст, после чего можно переходить к формализации отношений.
Формализация отношений
Тут все просто:
- Отправляем коммерческое предложение с программой исследования;
- Оформляем договор;
- Подписываем NDA;
- Если требуется, подписываем гарантийное письмо;
- Если начать нужно очень быстро, то подписываем письмо о намерениях.
В идеале на выходе из этого этапа получена предоплата, полная или частичная, но ситуации бывают разные. Так или иначе можно продолжать.
Формирование команды исследования
Команда формируется с двух сторон – представители тех, кто проводит исследование, и компании-заказчика.
Со стороны исполнителя это обычно:
- Команда исследователей;
- Привлеченные эксперты с уникальной компетенцией, если требуется;
- Дизайнер при необходимости.
Со стороны заказчика формируем команду координаторов, далее создаем общий телеграм-чат, обмениваемся контактами и определяем ролевой состав участников сессий исследования.
Запрос документов у заказчика
Параллельно с формированием команды исследования необходимо запросить первичную документацию и доступы ко внутренним системам.
Здесь перечень артефактов поистине неисчерпаем, например:
- Организационная структура;
- Штатное расписание;
- Релизная политика;
- Пример бэклога и его элементов;
- Карта бизнес-процессов;
- Описание технологического ландшафта;
- Описание процесса поставки продукта;
- Применяемые требования регуляторов;
- Описание интеграционной архитектуры;
- Описание информационной архитектуры;
- HR-бюджет;
- Стратегия компании;
- План найма;
- Материалы онбординга;
- Результаты опроса вовлеченности;
- ….
К сожалению, не имею возможности предоставить полный перечень с маппингом от целей, так как это закрытая информация, но тут важно учесть три вещи:
- Избыточный список может затянуть исследование.
- Каких-то артефактов может не быть, тогда их подготовку следует заложить непосредственно в исследование – в фазу сбора информации (это привнесет дополнительную пользу в исследование).
- Часть артефактов может быть представлена в неподходящем для дальнейшего применения виде и на приведение их в каноническую форму тоже может потребоваться дополнительное время.
Первая фаза заканчивается формированием календарного плана.
Формирование календарного плана проведения исследования
Задачи этого этапа:
- Разработать программу проведения аудита;
- Уведомить участников о готовности программы и подтвердить даты;
- Подготовить первоначальные гипотезы;
- Подготовить проверочные списки проведения исследования;
- Подготовить открывающий митинг;
- Согласовать дату итоговой презентации для руководителей/заказчиков;
- Согласовать дату итоговой презентации для всех.
Обратите внимание, что для каждой встречи должна быть указана цель и результаты, а если потребуется и примеры. Иначе люди будут идти в неопределенность, а это может в большинстве случаев порождать отрицательный настрой.
Например:
Разработка карты потока создания ценности.
Цели:
— Визуализировать поток работ для различных типов рабочих элементов (новая функциональность, инцидент, дефект, архитектурное изменение)
— Определить ключевые метрики по этапам работ
— Выявить существующие проблемы в потоке создания ценности
Результат:
— Определена цель существования команды/сервиса
— Определены источники поступления работы в команду
— Определены основные внутренние и внешние источники неудовлетворенности
— Определены типы поступающей в команду работы
— Определены интенсивность поступления, природа потребности и ожидания заказчиков по времени выполнения рабочих элементов
— Построена карта потока создания ценности для основных кластеров рабочих элементов
На этом заканчивается этап подготовительной работы и начинается фаза сбора информации.
Сбор информации
Это самая вариативная фаза, так как ее состав полностью определяется предыдущим этапом. Типовой процесс состоит из следующих элементов:
- Массовые опросы;
- Анализ организационной структуры;
- Исследование бизнес-модели;
- Исследование модели процесса;
- Исследование модели требований;
- Исследование архитектуры.
Массовые опросы позволяют собрать максимальный объем первоначальное информации в единицу времени. Например, можно разослать по всей компании Nokia Agile Test или опросник на основе модели DASA.

Анализ организационной структуры
Здесь мы смотрим, есть ли разрыв в коммуникациях и зависимости при работе над продуктом. Важно понимать, что у любой компании есть три структуры — неформальная, формальная и структура потока ценности. Но и формальная часто не совпадает с реальной. Поэтому рекомендуется опираться не только на формальную структуру, но и составить структуру со слов участников исследования, а в дальнейшем наложить на нее структуру потока создания ценности.
Здесь мы можем узнать, например:
- Доступность (процент выделенности) людей в команде;
- Наполненность команд.
Исследование бизнес-модели
Бизнес-модель продукта – это принятые решения в том числе по внешним контрагентам для интеграции, метафоре системы, high-level требованиям, горизонту планирования, портрету пользователя, бюджетам на разработку, ключевым рискам.
Типовой практикой описания бизнес-модели является Business Model Canvas от Александра Остервальдера.
Полезными практиками этого этапа могут быть:
- Распределение продуктов по кривой жизненного цикла продуктов;
- Интервью с целью выявления главных рисков бизнес-заказчиков;
- Построение модели Unit-экономики;
- Определение стиля руководства;
- Определение горизонта планирования на уровне всего бизнеса.
Исследование модели процесса
Процессная модель (методология) разработки – это ключевые решения по паттернам работы с неопределенностью, структуре стрима разработки, структуре команд(ы) и ее декомпозиции по фичам, самоорганизации, формализации, паттернам совместной работы над кодом, отчетности.

Процесс можно исследовать со всех сторон и как угодно:
- Провести STATIK;
- Создать VSM и подсветить проблемные зоны;
- Big Picture / Process Event Storming;
- Собрать информацию из систем контроля версий;
- Провести анализ логов CI/CD-инструментов;
- Провести анализ процессов CI/CD в командах разработки;
- Провести анализ структуры коммуникаций в Slack;
- Провести анализ процесса работы с Confluence;
- Исследовать процесс поддержки пользователей;
- Определить связь процессов с оргструктурой;
- Определить задержки из-за зависимостей;
- Анализ вероятностных характеристик рабочего потока;
- ….
Исследование модели требований
Модель требований к системе – это описание пользователей, видение (метафора) продукта, описание функциональных границ системы, сценарии использования, внешние и внутренние атрибуты качества, необходимые интеграции.
Здесь можно:
- Провести аудит бэклога;
- Посмотреть пример задач в бэклоге;
- Построить структуру бэклога;
- Собрать описание пользователей (персоны);
- Собрать описание функциональных границ продукта;
- Описать процесс работы с бэклогом;
- Описать процесс проверки гипотез.
Исследование архитектуры
Модель дизайна (архитектура) системы – это ключевые решения по приоритетам точек зрения на систему и по выбору паттернов: структурной декомпозиции системы, дизайну алгоритмов, физической реализации, интеграции.
На этом этапе мы можем:
- Провести интервью с архитекторами/техлидами;
- Построить диаграмму контекста и выявить риски;
- Построить диаграмму контейнеров и выявить риски;
- Построить диаграмму компонентов и выявить риски;
- Изучить существующие точки зрения на архитектуру;
- Собрать внутренние и внешние атрибуты качества, сформулировать фитнес-функцию;
- Изучить технологический стек;
- Выявить подходы к расширению ключевых систем;
- Провести интервью с целью выявления главных рисков разработки;
- Выявить уровень вариативности в ключевых системах;
- Провести анализ атрибутов качества, архитектурно-значимых требований, архитектурных принципов и ограничений;
- Провести анализ существующего процесса работы над архитектурой.

Теперь у нас на руках достаточно данных, чтобы провести анализ всей полученной информации. Очень важно, что вы должны заранее понимать, как будете ее увязывать вместе, иначе вы просто получите набор разрозненных фактов, в которых легко запутаться. Структура дает возможность сразу соединять различные точки полученных через отдельные практики знаний и прояснять общую картину, а не просто складывать данные рядом.
Анализ полученной информации
В рамках этой фазы мы получаем список проблем и определяем их приоритет.
В процессе анализа полезным может оказаться:
- Найти различия в ответах разных людей на одни и те же вопросы по итогам интервью;
- Проверить критичность проблемы с помощью вопросов: «Когда такое случалось в последний раз?», «Что вы пробовали, чтобы это исправить?»;
- Сопоставить словари: что такое «медленно» с точки зрения разработки и бизнеса?;
- Выявить самые медленные типы задач на пиках распределения;
- Найти системную причину аномалий в распределении Lead Time;
- Помедитировать 🙂
- Подготовить описание проекта по созданию целевой системы;
- Построить характеристику жизненного цикла целевой системы;
- Дать характеристику используемых технологий, описать результаты их применения;
- Выбрать инструменты автоматизации для реализации согласованного процесса;
- Отобрать бенчмарки.
- ….
Как можно было заметить, чем ближе мы к завершению, тем выше неопределенность в составе практик, и именно поэтому так важно на самом первом этапе провести хорошую подготовительную работу. Иначе на этапе анализа может оказаться, что не хватает каких-то критически важных данных или непонятно, как их использовать.
Презентация результатов
Презентация результатов тоже раскладывается на несколько этапов:
- Создание итогового отчета и/или презентации;
- Проведение итоговой презентации, чаще всего в двух вариантах: на всех и для заказчиков;
- Сбор обратной связи от участников, например в формате F4P (fitness for purpose)

Заключение
После завершения исследования имеет смысл положить результат и все сырые данные в общую базу знаний и проставить теги для простой навигации, например, это могут быть:
- Индустрия;
- Заказчик;
- Тип исследования;
- Исследуемые практики;
- Оценка по итогам обратной связи.
Для себя я еще записываю свои впечатления, ощущения и что можно было бы сделать иначе, если бы я проводил это исследование еще раз.
Надеюсь, эта информация была для вас полезной и интересной. В процессе подготовки статьи я поделился с коллегой, что пишу ее, и он предложил мне подумать про небольшую книгу, ведь у меня действительно очень много информации, а в интернете найти достойный контент на эту тему почти невозможно. Идея показалась дельной, поэтому, думаю, небольшая книга не за горами.

Доклад Сергея Григоренко на конференции OKR Russia 19 апреля 2023 года. История о том, как внедряли OKR в компании 12STOREEZ и внедряют до сих пор, о препятствиях, с которыми столкнулась команда, как их преодолевала и какие уроки из этого вынесла.

Третья статья проекта «Инструменты OKR» об инструменте Value Stream Mapping, который отличным и наглядным способом помогает изобразить шаги, которые необходимы, чтобы потребность людей превратилась в продукт или услугу.

Вторая статья проекта «Инструменты OKR». Инструмент Unit-экономика, который помогает построить бизнес-модель существующего продукта или услуги вашей компании и определить показатели, на которые вы можете повлиять.