Исследование компании / процесса / продукта …

Для чего проводить исследование?

Существует несколько сценариев, в которых вам может потребоваться исследование текущего состояния:

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

Общая структура исследования

Общая минимальная структура состоит из следующих этапов:

• Подготовительная работа;
• Сбор информации;
• Анализ собранной информации;
• Подготовка результатов;
• Презентация результатов;
• Сбор обратной связи.

Разберем каждый из этапов подробнее.

Подготовительная работа

На этой стадии закладывается основной фундамент будущего успешного исследования. Шаги этого этапа включают в себя, но не ограничиваются следующим набором:

• Сбор информации о клиенте;
• Согласование условий исследования;
• Формализация отношений;
• Формирование команды исследования;
• Запрос документов у заказчика;
• Формирование календарного плана проведения исследования.

Каждый из шагов включает в себя ряд задач, большинство из которых выполняются последовательно.

Сбор информации о клиенте

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

• Определить сферу деятельности компании;
• Получить описание продукта или сервиса;
• Ознакомиться с публичной информацией о компании;
• Определить технологический стек, используемый в компании (если потребуется исследовать технологическую составляющую);
• Договориться с клиентом, какую информацию он может предоставить до начала исследования, например:
  • Текущие проблемы / боли, которые видит клиент;
  • Реальная и формальная структура;
  • Архитектура;
  • Структура бэклога;
  • Жизненный цикл процесса;
  • Стратегия компании;
  • 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)

Заключение

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

• Индустрия;
• Заказчик;
• Тип исследования;
• Исследуемые практики;
• Оценка по итогам обратной связи.

Для себя я еще записываю свои впечатления, ощущения и что можно было бы сделать иначе, если бы я проводил это исследование еще раз.

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