Куда мы направляем наше внимание, там и выстреливает. Гос организациям часто не хватает умения атаковать задачу, и поэтому они ищут людей с коммерческим видением.

А последние попадают в неподготовленную почту и сбегают обратно, на волю, или выгорают.

Продуктовый подход – это ячейка целеустремленности в гос управлении.

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

Зачастую уровень процессной зрелости компаний отстает от общего уровня развития технологий, а также и от потребностей бизнеса. Иными словами, часто существует «наследие» в виде процессов, завязанных на конкретного человека или исполняющихся только потому, что исполнители знают, что конкретно требуется делать.

Почему нельзя сохранить медленные процессы? Потому что медленные процессы — это медленная реакция на запросы рынка, на изменения ситуации, а значит более быстрая и гибкая компания успеет предложить потребителям те же самые услуги, но быстрее, возможно, с меньшим качеством, но без ожидания.

Главный посыл, что в условиях рыночной экономики выживают наиболее быстрые и адаптивные игроки.

Как правило, осознание этих аспектов влечет за собой трансформацию бизнес‑модели, и модели управления. Зачем к нему подключают подразделение ИТ?

ИТ — это в первую очередь про оптимизацию и ускорение через автоматизацию.

Приходится коренным образом перестраивать бизнес‑процессы так, чтобы они становились по‑настоящему «цифровыми».

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

Недавно к нам обращались от Уполномоченного по Правам Человека, которая в день получает тысячи обращений в виде мейлов, звонков, рукописных записок, зачастую трудно читаемых.

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

Одно техническое задание требовало вовлечение 5 сотрудников разной квалификации в течение трех месяцев.

Похожая проблема наблюдалась пару лет назад в Россельхозбанке.

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

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

Продуктовая команда — занимается развитием и поддержкой определенного продукта и обычно состоит из набора:

· владелец продукта — отвечает за продукт, контролирует метрики, приоритизирует задачи, проводит внешние коммуникации;

· проджект-менеджер — контролирует работу команды, совместно с экспертами проводит декомпозицию задач и планирование, распределяет нагрузку;

· скрам-мастер — отвечает за эффективность команды, за соблюдение регламентов, трекинг выполнения работ над продуктом;

· бизнес аналитик — выполняет анализ данных вокруг продукта, генерирует гипотезы, рассчитывает эффект, анализирует документацию;

· системный аналитик — отвечает за связь бизнеса и разработки, описывает задачи для разработки, проектирует решения;

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

· технический лидер (архитектор решений) — проектирует архитектуру сервисов и приложений, отвечает за технические решения в команде;

· разработчики (dev, ds, de и т.д.) — специализированная разработка согласно экспертизе;

· тестировщики — тестирование сервисов, приложений, составных частей продукта.

Возможны также роли: сейл-менеджер, аккаунт-менеджеры, дизайнеры, девопсы и др.

Не существует единого, оптимального состава продуктовой команды. Состав определяется характером продукта, возможностями компании и принятой в компании типичной структуры команды.

Итак, продуктовый подход — это организация бизнеса вокруг продукта, его ценностного предложения.

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

Для того, чтобы облегчить поиск и соединение функционала, пользуются канвой.

Канва помогает нам упаковать всю информацию о продукте, его ценностном предложении и бизнесе, построенном вокруг него, в одном кратком документе.

(К слову, если продукт — автомобиль, то ценностное предложение можно сформулировать либо как владение собственным автомобилем, либо как услугу передвижения).

Канва опирается на бизнес-модель Остервальдера и представляет собой таблицу из 9 блоков, которые заполняются в определенном порядке, а читается слева направо сверху вниз:

Блок №1. Определяем целевую аудиторию

Блок №2. Проблема и альтернативные решения

Блок №3. Уникальная ценность продукта

Блок №4. Как продукт решит проблемы

Блок №5. Способы продвижения

Блок №6. Как продукт принесет доход

Блок №7. На что тратим деньги

Блок №8. Ключевые показатели

Блок №9. Скрытое преимущество

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

Только тогда можно быстро и оперативно решать поставленные задачи.

Перед тем, как начинать работу, продуктовую команду нужно обучить и сплотить и желательно отключить их от иной работы, чтобы не деформировать целевые установки.

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

#продуктовыподход #продуктоваякоманда #leancanvas #госуправление